Passing a large INOUT to FC in S7-300

MorphuisOGrady · May 10, 2012

Hi there,

First project in S7 in many years. I have a large Analog input block I need to convert from CLX to S7. Its very large (660Bytes) but I've managed to cull it back to 250Bytes.

Is there any restrictions on Local memory area of an FC? Would 250bytes be OK?

I want to have a DB containing all my AI's.
Rather than declaring all data as local and copying to and from a DB can I am trying to pass the UDT in as an INOUT.

In my function call I have a parameter I must use in UDT format?What should I use here?

Hope this makes sense

JesperMP · May 10, 2012

Rather than an FC and INOUT, how about an FB and pack as much as possible in the STAT part of the FB.

I have an FB that does all the scaling, filtering, and alarming.
I dont have any other inputs to the FB than an IN that tells the FB how many analog channels to process.

I then load the IDB outside the FB like this.
L PIW256
T "AI".iRaw[0]
L PIW258
T "AI".iRaw[1]
etc.

And I then get a number of scaled values that I can use elsewhere like this.
L "AI".rScaled[0]
L 100.0
+R
etc.

MorphuisOGrady · May 10, 2012

Hi Jesper,

Sounds good, but I really would perfer to keep the format off all other control modules: Valve, DI, DO, AO etc.

I have all the code written and rather than declaring all the data in the local area to match same address format in UDT I would like to pass the UDT in as an IN_OUT.

When I attempt to call the block I have a parameter called AI (INOUT) which is what I have declared as an INOUT inside my FC.

Do you know what I need to enter here?

I have never used an INOUT in Step7 before

JesperMP · May 10, 2012

You can certainly declare an INOUT by a UDT.
When you declare the INOUT in the FC, you specify the data type by the UDT number, i.e. UDT 21. Unfortunately you cannot just write the symbolic name of the UDT when you must specify it.

What happens is that every access inside the FC via the UDT will be by pointer. So it is not the most efficient way to do it, but it will work.

But this pussles me.

Sounds good, but I really would perfer to keep the format off all other control modules: Valve, DI, DO, AO etc.

Are you really programming all objects in FCs, even if they have memory associated to them ?
I think you should start look into FBs. FBs are much more suited to reusable code than FCs.

L D[AR2P#0.0] · May 10, 2012

Example INOUT using UDT attached.

MorphuisOGrady · May 10, 2012

JesperMP said:
You can certainly declare an INOUT by a UDT.
When you declare the INOUT in the FC, you specify the data type by the UDT number, i.e. UDT 21. Unfortunately you cannot just write the symbolic name of the UDT when you must specify it.

What happens is that every access inside the FC via the UDT will be by pointer. So it is not the most efficient way to do it, but it will work.

But this pussles me.
Are you really programming all objects in FCs, even if they have memory associated to them ?
I think you should start look into FBs. FBs are much more suited to reusable code than FCs.

Yep. Thats the way we have always done it. It was a preference for my superiors years ago to have one Shared DB for each data type rather than having an instance DB for each device. The DB is usually huge depending on amount of devices in project.

Is it much more inefficient? It always seemed to work quite well but I'm no Siemens expert.

MorphuisOGrady · May 10, 2012

Block won't download into an s7-314.

Error message is the block/ op.sys update is too large

L D[AR2P#0.0] · May 10, 2012

Copy your blocks to a library and post the zipped archive.

KalleOlsen · May 11, 2012

MorphuisOGrady said:
Yep. Thats the way we have always done it. It was a preference for my superiors years ago to have one Shared DB for each data type rather than having an instance DB for each device. The DB is usually huge depending on amount of devices in project.

Is it much more inefficient? It always seemed to work quite well but I'm no Siemens expert.

Your method could be more efficient regarding the communication to a supervisor system. A few big datablocks versus fragmented data from many instances.

Kalle

bara_hence · May 11, 2012

KalleOlsen said:
Your method could be more efficient regarding the communication to a supervisor system. A few big datablocks versus fragmented data from many instances.

Kalle

Why not using the multiple instance capability for example--

50 fbMotor declared in 1 fbMotors that way you get one DB..

JesperMP · May 11, 2012

It was a preference for my superiors years ago to have one Shared DB for each data type rather than having an instance DB for each device.

I have to say, that is idiotic !!!
This is an arcaic relic from days of yore when PLCs could only work that way. To program that way is analog to using PCs for your everyday office work, but then print out every document and every mail, just because that what one used to do.

One big or a few big DBs for HMI data exchange, yes indeed, and I do that too (for alarms because it has to work that way, and for overall visualisation because it is convenient for the HMI programming). But that does not stop you from programming reusable code in FBs with associated instance DBs.

JesperMP · May 11, 2012

MorphuisOGrady said:
Block won't download into an s7-314.
Error message is the block/ op.sys update is too large

How big MMC have you installed in the 314 ?

In Simatic Manager - right-click on the Blocks folder, open the Object properties, and select the Blocks tab. Here you can see the memory requirement in both load and work memory, and for code and data blocks, and the system data block. That should give you an idea where the problem is.

kamenges · May 11, 2012

I don't mean to take this in a different direction, but I thought that INOUT parameters passed to an FC were by reference. So they shouldn't have an effect on the size of the memory in the temp area of the called FC as all the access is effectively by pointer. Am I mistaken on the INOUT parameters?

Keith

L D[AR2P#0.0] · May 11, 2012

You are correct. However, every access to INOUT variables (of type UDT) requires the complete de-referencing of the pointer which generates a considerable amount of code if there is a lot of references to these variables.

L D[AR2P#0.0] · May 11, 2012

For example, here is an FC coded in STL performing 10 load/transfer operations on a UDT parameter.

Passing a large INOUT to FC in S7-300

MorphuisOGrady

Member

JesperMP

Lifetime Supporting Member + Moderator

MorphuisOGrady

Member

JesperMP

Lifetime Supporting Member + Moderator

L D[AR2P#0.0]

Lifetime Supporting Member

MorphuisOGrady

Member

MorphuisOGrady

Member

L D[AR2P#0.0]

Lifetime Supporting Member

KalleOlsen

Member

bara_hence

Member

JesperMP

Lifetime Supporting Member + Moderator

JesperMP

Lifetime Supporting Member + Moderator

kamenges

Member

L D[AR2P#0.0]

Lifetime Supporting Member

L D[AR2P#0.0]

Lifetime Supporting Member

Similar Topics