Step7 Pro: How do I propagate UDT changes?

[John Miller]

STEP 7 Professional, V5.4 + SP2, K5.4.2.0_16.6.0.1, K5.4.2.0

Address priority: "Symbol has priority for all accesses (I,Q,M,T,C and DB)" (lower-right choice in tab)

I feel I must be missing something. I have various UDTs defined. Some are used directly in data blocks "derived from UDT". Others are used as members of other structures or used for variables within a function block (i.e accessed via another FB's instance data block.) I don't think it matters which of these ways I might be using; the annoying result seems to be the same.

To use an almost hypothetical example, let's say I'm using D1_Oil_Prog_Parameters (DB606) which has been defined in SIMATIC Manager to be Data Block Derived From UDT606 (JT_Oil_Prog_Parameters).

So I am zooming along in the LAD/FBD/STL editor -- or really, it's more like stumbling around -- and I go to to set a member in this structure. Ooops! I seem to have forgotten to define that member. No problem, I open UDT606 and insert the forgotten member in the prettiest location (usually somewhere in the middle of the structure).

Of course, the newly added member still doesn't show up because I am accessing it via DB606. This is where (this small part of) my trouble starts. What is the best way to update DB606? If I open DB606 in the LAD editor, it notices that UDT606 has changed, ... and so it decides to throw away all the symbol information! (The "DB Param" editor does the same thing.)

The online help has the following workaround for cases including opening a DB that is derived from a modified UDT:
"To Correct or Avoid Error:
Avoid the procedures described above."

The only way that I have figured out to update DB606 is to invoke "Check Block Consistency..." function from SIMATIC Manager, select DB606 and invoke "Compile". At which point, the Consistency Checker comes back and tells me that I have blocks open in the LAD editor and I have to close all of them before the Checker can continue. (Of course, this also seems to mean that I must throw in some dummy value for the structure member I was trying to define, as well as clean up any incomplete networks.)

This procedure seems very drawn-out, annoying, and illogical. Is there no way to tell the LAD editor to "update DB606"?

Am I missing something obvious? Or perhaps something obscure?

Thanks for any tips.

 

[L D[AR2P#0.0]]

If I have to change the interface of any block, (UDT structure or initial value, parameters to a FC/FB etc.), then I always close down all other blocks, and then make the interface change to the given block.
You can the use the consistency checker to re-compile all blocks affected by the interface change. Of course, if you add a parameter to a FB/FC the block calling the changed FB/FC will not compile, you have to open each block and update the block calls and fill in the new parameters.

One thing you can do to minimise the number of consistency checks you have to perform is to create spare elements (BOOLS, INTs, DINTs etc) in your UDT (I also do this for the STAT area in FB's). You can change the name of a declaration without affecting the interface.

 

[Imi'ike]

If you do not want to run the Consistency Check / Re-compile All (perhaps it takes too long), then you can either:
- open the DB in declaration view then click File -> Check and Update Accesses; or
- open the DB in declaration view, right click on the line defining the structure which is also the line just above the one with the * on it, then select Update Declarations from the pop up menu.
Either way, you still need to first close all other blocks and then make the interface change.

 

[Ken M]

Can I re-open the coffin of Software Design vs. Software Coding? If we take a complex program to be a bit like a complex building, is changing UDTs half-way through equivalent to altering the dimensions of the bricks and windows after most of the building has been erected?

Which part of the design was not done correctly? How much time and frustration would be saved during coding if each program element was exhaustively designed and tested in advance? And by this I mean getting someone else to critically analyse your thoughts and results.

Alternatively should we go the way of Extreme Programming: change is inevitable so design your program to absorb and accommodate change? In other words build in lots of spare definitions in every UDT, don't do maths at any level below REAL, use WORDs where BITs might have been used before?

Ken

 

[L D[AR2P#0.0]]

Ken - your UDT/bricks+windows analogy got me thinking. Let's imagine, for example, you elected to use an UDT that just consisted of an integer and is used to represent material length in metres. You use this variable in data blocks, as a parameter to FC/FB's and indeed you (bravely) also decide to use it in another UDT. All is going well and you are performing acceptance tests. Some bright spark comes up with a production run that requires 35,000 metres of material.
Does your whole design have to be demolished and rebuilt brick by brick to fit around the new windows ? Well yes in that the software will have to replaced with something else, but no in that you simply change the UDT to a double integer and re-compile the whole lot. Of course there will be some replacement of >I with >D etc. but that's hardly a rebuilt house !

So, analogy failure for me.

Regards, Simon

 

[S7Guy]

Alternatively should we go the way of Extreme Programming: change is inevitable so design your program to absorb and accommodate change? In other words build in lots of spare definitions in every UDT, don't do maths at any level below REAL, use WORDs where BITs might have been used before?

Well, I agree with the concept that the project should be designed so that changes are easily accomodated, but I wouldn't let it affect my variable types, nor would I build my UDTs with a bunch of spares. It just isn't necessary. There are plenty of free tools out there that now let us build tag lists automatically when addresses change, and most plc platforms let you recompile if you change your structure.

Just this morning I had to add some new variables to one of my UDTs, which affected the address of almost every tag read by the OPC Server, and I didn't give it a second thought. I just added the variables, recompiled, exported my DB to a text file, ran it through a query, and generated a new tag list. It took less than 20 minutes.