Optimal GPIB commands sequence

[triarian1]

Hello everyone,

I have at least 5 different devices sharing the same bus and I am using GPIB for the communication with them.

I am looking for an optimal command sequence for communication like

for write *rst; *cls; some_command; read ; *wai (or *opt? *opt).

Additionally, GPIB communication occurs from a different VI's simultaneously (I am not an original developer of these programs).

Sometimes the program froze when one of the devices reveals the error of the command from the remote program (i.e. VI).

So, my idea is to prevent the error organizing a timetable for commands, I mean Check if device is busy, wait, if too long -- Cancel; send a command; read; wait until reads; make a mark that device is free for another command.

Thank you in advance for any suggestions.

Bests,

Dima

[sherlockholm]

Hi triarian1,

What exactly is your program doing?
What errors are you seeing?

[mkossmann]

Do you have an idea, which command causes the error on the device ?

You might run NI IO-Trace to log the commands on GPIB. That log could reveal what happens just before the freeze.

[triarian1]

Hi sherlockholm,

Program is communicating with two waveform generators Aglient 33521A and Stanford DS345 which sending a sine waves into samples, two Lock-ins Stanford SR830 analyze the response from samples. There is also a capacitance bridge which measures temperature.

So, the process is as follows: waveform generators send a sine signal with some amplitude and frequency; lock-ins took response; program analyzes this response and we obtain the experimental data, also it is calculated whether it should be change driving frequency or not.

Error appears at Aglient generator which said: Error generated by remote interface.

I watched through the program, there is a GPIB Write command which set Frequency to Waveform Generator.

My guess is there could be two problems:

1) the bad value of Frequency is send to Waveform Generator (such as negative or so). I tried to fix this.

2) two or more commands are send to Waveform Generator without waiting for previous command proceed.

[triarian1]

Hi mkossmann,

That's a good idea. I did not know about IO-Trace.

Unfortunately, I can not find it on a PC.

We are using Labview 8.5 under Windows XP and either IO-Trace was not available in this version or it was not installed.

[mkossmann · Accepted solution]

If you are using XP, you might also use an old version of the NI-Software. However in old versions of the NI-Software this program was called NI-Spy

[triarian1]

Thank you.

I turned it ON.

[triarian1]

Hi mkossmann,

After 40 hours of measurements the Error appears again. 

I saved the command and a few previous commands into error_log.png

I also attach the Labview window where error occurs W1.jpg as well as the previous window where data goes to storage W2.jpg

So, this particular part of the program communicates with the lock-in Stanford SR830 and as I understand at first 4000 points are saved into storage of this lock-in (W2.jpg). Further, those points are downloaded (W2.jpg) into an array and analyzed. During this downloading procedure the error occur.

Any ideas how to fix this?

Thank you

[triarian1]

What I realized from this error analysis is for some unidetifed reason lock-in stops responding and maybe I could say more if some reasonable timeout was set. Until now timeout was by default some huge number. I set everywhere timeout to 10 second which is not solving a problem.

Sequence right now is:

1) Turn on GPIB: OUTX1; Reset data buffer REST; Set sample rateSRATX;  sets or queries the end of buffer mode SEND0; Start data buffer read STRT

Then goes the pause, in my case 4 seconds to fill data buffer

2) Pause data storage PAUS; Queries the number of points in buffer SPTS?

After that program goes immediately to data read:

3) Data read TRCA?1 or TRCA?2 

So I think in the end of step2 I should put some command that will wait operations to be completed like *WAI.

I am not sure.

[JÞB]

How many times is that loop running?

Lets see, in hex you are sending an 0xFFFFFFFF im thinking that means put 4000 values into trace 1 storage starting at the highest addressable space.  I would expect something to complain about that