Change block numbers; keep imported library elements in same range

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.

Ecoleaf

Hi all

To be honest, block numbering it is an absolute pain in the ass for the folks we are coming from many years back to Simotion (being fully used to only write text for all)

Provably by this reason, and having this ancient mind already, block numbering it is a way to have some order into program. In fact while configuring safety administration a block range for automatic block numbering it is to be defined.

In any case, nowadays, seems block numbers tends to be useless or to originate confusion in the way they are implemented.

Besides folders that groups things perfectly, specially nowadays with such amount of libraries available, would be good to fully disappear it,or instead to be possible to have a "default" block range per folder or the possibility to select and re-number blocks into a range, as for S7 or S5 nostalgics like me before Simotion, will help to keep things into order.

 

------------------------------------------------------------------------------------------
Split from Styleguide auto numbering.