8/5/2024 4:52 PM | |
Joined: 7/7/2010 Last visit: 8/14/2024 Posts: 15089 Rating:
|
The only block numbers that matter are (for S7-1200/1500) OB numbers. Cyclic OBs start with 1, then jump to 123 and up (if I recall correctly). The order of OBs solved by the PLC establishes their priority. OB1 is first cyclic OB to execute. Next cyclic OB ≥ 123 executes next. I routinely have a _LastOB (OB # 2000) that I know is the very last OB to execute in every PLC project I do. I put things in there (OB2000) like: measuring PLC logic solve time, scan time, and overhead time. Also, if some bit(s) gets SET or turned ON for a specific purpose _during_ PLC scan (for specific single-scan state capturing) and need reset, OB2000 is where I tend to reset - and at the start of the next PLC scan (in OB1) those bit(s) are OFF. Most of my S7-1200 projects have an empty LastOB (OB2000) unless they also have an HMI or very specialized logic and/or hardware. S7-1500 projects likely have a lot of metrics about the PLCs operation and performance calculations finalized in my OB2000's. For FBs/FCs/DBs, years ago I used to manage the numbers with great care. Now, I tend to only manage a few non-optimized DBs used for communications, which is much easier with more recent TIA Portal versions providing automatic renumbering of blocks if you import them from another portal project and the imported block has the same number as an existing block in the current project. Every so often, when importing non-optimized DBs for comms and associated logic, I run into a situation where I want to keep the original DB numbers and instead renumber the existing (typically -- optimized) DBs. Hopefully that helps you understand how one long-time Portal user interprets and implements the styleguide's guidance. Now, back when I was still managing block numbers, I would create an excel sheet where block numbers were pre-designated for specific Portal groups as well as "global group" blocks (other than OBs). For example, in addition to using the PLC Tag Table -> User Constants for system specific constant tags, I have a global DB named SystemData which contains things system related that the mechanical engineer on the project needs to help define. The PLC Tag Table - User Constants are for me, the Controls Engineer / EE, to create and manage. Things like Motor Rated RPM, Motor Max RPM, Value to send to drive for 100% Speed (via Telegram or analog output), sensor range useful for scaling for HMI or other external system, motor/drive axis numbers, and things that allow the removal of hard-coded constants throughout the PLC logic while also giving the value some real-world meaning. I appreciate your post and thoughts on the style guide and your seeing how times are changing as far as block numbers go. For me, without the need for sending data outside the PLC, blocks need no numbers - except perhaps OBs so we can force PLC scan priorities.
------------------------------------------------------------------------------------------ |
Last edited by: Moderator_Lan at: 08/06/2024 07:27:51New subject after splitting science guy |
|
This contribution was helpful to
1 thankful Users |
Follow us on