LabVIEW
How do you List and Manage your network devices?
I use whatever makes sense for the hardware involved. For NI hardware this is usually DAQmx or whatever API the hardware provides. For T&M instruments, this can be the Plug&Play driver for that instrument which usually uses VISA (the advantage here is that if the driver follows a few specific rules it works for communication through GPIB, RS-232 and TCP/IP all the same). Even if the device does not have a ready made Plug&Play driver I may choose to develop my own based on VISA because it has certain advantages when communicating with typical T&M devices and easily allows to connect that device up through RS-232 or GPIB too, without needing to modify the driver.
For other hardware, I use the native LabVIEW TCP/IP (or UDP) nodes or a native driver (usually in the form of a shared library/DLL).
However your talk about layer 2 makes in none of these cases any sense. They all operate on TCP/IP or UDP level, which is layer 3. You have an IP address, either numeric or alphanumeric and communicate with that, but the protocol is TCP/IP or UDP based. Trying to communicate on layer 2 is only really useful if you want to implement your own network protocol for some weird reason (super realtime or whatever capabilities maybe). But that is NEVER something to do on application level, this really is a low level driver task and that pretty much excludes even a user space shared library. This is something that should be implemented in a kernel driver and if you were capable of doing that you would hardly be here on this forum asking these questions. 😁
Those network cards cost nothing nowadays. And you can also explicitly look to buy PCs with dual network. Not exactly the cheapest models on the market but for a test station you do not want to be on the cheapest hardware anyhow. Those work for infrequent home use and if they fail it’s annoying but not a disaster. In production, a day of failure can be more expensive than a high end computer.
A simple but good PoE hub can be had for $ 100, a bit more if you want a DIN-rail model to put in an e-cabinet. Hardly a big expense either.
USB can work well if you use self powered hubs but not for 24/7 non stop operation. USB is often ill equipped for long term stable operation. Even relatively good hardware including PC USB ports can misbehave, because of Windows power safe attempts and poorly written firmware drivers. They are often OEM hardware where the original manufacturer stops developing drivers the moment the product is first shipped and the OEM customer is not always able or willing to maintain those drivers themselves.
If it is about testing your hardware devices, this is less important as it is mostly about connecting your device, running a number of tests and then slapping a QC sticker on the PCB and boxing the stuff, but test equipment that is used day and night, is often not as reliable when connected through USB. And you may somehow have to test both interfaces on your hardware if it has them anyways.
@VinnyAstro wrote:
Just to be clear, when you say Ethernet hub, you mean a switch, right? Finding a hub isn't that easy anymore as switches replaced them for many reasons.
I use the term hub very broadly and the difference to a switch is in most use cases minimal. Only when you go to truly intelligent (managed) switches do you get into a rather different type of realm, but that is for data centers and professional IT. Self managed switches are more intelligent in how they route the data between different ports and improve performance in that way, but from the viewpoint of a user they are really pretty much the same.
