advice on camera acquisition program structure

[halvorka]

Hi,

I'm seeking some advice on the best way to structure a program who's central function is to acquire and save video images (resource intensive), but that also requires some initializing and setup beforehand.

In this case, the user will perform a couple of tasks:

1) initialize equipment

2) load, edit, and possibly re-save files to run the equipment

3) choose file format for saving video images

4) start the acquisition

5) end the acquisition

So far I've implemented this in an event-driven state machine, but I've read that these types of programs shouldn't include a long step such as the video acquisition (I had to enable front panel controls during the video acquisition event to be able to end the acquisition). I'm wondering what people here would recommend in this case.  A key consideration is that I want the video acquisition to run as fast as possible, as the acquisition rate will be CPU-limited due to some video processing.  Is it worth making two separate loops in a master/slave configuration using notifiers or occurances, or is that overly complicated for this case?  Would using notifiers or occurances slow the time-critical acquisition loop?  

Ken

[JÞB]

I like the idea of using an event structure to capture user events! deffinatly the way to go!  However, you are exactly correct to avoid doing the image acquisition image manipluation in the same structure (your UI will be unresponsive and the user will curse you).

I'd probaly use a second loop with a queued state machine in it to do the actual work and pass the commands in a queue from the event.  The user presses a button, the event fires, a command (init equip, load config, start acquisitions, exit etc...) is enqueued and the consumer loop is driven to actually take the actions you need.  It could even pass status updates back to the UI (which could cause events that enable or disable certain actions that would be meaningless)  

Take a look at the queue shipping examples and see if there is something you like.  Good Luck

Message Edited by Jeff Bohrer on 04-05-2010 01:46 PM

[GuenterMueller]

Hi Ken.

Proper usage of notifiers or occurances will not slow down a time-critical acquisition loop.
Putting your acquisition in a separate VI, giving it its own Execution System (maybe with a priority of "above normal") and communicate to it using occurrances, notifications or queues is a good approach.
Regards, Guenter

[halvorka]

Thank you both for the advice.  I've never used notifiers, occurances, or queues before but I'll give it a shot.  Do you have any recommendations on which is best in this case?

[GuenterMueller]

Notifiers and occurences can signal exactly one state.

Queues allow for stacking elements - which I perfer to have.

Happy coding, Guenter

[JÞB]

---

halvorka wrote:
Thank you both for the advice.  I've never used notifiers, occurances, or queues before but I'll give it a shot.  Do you have any recommendations on which is best in this case?

---

I agree with Gunther-  The Queue can pass a lot more information (like an enum for a case selector  ) Post back with what you come up with and we'll tweek it up with you !

[halvorka]

I am basically finished with my program (minus a few minor issues).  I took your advice and used a queued state machine architecture, which ended up being easier than I expected (with some help from a fellow labview programmer and the labview style guide).  I haven't really put in any good error handling yet, which the only thing left to do.  This is the most advanced program I've made, but it turned out to be not so overwhelming...

Ken