I'm writing a VI, which interfaces to a serial instrument, which can be
in various configurations. The baud rate may vary between 115200
through to 2400, and it may have hardware flow control (RTS/CTS),
software flow control (XON/XOFF), or no flow control (NONE). The data
bits, stop bits and parity may change, but rarely do so.
I have been successfull writing a program which tests various VISA
ports, and a range of configurations, by manually sending ASCII 17
(XON) to the VISA interface, and asserting the "VISA property Modem
Line Settings>>Line RTS State", to enable the instrument to
respond.
It all seems to work well, but on occasions (Every Second time I run
the VI) I have a 1073807253 error, when I do a VISA Read. A framing
error occured during transfer.
This happens after I have written a few commands to the instrument, and
the VISA Read is the first read after this. It is also immediately
after a "Serial Settings>>Number of Bytes at Serial Port"
property node.
What would be causing this error? and if it is a framing error, why is
it happening only the second time I run the VI? If I run the VI after
the error, it works.
serial comm can be quite tricky as you have seen here.
A framing error occures, when a signal change on the serial line does
not happen within the expected time frame. For any given baud rate, the
start bit defines the time frame for all the other bits in the data
word. When you try a different setting -say 7O1 instead of 8N1-,
this may result in valid data most of the time. But sometimes it may generate errors.
Another possibel source of errors are different 'effective' baud rates
of the computer and the device. This used to be a not too uncommon
error source in Z80 times (1980's) when baud rates had been
'created' from the CPU crystal clock and a simple divider did not yeald
to -say 9600 baud, but 9670 baud-.
I have no elegant solution for your problem. You may try to ignore this
special error and retry, but not having the 'Bytes at serial port'
cripplles serial comm in a way that makes it hard to use.
You may -for test purposes- check the actual comm settings of the
device in Q and check if this error happens as well when the VI is at
the very same setting. If so, your HW connection is bad and should be
repaired. If not, use this error as a sign that your VI does not have
found the right comm settings.
But after all I am not sure that this is a good idea at all. It is
probably much better to force the users to use just one or a very few
serial comm settings and to check just those.
I have an app with up to 8 test adapters (TAs) that all run on 115kbaud
8N1. They have an ID? command. The PC has up to 27 serial ports. My
test SW just runs through all of them trying to get an answer for ID?.
This takes some time, but reliably detects the number and port of all
active TAs.
Just my Euro 0.02! Greetings from Germany!<br>-- <br>Uwe
