Passing parameters by reference

S7-1200/1500 were designed with optimized access as the default.  That means the memory order (endian-ness) is set up for it.  For non-optimized access, memory has to be loaded into temp memory, bytes swapped, acted up, swapped back, and loaded to DB with non-optimized access.  Optimized DBs can all act directly on the memory in the DB.

I'm sure there are other things like memory allocation automatically configured to speed up access and manipulation by various instructions.  It is talked about somewhat in the various manuals, especially in the upgrade manuals as firmware and TIA upgrades happen.

crazyCow

 

Tom B.

The problem was solved by Siemens support. It was caused by mixing optimized and standard FB access. 

Dear experts,

might be a little bit offtopic, but still related to this problem:

can anyone explain or highlight any particular advantage of optimized data access? I can remember only problems with this approach (like OPC access and similar things, this topic problem also), but I see no particular advantage other than saving few bytes and ability to retain individual variables in datablocks.

Or maybe I am missing the point?

And where this standard access vs. optimized access comes into play is if your application needs raw speed, optimized access where appropriate and possible is an obvious advantage.

Since most things that reside, or are used just within the PLC can get along just fine with optimized access, it's when data needs to be brought in or sent out (or made accessible to external devices) that standard/non-optimized access is most useful.

I have to admit to using more non-optimized access DBs than is absolutely necessary, but every so often it pays off when I have to make zero changes to read that odd byte or bit from an MP177PN that does not understand optimized DBs.

crazyCow

 

Tom B.

The problem was solved by Siemens support. It was caused by mixing optimized and standard FB access. 

Dear experts,

might be a little bit offtopic, but still related to this problem:

can anyone explain or highlight any particular advantage of optimized data access? I can remember only problems with this approach (like OPC access and similar things, this topic problem also), but I see no particular advantage other than saving few bytes and ability to retain individual variables in datablocks.

Or maybe I am missing the point?

Tom B.

"However, this does not apply if one of the blocks has the property Optimized access and the other block the property Standard access. Principally, all parameters are then transferred as copies"

Thank you Tom for highlighting this case.
I agree with you that this important piece of information is too easy to overlook.

--

crazyCow

can anyone explain or highlight any particular advantage of optimized data access?

huggy_d1 has highlighted that the access to the "optimized" structure is quicker and not just have a smaller memory footprint. (Focussing on the S7-1x00 range.)

The two trouble areas are indirect addressing and data communication where it is essential for the code to know how the data is structured.

The S7-1x00 code loves to have data in structures (read: UDT) and arrays. Especially the array handling can substitute some of of the indirect addressing one would want to do.

Be warned  - You may be surprised that accessing an array element (runtime defined index) is just marginally better than the traditional indirect addressing. See attached PDF.

It would be interesting to know where "variant" instructions fit in.

There is not much substitute for communication though. This is where I think the warning from Tom plays a role - data being accessed by multiple sources giving unpredictable results. Also.. mixing standard and optimize access have potential processing penalties (see PDF).

crazyCow- I think frankly that your question needs an expanded answer more than said already. Coding only in optimized structures does not seem to be an option to me. Some data processing is just too expensive to execute on optimized structures.

Mixing optimized with standard access needs some understanding of the inner workings to do this optimally. Do we users have enough information at this moment?

w

Since we are only 6 years into the optimized DB, and TIA Portal is still slow and still growing with each revision, I would say we are in too much flux to thing optimized 100% is the way to go for many applications.

If you have a new PLC, HMI, and portal and it talks to nothing else, then optimized 100% might work.  Toss in an S-120 drive, or HBM torque meter, or any host of profibus/profinet applications and you simply must work in the mixed environment to get the most out of your hardware and software.

The "most" I write of relates to speed, robustness (Portal does a lot of work at compile time for optimized processing to help us not make mistakes), and if done right, a certain elegance to the code that can make it much more readable because of the reduced usage of absolute references that convey no meaning without comments.

How does this relate to passing by reference?  Quite a lot actually since there is such a small window of opportunity for optimized access and pass by reference, and only when using UDTs in my mind.

If we set up a UDT and pass that around in a DB symbolic reference, it will not mess around with the internal layout unless we add the odd set of bits/bytes/words around that UDT.  However, everything referenced from the UDT by name is exactly where we think it will be.

But, some instructions will not compile until we make that UDT containing DB non-symbolic.

As we move forward, I see this being a case of TIA Portal symbolic is for those getting into automation, and absolute addressing methods are for those who want to do something more involved and are willing to take on the responsibility of managing the data and pointer usage.

huggy_d1,

Your insight are highly valued.. thank you for sharing.

....

Some observations and thoughts when mentioning UDTs -
The "set in IDB" setting seems to force the standard access on the specific variable. From the the AT overlay is possible in a otherwise optimized data structure. Or is this simply forcing the variable onto a byte border to be accessible(?).

UDT and variables set to "set in IDB" changes the DB structure to a quasi-optimized structure - right?

Saying the question aloud also puts emphasis on the fact that using UDT / STRUCT is not processing or memory efficient. So if you do not have much memory to play with, then this should be avoided. But yet one is already hampered by the fact that (Siemens) pre-defined functions provided as standard PLC instructions, grabs a lot of memory space because of UDT usage.

I love working with UDT and STRUCT as it puts order to my work. It would be a shame to avoid those for the sake of optimum resource usage. Finding the balance between what the human designer needs to code efficiently and what the machine (PLC) needs to work optimally is key. But we do not always know beforehand which one we should favour before the project starts. Changing your coding style later in the project can be disastrous. A tough toffee to chew on.

....

On the subject of indirect accessing symbolic variables.. I wonder how much memory it will take to keep track of those for the use of "symbolic" pointers. Do we really need to cross that boundary, or can we then just simply do away with PLCs and use PCs? (rhetorical)

....

But please - one step back towards the original topic..
The aim is to create code blocks that can be re-used. You have no control over what the source of the data will be (optimized / standard DB structure) to the IN-OUT parameters for example. The same data may also be edited by an HMI.

How should the parameter definition look like for this re-usable code block to ensure that the data is passed to the code as per reference.. regardless where the data come from?

Or should we apply some other rules to our code to ensure that the HMI and code block does not override each other's attempts to update values? .. the simpler the better.