08-10-2011 08:51 AM
I have a test setup where another application is communicating with a device over a serial port and I want my Labview gui to be able to listen to the communication. Since two applications cannot have the same serial port open I can't just open the port and do a visa read. Is there any way to do an unreserved open and only listen to communication on the serial port or do I physically have to break out the receive line in hardware and add a second serial port in order to do this?
08-10-2011 10:11 AM
A better solution would be to have your reader post a message to a queue with the data. You can have a separate task that handles the UI updates. Depending on the type and amount of data you may not need to post all of the data.
The answer to your specific question though is no, you cannot have two readers on the same connection.
08-10-2011 11:25 AM
If it is a 3rd party application, that would be difficult. You could have write a program that will receive the data on one port and transmit to another, as well as receive and transmit back to the original port. It would require 2 extra ports. The original port into spare 1, and spare 2 going to the previous output. I used it to manipulate and filter the serial strings so I could add functionality to a process without modifying the original 3rd part program. I used a laptop and a two port NI USB to serial device.
08-10-2011 01:10 PM
You need external hardware to sniff the serial port data between the two devices.
http://www.fte.com/products/serialanalyzers-sniffingRS232.aspx
08-10-2011 03:19 PM
You did not mention what operating system you are using, but another possibility would be to use something like PortMon if you're on Windows. You could set it up to log to file and read the file from LabVIEW. I'm not sure if Portmon keeps a lock on the file, so I'm not sure if you'd be able to read the file from LabVIEW as it's written. One known limitation is that PortMon doesn't work on 64-bit systems.
08-11-2011 06:59 AM
Not sure what version of LV was the first to include this, but there is a set of functions that allow a LV app to directly control NI Spy. Should show up under Measurement I/O>NI Spy
08-11-2011
07:35 AM
- last edited on
12-02-2024
06:32 PM
by
Content Cleaner
If it a third party app and portmon (as Saverio mentioned above) does not float your boat then an extra serial port and custom wires can be used. I did that in this project (that I subtitled "Measuring the diameter of a pretzel) where I had to log data from a serial GPS feed while some commerical software was using the same unit to plot the postion on naviagational charts in real-time.
The cable ws sjust split and what came in one side went out the other.
Ben
12-10-2018 04:57 AM - edited 12-10-2018 05:03 AM
In-case anyone else bumps into this thread for solutions...
I have recently discovered ttybus.
Here is a sketch of how it works and may be used:Here are the commands for copy paste:
# STEP 1: create a new tty bus tty_bus -s /tmp/ttyS7bus # STEP 2: create virtual tty device, attached to the bus: tty_fake -s /tmp/ttyS7bus /dev/ttyS7virt # STEP 3: connect the real device to the bus using tty_attach tty_attach -s /tmp/ttyS7bus /dev/ttyS7 # SNIFFING create virtual tty device, attached to the bus: tty_fake -s /tmp/ttyS7bus /tmp/debug # WATCH output in terminal: screen /tmp/debug ## Remote machine # STEP 1: create a new tty bus called tty_bus -s /tmp/remote_ttybus # STEP 2: connect the two buses on the two hosts, using remote ssh command and tty_plug: dpipe tty_plug -s /tmp/remote_ttybus = ssh user@host tty_plug -s /tmp/ttyS7bus # STEP 3: create virtual device, attached to the bus: tty_fake -s /tmp/remote_ttybus /tmp/debug # WATCH output in terminal: screen /tmp/debug
ttybus binaries for sbRIO-9627 are attached.
12-10-2018 05:21 AM - edited 12-10-2018 05:22 AM
I've used com0com in the past.
It doesn't do exactly what OP was looking for (8 years ago), but it can do that (and more).
You can actually make the application send data to a virtual serial port, route that to TCP\IP, monitor (and change!) the data, and send it to another TCP\IP port that is directed to a real serial port.
This does mean that even if you don't change the data, you need to redirect it in a simple running program. But it's well worth the money (0$).