GPIB issue

[Beach_Comber]

Hello,

I am having an issue with a GPIB instrument where the only way I know to recover from is to quit labview and restart labview.  Communication is lost to the instrument unless I restart labview, not the program written in labview.  I am wondering if there is a function that simulates what labview does to the GPIB card in the PC, when labview starts?

Thanx,

Karl

[smercurio_fc]

I'm guessing this has to do with this thead.

It's not clear what you mean by a function that simulates what LabVIEW does to the GPIB card when LabVIEW starts. LabVIEW doesn't really do anything to the GPIB card. It sounds like you may want to use NI Spy to see what's going on with the GPIB bus.

[Beach_Comber]

Hello smercurio_fc,

I guess I can do that but labview is certainly doing something since I am able to resume communication with the instrument only after restarting labview, unless there is some sort on reset command I can send from within labview.  I am using labview V8.2, this behavior was the same under older versions of labview.

Thanx,

Karl

[LabViewGuruWannabe]

It sounds like it has something to do with not closing the port, but without seeing your code, its hard to say. Can you post your code, or a sample program that behaves as you say?

Are you using the VISA GPIB functions? If your program is using the GPIB port, and not closing it properly when you exit the program, then yes, you might have some communication issues. Luckily, you should be able to test this with a simple program that opens the port, sends a command, and closes the port.

B-)

[Dravi99]

Hello Beach,

 I guess you are having some problem like, when you close your application your GPIB is still under the control of Labview. I think what you can do is try to look for a Local Button on your instrument  that you can free your instrument at any moment from the GPIB.

I dont know what exactly goes behind when you do a GPIB control from Labview but it does locks out the GPIB and does not free the instruments until Labview is closed completely even when the VI which used to control the GPIB is closed.

Ravi

[LabViewGuruWannabe]

It should not lock out the GPIB instrument completely, if you use the VISA Close to close the session properly. You can do this upon exiting your program, or specifically with a control.

In the block diagram, its under Instrument I/O -> VISA -> VISA Advanced.

Good luck!

[Dravi99]

What about the GPIB functions like write and read they are low level functions. If we use them we get the above mentioned problem.

Will try to modify them for VISA.

Thanks

[Dennis_Knutson]

Dravi99,

The issue you are seeing is just that the LabVIEW code (or any other language you use), is leaving the instrument in remote mode. If you want the instrument in local mode when the program finishes, send the GTL (Go To Local) command. I don't remember the GPIB function for this but with VISA, its the VISA GPIB Control REN function.

It would be a good idea to convert to VISA in any case. You have a lot more flexiblity in porting the code to other instruments and it can also be used with nin-NI controllers.

[Beach_Comber]

Well I do not think it is anything like a port left open or else there would be a way to deal with it from within labview.  Anyway here is an example of the code and a template from the SUSS Proberbench Remote Communicator help file.  This instrument is actually a multi axis controller and does not have a remote or local front pannel as wou might find on a function generator etc.

Help File (there can be up to four XYZ probes) with example at end:

Command:

ReadProbePosition

Data:
Probe#           Char (required)   1, 2, 3 or 4  
Unit                 Char (optional)   Y micron (default)

                                                   I mil

                                                  E encoder steps

PosRef          Char (optional)    H from home (default)
                                                  Z from zero

                                                  C from center

CompMode   Char (optional)    M matrix comp    

                                                  L lin comp only

                                                  N no comp

Response:
Probe#         Char  1, 2, 3 or 4
xPosition      Float
yPosition      Float
zPosition      Float

Description:
Returns the actual Probe# position in X, Y and Z. The default Compensation Mode is the currently activated compensation mode of the kernel.

Example:
Command: ReadProbePosition 1
Data Response: 1 -1263.4 6766.7 -3336.7

ProberBench Version 4.0

The code is simple... a typedefed command followed by the relevent arguments for the command, a VISA write, delay (a delay is required whether there is a write/read or just a write) and then VISA read.

Cheers,

Karl

[LabViewGuruWannabe]

Hey Beach,

Maybe I'm misunderstanding your problem.

Are there LabVIEW drivers available for your device, or do you have to develop them yourself? With the additional information you've provided, it seems you are developing the drivers yourself. What happens if in your main application, you close the GPIB port before exiting the program? Also, does the communication between your PC and the instrument work properly the first time you run LabVIEW?

As far as I know, with NI-VISA, the GPIB ports are listed just like the Serial COMM ports, and you certainly have to open and close those ports properly in order to allow any other program to access that port. Nearly all of the drivers/example programs I've used from the manufacturers (such as HP/Agilent equipment) include an Initialize VI and a Close VI, specifically for releasing the port for other applications. They also usually incorporate some sort of functions to set the device into a safe state before releasing the port as well.

B-)