Skip to content

CaseNotes

mgledhill edited this page Oct 10, 2024 · 9 revisions

PAL Logo showing Wiki Documentation heading

The Engineer's Casenotes

These case notes are intended as a brief points list of current and upcoming items within the PAL software development. In short: notes to myself, a sort of aide-memoire of things I need to do (or at least think about).

It is written in the form of an engineering log book in reverse chronological order (most recent at the top). I know that GitHub provides similar facilities: issues, milestones, actions &c. all of which have their uses. I just wanted something that was a bit more free-flowing and less official. I also wanted something that I could keep in the main repository (on my PC) rather than something that I could only access via GitHub.

This Case Notes file was created on May 8th, 2024.

Michael Gledhill Chester — May 2024



0005 — ENGINEER'S LOG      

Branch Associated Commits
master
D0017A-FC18002

Thoughts

I'm beginning to think it may be better to rely on PDFs for block comments rather than transcribing the full extent of the SMDS into the block comment fields. The conversion process is taking a long time (longer than it takes to write the block in the first place) and it is difficult to keep the comments up to date with any SMDS changes.

It's a bit of a bastard. I've noticed it now because I'm re-working the anaglog read blocks to incorporate the UT/DB00801/802/851/852 constants and I'm effectively having to modify the same document twice (firstly the SMDS in Word and secondly the comment fields in the module in TIA Portal) and this seems daft. Better I think to modify the SMDS, convert it to a PDF and put it in the User Doc area of the TIA Portal project.

The comment fields are a right pain in the arse, especially the tables, it takes ages to get everything lined up (I've also noticed that any scaling introduced on 4K/5K monitors screws the spacing up); again, the UserDoc route seems to be the way to go. That said, I do like having all the information available in the comment fields, it appeals to my engineering conservatism — it means the block information is always there and can't be stripped out of the project. Hmmm.

So my idea is this:

  1. Limit the block comments to the title, abstract and technical information (possibly the functional description, parameters? where do you stop?)
  2. Begin incorporating the PDF version of the SMDS into the UserDoc area of the project
  3. Change the SMDS PDF documents available via the website to use the same filename as the UserDoc PDFs (for consistency)

It leads to some problems though:

  1. How are User Docs handled within the Siemens Version Control Interface and VSCode/GitHub?
  2. It's a lot of PDF data to put on GitHub (shouldn't have PDFs in the repository)
  3. How do I track the PDF versions and ensure that they're up to date?

Outstanding items

  • FC02001 — change out of range calculation to be based on scaled range rather than raw range (SMDS updated too)
  • FC18001 — change out of range calculation to be based on scaled range rather than raw range
  • Add OVER/UNDER range limits to UT00851
  • Add OVER/UNDER range limits to UT00852
  • Add OVER/UNDER range limits to SMDS DB00851
  • Add OVER/UNDER range limits to SMDS DB00852
  • Modify SMDS FC02001 for OVER/UNDER range limits
  • Modify SMDS FC18001 for OVER/UNDER range limits

Note: Orignally, the out of range was calculated as a function of the RAW range (RAW_MAX-RAW_MIN), the problem with this is that the our of range limits would be different for bipolar/unipolar ranges. Better to calculate the out of range value from the scaled range, this will return the same results irrespective of the raw input type.

My other thought on this is that if the OOR is set too high, it may be beyond the range of the actual RAW input (i.e. outside the numerical range of the analog input itself), I'm not sure how to check this, it depends on the uni/bipolar range of the card itself.

⬆️ Top



0004 — ENGINEER'S LOG      

PAL Website Development


  • Update standard web engine for PAL website (review all CSS/HTML exisiting files and pages)
  • Update Google analytics
  • Add Google programmable search engine to site (all pages in nav bar)
  • Put together landing pages for base website, add links to project documentation and install sitemap and analytic file for Google.

⬆️ Top



0003 — ENGINEER'S LOG      

Branch Associated Commits
master
D0017A-FC18002

Outstanding items

  • UT00851 change USER_DESC to USER_INFO
  • UT00852 change USER_DESC to USER_INFO
  • SMDS for UT00851 change USER_DESC to USER_INFO
  • SMDS for UT00852 change USER_DESC to USER_INFO
  • SMDS for FC02001 change USER_DESC to USER_INFO
  • SMDS for FC18001 change USER_DESC to USER_INFO
  • Update FC18001 (AI read subroutine) with DB00801/851 interface
  • Update FC18001 (AI read subroutine) with comments from revised SMDS
  • Update FC02001 (Inst read and scale) with DB00801/851 interface
  • Update FC02001 (Inst read and scale) with comments from revised SMDS
  • Retest/reissue FC18001
  • Retest/reissue FC02001
  • Write FC18002 AQ Scale SMDS

Outstanding items

  • FC18002 (Analog output write) create and build

⬆️ Top



0002 — ENGINEER'S LOG      

  1. Add enumerated "STATUS" variable (reflecting opened, closing, starting &c.) to all device types to allow GraphicIO objects to interact better

⬆️ Top



0001 — ENGINEER'S LOG      

Branch Associated Commits
master
D0017A-FC18002

Outstanding items

  • UT/DB00800 to be renamed UT/DB00801 (inline with analog input and output subroutines)
  • Write/test runtime AI parameterisation using DB00801 and update SMDS with example code
  • UT/DB00851 (SCALE_VALUE) structure to be developed, common values to be added
  • Update FC02001 (analog instrument read/scale) with DB00801/DB20801 interface


Wiki contents           

Home

     Casenotes

   The licences and other details

       The Licence
       Why did I choose the MIT Licence?
       Permissive licences
       Copyleft licence
       Limiting liabilities
       Which licence to use?
       A note on spelling

1. Introducing the PAL

   1.1.      The approach taken
   1.1.1     The structure of the software
   1.1.2     The standard modules
   1.1.3     The user interface
   1.1.4     Templates and documentation
         Template modules
         Documentation modules
   1.2.      Background to the Project
   1.3.      Regulations and standards
   1.4.      Assumptions and limitations

2. The controller software and structure

   2.1.      Internal structure of the Controllers
   2.1.1     Programmable blocks
         Organisation blocks (OBs)
         Functions (FCs)
         Function blocks (FBs)
   2.1.2     Data storage blocks
         Data blocks (DBs)
         Instance data blocks (iDBs)
         User data types (UDTs)
   2.1.3     Built-in system blocks
   2.1.4     Block numbering and quantities
   2.2.      Execution of Controller software
   2.2.1     Cyclic programme execution

90.  How to build a GitHub Wiki

   90.1.    What are GitHub Wiki pages?
   90.2.    Understanding the Wiki pages
   90.3.    Creating a Wiki for a repository
   90.4.    Cloning a Wiki to a local machine
   90.5.    Basic components of a Wiki
   90.5.1   Title bar and revision
   90.5.2   Contents area
   90.5.3   Listing pages in the order you want
   90.6.    Sidebars and footers
   90.6.1   What are sidebars and footers?
   90.6.2   Create a sidebar or footer in GitHub
   90.6.3   Create a sidebar or footer locally

91.  Imposing a folder structure on a Wiki

   91.1.    The default arrangement
   91.2.    A practical Wiki folder structure
   91.2.1   Page Numbering in the Wiki
   91.2.2   Rules for page numbering
   91.2.2   Subfolder names for Wiki pages
   91.2.3   Page names for Wiki pages
   91.2.4   Storing images and other data

92.  Markdown, GitHub Markdown and HTML

         A note by the Author
         Some useful Markdown sites
   92.1.    An overview of Markdown
   92.2.    How Markdown works
   92.3.    Markdown flavours
   92.3.1   GitHub Flavoured Markdown (GFM)
   92.4.    HTML and Markdown
   92.4.1   HTML with GitHub Markdown
         GFM Blacklisted HTML tags
         GFM Whitelisted HTML tags
         GFM HTML tags — the grey area
         GFM whitelisted HTML attributes
   92.5.    PracticalSeries Markdown

99.  Template
⬇️ End of page
Clone this wiki locally