LabVIEW
Communication via USB cable between 2 PCs
Solved!
Hi ahmed,
@ahmedmaken wrote:
I currently trying to send an input that I put from computer A to be output in computer B. I can only use USB ports and a USB cable.
This is NOT SUPPORTED by default USB ports of typical computers!
Infact you may damage one or both computers when connecting them via USB cable!
@ahmedmaken wrote:
My main problem now is how to establish a connection/communication to the other computer?
Anyone had a simple method on how I could do it?
What about using a simple (direct) LAN connection between your two computers?
What about an old-fashioned RS232 connection between your computers?
@Kevin_Price wrote:
@GerdW wrote:
What about an old-fashioned RS232 connection between your computers?
Just to expand on that a tiny bit -- you could outfit both PC's with a USB-to-RS232 adapter. Folks around here advocate the ones that use the FTDI chipset. This makes use of the physically available USB ports, but lets you communicate with regular serial which is *much* simpler than dealing with USB at the low level you would need.
Exactly what I was going to suggest. I am personally a fan of StarTech devices. The industrial USB-Serial adapters I like (4 port) use a TI chipset. For a much less expensive route, Trendnet's TU-S9 has also been very reliable for me even with a Prolific chipset.
So with 2 USB-RS232 adapters and a NULL Modem cable, you can have two computers talk over a simple COM port.
Why is "USB to USB" a requirement? Every computer I know of has some kind of networking capability. "I can only use..." the way this is worded, it sounds either like a homework problem or a slight case of language barrier. At any rate, if you can tell us why you have such a constraint, we may be able to find a better solution for you.
As already mentioned this is not a standard supported feature of the USB bus. USB was designed as a point to point, controller and servant connection. One side, also called the host, is the controller while the other side is the servant and device. There used to be even a physical distinction with the host using the rectangle USB-A connector and the device using a square USB-B connector, and the whole USB protocol is very centered around the fact that one side is the controller (and bus negotiator) and the other side is the device which just sits there and does nothing else out of itself than signalling its presence to the controller.
The whole software stack in your computer is designed to provide this controller functionality and to operate a USB port in a computer as a device requires quite special software drivers that are not standard built in in many OSes.
Also you will be hard pressured to find USB cables with both an USB-A connector on each side, just as there are no cables with an USB-B connector on both sides, simply because USB was never designed to work between two hosts or two devices. With USB-C the physical distinction has gone away, but the logical distinction is still very much there, baked into every major OS from 25 years of USB adoption.
Smartphones take a bit of a special position here. Traditionally their USB connector is operated in device mode as it was quite common to want to connect them to your computer USB-A connector, which is always a host connector. But smartphone manufacturers also found it useful to let a smartphone connect to other smartphones or devices and for that they developed the USB OTG (On The Go) functionality where the USB port can adapt to the other side, working either in host, device or OTG mode). But there are no OTG USB interfaces for computers AFAIK. There may be some in the future as USB-C is physically very much able to connect together but that will take some time to appear as a standard feature in computers.
If your two computers have an RJ-45 Ethernet connector, it would be easier to configure them both with a static network address in the same subnet and just connect them together. You don't even need a special cable for that since all Ethernet controllers in the last 10 to 15 years support Auto MDI-X, which will detect internally if the communication pairs need to be swapped, making the requirement for an external null-modem cable or crossed cable unnecessary. To talk over these you simply use the built in TCP or UDP nodes in LabVIEW, or you can also use VISA if you want to only use TCP and want to make it easily switchable to a RS-232 connection instead.
If that is not an option, I would use two USB-RS232 adapters, as was already proposed, and connect them together. Here you will need a null-modem cable as RS-232 doesn't support auto negotiation of wire functions. To talk over these you can then use VISA functions in LabVIEW.
