Polling Loops vs. Master/Slave Pattern

[Angelo1]

Hello,

I am working on a machine control. I figured out the best way to handle the overall functionality with a Statemachine.

The core functions includes two subsystems controlled by time. So I made a SubVI with parallel loops that were polling the state of the indicators whether to run the subsystem or not.

As I know, polling loops are not best practice, especially since two loops individually poll the same indicators. Then I changed the parallel loops into a Master/Slave design.

That I like very much. Downside, I cannot run the Master/Slave as SubVI, because the Notifiers are killed before they execute, right?

What is the best way to do with this situation? Go back to my parallel polling loops?

Running the Master/Slave and showing it in a Subpanel won't give me the outputs (indicators) and won't let me start/stop it, right?

Thanks for any ideas, or advice!

-Angelo, still Newby ;-)

[Kurt Friday]

Hello,

I am working on a machine control. I figured out the best way to handle the overall functionality with a Statemachine.

The core functions includes two subsystems controlled by time. So I made a SubVI with parallel loops that were polling the state of the indicators whether to run the subsystem or not.

As I know, polling loops are not best practice, especially since two loops individually poll the same indicators. Then I changed the parallel loops into a Master/Slave design.

That I like very much. Downside, I cannot run the Master/Slave as SubVI, because the Notifiers are killed before they execute, right?

What is the best way to do with this situation? Go back to my parallel polling loops?

Running the Master/Slave and showing it in a Subpanel won't give me the outputs (indicators) and won't let me start/stop it, right?

Thanks for any ideas, or advice!

-Angelo, still Newby ;-)

Hi Angelo

Definitely the Master Slave architecture is superior to polling, don't go back.

I don't know why in your case you can't call it as a subvi and display in a subpanel, the Notifier shouldn't be killed, take a look at the attached demo.

MasterSlave.zip

I just built it up from a LabVIEW template in 8.5.

If you need more help post some code up that replicates the issue.

[Angelo1]

Hi Angelo

Definitely the Master Slave architecture is superior to polling, don't go back.

I don't know why in your case you can't call it as a subvi and display in a subpanel, the Notifier shouldn't be killed, take a look at the attached demo.

MasterSlave.zip

I just built it up from a LabVIEW template in 8.5.

If you need more help post some code up that replicates the issue.

Yes, I had the subpanel before. The Examples made it easy for me to get the subpanel and run the VI.

However I did not find a way how to let the VI react to other inputs of my Statemachine (which can change any time).

About my Master/Slave VI:

The Master notifies the slaves depending on elapsed time. The Timer also has a Pause functionality, which will be activated if the user press the pause button or opens a machine door. So I need to be able to give the Master/Slave VI a run/pause input. This was easy with parallel loops, because they are not running until I stop them but rather are controlled by calling them again the next iteration of my Statemachine.

The only way I can think of is to create a LV2 Variable which will be written by the Statemachine and then read by the Master/Slave VI. (wouldn't this be polling again?) And the same procedure for the outputs of the Statemachine, which will determine the next state.

Or is there a simple way of running a VI in a subpanel but at the same time treating the input/outputs in the same way as a SubVI?

Thanks,

Angelo

Edited July 29, 2009 by Angelo1

[Kurt Friday]

Yes, I had the subpanel before. The Examples made it easy for me to get the subpanel and run the VI.

However I did not find a way how to let the VI react to other inputs of my Statemachine (which can change any time).

About my Master/Slave VI:

The Master notifies the slaves depending on elapsed time. The Timer also has a Pause functionality, which will be activated if the user press the pause button or opens a machine door. So I need to be able to give the Master/Slave VI a run/pause input. This was easy with parallel loops, because they are not running until I stop them but rather are controlled by calling them again the next iteration of my Statemachine.

The only way I can think of is to create a LV2 Variable which will be written by the Statemachine and then read by the Master/Slave VI. (wouldn't this be polling again?) And the same procedure for the outputs of the Statemachine, which will determine the next state.

Or is there a simple way of running a VI in a subpanel but at the same time treating the input/outputs in the same way as a SubVI?

Thanks,

Angelo

The best way to do what you want is to use a queue. Input the queue into your Slave by either using the VI Server Control Value Set method or use a named queue, when pause is hit or elapsed time occurs it messages into the Slave. If you use 2 queues queue 1 can message into your slave from master and queue 2 can message into the master from slave.

Have a look at Queue Driven State Machine Architectures.

Another way that might work for your use case is instead of creating and destroying the notifier in the Slave, create it in the Master and give the Slave a reference, that way the Master can message into the Slave.

[Angelo1]

Hi SciWare,

Thank you for all the good hints.

Finally I tried a different approach.

I had three loops in my Master/Slave VI. Every loop I changed into separate SubVI. The previous Master-Loop has in its SubVI version a terminal that indicate a change to the previous iteration/call. (this was the trigger for the notifiers in the Master/Slave design)

The Two previous Slave-Loops are are as SubVIs each in a case structure controlled by the indicator of the Master-SubVI.

In this way I can fully control the Master-SubVI. And the Slave-SubVIs will be only called when it is necessary.

So far it seems that it works alright.

Thanks,

Angelo