03-22-2013 12:22 AM
Hi,
I'm designing a control system for a small pilot plant.
I've settled on using Statecharts to code low-level actuator I/O (input sensor readings and instructions, output command signals). However, I'm stumped on how to architect the system as a whole in LabVIEW. I need to support reasonably complex interlock sequences, allowing the safety system to do its thing without blocking unrelated parts of the plant.
e.g. If High-High alarm A triggers, open valve B and close valve C. Wait for condition D to be met, then close valve B and open valve C. In the meantime, valve X is scheduled to open for 5 seconds every 10 minutes as part of normal operations -- it should continue its pattern, without regard for High-High alarm A. In case of High-High alarm Y though, valve X should be immediately opened until condition Z is met.
Does anyone with experience have any tips or resources to share?
Thanks in advance!
Solved! Go to Solution.
03-22-2013 03:40 PM
Hello JKSH,
Looking at your description, valve X should cycle continuously, except when High-High alarm Y occurs. When High-High alarm A triggers, valve X would continue cycling, and valve A and B execute that sequence. If this correct?
Best Regards,
Alina M
03-22-2013 09:33 PM
Hi Alina,
Yes that's correct.
I'll have more groups of actuators actuators than this example, and I'll need to detect if one alarm-handling sequence interferes with another -- if so, the lower-priority one will be interrupted/deferred.
I was thinking of modelling the system as a big state machine, but it seems messy (if not impossible) to handle cases where an actuator can be part of different sequences in a Statechart. Is there a tried-and-true approach to controlling an entire plant using LabVIEW + cRIO?
03-23-2013 11:45 AM
Consider putting the parts of the code which deal with unrelated (more properly: independent) parts of your plant into parallel loops. Those loops can run without interference to each other. Pass messages between the loops as needed via queues.
Look at the Producer/Consumer architecture and Queued Message Handler examples as ideas to get you started. Probably neither of these is entirely suited to your needs in the basic forms, but the concepts are useful. The state machines for various parts of the plant can be implemented within those forms.
Lots of planning in advance of writing code will pay off in terms of reduced need to go back and start over.
Lynn
03-24-2013 04:58 AM