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