Function Block and STRUCT data format

rpax45

Member
Join Date
Oct 2019
Location
Ireland
Posts
3
Hi, just wondering if I could get some advice when setting up function blocks (Currently using Siemens S7) using a STRUCT data format.

Say I was coding a FB for a valve with some Inputs and some Outputs for that valve. Is it best to combine all the Inputs and Outputs etc under the same STRUCT and add to the function block as a VAR_IN_OUT parameter (STRUCT declared as a VAR_IN_OUT)? Or do you create 2 STRUCTs, one for Inputs and one for Outputs and add as VAR_IN and VAR_OUT to the block call (STRUCT for inputs declared as a VAR_IN and STRUCT for outputs as a VAR_OUT). Is there any other better way to do this?. Hope the above makes sense.

Appreciate any help with this or pointing me to another thread if already discussed.

Thanks
 
I don't like to have that approach of putting structs as inputs because you'll have to map them into structs and if someone wants to see the valve state, they won't be able to online.

In your case, I think separate Inputs and Outputs are definitely a better visualization option.
What I use a struct for is to transmit data to and from the HMI. So the block has the field inputs and outputs and a struct where I group all the data to be communicated to HMI/SCADA.
 
Thanks for the reply Cardosocea

I don't normally use STRUCT myself but though it maybe handy grouping an object data nice and neatly together.

So would the normal practice be to create a DB with STRUCT Inputs and a separate DB for STRUCT Outputs when there is many valves, motors etc?. To be honest I'am trying to learn Structure text and how to work with large amounts of data or data for a large number of objects. By the looks of it, laying out the initial data seems to be the key to this .. although I could be wrong.

Thanks again ..
 
The FB inputs/outputs group the valve data already - assuming the valve controls are from individual bits etc. If the valve is a field bus device then a struct (a UDT would be better) would make more sense.
 
You are correct, laying out the correct structure at the beginning is key. I'd recommend UDTs over simple structures whenever possible, especially for the newer 1200/1500 PLCs.

Remember that when using an FB, the inputs and outputs are all stored in the instance DB, so you may not need a separate DB to stage all the info.

I generally recommend that inputs/outputs that would most likely need to be monitored (change often/control state of machine/etc) should stay separate. It can make sense to lump things that are changed only rarely into a big UDT to pass in as an INOUT. If you are passing a UDT, at least for the new PLCs, you ALWAYS want to do it as an INOUT. There is a certain number of inputs or outputs at which point the block starts looking kludge, but it can be a matter of personal style: one person might think that 10 is too many, whereas someone else might think 30 is ok. Once you get over your threshold, it starts making sense to group things into UDTs.

In the 1500s, you can mark parameters as optional; I forget exactly what the checkbox is. This means that the FB interface gets a down arrow where you can expand to see EVERYTHING, but otherwise when you call it you only see the minimum that you always require.

Note also that arrays can be passed in as one big chunk, you don't have to pass in arraytag[1], arraytag[2], etc, separately.
 
Just want to say thanks for your replies .. what you said makes sense. I'll have a play around and experiment with the different formats.

Thanks again for the help.
 
In the 1500s, you can mark parameters as optional; I forget exactly what the checkbox is. This means that the FB interface gets a down arrow where you can expand to see EVERYTHING, but otherwise when you call it you only see the minimum that you always require.
Good tip. I did not know that.
Would this not actually provide almost the same functionality as if you placed all command and status variables on individual IN or OUT pins ?

One advantage of grouping the interface data by UDT is that when you make changes to the interface, i.e. to the UDT, it is automatically updated on both sides.
 
Oh I see, it is set in the IDB, not in the FB.
Reading the help for that function, I think it is not what I am after.
I thought that if I had a parameter defined by a UDT, it would allow me to see the content at the data when being online.
It is the opposite, it hides unused IN/OUT pins, which is useful if you have many IN/OUT pins declared by the elementary data types.
 
That feature is available for S7-1200 as well with the three options available for FBs and the last option (Hide if not parameter is assigned) is not available for FCs.
 
I appreciate you raising the question rpax. I struggle with organizing data. Putting everything of importance into a STRUCT is something I have carried with me from Allen Bradley’s UDT types. To me, it’s a way to organize the data into a structure that makes sense and keeps things object oriented. Although, a STRUCT and a UDT are similar but functionally different in some areas. Namely, the option whether to retain the data stored in the struct after warm restart. I would always map physical IO to tags within the STRUCT or UDT but would also store process values within the same STRUCT that would need to be retained.
Naturally, that doesn’t work well. So how do you guys do it?

BTW, I almost exclusively use B&R Automation.
 

Similar Topics

Please see attached file. I need this program in Function Block form but I am totally lost on this. Any help would be appreciated. Thanks!
Replies
8
Views
252
Hi! I am using a TM200CE40T PLC from Schneider to write data over Modbus. I have used Memory words (%MW) before using the Write variable...
Replies
1
Views
510
Hi folks. New to the forum, but been working with PLCs for several years now. Would like some advice on whether you would keep this logic, or...
Replies
9
Views
1,037
Hi Yes, I'm stuck again. Trying to define a Function Block. What I've put in there so far has been a straight copy/paste from the code (and that...
Replies
22
Views
2,627
Hello, We have a startup valve, that has to open on startup etc. We also want to know the flowrate throughe valve. They told me that in previous...
Replies
17
Views
2,703
Back
Top Bottom