From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
02-09-2007 10:20 AM
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...
02-09-2007 11:13 AM
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,
02-09-2007 11:49 AM
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!
02-19-2007 09:44 PM
02-20-2007 01:52 AM
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.
02-20-2007 07:56 AM
02-20-2007 07:58 AM
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
02-20-2007 08:04 AM - edited 02-20-2007 08:04 AM
Message Edited by K C on 02-20-2007 03:07 PM
02-20-2007 08:05 AM
02-20-2007 08:11 AM