Factoring Code and Instantiating Parallel Processes in subVIs

[AlexA]

Hey James,

Thanks very much for the input! I actually do have a working prototype of the code I'm trying to achieve which was the image I posted a few posts back.I think you're right in that I'm trying to do too much at once, perhaps I should just compress the FIFO read loops into some sub-VI's.

On the subject of queues and passing data around, of course I see the potential for errors if the queues get out of sync. It was just the only way I could think to decouple certain sections of the code so that I could stop them if I didn't want that functionality. I guess it's needless compartmentalisation though, as whenever I want one I'm going to want the other. In any case, you've given me a lot to think about! And at worst, I've learnt a whole lot about Labview that I didn't know existed before!

[AlexA]

Hey Guys,

I'm a pretty stubborn guy, so I couldn't just let the approach I was taking go without tinkering a bit more. It's now working for the funtionality I've implemented, namely, starting and closing an FPGA. Listening to a specific set of FIFOs from said FPGA, and triggering the FPGA to do something. Hopefully it doesn't break too badly. Paths are fixed again and the main vi is actually in the "Scratch Pad" sub folder, it's called "Main Scratch Pad.vi" (though of course you guys won't have the FPGA set up that I do).

Hopefully I've addressed a lot of the concerns you raised James, though there are some nasty cludges, particularly in the handling of the messenger queues while in host (look at the run/stop trigger and similar states).

I still need to implement the functionality of listening to the queue provided by the VI which is listening to the FPGA FIFO and dequeing to display etc. Which as you stated previously James, could be pretty nasty. Hopefully I've addressed that by making the queue itself package all the relevant data from the FPGA listener. So it should just be a matter of dequeuing and processing.

Can you take a look at this and see what fundamental flaws there are in the design?

As I mentioned previously, the one glaring fault that jumps out to me is the handling of the messenger queues. I can't figure out how to encapsulate the queue information (i.e. which queue to use), so that it's obvious to any state that wants to talk to a certain VI exactly which queue it should load its messages on.

Edit: Oh and another thing: I've noticed that my sub-vis running in parallel, when sent the command to run whatever their task is (which takes place in a run state which enqueues itself until a pause command flushes the queue) will constantly flicker between "Idle" and "Action", even though the only thing entering the message queue should be "action". All the VI's reference a sub-vi called "State Manager Sub" which simply enques whatever is input to it and checks for an error, flushing the queue and enqueuing and error state (which in turn calls exit and shuts down the VI). My understanding is that the application should generate a new version of that code for each VI that calls it, but I was suspicious they might somehow be sharing a queue, so I took all the stuff out of State Manager and just put it straight on the BD, no change, I still see the flickering between states. Can anyone tell me what's up?

Edited September 15, 2011 by AlexA

[AlexA]

Ok, further thoughts. I've seen Daklu say around this forum that letting a message handler enque to itself is dangerous. So I've tryed to change the architecture of the parallel process VI's (not in the latest zip file) to be a bit of a compromise. The only state that's allowed to enque to itself now is the action state. The problem is, this doesn't seem to play nice with the FPGA. Arggh, it would be nice if there was a simple bug in the code linked above which explained the state flickering.

[AlexA]

Update:

I understand why the states are unstable. The fact that idle can enque itself combined with the fact that the queue can receive a "Run" command while the idle state is happening and then the idle state enqueus itself means the states swap enqueuing themselves back and forth.

As mentioned above, I think the key is to remove the idle state. The problem with this is, I can't then figure out how to handle typo errors in the state commands without the default structure having that error handling ability. That's fine for me, as I can be really rigorous, but if I want to give this to anyone else, for sure they'll make a typo at some stage. Anyone got any ideas?

Alternatively, I could make the run action flush the queue every time, this seems kludgey to me though, and I'm not sure how expensive it is CPU wise.

Also, I'm about to test whether removing the idle state actually does fry the FPGA, wish me luck!

Report: It doesn't, at least on the VI I tested, yay! I realised that I actually can still have the typo error handling. When each parallel process starts up, it runs an Init state (w/e is needed), then goes into wait mode. Running the action command goes into a loop of continuous action, until a pause command is sent, then it goes to a pause state which flushes the queue, and then waits again. I'm pretty happy with that actually, can anyone see any obvious holes I'm missing or ways to break that pattern?

Edited September 15, 2011 by AlexA

[drjdpowell]

I understand why the states are unstable. The fact that idle can enque itself combined with the fact that the queue can receive a "Run" command while the idle state is happening and then the idle state enqueus itself means the states swap enqueuing themselves back and forth.

Yes.

As mentioned above, I think the key is to remove the idle state.

Yes.

The problem with this is, I can't then figure out how to handle typo errors in the state commands without the default structure having that error handling ability. That's fine for me, as I can be really rigorous, but if I want to give this to anyone else, for sure they'll make a typo at some stage. Anyone got any ideas?

Huh?!? What's this got to do with a default state? The last time I looked at your code, the QSM structure was set up such that it always enqueued another state. Normally, the QSM doesn't do this. When there is no further state in the queue, the dequeue just waits until a new command comes in (or it hit's the defined timeout). Thus, these QSM designs sometimes have "timeout" states, but they never have "idle" states, nor is "default" used for anything other than typos.

Report: It doesn't, at least on the VI I tested, yay! I realised that I actually can still have the typo error handling. When each parallel process starts up, it runs an Init state (w/e is needed), then goes into wait mode. Running the action command goes into a loop of continuous action, until a pause command is sent, then it goes to a pause state which flushes the queue, and then waits again. I'm pretty happy with that actually, can anyone see any obvious holes I'm missing or ways to break that pattern?

OK, should have read your whole post before starting to reply. So, yes, that's better. But as I've pointed out before, your developing your QSM design in the middle of trying to get up to speed on dynamic launching AND debugging what I'm sure is a complex FPGA/imaging project. Doing all that at once is fraught with difficulty.

-- James

Edited September 16, 2011 by drjdpowell