09-12-2022 08:15 PM
Hello,I need to write 422 com port in one thread and read data from another thread. Is this possible for com port?
09-13-2022 01:34 AM - edited 09-13-2022 01:36 AM
@MayCN wrote:
Hello,I need to write 422 com port in one thread and read data from another thread. Is this possible for com port?
You're a bit thin in the information you provide! What is that thread you mention?
Generally you can of course read from a different place than you write but most instruments follow a strict command response pattern. It means they only answer after being prompted for and that has to be of course done in a strict order. When you then go and write in between such a command and response sequence to that instrument it gets utterly confused as it doesn't know anymore what this is. Even if you write the whole command always in one go you still have the problem of the both write functions not knowing which answer in the incoming buffer is for them (even if you simply write something to an instrument it usually will answer at least with an ACK or NACK message of some sorts.
Depending on the protocol your device is using, you might be able to simply wrap the write and read in a single VI and always only access the device through this VI. If you do not make it reentrant, LabVIEW will always arbitrate access to it. But that also slows down the loops that access this VI as each loop has to wait until any other loop has finished using that VI before it can run it. A bit more hassle with little added effect is to create your own semaphore and always try to acquire that before accessing the instrument and releasing it afterwards. This lets you try to access the semaphore with a short timeout and when it returns with a timeout indication you can decide if you want to wait more in a loop or rather do something else first.
Generally however, the best approach is to write a "daemon" (basically a VI with a loop that initializes the device and then waits for commands from a queue or similar from other parts of your program to perform, then does its thing and returns any answer in an optional notifier that your caller passed with the request.)
The next step is to go with a real message based framework such as DQMH or Actor Framework where this daemon basically is an independent actor.
09-13-2022 09:09 AM - edited 09-13-2022 09:13 AM
Short answer: Yes you can...
The numbers (RS422, RS485, RS232, etc.) just describe the physical interface
RS485, RS422 and RS232 Differences and Typical Applications
With today's modern electronics you can get a USB to RS(whatever you need) adaptor that will install a virtual com port when Windows recognises it.
That same virtual com port will also be recognized in NI-Max and therefore LabVIEW
Then you use VISA to communicate with your instrument just like any other instrument on a com port.
09-13-2022 10:29 AM
@RTSLVU wrote:
Short answer: Yes you can...
The numbers (RS422, RS485, RS232, etc.) just describe the physical interface
RS485, RS422 and RS232 Differences and Typical Applications
With today's modern electronics you can get a USB to RS(whatever you need) adaptor that will install a virtual com port when Windows recognises it.
As you stated, those define the physical interface for how bits are transferred. Most devices that use RS-232/422/485 use a UART protocol, which defines how the bits should be interpreted.
But do be warned. I once had an application where we were told the device was going to use a RS-422 interface. Of course we all just assumed we could buy a simple PCI or PXI or USB device that did a RS-422 UART. Nope! We later learned (luckily before we bought hardware) that the device was using a Manchester encoded protocol. So we had to get an R-series FPGA board to handle the encoding and I got my feet wet on LabVIEW FPGA.
09-13-2022 01:26 PM - edited 09-13-2022 01:27 PM
I forgot to recommend this video... this should save you from falling into the "Bytes at Port" trap.
VIWeek 2020/Proper way to communicate over serial