-
Notifications
You must be signed in to change notification settings - Fork 5
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
Branch | Associated Commits |
---|---|
master | |
D0017A-FC18002 |
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:
- Limit the block comments to the title, abstract and technical information (possibly the functional description, parameters? where do you stop?)
- Begin incorporating the PDF version of the SMDS into the UserDoc area of the project
- 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:
- How are User Docs handled within the Siemens Version Control Interface and VSCode/GitHub?
- It's a lot of PDF data to put on GitHub (shouldn't have PDFs in the repository)
- How do I track the PDF versions and ensure that they're up to date?
- 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.
- 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.
Branch | Associated Commits |
---|---|
master | |
D0017A-FC18002 |
- 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
- FC18002 (Analog output write) create and build
- Add enumerated "STATUS" variable (reflecting opened, closing, starting &c.) to all device types to allow GraphicIO objects to interact better
Branch | Associated Commits |
---|---|
master | |
D0017A-FC18002 |
- 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
The PracticalSeries of Publications — Copyright © 2021 Michael Gledhill
⬆️ Top | [email protected] | PracticalSeries of Publications | PAL website
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
⬇️ End of page |