Sending live data to another serial port

[Sakib001]

Hi,

I have a temperature readout from which I am receiving data into my computer via a serial to USB converter and getting it stored in an excel file using a LabView code. Now, I need to use these same live data to be fed into another device which also permits serial communication. Can I use " Serial Write" and and write live data directly into that other serial port (of the receiving device) using another USB to serial covnerter? I am a little confused. Any help is greatly appreciated ...

Thanks

Nazam

[Dennis_Knutson]

There is no such thing as serial write. You can, of course, use a VISA Write with a different resource. What are you confused about?

[Sakib001]

I am so sorry. I actually meant VISA Write  The thing is I need to have these data going into the PC and into the other device at the same time. But, if I use VISA Write and write data to the receiving serial port, it seems that there would be a time delay as data would first come into the PC throuhgh one com port and then go out through another. Thats what making me confused ...

[Dennis_Knutson]

Have you tried connecting both? Can this second instrument understand the first without any modification? Seems you need to test this first.

[James.M]

You can communicate with different serial devices at the same time, but if your data is coming from one, through your computer, then to another, it won't be instant.

Consider the following: if Dennis tells me that he "hates bagels" and wants me to relay that information on to Christian before the next NI Week, even if I'm the fastest talker in the world, Christian won't find out instantly.

Ideally, your devices can communicate themselves without your PC middle-man.

[Sakib001]

I actually tried that out today morning (connecting the two serial ports with one another). This is where it gets interesting. It seems that no data is being transferred from the sending to the receiving device (or maybe the receiver can not understand what the sender is sending). But, when I connect the first device to my PC, I get live data from my LabView code.

To get the idea of what is happening, I studied the code thoroughly (actually I wote it long time back and almost forgot the key points of it) and found that the code uses a loop in which it continuously asks the sending device for the most recent data using a "FETC?" command. But, as the receing device does not have option of sending a command like it, it is receiving nothing. Thats why I thought that perhaps I should send the data, that I am receiving through my existing code, to the receiving device using something like VISA write.

Is my explanation correct? What do you guys think?

[crossrulz]

Something you could try is to have your second device piggy back onto just the PC's RX signal of the serial port.  So your PC sends the fetch command to Instrument 1.  Instrument 1 then sends out its data.  Because the TX of Instrument 1 is connected to the RX of the PC and the RX of Instrument 2, both the PC and Instrument 2 will get the same data at the same time.

I do not recommend doing this in a noisy environment and do make sure all grounds for the ports are connected.

[Henrik_Volkers]

Did you check if the  baudrates and protocols of the two devices are the same?

I would run three loops in parallel, on producer loop reading the serial, that feed two queues to two consumer loops, one for saving and one (without indicators, different threat) to send the rigth data to the second device.

[crossrulz]

---

Henrik_Volkers wrote: I would run three loops in parallel, one producer loop reading the serial, that feed two queues to two consumer loops, one for saving and one (without indicators, different threat) to send the rigth data to the second device.

---

This would be the best route.  I would just use an User Event instead of two queues.  Makes it a little easier to pass the data to whoever needs it.

[Sakib001]

Humm, these are great ideas to get the data into the second device.

What about this: if I take a serial Y-splitter cable and then get one end (single port) attached to the sender and another end (dual port) to the PC and to the receiver. I think this may be one way of doing the piggybacking while keeping the noise out ...