Is there any drawback of using "Subvi" or "Local variable"?

[andre.buurman@carya]

How you get 75 different states. Shouldn't you be dividing fucntionality in multiple loops are so.

My SM almost never go beyond 10-15 states each.

Regards,

André

[MogaRaghu]

---

andre.buurman@carya wrote:
How you get 75 different states. Shouldn't you be dividing fucntionality in multiple loops are so.

My SM almost never go beyond 10-15 states each.

---

Let me explain 😞 at least a small part of it ..)

State 1 : Wait for user start command.
State 2 : On Start command, initiate a time out timer and start the belt tension motor.
State 3 : Wait for belt tension motor to reach 1500 rpm.
State 4 : On 1500 rpm, energize belt tension solenoid.
State 5 : Wait for belt tension to reach 200N.
State 6 : On reaching 200 N, switch off belt tension motor.
State 7 : Switch on Main motor.
State 8 : Wait to reach set rpm.
State 9 : Once set rpm is reached, switch on belt tension motor again.
State 10 :Wait for belt tension to reach user set value.
State 11 : On reaching user set value, start solenoid sequencing.
....
.....
..... ( complete the states to switch 4 different speeds and 3 different loads in line with user program )
......
State 74 : Check if elapsed cycles = programmed cycles.
State 75 : If NO, goto State 11. If  YES goto "Terminal State " 100.

Any suggestions for squeezing ? I do know that certain states can be combined ( like State 7 and 8 ) but then there are lot many other things being done and having seperate states helps in clarity.

Regards

Raghunathan

Message Edited by Raghunathan on 08-28-2007 11:04 AM

[andre.buurman@carya]

There where you say repeat for is the reduction in states.

Which leaves at about 10-15 states in the end.

Repeat for 5 speeds
    Repeat for 4 loads
       SM

Regards,

André

[Ben]

It looks like your states 1-10 should be a single state since they run from one to the next with any branching.

RE: State machine design

I try to keep the number of states under about ten myself. While I am in the process of designing the state machine, I often step back and look at what I've drawn up. If I see a single transition into a group of states with a single transition out, I come up with a descriptive name for that group and all of those mini-states, go into a sub-VI for that state. That is where the design step in the development really helps out in the end.

Ben

[johnsold]

States 1, 3, 5, 8, and 10 are all Wait states. Perhaps these could all be a single state with a termination parameter (1500 rpm, 200 N, ...) and a timeout limit.

As Ben said, design of the state machine is key.

Lynn

[altenbach]

---

@Ben wrote:
It looks like your states 1-10 should be a single state since they run from one to the next with any branching.

---

But they could take a long time to execute. To keep a state machine responsive and interruptable at any time, states should be kept short.

The argument can go both ways. 🙂

[Ben]

If they need to be interuptable, pass a control ref into the sub-VI so it can check the stop button.

Generally I keep the GUI sepearte from the state machine that does tha catual work.

To add to my previous post about desgining to keep the number of states small.

In reply #22 of this thread I included the complete design of an application that demonstrates using state machines within state machines.

I hope that helps illustrate,

Ben

[TCPlomp]

OpenG wait with an occurence input?
My wait for change with timeout VIs posted at OpenG?

TOn

[MogaRaghu]

---

@Ben wrote:
I try to keep the number of states under about ten myself.

---

Instead of setting a target on the number of states, I generally allow it to grow as demanded by the system.

The pseudo code snippet that I posted is a small part of the larger picture. Its a complex sequence that does all of the following simultaneously :

- Monitor the health of 9 DIs and halt the machine ( after saving the last valid data to disk ) once every 500ms.
- Acquire, find the mean and populate an array with the results of 8 AI channels once every 50ms.
- Control 3 electric motors, 6 solenoids by DOs once every 50ms.
- Generate ramp up and ramp down signals for two proportional valves and AOs once every 50ms.
- Check the user response for on line plotting and show up those plots on a chart in front panel.
- Verify at the end of every cycle ( lasting 1 sec) if the required milestone cycle  is reached. If yes open a  file with a formatted name and save the waveform of the 8 AIs for the number of user programmed cycles and close the file.
- Verify at the end of every cycle if the required number of programmed cycles are over and update the front panel indicator with details on  time left and cycles to go.
- Once every 500ms log to disk the critical parameters of rig status to the CurrentData file. At the end of every half hour, move the contents of this file to HistoryData and start a fresh CurrentData file.

Then there are special sequences for initilaizing and getting user data from disk into the SM, handling aborted cycles, emergency shut down , normal stop and total machine shutdown. Each of these routines have different kinds of data saving requirements.

And this machine runs 24x7. Many a times ( initially ) I have wondered if LV is the right choice for a job as above - but now this doubt has vanished. Only I need to learn more.

Raghunathan

[andre.buurman@carya]

Hello,

Is all your functinality handled in 1 VI?

Your description would result in multiple parallel operation VI's.

One doing UI handling
One doing AI and AO
One doing DI and DO
One control
Etc.

In that way each parallel task only has a specific function, which is more easily maintained.

And of course there would be the occasional SM when required.

Regards,

André