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