PHarris

Thank you all very much for your suggestions and contributions, I appreciate you taking the time. I'm continually trying to improve my knowledge on good architecture design for larger applications, so it's really great to hear a variety of different approaches and gain insight from experienced developers.

I'm not familiar with LapDog so I don't know if this is useful, but I've been using the approach shown below. Inside the Fire VI (this application controls a system that fires droplets of ink) you can have a state machine where each iteration of the main while loop executes only a single iteration of the state machine. It's easy to interrupt but because all the actions are inside one VI, it can't be interrupted at the wrong time (as can happen when you queue your states). You could trivially add a "Cleanup" VI that would run on the class stored in the shift register whenever the dequeue did not time out and the previous action was not yet Done.

 

I do use this code for sweeping various parameters. The class hierarchy has a simple Fire action at the top. One child of Fire is Stop. Another child is a Measure class which takes a single measurement. Below that is a Measure with Sweep class that can sweep through various parameters, executing the parent Measure method at each step. When the parent Measure object is Done, the sweep moves to the next parameter.

Thanks ned, this sounds like an interesting approach. Would you be able to post a generic template of the code so I can take a look? 

I'd use normal VI sequencing and dynamically launch it. If you want to stop it just Abort/close the VI. Quite often there will be a "controller" to launch/abort which the rest of the system messages to, effectively making it a module with an API.

Ah yes, I never thought much about dynamic launching. This makes sense. Also, I guess if you don't want to abort the VI and its sequence abruptly, you could always use the 'control value:set' invoke method on the VI reference to send a boolean which causes a clean up case to be entered. Thanks for your help 

It appears that the latter posts of this thread on the QSM (Producer/Consumer) discuss the kind of thing I'm talking about. One more satisfactory solution to using the QSM which was discussed is to ensure you keep the public message queue and internal functions queue separate. This way the QSM can enqueue its own sequence of states internally when a public message is received to tell it to do so. By adding a check for an external interrupt on each iteration of the QSM loop, a sequence can also be interrupted by a public message. This snippet of code from Daklu in that thread shows the kind of thing.

What I'm interested to know is what forum members such as Daklu, who have said they would seek an alternative to the QSM in any scenario, would implement as an alternative to achieve the same functionality? i.e. You need to be able to trigger a sequence to run, but it should also be possible to interrupt it (can't just be subVI'd as it would lock the QMH loop until it completes).

Does the sequence need to change dynamically? If not, then a chain of sub VIs is hard to beat :-)

Thanks for your reply.

The sequence doesn't need to change dynamically, but certain operations have to be looped until a condition is reached (acquire, move local oscillator, acquire, move local oscillator, acquire...). Are you saying to simply place a state machine within a sub VI which will carry out the entire sequence when called? What if I wanted to abort the sequence while it was running? When a QSM is used, the abortion can be ordered by the calling process by adding an abort message to the front of the input queue.

I'm wondering in general now what the best approach would be for a scenario where you have a sequence of operations you wish to "trigger", but still wish to have the option to intervene and cancel once running. Say the sequence is finite but could take a while to complete, you'd need to be able to abort it somehow. The way I've currently been thinking is to have the slave process waiting on an "initiate" message and subsequently enqueue the next stage of the sequence onto its own message queue. The loop would then churn away doing its job until it finishes or receives an abort message which cancels the sequence. This nature of adding messages to the loop's own queue and the potential consequences of performing such actions is what appears to be argued, so I'm trying to gain some insight into the alternative and 'safer' method.

Hi Lava's,

I have an application which I have constructed around Slave loop obects (Daklu's approach) using the Lapdog messaging library, and I'm currently struggling to decide upon the best approach for implementing a sequence of operations. 

The application involves doing some DAQ with a USRP device where by I require it to sweep an entire spectral range and acquire samples for each subset, what would seem standard state machine material. I currently have a slave process/loop named "scanner", which I planned to have sit there and wait for a "start scan" message to be sent to it from the powers that be. Upon receiving this start command, it would need to initialise, acquire, move local oscillator, acquire, move local oscillator, acquire... and so on, until it reaches the end of the range.

Aside from the slave loop using its own input queue to enqueue messages to itself and carry out this sequence, how else could it be approached? I'm asking because I've been reading around for quite some time on the topic of QSMs and I can see they are widely disliked for reasons I can generally appreciate, however, I'm struggling to think about a better way for a slave loop in this scenario to carry out a sequence of operations when instructed. I.e. for a mediating loop to send it the "start scan" command and then for the scanner to return a message via its output queue to say its done and here are the results.

Many thanks in advance for any contributions,

Hi LAVA,

This is my first post since joining the forum, so first of all hello to you all.

It's a bit late really considering I have the exam tomorrow morning, but I did my last two practice exams this week for the ATM and Sprinkler system and thought I'd pop them up to see if anyone has some last minute feedback or wise words. Both are saved for LV 8.6.

I've actually only been using LabVIEW for about 12 months and not as a full time developer, so I probably fall a bit short of the recommended experience, but the opportunity arose and I figured there's no harm in giving it a shot!

Thanks in advance for any feedback or pointers...

CLD Attempts 8.6.zip