LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RS485 communiciiton via USB-RS485 convertor

 Hi all,

 

I have a system where I need to read/write from multiple RS485 devices via NI-VISA. I am opening the com port that is connected to USB to RS485 converter and have for this test 2 RS-485 devices that are connected over that bus (I am using unique ID's fro each device so when I send it over the bus ONLY the device with that ID is responding). When using only one 485 device there is no problem and I continuously read and write to that device over the bus. But when I have two devices it starts working OK but after some time it seems that one of devices is not responding and the loop is hanging while waiting for Number of Bytes at Serial Port. I have discovered that if I send again the same command ID then I receive the answer from the appropriate device. Each device is sending first 6 bytes header with info how much bytes it will send. 

The sequence I use is: Write to COM port 3 bytes that identify the device ----->>> Wait for Number of Bytes at Serial Port----->>>Read the answer from that Device->>>> than same for the second device and loop again.

 

Why is this happening? Any ideas?

Thanks,

0 Kudos
Message 1 of 13
(4,623 Views)

I cannot open your vi because of my old LabVIEW version, so I cannot see what's the format of the "command" and what is expected as answer. However, keep in mind that the idle device will receive the answer of the other one. Is it possible that this answer contains a 3 bytes sequence triggering a multiple data transmission? If both devices transmit more or less at once, you will not be able to get the correct answer.

Another possibility: you don't have any wait between subsequent commands and occasionally one of the devices does not release the serial line fast enough; in this case, the command may not be properly received.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 2 of 13
(4,597 Views)

Hi Paolo,

Thanks for your reply. The command is a 3 byte ID for each device and all of them are being called one after one so they should not transmit at the same time. After sending the 3 Byte ID the app first reads 6 bytes header telling how many bytes is the data packet  to be read (2 VISA reads). After that the same is done for the second device and so on. Like you said it seems like at some moment the command is not received properly. However this is a timing sensitive application so adding a Wait[ms] is not recommended.

 

Thanks again,

 

0 Kudos
Message 3 of 13
(4,587 Views)

The needed Wait may be as low as a few tens of ms. I would try anyway as a diagnostic test. If this the reason of the failure, you would loose data anyway from time to time.

Still you did not answer to my first question, i.e. whether a subset of the data packet to be read may mimick a 3 byte ID.

 

 

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 4 of 13
(4,576 Views)

Hi Paolo,

 

I've tried the wait function but still the same issue.

Regarding the 3 Byte ID it is possible some of the data packets to mimics the 3 byte ID. Since each of the devices is sending lot of data it is possible that some of the bytes while sending contains the same 3 Byte ID of the other device. I will make some tests and let you know.

 

Thanks again, 

0 Kudos
Message 5 of 13
(4,563 Views)

Why did you put a wait loop with a call to Bytes at port? This is absolutely meaningless action, which also loads the processor. The function VISA look async is also useless. In the COM port driver settings, set the FIFO receive buffer size to 1. This will reduce read delays to a minimum. Make sure that the second device does not respond to the command for the first device and vice versa.

If you have two-wire RS-485, then the protocol of exchange should be more strict. Namely: A command's alphabet should never overlap with the answer's alphabet. See, for example, the protocol for exchanging devices such as ICPCON i-7017.

Labview 4.0, 5.0, 6.1, 8.6, 2009, 2011, 2012, 2014
If you do not know something, ask me.
0 Kudos
Message 6 of 13
(4,555 Views)

Hi,

I have made some tests by using two devices that communicate on the same RS485 bus. When I set the devices to transmit fixed values i.e. one transmits 0xAA  and the other 0xBB then there is no problem. So it must be something with the addressing of the slave devices. Any ideas?

 

Thanks,

0 Kudos
Message 7 of 13
(4,476 Views)

Unless you can figure out two 3 byte sequences that will never be output as data - and assign those sequences as device adresses, the cheapest workaround is to use 2 serial ports. Any other action, if ever possible - it would be necessary to change the communication protocol - would cost a significant work.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 8 of 13
(4,467 Views)

I also think that the first answer from pincpanter is the key to your problem.

 

Consider this: The answer from one of your two devices contains the strings 761 or 981. Since the second device will listen to the communication on the bus too, it probably will interpret these bytes as a command and will start to transmit its answer. After that your communication will get out of sync.

 

Regards, Jens

 

EDIT: I just read that you assume yourself that the datastream from your devices can contain the command strings. Excuse the duplicate answer.

 

About your devices: Can you influence/change the protocol. It is not fail-save in this constellation.

Kudos are welcome...
0 Kudos
Message 9 of 13
(4,466 Views)

Thank you Jens and Paolo,

 

Do you have any suggestion for a simple RS485 protocol? I need just proper addressing of the slaves. Each device will respond with dynamic data once being called.

Thanks again,

 

0 Kudos
Message 10 of 13
(4,458 Views)