04-27-2022 08:17 AM
This is a question for you serial RS232 experts:
I have some software that communicates with various types of instruments using RS232. Many of those instruments use no flow control at all. So there are only 3 pins of the RS232 connector that are being used: GND, TX, RX.
Data from the instrument comes in packets, and sometimes those packets are infrequent (eg at 5 second intervals)... so we can sometimes have pauses with no data being received for ~5 seconds.
My goal is for my software to immediately (or as quickly as possible) detect when the instrument is disconnected. My current method is to use a timeout... so if no data is received in a 10 second interval, then communication has been lost. But it would be great to detect this quicker. The slow 10 second pause leaves my users wondering what is going on.
Is it possible to detect that disconnect immediately when there is no flow control at all?
04-27-2022 08:31 AM
More of a design issue and not a LabVIEW problem.
The obvious first thought would be some kind of heart-beat message. It could be as fast as you want... 1 second? 0.5 Seconds.
04-27-2022 08:33 AM
Thanks. Yes, this is definitely not a LabVIEW issue. I am working under the constraints of the instrument and how the manufacturer decided to create this interface.
04-27-2022 08:44 AM
A simple query of the instrument's FW version would suffice as a heart beat msg. As long as you don't DDOS the instrument.
04-27-2022 09:11 AM
@josborne wrote:
Thanks. Yes, this is definitely not a LabVIEW issue. I am working under the constraints of the instrument and how the manufacturer decided to create this interface.
Unless the device send data at regular intervals there is no way to tell if an RS-232 device is connected or not without polling it to see if it is connected or not.
04-27-2022 09:32 AM
Although probably useless, I would try to use a fully connected RS-232 cable and check if any of the unused lines (RTS, DCD, RI etc.) changes its state when the cable is connected/disconnected.
04-27-2022 10:19 AM
You could also just loop back some of the RTS/CTS lines at the "device" side of the cable. Figure out what they are with nothing connected, then use property nodes to set the output to the opposite of that. Check every half second or so to see what it is, then you'll see when it's disconnected.
04-29-2022 06:07 AM
The most simple solution is probably to abuse a query command to periodically ask for some identification such as firmware or other version information. The challenge here is that you need to serialize this properly with other requests in your application. If it is Actor based, or a similar message based architecture, it’s very easy to add that to the actual actor whenever it had not go communicate for a certain time with the device to serve other requests.
The only other way, as Bert proposes, would be to modify the cable on the device side to loopback some handshake line, but that would not suffice to detect that the device was really connected to the cable. That would require a modification inside the device which in most cases is likely not a real option!
04-29-2022 06:57 AM
@rolfk ha scritto:
That would require a modification inside the device which in most cases is likely not a real option!
At least it would need a modification in the external connector of the device. I would be reluctant to do this as well.
04-29-2022 10:29 AM
If your application is sending a whole lot of units to customers, modifying the device isn't a great option. If it's a one-off in your lab it might not be a big deal.
The easiest solution is definitely a heartbeat signal (query version, current settings, etc) like someone else said and set your timeout to something like 1 second or 0.5 seconds.
But if you MUST have a hardware solution, you could either modify the internal connector on the device to loopback some lines, or you could screw mount a custom PCB with a pair of DB9 connectors on it that does your loopback externally. Your user would then connect and disconnect from this terminal rather than the one actually on your unit.
And if this is actually a USB serial connection on the device (i.e., not a USB to serial converter cable, but internal to the device) then you should be able to see it error out when it disconnects.
Are you able to tell us what your device is?