Studio 5K: UDTs and Strings as AOI Output Parameters

[JeremyM]

Interesting. To clarify, the limitation is to the AOI type itself, not necessarily a type embedded within the AOI that you read directly?

If I can find a free moment I'll fire up Ignition and do a few test reads in different ways.

The quickest metric I can lend to the discussion is the Class 3 usage % on the Logix webpage during reads.

 

[pturmel]

The AOI variable constructed from that AOI datatype is un-optimizable in Ignition's Logix driver. InOut parameters are never accessible from the AOI's data type, so that is moot. AOI params and locals that are nested are probably optimizable individually. (Not tested.)

 

[Rsflipflop256]

Is it possible to use this AOI method in a guardlogix safety routine?

 

[tlf30]

For the sake of safety logic, I would not use it in a safety routine.
While it is a cool trick. I would be hesitant to use it in production for any application.
That does not mean I do not use it on my bench at home though.
I figure that for production ready logic, especially safety related production ready logic, the code should be VERY easy for someone else to understand and maintain.

EDIT: To clarify, I do not know of a technical reason why it would not work in a safety routine, other than having a negative affect on my sleep to know that somewhere there is a plant that I may step into with this in its SIS.

 

[Rsflipflop256]

I plan to do it in a SIL 2 application where the plc is only safety rated for equipment, not personell, so no gates or mats or any of their pre-canned safety instructions as I am only controlling valves with the program. Its for a once monthly test to cycle the valves 20 times to clear debris and then perform a leak test, not daily production. (Natural gas valve trains is probably another reason for safety rating)

 

[tlf30]

I'll just say, as someone who maintains legacy process safety systems that are exactly as you described (I work in upstream oil&gas though) I would be hesitant to use any "nifty tricks" and would just stick with old-school logic. If an InOut will work, that is what I recommend.

I save the cool tricks for when some crazy messaging logic comes up. That is where stuff like this really is helpful.

Not to say I don't like things like this, I absolutely love them, and I love finding applications for them. I just always am hesitant on anything that is even remotely safety related. Especially if it is not sanctioned by Rockwell. Say the safety system fails and your company goes to court over loss of profits from damaged equipment. Rockwell will be the first to say that the logic does not follow their recommendations for AOIs and that it is not their fault.

 

[Rsflipflop256]

Understood, thanks for the advice, keepin it simple as possible