Re : Re: RS-232 framing error and I/O error

[hyenah]

I am trying to use SignalExpress to acquire data from multiple sources, and I created a user-defined step in LabVIEW 8 for SignalExpress to use. This VI acquires data from a thermistor that has an infrared-RS232 (9 pin) adapter, which in turns plugs into an RS232-USB converter cable (because my laptop does not have a 9-pin RS232 port). However, when I try running the step, I am getting an error in SignalExpress that says

Possible reason(s):

VISA:  (Hex 0xBFFF006B) A framing error occurred during transfer

and occasionally I also get an error message suggesting an I/O error. There was one attempt at running my project when data was properly transmitted every other time (my device outputs every three seconds), so I'm kind of confused...

The VI itself works fine in LabVIEW; I've never gotten any errors when I run it in LabVIEW. Following the information I found in a forum search (this seems to be a very common problem!) and a KB article, I checked the port settings (baud rate, number of data bits, parity, flow control, and number of stop bits) in MAX and what I specified in my VI, and they match my device's port settings specs. I closed other programs that might have been using the COM port. In MAX, I also performed a test panel and it seems to be transmitting something, although when I select "ASCII" only (which is what my device outputs), the reading is just a bunch of elipses and X's, which isn't what I would expect, but then again I'm a student and don't have a lot of experience with this stuff.

I'm not really sure what's going on, if my VI seems to work perfectly in LabVIEW and problems arise only when it's imported into SignalExpress. I wonder if the problem could be noise due to a long cable (the infrared-RS232 adapter that I ordered with the thermistor is several feet long) and/or a cheap RS232-USB converter cable that I just bought at a local store. Or maybe there is too much EM radiation in my room (what kind of appliances would cause interference? Refrigerators? Stereo system?) As extra info, I also programmed a kind of wait in my VI to not read my selected COM port until Number of Bytes at Serial Port is more than 0 (because this will be a continuosuly running step in SignalExpress and there will only be a temperature output every 3 seconds); maybe there are some timing issues involved with that? Any other ideas? This is a student project and I'm hoping to, uh, finish it on time. Thanks!

Message Edited by hyenah on 05-19-2007 01:59 PM

Message Edited by hyenah on 05-19-2007 02:01 PM

[tuba]

You can run into framing problems when you try to perform a single read of a device which transmits periodically, without needing to be queried first.

The problem is probably that you are opening the port while the remote device is in the middle of transmitting. This can cause your serial port to misdetect the start bit of the data byte, causing corrupted data (framing errors) until there is a gap in the communication and the UART can resynchronize with the next start bit in the data stream.

The reason it may behave differently in LabVIEW depends on the way you have programmed the application. If you are not explicitly opening and closing the port in LabVIEW, the port will actually stay open even when your VI is stopped, so you are only likely to see this problem the first time you run your VI.  The downside of this is that when you run your VI, you will be grabbing the next reading from the serial buffer, rather than the last reading from your device, so you will likely have to take this into consideration if you read less frequently than the device transmits. When running it in Teststand, you may not see this behavior, even though you are using a LabVIEW step (I don't really know that much about Teststand).

To solve your problem, you will either need to make your VI handle these framing errors, and wait for a good packet, or make some sort of background application which runs constantly and receives all measurements, and your Teststand step simply retrieves the last measurement from this application.

[hyenah]

Thanks for the response.

I'm not sure if this is what you mean by opening and closing the port, but in my VI I configure the serial port, read VISA, and close VISA in each run. How else can I handle this possible reason for the framing errors?

[Henrik_Volkers]

I had framing errors in the past with too slow optical isolators.  In detail they where just fast enough, however together with the given timing tolerance of my talker (sensor), I had framing errors. Reducing the baudrate helped in my case.

[Nick_D]

Hey Hyenah,

Something you may do, is try to use NI-SPY to notice if you're able to see anything on behind the scenes. NI-Spy is a program of ours that reads the ports, and reports whats going on. Just go to Start->Programs->National Instruments->NI-Spy.

Also, what you could do, is in the VI, get rid of the initialization VI, and just pass the Com port through as a constant. The default configuration created through MAX should be able to carry through.

Can you let me know if this helps?

Regards,

Nick D.

[hyenah]

I tried using NI-Spy and am not really sure what to make of it. When I "Run Once" in SignalExpress, my user-defined step seems to work fine and reports a single temperature, and NI-Spy reports no errors. The general sequence of events seems to be a "viParseRsrc", a VISA GetAttribute, a bunch of VISA SetAttribute related to port settings, VISA Read, and VISA close, which all occur with my original VI (without removing the configure serial port block, which is what I assumed you meant by removing the "initialization VI").

If I remove the Configure Serial Port block my VI won't even run in LabVIEW; it cites an I/O error.

Using NI-Spy and selecting "Run" (continuously) in SignalExpress, the same error relating to framing error appears (0xBFFF003E):

> 54678.  VISA Read ("COM4", 20, "..16:40:")
> Process ID: 0x00000A30         Thread ID: 0x00000EB0
> Start Time: 16:40:41.021       Call Duration: 00:00:00.000
> Status: 0xBFFF003E (VI_ERROR_IO)

What seems to be read from my device is a truncated version of the ASCII string I should be getting. Curiously enough, it now consistently seems to correctly read every other second, which is odd because my device is supposed to be transmitting every 3 seconds -- this just doesn't make sense to me, unless the x-axis in SignalExpress is labeled "Time" even though the x-axis may be instead be something like "Get Data Attempt #" and my user-defined step is working every other time my device transmits data.

I am starting to get really frustrated, so thank you all for posting suggestions. Additional advice would of course be even more appreciated...

[hyenah]

I've been thinking about my problem, and I'm wondering if there is a better way to implement a kind of wait in my VI that will only read the COM port when my thermistor transmits data (every 3 seconds). I'm posting my VI, which has the solution of staying in a while loop until the number of bytes at the serial port is greater than zero, and then configure/read/close the serial port. Being a student means that I might have done something wrong...

[JB]

There is a big problem in your code. The configuration of the port may delete some data or at least cause framing errors. Do the different operations in following order :

1) Configure the port --> once when running the VI
2) Main while loop with :
    a) wait for bytes at port --> inner while loop (use a delay  to avoid to use 100 of the CPU to do "nothing")
    b) read the data
    c) decode the data
    d) check if the user want to stop
3) Close the port --> once when closing the VI

The sample code of Dennis in this discussion will be a very good starting point for your application.

[hyenah]

Hmm, I am a little confused on how to properly implement the same idea for my application. Because my VI will be a step in SignalExpress, there can't be any required user interaction such as a manual stop button for the while loop. If i were to copy the example VI that you directed me to from Dennis, I would need to stop the while loop after, and only after, the "true" case has been executed. I'm still thinking about how to modify this appropriately...

Also, I am not sure what you mean by "(use a delay  to avoid to use 100 of the CPU to do "nothing")".

[Matt_F]

The application note at http://zone.ni.com/devzone/cda/tut/p/id/3203 has a lot of great information on creating plug-ins in LabVIEW for use in LabVIEW SignalExpress.  It also covers how to architect your code when connecting to external instrumentation.

Regards,

Matt F