Showing results for 
Search instead for 
Did you mean: 

Errors and Multiple Instruments: What's Considered Good Labview Practice?

A general question:  If I'm writing a VI that runs two different instruments in tandem, how should the error wires be routed?


Personally, I've been keeping the error wires on the instruments isolated and checking both independently for errors.  I've got some nice rail-road tracks going with my VISA devices.


But is that the best way to go about things?  I seems I could just use a single wire between all my devices, which would give me the added benefit of data flow ordering.  I worry though, that I might lose errors or warnings if both malfunction at the same time.  What's the best practice most Labview programmer use?

0 Kudos
Message 1 of 7

What I do is have a separate Error handler loop/object etc. that populates a list on the UI with any current errors (date/time stamped of occurrence). Then I'd pipe the each error from the instrument loop(s) to the Error Handler loop via Queues or any other similar mechanism. This way you can see all the active errors and resolve each independently without loss of information (as you would get with merging errors). 


Looking inside an instrument scope - on rare occasions I may have a 'hierarchy' of errors where one error make take priority over another. In these more unusual circumstances I tend to do the error priority management 'manually' via an extra priority metadata field in a typedef / object etc. and then an error management VI that performs the selection. But again I've only used this in cases where errors generated were cascading in nature.

0 Kudos
Message 2 of 7



If the devices can run simultaneously I would keep the code to run them simultaneously. You can use a merge error function at the end, I know it is just going to show the last error but if it is not a critical application you can solve the errors/warnings one by one.



Jose F.

0 Kudos
Message 3 of 7

I think that it's on a per-case basis and you should decide based on what the code is attempting to accomplish.


For instance, if you're doing two independent operations, one per instrument, and they each can accomplish something useful on their own, keep them separate.  However, if the operations are linked in some way (i.e. instrument A powers up device X, Instrument B measures, Instrument A changes power level, Instrument B measures again,etc. etc...) then interweave the error chains together, both to enforce order of operation and also to skip the remainder of the routine which is now providing no useful information because half of the tasks are skipped.

0 Kudos
Message 4 of 7

 thanks for the advice!


If you're curious, it's a sequence of measurements; a temperature measurement followed by a lock-in amp measurement, followed by another temperature measurement.  The order is important, but otherwise they're independent.  It's a bit late to code a single error line now, but I think I'll do that in the future.

0 Kudos
Message 5 of 7

One point to consider is are they on a shared bus like GPIB?  If they are, then only one instrument (other than the controller) can be active.  There are special cases where multiple instruments can be configured and  placed into certain states that await special commands like:


which will then allow each waiting instrument to run simultaneously independent for some period of time. 



However, when running normally, this type of bus (I.E. GPIB) will essentially place other instruments into a Hold State until the bus is released and those other instruments are then addressed/controlled in a sequential manner.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 6 of 7

I didn't know that!


I am using GPIB, so that's good to know; I'll definitely wire all the errors together next time I get a chance.  Thanks!

0 Kudos
Message 7 of 7