Why do I get a framing error?

[thisisnotadream]

Still confused.

As I mentioned earlier, all the serial setup is hard-coded.  The only option the user has is to select which COM port is connected.  On a PC with a PCI RS-485 card, it works.  On a laptop with a USB-485 adapter, it doesn't.  An old version of the software (which doesn't use VISA) works fine on both.

I am using VISA read, but I have always used the "Number of bytes available" VI prior to calling it to tell the VI how much to read.  I assume the serial device is being startup by plugging the USB adapter into the port.  In software, I call the VISA Configure Serial Port VI with all the settings.  The device I'm communicating with (actually, just listening to a periodic data packet) is probably already communicating when I start the software.  The user claims that he tried running the software and then restarting the talking device.  I wasn't there to verify.

I have noticed that disconnecting a device while it's talking often gives my software a bad case of gas, so I avoid it whenever possible.  This doesn't appear to be the case this time, though.

How to you "reset" the NI USB-485 devices to manufacturer settings?  I would assume this is done by unplugging and replugging the device...

[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!

[ananda]

I am getting exactly opposite of what you are getting. However, I am not using LabVIEW. I am using Visual Basic and my program works fine for a USB 485 but gets framing as well as break error when used with the NI PCI 485 ports. Like you said, it used to work for the old version of the software where it would open the first available comport. I changed in the new version so that it scans through all the ports and determines the port it is supposed to talk and it is getting all sorts errors. Any thoughts why that might be???

Ananda

[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    (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

[thisisnotadream]

Ananda--

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

Dan

[K C]

Message Edited by K C on 02-20-2007 03:07 PM

[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 ?

[thisisnotadream]

True.

For errors, my habit has been (for most cases) to close the port, report the error, and end the software.  If there was something flaky going on, with the old software, you could possibly never notice (assuming there were enough "good" packets for the eye to see), whereas with my software, you would be notified immediately.

Dan