Controlling Multiple Instruments: Continuous Read and Dynamic Parameter Update

[Akello]

Hello,

I am trying to control three instruments via LabVIEW. My DC power supply and function generator are connected to the computer with a GPIB/ENET 1000 while my scope is connected via USB. I am trying to have the scope take a reading during every iteration of the while loop and have the Event Handler check if there are any changes to the supply parameters. I went by the instrument's respective examples and came up with the VI attached. I've wondered for some time about a setup where you are constantly logging and are able to change the parameters dynamically; this is my first crack at it.

The idea is to expand this VI into logging the readings to a text file, automating a sweep from 1K-1MHz and taking averages from that sweep to plot in Excel. For now, I need to get the basic down and I'm getting constant freezes when I run the VI. Sometimes it runs without issue but begins to freeze when I try to set the DC supply voltage and other times it just freezes from the start. I'm wondering if it has to do with the placement of the scope read; before versus after the event handler, but I can't test the theory now as I'm away from the lab.

Would appreciate any advice you can give,

Yusif Nurizade

[johnsold]

Yusif Nurizade,

I do not have all the subVIs, so it is hard to tell about some issues, but one big red flag waves: Nested event structures! Please read the Caveat in the help file on event structures. It is rare that you use more than one event structure. I have never seen a good use case for nested event structures. If it is even feasible to program this way, it will require very careful planning to avoid lockup conditions. The way yours is set up, the program will freeze in the Current limit (0.0 A)...Value change event until an event occurs on the inner event structure.

Local variables should be used sparingly, if at all. Your Wait Text local has a race condition and probably does not work quite as you expect. Similarly the Voltage Level (0.0 V) and Current Limit (0.0 A) locals have race conditions with the terminals.

Consider a Producer/Consumer architecture for your program. You may need more than two loops. One loop should have (only one) event structure to handle all the UI inputs. The data will be passed to another loop via queues. No Instrument I/O will be in an event case. The scope I/O would be in a parallel loop since it is to be read periodically. The power supply and function generator I/O might be in still another loop since they only need to communicate when the user changes parameters.  The Instrument I/O loops can probably be combined by using a state machine within the loop. Whether combined or separate loops is best may depend on the details of the timing requirements and your comfort level with the programming.

Lynn

[Akello]

Lynn,

Thank you very much for the response. You've suggested the the Producer/Consumer architecture in another thread I started and I am still learning how to best implement it.

This particular VI is on a tight schedule and I do not feel confident enough with the consumer/producer to implement it as a solution in time. Plan B is to take a step back to an older version of the VI where the DC power supply parameters are set once with constants and the event structure controls only the function generator. This will be expanded a bit to have the function generator increment the frequency by a constant and take readings accordingly. For now, however, I need the readings to be taken regularly and independant from what's going on with the function generator. Could I do this with a parrallel loop as you suggested?

Thanks again for the advice,

Yusif

[johnsold · Accepted solution]

Yusif,

Yes, the readings could be taken in a parallel loop. If that loop will be completely independent (not sharing data or control with the other loop), it should be straightforward. If you do need to pass data between the loops, you might well be better off learning the Producer/Consumer architecture because youwould essentially have to re-invent it.

Lynn

[Akello]

Lynn,

Understood.

As I mentioned previously, time constraints are forcing me to fall back on the parrallel loop and an older version of the VI where some parameters are constants. This is not my ideal case but will be improved once the milestone is passed and I can better implement the procuder/consumer architecture.

Thanks again,

Yusif