serial write and read only reads if command is written 3 times

[dugan]

I had set the output port to RS232 manually on the instrument so I wasn't using the OUTX0 command, but even if I submit "OUTX0\n*IDN?\n", I still have to submit that twice before it reads properly.

[dugan]

Something I didn't mention before - the RS232 port on the lock-in is a 25-pin connection, and I'm getting it into my computer via a 25-pin to 9-pin adapter and then a 9-pin to USB adapter. Could there be a problem with the pin configuration? I assumed there wasn't since I can successfully write commands on the first try, and I ultimately get the correct output from a querying command (albeit only after 2 tries). But is there maybe another way the information could eventually make it to the right place through an incorrect configuration?

[crossrulz]

What USB-Serial adapter are you using?  Prolific chipsets tend to cause issues while FTDI tend to be pretty rock solid.  I would expect an issue there.  Since you are occasionally getting a message through, the cabling should be fine.

[dugan]

Hm, I am indeed using a prolific chipset adapter. I've ordered an FTDI adapter and will update the thread when I get it. Fingers crossed!

In the meantime, I've found that the the read output is always in response to the first query I send. For example, if I send "*IDN?\n*STB?\n" (where *STB? queries the instrument status byte, but it could also be some other simple query), I get the correct output for the *IDN? query. Strangely, only a single additional *STB? is necessary, while two additional *IDN? queries are necessary to get the response to the first one.

[crossrulz]

The other weird thought I was having is it could be a handshaking issue.  But I would expect no response at all if that were the case.  But you should probably double check all of your serial port settings match.

[dugan]

Update: I got the FTDI serial to USB adapter and it is behaving the same way as the prolific chipset adapter. Still stumped!

[niarena]

If you can send commands and receive the response when you write the commands 3 times, it seems that the connection works, randomly but works, and the device generates the behavior, I would contact the manufacturer, there could be something missing.

[billko]

Are you able to set the baud rate on the instrument?  Maybe you can slow it down (and adjust the code accordingly) and try it?  If the problem goes away, or gets a lot better, maybe something is wrong with quality of the connection.  Higher speed connections are more susceptible to "line noise" than low speed ones.

[dugan]

Ok, problem solved, but not in a satisfying way. I was trying to get the basic interface working on my laptop before transferring it over to the computer that will actually run the instrument, but when I tried running it off that computer, I don't run into the problem at all. The computer is running Windows 7 while the laptop is Windows 8, but I don't think that is the issue. More likely I would guess is that the laptop is running a 32-bit version of LabView on a 64-bit OS while the computer is running a 64-bit version of LabView on a 64-bit OS. Sorry I can't offer any better info, but at least my problem is solved.

[billko]

---

@dugan wrote:

Ok, problem solved, but not in a satisfying way. I was trying to get the basic interface working on my laptop before transferring it over to the computer that will actually run the instrument, but when I tried running it off that computer, I don't run into the problem at all. The computer is running Windows 7 while the laptop is Windows 8, but I don't think that is the issue. More likely I would guess is that the laptop is running a 32-bit version of LabView on a 64-bit OS while the computer is running a 64-bit version of LabView on a 64-bit OS. Sorry I can't offer any better info, but at least my problem is solved.

---

I doubt that it the LabVIEW flavor has anything to do with it at all.  I think it's more likely due to the differences in the operating systems.  The recommended configuration is LV 32-bit on a 64-bit OS.