You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
Thread Tools Display Modes
Unread November 7th, 2019, 11:18 AM   #1
rpax45
Member
Ireland

rpax45 is offline
 
Join Date: Oct 2019
Location: Ireland
Posts: 3
Function Block and STRUCT data format

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
  Reply With Quote
Unread November 7th, 2019, 11:30 AM   #2
cardosocea
Member
United Kingdom

cardosocea is offline
 
Join Date: Nov 2016
Location: Fields of corn
Posts: 1,466
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.
  Reply With Quote
Unread November 7th, 2019, 12:54 PM   #3
rpax45
Member
Ireland

rpax45 is offline
 
Join Date: Oct 2019
Location: Ireland
Posts: 3
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 ..
  Reply With Quote
Unread November 7th, 2019, 01:55 PM   #4
L D[AR2,P#0.0]
Lifetime Supporting Member
United Kingdom

L D[AR2,P#0.0] is offline
 
Join Date: Nov 2006
Location: UK
Posts: 5,738
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.
__________________
S7-300 to 1500 conversions done - email to s7conversions@hotmail.com
  Reply With Quote
Unread November 7th, 2019, 10:39 PM   #5
mk42
Member
United States

mk42 is offline
 
Join Date: Jun 2013
Location: MI
Posts: 2,238
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.
  Reply With Quote
Unread November 8th, 2019, 04:00 AM   #6
rpax45
Member
Ireland

rpax45 is offline
 
Join Date: Oct 2019
Location: Ireland
Posts: 3
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.
  Reply With Quote
Unread November 8th, 2019, 06:41 AM   #7
JesperMP
Lifetime Supporting Member + Moderator
Denmark

JesperMP is offline
 
JesperMP's Avatar
 
Join Date: Feb 2003
Location: Copenhagen.
Posts: 13,964
Quote:
Originally Posted by mk42 View Post
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.
__________________
Jesper
See my profile interests for Q&A
  Reply With Quote
Unread November 8th, 2019, 08:17 AM   #8
JesperMP
Lifetime Supporting Member + Moderator
Denmark

JesperMP is offline
 
JesperMP's Avatar
 
Join Date: Feb 2003
Location: Copenhagen.
Posts: 13,964
I cant find that setting. I would be grateful if you gave me hint where to look.
__________________
Jesper
See my profile interests for Q&A
  Reply With Quote
Unread November 8th, 2019, 08:39 AM   #9
L D[AR2,P#0.0]
Lifetime Supporting Member
United Kingdom

L D[AR2,P#0.0] is offline
 
Join Date: Nov 2006
Location: UK
Posts: 5,738
Here you go:
Attached Images
File Type: jpg fbo.jpg (129.0 KB, 47 views)
__________________
S7-300 to 1500 conversions done - email to s7conversions@hotmail.com
  Reply With Quote
Unread November 8th, 2019, 08:48 AM   #10
JesperMP
Lifetime Supporting Member + Moderator
Denmark

JesperMP is offline
 
JesperMP's Avatar
 
Join Date: Feb 2003
Location: Copenhagen.
Posts: 13,964
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.
__________________
Jesper
See my profile interests for Q&A
  Reply With Quote
Unread November 8th, 2019, 02:10 PM   #11
kalabdel
Member
Canada

kalabdel is offline
 
Join Date: Feb 2015
Location: Ontario
Posts: 484
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.
  Reply With Quote
Unread November 8th, 2019, 10:17 PM   #12
seth350
Member
United States

seth350 is offline
 
seth350's Avatar
 
Join Date: Jul 2011
Location: Over yonder
Posts: 352
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.
__________________
“Did the Lord say that machines outta take the place of livin’, and what’s the substitute for bread and beans? Do engines get rewarded for their steam?” -John Henry
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Problem with struct data in FC (Simatic) Combo LIVE PLC Questions And Answers 2 August 5th, 2015 12:50 PM
Code Working in PLCsim Not in CPu Berra LIVE PLC Questions And Answers 22 June 10th, 2012 03:33 PM


All times are GMT -5. The time now is 04:31 PM.


.