VISA vs TCP

[DailyDose]

Hey LabVIEW community.  Allow me to apologize beforehand, this is not the most "LabVIEW' related question.  More of a design question that I thought I'd ask the very smart people in the NI community.

I am updating a system that used LabVIEW to talk to a serial device and of course send and receive commands/messages while doing various other things.  The client has requested that they now be able to take the laptop to a decent distance and still be able to control the system by plugging into an ethernet port.  The system uses a cDAQ with ethernet.  I know it's not wise to try to send serial at any amount of long distance.  The question here is: is it possible to convert the RS-232 data to ethernet and then convert back to RS-232?  Or should I be trying to send the data on the network via TCP and have a converter on the other side that just converts the TCP data to RS-232 and if there are any messages to be read... somehow figure out a way to decipher that from any other incoming data?  Idk, I'm kind of stumped on this one.  Cuz I don't want the client to be carrying around converters with the laptop either.  Any thoughts?  Again, sorry about this sort of LabVIEW question.

[nathand]

I don't quite understand the question. First, what role does the "cDAQ with ethernet" have in this? Does the serial device plug into the cDAQ, or into the laptop? What are the roles of the cDAQ, the serial device, and the laptop? A simple diagram would help.

You can get a terminal server that converts serial to TCP and vice versa; you can also get a serial extender (such as https://www.startech.com/Networking-IO/Serial-over-IP/RS-232-Serial-Extender-3300-feet-1000-meters~R...) that lets you run serial a longer distance over a CAT5 cable (which is identical to an ethernet cable, except the data it carries is not TCP over ethernet).

[DailyDose]

I've attached a very simple picture of the system.  The serial device (let's say) is a servo and the cDAQ is not necessarily important except for the fact to inform that networking is invovled.  The terminal server idea sounds intriguing, however, like I mentioned I'm trying to limit the amount of things the client needs to carry outside of just the laptop.  I will investigate what a terminal server is.

[DailyDose]

Should also have pointed out in that picture that the data needs to be converted back from TCP to RS-232.  So how will it know the IP?

[nathand]

Will the servo and the cDAQ always be near each other? If so, do you have the option of plugging the servo into the cDAQ?

If you use a terminal server (also sometimes described as a serial server, or serial/232 to TCP converter, such as http://www.moxa.com/product/NPort_DE-311.htm), you will need to assign a specific IP address to the device. Most of these servers come with "virtual serial port" software that lets you use the remote device as though it were a serial port, even though the data is transmitted over TCP.

[DailyDose]

Hmmm... is there an RS-232 C Module and then that would just communicate wtih the Motor?

[DailyDose]

Ah dude, ok, looking at that Serial Server, that looks exactly like something I want.  I saw NI had something similar where NI Max would locate it and offer it as Serial ports.  The problem, of course, is that NI wants to charge $700 for it and I'm probably already over budget. 

Anyways, I think this is the solution to my problem.  Will this run as a service or will it need to be turned on each time the lap top is booted up?

[nathand]

The virtual serial port driver will set itself up like any other driver, no need to run it specifically each time the computer starts.

I think (but am not certain) you can get an RS232 module for the compactDAQ, although it will probably cost more than a one-port terminal server.

[crossrulz]

---

@DailyDose wrote:

Hmmm... is there an RS-232 C Module and then that would just communicate wtih the Motor?

---

NI has a couple of them, but they only work with cRIO.  They will not work with a cDAQ.

[Bob_Schor]

I can't look this up until I'm back in the Office on Tuesday, but I know we are reading some Mettler balances that are several floors away from us.  To our code, they "look like" VISA devices, but I'm pretty sure that the connection between us and them is TCP/IP.  If this thread seems still "active" and without a resolution next week, I'll go take a look and see how my colleague did this.

DailyDose -- if you haven't heard from me by, say, Wednesday of next week and still "are looking", shoot me a Private Message and tell me to "get moving" (or words to that effect).

Bob Schor