Permanent address setting in MAX

[Julianti]

Hi,

Thank you in advance for your help.
I want to establish communication with an oscilloscope via GPIB-USB. I can save the waveform from the oscilloscope but once I restart the VI and input the same GPIB address at the VI, the communication will not work. It can work again, if I change a new GPIB address at the oscilloscope, MAX and the VI.

I think the problem is with the MAX setting. Can you please tell me the steps to permanently set the address, so that I need to input the address only for the VI every time I run the VI?
Thank you!!

[Dennis_Knutson]

Once you do a scan for instruments and one is found, that address will stay in MAX.

When you re-run the VI, what error code do you see? What is the make and model of the scope? Are you using a driver and if you are, what type (LabVIEW, IVI, etc.)? If you are using the Instrument I/O Assistant or code you've written, why don't you post what you have?

[Julianti]

Sorry for late reply.

I am using HP 54810A oscilloscope. The error code is -1073807302. I modified the VI from the driver, but I don't know the "type". The VI cannot recognize the oscilloscope connected via GPIB even though the GPIB address at the oscilloscope, the MAX and the VI input are consistant. The VI is attached here.

Thanks a lot!!

[Dennis_Knutson]

I don't see anything that would cause that error but I don't have the scope to try the VI. If the first iteration of the for loop works but it fails on the second, I would suspect that the scope is not being triggered for continuous acquisition and there is no data to read.

[MXI Master]

Since you seem to be getting inconsistent attributes, you might want to try sending a reset command to your scope. This should clear up any unresolved states in your scope. These commonly occur when communication with your instrument is not terminated  properly, are you using the close VIs associated with your scope?
Cheers,

[Julianti]

My VI fails at the first iteration during the first VISA write. I tried with a "close" command but the same problem occur. The VI with "close" command added is attached. I hope that I can avoid "reset" command because if I use "reset", I have to write a more complicated VI to set the configuration again.
Another member in my lab also experience the same problem with another oscilloscope from different manufacturer. So I think it is not due to the oscilloscope nor the driver. Please help....

[RavensFan]

I noticed few odd things about your program.  I'm not sure whether one of these would explain your issue.

1.  You have your VISA reference wired to a shift register at the end of the internal for loop, but at the front of the loop, it comes through a normal tunnel and the shift register is completely unused.  I would recommend putting some probes, or some temporary indicators before and after the functions on the VISA reference.  I don't have the HP548xxa subVI, so I don't know what's going on in there.

2  You have the VISA read immediately following the VISA write.  You may want to put in a small wait timer between them to allow enough time for the device to get the message and respond.  However, this may also depend on the settings for the VISA port as to the number of bytes, any end of message characters, or timeouts set.

3.  You are comparing the millisecond timer to a value to determine when to stop the loops.  Look at the context help for that function.  You'll see that its timebase is undefined.  So whether its value is greater than or less than 9000 would be arbitrary.  If it's a case where you only want the loop to run for 9 seconds.  Then get the timer value before the loop, add 9000 to it and compare the timer value inside the loop to that value.  I don't think there are any guarantees that the timer starts at zero.  How does the VI stop now?  Does it stop on its own or are you forced to use the abort button?  If you're forced to abort, then the close VISA function will never run.

If you can't get it figured out, your best bet may to write the more complicated VI.  Wrap up all your configuration setting commands into a subVI that you can call from within this one.

[Julianti]

1) I use the shift register just to get the last data, i.e. the VISA resource name. Without the shift register, it is an array and it cannot be wire to the VISA close. This may looks stupid..so what about to avoid the For loop, as in this VI attached? The driver for the oscilloscope is available at  http://sine.ni.com/apps/utf8/niid_web_display.model_page?p_model_id=485.

2) I never modify the arrangement of VISA write and VISA read. It is given in the driver for the oscilloscope. So I assume that it is fine. Is this assumption correct?

3) I already put another Tick Count to compare with. Is this what you mean?

I tried to run and it stoped after the VISA close. Then I close the Labview and rerun this VI. The error occured at the VISA write during the first iteration. Then if I change a new GPIB address at the oscilloscope, MAX and the input for VISA session in the VI, then it can run with no error.   This is only annoying for this VI but it becomes a real problem when I combine all my sub VI together later.

Thank you for your help..

[RavensFan]

Julianti wrote:

1) I use the shift register just to get the last data, i.e. the VISA resource name. Without the shift register, it is an array and it cannot be wire to the VISA close. This may looks stupid..so what about to avoid the For loop, as in this VI attached? The driver for the oscilloscope is available at  http://sine.ni.com/apps/utf8/niid_web_display.model_page?p_model_id=485.

A tunnel coming out of a For loop will often default to an autoindexing tunnel and give you an array.  You can right click on that tunnel and select disable indexing to get a normal tunnel coming and not the array.  I'm not sure why the need for the For loop, unless you intentionally want to run this code exactly 180 times.

2) I never modify the arrangement of VISA write and VISA read. It is given in the driver for the oscilloscope. So I assume that it is fine. Is this assumption correct?

I don't know.  I am used to serial port communication and not GPIB communication, so my reference basis is that where I am used to needing some sort of delay.  In a situation like that if you write then read too fast, there is nothing yet to read.  But by the time the loop gets around to the next iteration then there would be something in the read buffer but from the previous iteration.  I don't know if the mechanics behind GPIB are inherently different than serial.

3) I already put another Tick Count to compare with. Is this what you mean?

Exactly.

I tried to run and it stoped after the VISA close. Then I close the Labview and rerun this VI. The error occured at the VISA write during the first iteration. Then if I change a new GPIB address at the oscilloscope, MAX and the input for VISA session in the VI, then it can run with no error.   This is only annoying for this VI but it becomes a real problem when I combine all my sub VI together later.

Thank you for your help..

[Julianti]

Hi everybody,

I solved the problem by installing a VISA driver. I should know this earlier.
Thanks for your time and effort to help. All the best!!