Serial VISA operation does not work while PC Software does

[lukepike]

Hello everyone.

I am using LabVIEW to communicate with a control box via VISA Serial. I can communicate with this control box in most areas just fine, like the data monitoring function which I use without any problems. The one thing I'm having trouble with is calibrating the unit. Calibration is done by opening a binary file and transferring the data 16 bytes at a time over serial using a 16 byte write command, which has this structure: [Command, in this case "P"][2 byte address starting at 3800 HEX][16 bytes of data][1 byte checksum]. I am calculating the checksum correctly, and documentation says that the box should respond to any command within 100 milliseconds.

When I  attempt to do this, the box responds with an E several times (E is supposed to mean checksum error, even though I'm correctly calculating it), then stops responding to anything at all. The weird thing is that this box comes with software that can calibrate it and that software has no problems with it!

I tried using SuperMon to capture what the software sends over serial and compare it to what I send, and from what I can see, it sends the same data that I do, only it works and mine doesn't. I also tried using SuperMon to manually send the calibration one 16 byte write function at a time, and it seems to have the same problem.

It seems because their software works, I must be doing something wrong. Here's a screen shot of my code that I'm trying to use. Any help would be greatly appreciated!

[Ben]

Try agin using NI Spy to log the data. Look for termination characters etc that VISA may be tossing in by default.

You also may want to try slowing down your transmision in the event this is an old widget that can't handle a lot of dat fast.

Ben

[lukepike]

Thanks for the suggestion! I logged some of the data as I ran my vi, but all of it seems to be correct. One thing that's odd is that while the hex representation is correct, the ascii representation doesn't seem to have the  last hex byte correct. I've attached a screen shot of the property window so you can see what I mean. I don't know if this has any impact, but I'm just trying to figure out what I'm doing wrong.

Thanks again for your help!

Message Edited by lukepike on 08-04-2009 12:54 PM

[billko]

You don't think it's something silly like your data needs to be byte-swapped (so your checksum needs to be byte-swapped also)?  It's hard to tell when you're sending all zeroes.

[lukepike]

Could you explain what you mean a little more? I never thought about that, I tried byte-swapping the whole command string right before I wrote it to the port, that didn't work. I also tried just byte-swapping the data only and nothing else, still no go.

I had another look at the NI Spy data, and it seems that some hex values are unprintable, maybe this is why they don't show up in the ascii part of the property window.

[Rod42]

Two thoughts.

1) Should the address be included in the checksum? If not, that may be your solution

2) You have a long winded way of getting the address into two bytes. All you need to do is to make sure that the address is in a U16, and use "split number"

Rod.

[lukepike]

Yes, the address needs to be included in the checksum. I did not know about that split number, thanks for the pointer!

[billko]

---

lukepike wrote:

Could you explain what you mean a little more? I never thought about that, I tried byte-swapping the whole command string right before I wrote it to the port, that didn't work. I also tried just byte-swapping the data only and nothing else, still no go.

I had another look at the NI Spy data, and it seems that some hex values are unprintable, maybe this is why they don't show up in the ascii part of the property window.

---

That's exactly what I meant.  Hmmm, the serial port is config'd the same way it is for the parts of the code that work?  Maybe there's a framing issue so the data is offset and the UUT sees it as garbage?

[lukepike · Accepted solution]

I contacted the makers of the control box and have solved the issue. The control box needs a 5-10 millisecond delay between every byte, not every command as I had originally thought. Thanks for all the helpful replies, and especially the split number tip, that really cleans up my code!

[billko]

---

lukepike wrote:

I contacted the makers of the control box and have solved the issue. The control box needs a 5-10 millisecond delay between every byte, not every command as I had originally thought. Thanks for all the helpful replies, and especially the split number tip, that really cleans up my code!

---

Yay! Good to see you got it solved.  Wow, a time delay between every BYTE???  Who would've thought... (Obviously, not *US.*)  That was the path I was choosing when I asked about framing issues.  Comm errors.