Standardisation (TIA) with UDT and FC or FB with multiple instance

userxyz

Member
Join Date
May 2002
Location
any
Posts
2,768
Hi,

I have an issue about the choice for FC or FB in my standardisation... 📓

My current standard is:
FC + UDT on a IN/OUT parameter + FACEPLATE.
In a DB Valves for example I add a UDT per Valve and I have in a FC Call Valves all my valves with standard Valve FC with UDT connected via UDT on IN/OUT.

My programs are OOP minded.

UDT.png

Now I want my Alarms also to be integrated in my objects. So I tested Program_Alarm in an OOP way and experienced that it needs an FB to be called in. Problem is, if I want this to be OOP that all my objects sudenly need to be FB's instead of FC's. It kills my standard.

I have for each object (Motor, Valve, etc...) an UDT with a CMD, MEMO and RESULT struct. So if I really need an instance then it's better to change my UDT to CMD + RESULT and integrate it in the instance, the MEMO data elsewhere in the same instance. This way I will change my faceplates that MEMO is not integrated in the UDT anymore.

So calling FB's (objects) in an FB with the multiple instance method is my final method I came up with. The Program_Alarm is configured to use path as alarm and takes the instance of the objects for the alarm creation.

So now yes, alarms are integrated in my objects. And I still have one DB (multiple instance). (y)

But... there is one thing that bothers me...
HMI's controlling data in an instance DB. It has also bin considered not done.
(n)
What are your opnions about this... ?

In the CMD struct there are also HMI bits, wich means that the HMI will control data in a multiple instance... is this okay to do this way ? In wouldn't do this in Simatic, but in TIA ? 👨🏻‍🏫 🙃

Opinions?



PROGRAM ALARM.png
 
Transfer the relevant HMI data to/from a shared DB via an IO pin.

If you are worried that the performance will be hit because the FB will reference the data by pointer, then duplicate the data so you have them both as instance data and as parameters via one or more IO pins. The data should be defined via a UDT.
As the first thing in the FB, you transfer the data from the IO pin to the instance copy, and as the last thing you transfer the data from the instance copy to the IO pin. Between these two transfers, the FB uses the instance data.
Only really necessary of you do a lot of heavy calculations on the data.
 
I think the main concern when externally accessing Instance DBs is that if you change the FB (such as adding in a STAT or IN or OUT or INOUT) then you need to realign the SCADA.

With TIA however I think you can link FB IN, OUT or INOUTs for use in WinCC.
 
Combo,

From my perspective, an FB can do everything an FC can, plus more, with the tradeoff being that the instance is automatically managed vs manually declared (inout to a UDT in a DB somewhere else). For me, the FB instance management is much simpler. You can even have arrays of instances these days. The nitty gritty access details are different between an FC's INOUT and an FB's STAT, but ultimately they do the same thing. You can get into performance issues having huge structures plugged into an IN or OUT of an FB, but I don't think there is much of a performance difference choosing between an INOUT vs STAT.

You can still use the external INOUT data in combination with FBs if you want to. INOUTs are passed by reference, just like they would be in an FC. I've seen this done where the data object needs to get processed by multiple FBs. I suspect that there is a more OOP way to structure things that what happened on that project, but it worked fine. There is plenty of data that can be kept internal as a stat or temp, but if you want, you can keep it all outside via INOUT.

For the HMI interface, I've seen that done both via INOUT and via the internal instance. I wouldn't ever recommend simply accessing random STAT tags, but if you do it in an organized and commented way(like having an HMI structure/data type inside the FB STAT area), then you should stay out of trouble. To me, the risk is having someone look at your code later and not understand where a signal is coming from because the cross reference is a dead end. If things are organized/contained and commented, the risk is minimized. If the HMI writes to any bit in the instance, then it becomes much harder to troubleshoot.
 
Hi

Hi,

Yes, that's a difference, but in a prototype machine with only 1 or 2 HMI's it maybe isn't a big issue.

Second question... If I change my objects to FB's, then I have an instance for each FB in case I call the FB's with an own DB. But I could also call them in an FB with multiple instance... what would be the best here todo ?

Kind regards,
Combo

I think the main concern when externally accessing Instance DBs is that if you change the FB (such as adding in a STAT or IN or OUT or INOUT) then you need to realign the SCADA.

With TIA however I think you can link FB IN, OUT or INOUTs for use in WinCC.
 
Multiple instance link to UDT not possible ???

I cannot link my UDT "Roller Type" that is nested in a multiple instance to my faceplate interfaces anymore when working in multiple instance...

1.png

2.png
 
hmm

It works when the TYPE/UDT is not nested in a Multiple Instance to link to a faceplate... this is far away from OOP again... I think I will need to let Multiple Instance go... I will need an instance DB for each object... kinda stupid...


fffff.png
 
Nahh, I found it...
The UDT that you want to reach needs to be in the stat area instead of In/Out offcourse :)
 
aiaiaiaiai

:unsure::unsure::unsure::unsure::unsure:

I just destroyed TIA I think (y)(y) :ROFLMAO:

I didn't change anything on my HMI side, after messing with the instances in the PLC program, after compiling, 1000 errors, errors in the faceplates ??? while no UDT's changed in the library... weird... o_O :ROFLMAO:

dddddd.png
 
I made a new version of UDT in the library and updated every single faceplate with the new version and released it, compile, zero errors... Must have bin a little bug... anyway, I can do my further tests...
 
It all works

It all works now.

Brzzz, even PROGRAM_ALARM works in an OOP way now.

Now to decide if I want to work like this or not in the near future...

I think I should if I want to grow in an auto code direction (y)

dededede.png
 
Well Done!

As an aside, I think I sometimes forget how much you can test with just PLCSIM and the HMI simulator.
 
Well Done!

As an aside, I think I sometimes forget how much you can test with just PLCSIM and the HMI simulator.

In my past work, I developed in PCS7... Everything was tested on PLCSim and WinCC in the same computer. Even the communication links to other equipment. It is a fantastic tool, although the V15 of it is quite heavy.

Edit: The software was for the control of a mini refinery... so not exactly lite either.
 

Similar Topics

In our production plant we have multiple different networks (subnets). IT dept have setup routing between them so different subnets can...
Replies
0
Views
49
My PLC (S7-1200 with CPU-1212C) has now been delivered to customer site. They've asked me to do some updates to the software. I can do that on my...
Replies
21
Views
327
Does anyone know why the connection interface is greyed out and says why I can only use Teleservice instead of the other options like PN/IE? I am...
Replies
0
Views
44
Hi guys I after a bit of advice on Tia portal graphics, I would like to add a conveyor belt graphic to a hmi and the conveyor in the basic...
Replies
3
Views
130
Hi I used to be able to launch PLCsim without any problem. Now it tells me " STEP 7 Professional Licence is required to simulate this PLC"...
Replies
15
Views
452
Back
Top Bottom