Why do I get a framing error?

[thisisnotadream]

I have recently updated a program written using old-school serial VIs and made it use VISA.  My users are complaining that they are getting a "framing error" when they use the new software, but it works just fine using the old software (note:  there was also no error-checking in the old program).  They are reading a periodic message using an N.I. USB-485 converter.  I was under the impression that a framing error was a bit-level issue, not related to serial drivers.
 
It's kind of making me look like a schmuk since I pushed for the upgrade to the new drivers and better programming techniques.
 
Any ideas on how to chase this down? 
Dan

[centerbolt]

A couple of questions.
1- Is the PC in the lab using the USB-485 converter as well?  Does the old software use the same USB-485 converter.
2 - Does the laptop user always get the framing error or does the program work sometimes?

[thisisnotadream]

The PC is using an NI PCI-485 card.  The old software was using the old serial VIs.  Most users had RS-232 converters or a Quatech 485 PCMCIA card for use in laptops.  The user is now switching between the old and new software, using the same USB-485 converter, and getting these results.
 
According to the user, he claims that he invariably gets a framing error with the new software on his laptop even after a computer restart and a system-under-test restart.

[thisisnotadream]

The user installed it on the laptop using an installer, which I would assume included LV runtime and VISA drivers, as well as the application.
As far as your comment about access times, shouldn't that information be transparent to me, the programmer?  I mean, I check the number of bytes at the port before I read the port.  And the old serial drivers don't seem to be affected...Perhaps I'm just not understanding the subtle nuances of what causes a framing error with NI hardware.

[Steve.Briggs]

When I receive a "framing error" it often has to do with parity issues.
 
Serial communication error (Baud rate, parity, or data length mismatch between instrument and connected serial device):

- Check application software sets correct serial parameters

- Check baud rate, parity etc. set correctly.

I know, I know...you are probably tired of hearing you need to check the baud rate, parity, etc., but I'm just telling you what the description of an error is that I often receive. 
A few questions...

- Are you using VISA read?  If so, this could be where the data length issue comes into play. 

- How do you start up the instrument and serial device?

- Do you ever disconnect and then reconnect the serial device to any other instrument while it is still operational?

- Have you tried resetting everything to manufacturer defaults?  Sometimes by doing this and starting "fresh" a problem can be avoided.

Regards,

[Steve.Briggs]

In reading what Centerbolt has said to you...
You haven't confirmed whether or not you have the most recent LabVIEW Run Time Engine or VISA Drivers.  These are crucial for a stand alone.  Both the run time engine and drivers can be downloaded from National Instruments.  I would suggest confirming this...then moving onward.
 
Regards,

[thisisnotadream]

Agreed.  I also love the idea of running the software using the USB-485 adapter on the PC. 
The lab is pretty well tied up, but I'll get to it when I can schedule some time.
Thanks!

[K C]

Hi Dan,
In your first message you mentioned that the old software has no error check. What would happen if there was an error ? Is it visible or does the program just keeps trying to communicate ?
Framing errors are normally the result of a wrong frame length. UART's give a framing error when the IC does not see a stopbit at the moment the IC is expecting one. So setting the wrong data length or setting parity where it should be can cause this. Because you have a working situation I don't think this is the case.
A framing error is hardware related, so normally I would not expect that software (drivers) can influence this  :smileysurprised:  (I think and I hope)  unless you are using the wrong drivers or combinations.
Did you check you transmission lines and termination resistors ? Different interface can act differently with incorrect transmission lines.
 
 

[thisisnotadream]

In the old software, the error lines were never connected.  So, in case of an error, the software would just plow on as if nothing had happened.  The user would never know it.
 
We spent some time in the lab last week on this issue.  We hooked the adapter up to the LRU like they did in the field.  I didn't know this, but in the field, they have to use a break-out box and jerry-rig some wires to the RS-485 adapter connector.  At first attempt, we weren't getting any communication due to some grounding issues with the BOB connections.  Then we started getting a framing error.  I discovered that this was in relation to the fact that they had swapped the RS-485 high and low lines.  This makes sense why we were seeing a framing error.  But, it still doesn't make sense why the other software would work.
 
At this point, we were able to get the USB adapter to work in the field with a laptop.  I'm going to assume that in addition to using the old software, someone made different connections on the BOB that fixed the hardware issues.
 
Dan

[K C]

Well if the old software doesn't report  an error and just keeps trying it might work sometimes. Just like retries.
I saw a lot of strange things happen on a RS-485 interface with many devices.
 
In your new software you report the first error and if you don't retry your communication end here.
 
Could this be the case ?

[Steve.Briggs]

Hey,
Much like what I do when an error comes about.  Normally a timeout error, I simply close the port, completely clear and flush out the VISA, then reconnect RS232 communication through my instrument. 
The errors aren't completely visible in my case, the data is never transmitted from instrument to computer.  The instrument completes what it should and is then ready to move on, but the data is never sent.
Regards,

[Dennis Knutson]

I've been observing this thread with some interest because I've been recently seeing a problem with framing errors as well. It all started when the IS department upgraded some old pc's from NT to XP. The serial routine originally written about 8 years ago with VISA, all of sudden started to detect a framing error. It would only happen when the routine was monitoring a product when it was booting up. At all other times, communication with the product was just fine. I've tried all different versions of VISA from 3.0 to 4.0 but the error persists but only on the XP pc's and it happens with both USB->RS232 and built-in serial ports. I did a quick patch to the program to ignore the framing error so that production could continue but today I've been working on it a little more. I used portmon to capture the serial traffic and the error happens when the ASCII Null character is read. I have no idea why this character would cause a problem and my next step is to wade through Microsoft's web site to see what ms might have changed in XP that could affect the serial port and VISA.
I wish I had an answer and if I find anything, I'll post it here.

[Steve.Briggs]

Hey Dennis,


Dennis Knutson wrote:

As I mentioned, this only happens on windows xp with code that has been working with no problem for several years.
The product may be sending a serial port break at this time but I'm unable to see this with portmon. I don't know if NI-Spy would see this either but I'll give it a try when I get some time. I really think Microsoft did something with the serial ports in XP but I haven't been able to figure out what yet.




My problem appears to be similar to your problem and I can convey to you the error because you originally helped me with my vi.  Maybe I can shed some light unto your problem as well...
A while back you created this vi for me:
<img src="Loading Image..."> For the longest while it was fully operational and giving us the scanning results we needed and had hoped for.&nbsp; To further our testing procedures we created an excutable of this vi (which you helped me with as well) and things started to fall apart from there.&nbsp; The vi was originally created on a computer operating on Windows 2000.&nbsp; The executable was attempted on computers both with Windows 2000 and Windows NT.&nbsp; Some non updated VISA drivers and port failures were obvious problems as to why they didn't work right away, but there on the original vi didn't work on the original computer.
Perhaps some serial port configuration from the other two computers affected the original serial port, but that doesn't make sense because I can still send full commands to the port.&nbsp; I just don't receive any bytes when I perform the scan.&nbsp; The original vi you made for me had a 2 second wait in it.&nbsp; So I tried waits ranging from a few milliseconds all the way to 20 seconds hoping for a byte count to appear, but it never does.&nbsp; The 100 byte count constant causes the Read to timeout, but when I wire in a VISA Bytes at Serial Port I get the 0 byte count going in and the loop never detects the "END" string and is never ending.&nbsp; Could the termination character prevent a byte count from appearing?
Somehow the switching from serial ports messed up my entire process and it holds some similarity to your problems with Windows XP and serial port malfunctions.
&nbsp;
Thank you&nbsp;for any help and input,Message Edited by Steve.Briggs on 02-28-2007 10:57 AM

[centerbolt]

Dennis,
There is property that can be set via&nbsp; property node&nbsp;called "Serial Settings:Error Replacement Character".&nbsp; The documentation does not directly say what the default is.&nbsp; I suspect that it is a null character.&nbsp; If that is true, your error&nbsp;may be due to a error in the COM port and not the reception of the null character.&nbsp; You might want to try and put a scope on this and verify the actual character that causes the framing error.

[thisisnotadream]

Ananda--
It's difficult to say what could be causing the problems without seeing the code.&nbsp; You mentioned that your new version&nbsp;"scans through all the ports and determines the port it is supposed to talk".&nbsp; The problem may lie in this section of your code.&nbsp; What's the procedure for determining the correct port?&nbsp;
Dan