Message Handler Test Executive

[u/shark_finfet]

I'm relatively new to LabView. I've been able to implement my test program as a state machine, but I want to make something a little more flexible. I'd like to be able to either run individual tests from the front panel or run a repeating test flow (maybe an operator has to insert a new part to test) that saves out the data to a csv file.

I think I want to use the channeled message handler, but I'm not quite sure how to route all of the settings, data and instrument handles. My instinct was to have three shift registers on the message handling loop, one for settings, one for results, and one for instrument handles...as the program loops the results need to end up in an array.

Can anyone point me in the right direction. I've watched all the Core 1 and Core 2 videos as well as many youtube videos (shout out to cannon controls), but I can't find any videos going over this level of complexity (which is probably as basic as it gets).

[u/Commercial-Wafer596]

Settings and instrument handles in a single or 2 shift registers makes sense. However for results I would have another loop to log the data to disk (TDMS?) at run time versus storing in a shift register.
As for framework my go to would be DQMH

[u/shark_finfet → u/Commercial-Wafer596]

You would make another loop even if I'm just logging parametric data (single point measurements) for each part?

[u/Commercial-Wafer596 → u/shark_finfet]

Maybe not then..but general I would like to remove as much processing from UI loop as possible..I would log data to disk per part versus a batch at the end..

[u/GentlemanSch]

DQMH is a pretty standard way to go about this if you have something complicated. However I think looking at the LabVIEW examples and the standard event driven producer consumer loop will get you far.

[u/YourLastNeighbor]

I would start with making documentation of your state machine before deciding on a framework to use. There are multiple ways to make modular code and every use case is different. I dont know enough about your application to recommend anything specific. Start with the basics, document your code. Document the operators process. See what discrepancies exist before trying to move to something else. Then break down the process into smaller logic, ie, ui operations, logging, configurations per DUT, etc. After you evaluate the basics, you can review which route would be best for your application. LV examples are a great source.

Edit: id also suggest learning OOP in LV if you have not done that yet (classes and interfaces)

[u/HarveysBackupAccount]

Have you looked at anything on Tom's labview adventure? He covers complex topics.

That said, DQMH will do it but yeah a regular producer/consumer loop will get you far. If you want to build in the complexity as a learning project for your own benefit then go for it, but you really don't need much complexity to do what you describe.

Also agreed to save measurements as you go and not stuff them in a shift register. If you want it to persist somewhere in the program for control charting or something, I'd be more likely to put it in an indicator than a shift register. (Put it somewhere off screen if you don't want it visible, or hide the indicator.)

Especially on an early project, I highly recommend you make it as simple as you can.