LabVIEW
Actuating a Piston With two valves in a cycle
Solved!
Hi GBEN,
@GBEN wrote:
The VI as attached is a simulation for a system I am building on a crio so some things may seem a little off (I am simulating some controls and data in for instance).
Again, appreciate your advice as always.
When using a cRIO you should stay away from "value" property nodes and "value (signalling)" even more!
Why do you use so many property nodes?
Why do you use property nodes even though the terminals are unused in the block diagram?
Why do you need to set button states on a headless (?) cRIO?
How is your user able to switch frontpanel buttons on a headless (?) cRIO?
When you need to keep track of flags/internal states then you should collect that information in a (typedefined) cluster and change the booleans in this cluster.
Btw. you forgot to attach the enum typedefinition!
@GBEN wrote:
Again, appreciate your advice as always.
I agree that this is really bad! There should be no property nodes, especially no signaling value properties, since there are no associated events anyway. What was the logic behind that decision?
You are completely blurring the distinction between controls (data source) and indicators (data sink) by making everything a control (LEDs, switches, etc.), then use them as "variables", bouncing the data around with property nodes. That's now how a highly parallel dataflow language should be used.
All you probably need is a simple state machine containing all controls and indicators, and keeping a cluster of states in a shift register. There should not be any event structure!
To get more specific help:
- attach a runnable version, including the typedefs.
- explain in detail all the functional requirements: what should happen as a function of user interactions and time, and what are all possible states the system can be in.
