Chaining Instrument Driver VISA (dup) output versus using VISA output of Initialize

[DEppAtNGC]

A) Are there any advantages of chaining the Instrument Driver VISA (dup) output from driver VI to VI versus using the VISA output of Initialize to the inputs of all VI's?

Flow control is being maintained by chaining the Error in / outs or by other means - so flow control is not an issue. The main reasons I ask this question are:

1) I'm using stacked sequence structures (etc.) and would like to avoid using a sequence local to chain the VISA resource. I can maintain flow control by chaining the Error in / outs and using a sequence local for that only.

2) There appear to be some differences between drivers where some drivers dup the VISA resource, others just pass along the original? Any driver dependencies?

B) Is there any speed improvement that can be realized by NOT chaining and NOT using an extra sequence local?

C) Also, another question, is there any problem with calling Initialize more than once using the same GPIB address without first closing the VISA resource? Any driver specific dependencies?

Thanks,

David

[Jeff at home]

Hi Depp

There are indeed advantages to maintaining the VISA resource chain.  Sometimes a sub vi will change one or more VISA properties the Resource in to this vi then becomes stale and the correct VISA settings are only in the VISA out.  Worst case scenario-  your predicessor did it without chaining and it worked, but you need to make a slight change and add a vi that changes a VISA property.  you broke the code and are trying to keep your sanity while cursing the developer 

Always use the VISA in and VISA out chain for that very reason.

You brought up a couple more good points 

"There appear to be some differences between drivers where some drivers dup the VISA resource, others just pass along the original"  VISA in and VISA out suggest that the resource is chained through the vi  VISA in and VISA dupis the naming convention used when the indicator iswired directly to the control.  There may be times VISA dup is aneeded but I can not think of any-  modify the driver to bring it up to good programming standards.

 "I'm using stacked sequence structures (etc.) and would like to avoid using a sequence local"  While we are on the subject of good programming practice.  Treat stacked sequence structures like vermin- stap them out every time you see one.  Replace it with a state machine and put all your sequence locals on shift registers.  Ive attached a stacked seq replacement that I keep around just for these events.

Good hunting!

[DEppAtNGC]

I would like opinions on my original questions from others as well.

[DEppAtNGC]

Jeff wrote:

"There are indeed advantages to maintaining the VISA resource chain.  Sometimes a sub vi will change one or more VISA properties the Resource in to this vi then becomes stale and the correct VISA settings are only in the VISA out. "

One problem with chaining is that if this chain is feedback via a register / feedback that is part of an overall event processing state machine, the changes are fed back to the beginning of the state machine so that when a new command is issued, it uses a VISA resource that may be different than the first time it was executed - and that's certainly bad.

I don't think that the VISA resource should be modified, except perhaps once, under control, during initialization. In any case, that should be strictly controlled and not propagated arounda state machine.

I'm still looking for good counter and/or agreement opinions...

[Dennis_Knutson]

I don't believe that changing the properties of a visa resource would change the resource at all. They are two separate things. Once you change a property, that property stays until you change it again or exit. I don't believe it matters in this case whether you use a shift register or not.

On the other hand, if in your scenario with the state machine, one of the states changes the resource from say com1 to com2, you would certainly want to maintain that resource in a shift register and would certainly be a good thing. I've done this often where I have a single VI that I've used to control several identical instruments. I did not have to stop and restart the VI, just change the resource name.

[DEppAtNGC]

Please see my original question... is there any disadvantage to NOT chaining when the resource remains static? It's an HP-IB instrument that just gets new commands as the application rolls along... and within a loop that services "start test" events

[Dennis_Knutson]

I thought I gave my opinion on that when I said that changing the properties would have no effect on the resource and chaining was unecessary. The resource remains static and I'm not aware of any disadvantage.

[DEppAtNGC]

Thanks for the clarification! And it's what I wanted to hear... I'm still listening for any dissent...

[JÞB]

Dissent-

This can be benchmarked fairly quickly.  Try changing a VISA property in a vi and comparing the properties of VISA in, Dup VISA and VISA out.  You may also look at the validity (staleness) of the resource with the LabVIEW.ini configured with and without the "Automatically Clean up VISA sessions" property set. 

I maintain the VISA chain for reasons of style and because I once got bit by an instrument who's termination character variable did not have the same value as the termination character of the VISA resource (which was dup'ed by the vi that reset the instrument.) 

[Dennis_Knutson]

Here's two VIs. Run the read VI and note the timeout value. Run the write VI and change the timeout value. Run the read again. The property value matches what was set. I believe this is the sort of situation the op is discussing where the resource is not closed and reopened.