S7: Symbolic pointer reference to UDT element

GWB

Member
Join Date
May 2005
Posts
3
Hi all,

I have several FB's which each perform different control functions for a drive unit. There is a large amount of drive data which is shared between the FB's, which is collected into a single UDT, and stored in a shared DB.

Each of the FB's receives this drive data as an IN/OUT parameter. I can then access the data inside the FB as below:

L #DriveData.Speed
T #Speed // a TEMP variable


My problem is:

The size of DriveData is very large. As I understand it, each time the drive data is passed to an FB, it is copied to the FB's instance DB. This creates load on the PLC.

Hence, instead of passing the drive data itself to my FB's, I would like to pass a pointer to it. Using symbolic referencing, how would I then access the values within DriveData (eg. Speed)?

Thanks in advance for any help!

GWB
 
Create the drive structure in the static data area of an FB (using your UDT). You can refer to the elements of the UDT using symbolic addressing in the FB. Set up the instance data block register and AR2 to point to the drive data before calling the FB.
 
It sounds like your problem is that you have a lot of drive data that must be exchanged, and some of them needs to be exchanged cyclically.

How about splitting the data in your DriveData DB into two separate UDTs.
One UDT is for the few cyclical data.
The other UDT is for the larger number of noncyclical data.

You can then call the FB twice, cyclically and noncyclically, passing only the UDT data that is relevant for each call:
DoubleFBcall.GIF
 
Thanks very much for your replies.

Simon, my FB's need to receive various parameters as well as the drivedata udt. These are different for each FB. Is your suggestion still plausible? If so, how do I set up an instance DB and AR1 as you suggest?

Jesper, unfortunately this is a more complicated problem. I am using certain "standard" drive comms blocks both developed in-house and supplied to us by Siemens. These rely on the UDT that I am using. I would be very hesitant to modify them significantly.

I see the pointer solution as a good one: if an FB receives a pointer to the drive data (a structure of UDT type), it should be able to read/write elements of the drive data structure in place. But being new to STL, coding this is proving difficult, especially with symbolic referencing.

Is what I'm trying to do possible?
 
GWB, the principle I was suggesting relies on the fact that a function block uses the instance data block and AR2 to access it's static data area. If you "call" an FB then the instance DB and AR2 are managed for you. If you use "UC" to call the FB, you can set the instance DB and AR2 as you wish. Thus when you reference the static data in the FB, the actual location of the data is set by you. Note that with the "UC" method you cannot enter parameters. There is another thread (created by S7Guy I believe but I can't locate at present) which goes into this method in more detail.
 
GWB, a further thought would be to replicate the whole of your drive DB as static data in the FB. You could then use areas in the DB for providing inputs/outputs using the DB as the interface. It all depends on the flexibility of your drive DB layout, could you make it look like an instance db with the in/out/inout/stat stucture and relocate where your UDT's are in the DB?
 
Thanks for the extra clarification Simon.

I have discovered that my understanding of how a UDT is passed to an FB was wrong. They are not copied to the FB's local data area, but are passed by pointer instead. Hence, the size of the UDT does not have an effect on the size of data copied to the FB's local data area.

This information makes my problem non-existent! However, I have still learnt a lot from your replies so thank you.
 
GWB,
you are right about that UDTs are passed as pointers. I didnt think about that.
It means that my example with passing the two UDT pointers in two calls is meaningless.
However, it may still be a good idea to split the data into cyclical and noncyclical parts.
By having a pointer to both you have more flexibility inside the FC to do what you want.
 
Loading the PLC

From an Empircal point of view, what kind of load are these blocks adding. Have you actually ran tests on how much additional load is being added. How many of these blocks are being called each scan. I wonder if the impact is as great as you might fear.
 

Similar Topics

Can a single MSG_CIPSYMBOLIC function block be set up to write multiple REAL values (setup in an array)? I've read through a lot of help files...
Replies
0
Views
589
I am trying to make a change to a Mitsubishi plc FX3GE program that is running currently in the machine. I do not have a copy of the original...
Replies
4
Views
1,534
I have 2 Micro850 PLCs that I am working on that use MSG_CIPSYMBOLIC blocks to transfer data back and forth. Or at least they were... Basically...
Replies
6
Views
2,332
Sorry if this is a beginner question, and I have looked at the manuals. Seems like a couple of tech notes would answer my question but I don't...
Replies
8
Views
6,330
SOmething I forgot how to do or where the setting is. There is a couple of DBs I have to rename, but when I do I have to rename them individually...
Replies
1
Views
2,264
Back
Top Bottom