07-26-2011 11:30 AM - edited 07-26-2011 11:33 AM
I am communicating with an instrument using a serial port (a real one, COM1) at 57600 bps. I have a VI I developed with Labview 8.6, which works without a problem. After upgrading to 2010, this VI still works, but another VI I've created and is using an identical way of configuring and writing to/reading from the port does not work.
I have an EZTap pro, which is a USB device that is placed in-line with the RS-232 cable to snoop in on the communications.
My VIs are using VISA Configure Serial Port to set the baud rate, a property node to set the timeout, followed by a VISA Flush Buffer, VISA Write, VISA Read, and VISA Close.
For some reason, after doing the first write/read combo on the VI that doesn't work, data simply stops being transmitted on the serial line after the first write/read. The VI that works doesn't have this issue. Sometimes, it will work for a few write/read cycles before stopping.
Below is a capture of the output from my little EZTap device. I noticed that the DTE_PAR in the break column is not there when I run the working VI. A search of the web says that this results from a baud rate setting issue, but I am setting the baud rate properly (setting it the same in both VIs!). Immediately after line 11 is transmitted, nothing is transmitted after this, and as a result, nothing is received.
Line 6 and 7 is the first command sent, line 8 is a proper response, and it also looks like in line 9 I'm transmitting a null character. I'm not sure why that is... I'll have to look into that. However, sending a null character shouldn't completely shut down communication. After taking a loot, I have enable termination char set to false, so that NULL char isn't coming from that.
07-26-2011 11:39 AM
I suspect a parity error.
You can also use NI Spy to log the exchange and comparing the two logs should tell if this is a hradware issue... which I suspect.
If you can try using the same hardware and widget that works with the new code that gets lost.
Ben