Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

GPIB device suddenly stopped sending responses in correct order

Howdy,

I have a labview program that controls an SR850 Lock-in amplifier and has been doing so without incident for some time. It queries two channels twice (the second pair of readings are taken after a delay) and then the frequency, and has always immediately responded to the queries. This week, something changed, and I can't for the life of me think of anything we've done to it, but I'm willing to try pretty much anything to get it back in working order. The first few queries sometimes come back normally, but they quickly re-settle into a delayed order. They're often more than one step behind, causing what is actually on channel 1 to be reported on channel 2, the frequency to be reported as on channel 1, etc. We had been developing the program, so the first thing I tried was using the previous working version of the program, but the problem persists.

 

Since it was possible that some settings on the Lock-in had been changed, we completely reset it and started over, but the issue persists. We happen to have an earlier version of the Lock-in (an SR830) and a version of the program from 6 months ago (well before anything of the more significant alterations we'd made), and the issue still persists with these. We've tried adding delays after each query to give the device plenty of time to respond, but no matter how long the delay is, it still reads in the wrong order. I've re-built the program from scratch with the absolute minimal functionality, but the problem persists. Unless it queries only one thing, the responses are returned incorrectly. We're reading 100 bytes, but our responses are only about 10 characters, and I've played with altering this from 8-1000 without any change. I'm sure that there's some things that I haven't tried, but I've only been using labview for about 6 months and am primarily self taught. I could attach the program, but as I said, it worked fine until early this week, then suddenly stopped, and whatever has changed applies to older versions of the program. Is it possible that this might be a hardware issue (our GPIB card is pretty old?), or are there buffers that I should clear, or anything I should try? If it had never worked properly I'd be asking entirely different questions, but this is pretty out of the blue. Thanks for the help.

0 Kudos
Message 1 of 9
(3,645 Views)

please submit the minimal program, so that we can see what maybe is wrong.

one of the problems could be a racecondition. Although it worked correct it can change with a minimal edit.

There is a lot possible but it can be be defined and changed, so it never happens again.

greetings from the Netherlands
0 Kudos
Message 2 of 9
(3,633 Views)

Thanks for the response. I've attached the simpler version of the program. There's a lot of little things that are in there for troubleshooting purposes (loop checks, error reporting, etc) that don't really need to be. I've recently changed the VISA read and writes fro synchronous to asynchronous without any change, and a lot of the delays that are in there are artifacts of trying things that haven't seemed to work to fix this issue. The inner most while loop is the one that seems to have the problems, which is currently in 'film strip' setup, but wasn't originally (ordering was by 'error in/out' connections, but we gave the film strip a try right off the bat as a fix).

 

Again, any suggestions you might have would be helpful, I'm reasonably new to labview and so I expect that my code is a little clunkier than it needs to be, but right now I mostly need it to work. Thanks!

0 Kudos
Message 3 of 9
(3,621 Views)

The sequence frame adds nothing to the code and can be removed. execution order is determined by wiring already.

This is called sequencing by wiring and the compiler makes sure that no subroutine is called before all its inputs are valid.

 

In which case does it stop. Or better where in your program is the stop? Is it reading the sr830 or the ds345?

greetings from the Netherlands
0 Kudos
Message 4 of 9
(3,615 Views)

We're only using the SR850 right now, the DS345 is a separate function generator that we occasionally using. The sequence frame (along with most of the delays) are attempts to nail down what is happening, and are new additions, so it wouldn't be a problem to remove all of that. The program doesn't actually stop running, after a a few runs (sometimes, sometimes it's right away) through the most interior loop we're not seeing the replies to the querries (OUTP? 1, OUTP? 2, FREQ?) in the right order. We'll have the actual frequency reported as the response to OUTP? 2, and what's on channel 1 might be reported as the answer to FREQ?. This was originally working, and I don't know what changed, but my sneeking suspicion is that something had always been wrong, and it just hadn't come up. We've also gained a timeout error that sometimes comes up after the "FREQ?" request, but it doesn't always happen, and it never happens after every iteration of that While loop, but maybe every other or every third.

0 Kudos
Message 5 of 9
(3,599 Views)

I've just build the simplest possible version of our program, and the issue persists. I built it from scratch, without copy/pasting anything from the original program. With this one, I don't get any timeout issues, but things are still reported out of order. Running the progam over and over, almost every time everything rotates one step out of place from the previous location it was reported.

0 Kudos
Message 6 of 9
(3,593 Views)

Do you get any errors?

 

Is the instrument capable of responding to multiple commands?  How long does it take the instrument to respond to a single command?

 

Lynn

0 Kudos
Message 7 of 9
(3,586 Views)

And maybe, just maybe slow down the the gpib bus speed in MAX.

Set it on 2 microseconds and disable autopolling.

 

For some old machines and the sr830 is not really new.

greetings from the Netherlands
0 Kudos
Message 8 of 9
(3,579 Views)

Howdy,

Long story short, the issue is resolved, but to answer your questions, the instrument can take a series of commands in one long chain if necessary, it takes a very short amount of time to respond (millisecond range, much shorter than a quarter second), and we occasionally got some "Error 6: Generic Error" or "Timeout Error" type errors. Anyhow, that's all fixed.

 

While trying anything we could to resolve the issue, we tried clearing the buffers in a handful of ways, by sending commands to the instrument, with both the VISA and GPIB clear blocks, and a handful of other things that we came up with, since it originally seemed like a buffering issue. When none of those things worked, and I had run out of other ideas, I posted here. I kept rolling back to simpler and simpler versions of the program, until I created the 'simplest version' that I posted above, which had the same problem. I decided to start over my troubleshooting with that one, since there's very little that could go wrong with it and it'd be easier to see errors, so I tried clearing the buffers again. This time it worked, and my instrument ran fine. I re-tried this with the more complicated versions of the program, without success. I didn't see much of a difference, except that the 'simple version' above uses only GPIB and the other versions use both GPIB and VISA, so I removed all of the VISA elements and replaced them with the corresponding GPIB elements, and it started working with the extra buffer clearing in the inner while loop as well. I scaled this up to the full version of the program (which was a PitA, since it was mostly VISA) and now it runs without any problems. I don't really understand why adding the GPIB clear unit works now and didn't work when it was intermixed with VISA units, but that change seems to have made all of the difference. Thanks everybody for the assistance.

0 Kudos
Message 9 of 9
(3,567 Views)