How do you List and Manage your network devices?

[VinnyAstro]

Hi!

This is more of a networking question than a LabVIEW one, but since LabVIEW will be managing the application layer of the system I'm building, I hope it's okay to ask here. If not, feel free to point me toward a more suitable networking-focused community.

I’m working on a modular rack system for production testing. Each rack would include a power supply, multimeter, PC, and a custom "box" that embeds our own communication adapters (Ethernet-to-CAN, RS485/422, etc.) connected to various DUTs. The goal is to make these racks duplicable and plug-and-play: assemble, connect DUTs, and start testing.

Before looping in our IT department, I’m trying to explore options for the network setup so I can ask better questions and ensure smoother collaboration.

I'm considering two architectures:

1. One VLAN per rack:

   • Pros:

     • Easier device discovery from LabVIEW via broadcast messages.

     • Moving a rack to a new location doesn’t affect IP structure.

   • Cons:

     • Requires managed switches, which may increase costs.

2. Fixed IPs for all devices:

   • Pros:

     • Lower cost, simpler unmanaged switches.

   • Cons:

     • Harder to maintain (manual IP tracking, potential conflicts).

     • Less flexible if devices are added or updated without notice.

Objective:
From LabVIEW, I’d like to scan and monitor all devices across racks (for AdminPCs) or devices only inside the current rack (for the PC mounted inside the rack) —ideally without needing to hardcode IPs. I'm not sure how feasible this is with fixed IPs or if VLANs are the way to go.

Any advice or experience with similar setups would be greatly appreciated!

Thanks!

PS: for the interface, this a general idea I have for an "admin PC", overviewing all devices. A "local PC" (Rack mounting) would only see one of the parents on the tree

[Kyle97330]

It sounds like you're planning on having all devices on the same general network.  Is this really the case?

If so, is this a requirement, or even a "nice to have"?

I have always set it up so that my test PC has one network card that leads to the company network, and then one or more additional network cards that connect from the PC either directly to Ethernet-enabled equipment or private switches that do not connect to any other networks (just groups of equipment).  There are 3 main private networking spaces in IPv4 (10.x.x.x, 192.168.x.x, 172.16-31.x.x)

This both gives a dedicated channel to the equipment (meaning I don't have to worry about duplicate IP addresses) and isolates it (meaning I don't have to worry about multiple PCs trying to control the same equipment).

[Kyle97330]

---

@Kyle97330 wrote:

There are 3 main private networking spaces in IPv4 (10.x.x.x, 192.168.x.x, 172.16-31.x.x)

---

I realized later I didn't finish what I was typing here.  I meant to say "There are 3 main private networking spaces in IPv4 (10.x.x.x, 192.168.x.x, 172.16-31.x.x).  Your company probably uses just one of these, so the other two are likely both available to use as instrument networks on your PCs if you use separate network cards with no danger of duplicate IPs."

[VinnyAstro]

Hi Kyle, thanks for your answer.

---

@Kyle97330  a écrit :

If so, is this a requirement, or even a "nice to have"?

---

To be honest, I’m still figuring a lot of this out. It’s a bit blurry because I’ve never done this before, and in a small, old-school company (about 70 people, with just one IT person), trying to build something new often means doing everything yourself. On top of that, the whole system is being developed in parallel—so requirements keep shifting as I discover new things along the way.

---

@Kyle97330  a écrit :

It sounds like you're planning on having all devices on the same general network.  Is this really the case?

I’m not fully sure what this would involve.

The DUTs (actually comm adapters) are connected to a switch and talk to one test software (running on the Rack PC or on another PC, see my list below). They’re “half-smart” — they send status updates like standby or busy, so other test software can know if they’re free, but otherwise they just relay commands and telemetry.

Whether the switch needs to be on the general internal network is still unclear but I would say yes (because I'm interested in centralized monitoring, see below)

---

@Kyle97330  a écrit :

I have always set it up so that my test PC has one network card that leads to the company network, and then one or more additional network cards that connect from the PC either directly to Ethernet-enabled equipment or private switches that do not connect to any other networks (just groups of equipment).  There are 3 main private networking spaces in IPv4 (10.x.x.x, 192.168.x.x, 172.16-31.x.x)

---

What exactly is the point of this (both dual network card and extra-private network)? Cybersecurity or avoiding to clutter the network? Also side-note: what's 172.16-31.x.x? I have never seen an IPV4 address written with a dash.

I like the idea of a private network, it would likely leave a clean space. But I would still need to see if other PCs could access it or not.

To clarify the requirements I have so far:

• Each rack controls up to 5 DUTs, either simultaneously (same test) or independently (different DUTs/tests).

• Each rack has a PC connected to the network for:

  • Test data and report upload

  • Test-Software/OS updates + DUTs firmware update

  • Accessibility in Remote control via Windows Remote Desktop is an absolute.

• Network access should allow:

  • At least one-way remote access from personal(VPN) / Office PCs to test PCs

  • Ideally, two-way remote access (From Test-PC to Office PC)

  • Automated report generation and file transfer to servers
    (Note: I think IT wants to splits servers between "test" and "main" environments (basically production data vs contracts and reports data), with some access restrictions between the two thus my concern with the remote accesses.)

Nice-to-haves (still under evaluation if they're nice to have, or actually necessary):

• Ability for other PCs (on the test network) to control DUTs on the rack when the embedded PC is in use

  • Useful if one person is using the rack PC, but others need access to some DUTs

• Ability for other PCs (on the other network) to control DUTs on the rack 
  • That's specifically necessary when VPN is in play, working remotely is often happening here, either because of quick checks over the weekend, or simply because of employees needs.
  • This could be split between VPN access to Remote control of Rack PC and/or VPN direct access to DUTs control.

• Centralized monitoring of all test racks (I believe this is more Application, rather than purely network):

  • Admin overview (e.g. test status, errors)

    • This can be the control software (running on PC) updating its own status (how many devices it controls and their statuses) and I have a seperate application collecting all these statuses
    • Which is very much different than the Communication Adapter (which I've been referring as our DUT but in reality its an additional bridge) updating its status on the server directly (and not through the controlling PC)

  • Operational tracking (e.g. test progress, DUT availability, board matching)

That's a lot of words, sorry for that, I tried to keep it simple...

[Kyle97330]

"What exactly is the point of this (both dual network card and extra-private network)? Cybersecurity or avoiding to clutter the network? Also side-note: what's 172.16-31.x.x? I have never seen an IPV4 address written with a dash."

It might be more of a concern to different applications.  My company uses devices that can actually be dangerous if activated accidentally (powerful motion controllers, high-energy lasers, power supplies for them, etc.).  So while part of that is just keeping the networks "clean", an even more important part is being 100% sure that nobody can connect to the wrong device and energize something that could be destructive.

"172.16-31.x.x" is just an easier way of saying "the IP range between 172.16.0.0 and 172.31.255.255" and what I thought was a clearer way of saying "172.16.0.0/12", which is how networking professionals would likely define it.

It does look like your general request here isn't terribly LabVIEW-related, though.  I'm not a networking professional, I just learn enough to keep being able to safely fire lasers.  You might have better results posting on forums with a more networking-related focus, then coming back if you need help designing a LabVIEW architecture to work with the solution you create.

[VinnyAstro]

---

@Kyle97330  a écrit :

It might be more of a concern to different applications.  My company uses devices that can actually be dangerous if activated accidentally (powerful motion controllers, high-energy lasers, power supplies for them, etc.).  So while part of that is just keeping the networks "clean", an even more important part is being 100% sure that nobody can connect to the wrong device and energize something that could be destructive.

---

That's a good point, I'll look into that, I don't think there's a huge risk for people, but some devices are powered with 5V, others with 28V so I'll need to find a way to avoid accidental changes.

---

@Kyle97330  a écrit :

It does look like your general request here isn't terribly LabVIEW-related, though.  I'm not a networking professional, I just learn enough to keep being able to safely fire lasers.  You might have better results posting on forums with a more networking-related focus, then coming back if you need help designing a LabVIEW architecture to work with the solution you create.

---

Fair enough, I'll try and find a good network community (pun not intended)

However if you have some recommendations on the centralized monitoring, I'll take it. (The idea to have multiple Test software running on various PCs sharing their status to another application elsewhere on the network.) I was thinking of maybe using Shared Variables for the first time, since it is only about sharing status. But I will have to watch out to not saturate the network I guess.

[rolfk]

As long as it is about NI hardware mainly, or hardware that corresponds to general VXI PnP standards such as LXI, VXI-11, or HiSlip, you can most likely work with a combination of NI System Configuration API (for all NI related hardware) and VISA for the VXI PnP stuff, to discover the various hardware components. If it is about other 3rd party hardware, things get a lot more involved as each tends to have their own way of being discovered.

There are many so called ZeroConf network discovery technologies, some being partly compatible, but often also completely independent islands, vigorously trying to defend their independence. 😁

And each of these technologies tends to have their own APIs that also can vary greatly from OS to OS. Interfacing to them from LabVIEW, while not impossible, is usually quite a bit of work.

As to organizing: Unless you have a shared resource that needs to be available from different places, it should all be on a private network on your test station. You do not want Pete from the next room to suddenly control your oscilloscope in the middle of a test run, because he got the network address wrong (or just wanted to prank you).

For providing status information to an overarching service or performance monitor application I would recommend to use a standard protocol. Shared Variables while possible, would limit you to LabVIEW only monitoring applications that you need to develop and maintain too. System Link would seem more appropriate here but is largely an NI locked in technology too, despite that it is build under the hood on SaltStack, which is based on ZeroMQ. NI's recommendation for sharing SystemLink data through OPC UA to other systems is a good one, but if you build your own application framework anyhow with a substantial part of non-NI hardware, you may as well just incorporate the OPC UA interface directly in your various apps to share data with your management system.

[VinnyAstro]

Hi Rolf,

---

@rolfk  a écrit :

As long as it is about NI hardware mainly, or hardware that corresponds to general VXI PnP standards such as LXI, VXI-11, or HiSlip, you can most likely work with a combination of NI System Configuration API (for all NI related hardware) and VISA for the VXI PnP stuff, to discover the various hardware components. If it is about other 3rd party hardware, things get a lot more involved as each tends to have their own way of being discovered.

---

Nothing is NI Hardware. Most of it is an in-house specialized solution, the power supply or other equipment we have are usually fairly compatible with labview (as in they provide libraries that are not too bad at least for starters) but that's about it.

---

@rolfk  a écrit :

As to organizing: Unless you have a shared resource that needs to be available from different places, it should all be on a private network on your test station. You do not want Pete from the next room to suddenly control your oscilloscope in the middle of a test run, because he got the network address wrong (or just wanted to prank you).

---

Yes, that's pretty much what Kyle was mentioning too.

The problem is I think only the test station accessing this equipment is, for some test stations, fairly limiting (lack of space in general, leading to having to share the same test station) 
While we do have "flying" computers in our test facilities that could be used for that.

But you're right, I'm just thinking of how much more problem that will bring when people don't close the software/keep the connection open for days etc. I need to think this through a bit more.

By "private network on your test station" you mean really a small VLAN dedicated to the Rack my equipment is mounted in ?

[rolfk]

---

@VinnyAstro wrote:

By "private network on your test station" you mean really a small VLAN dedicated to the Rack my equipment is mounted in ?

---

Yes! I usually have a local network with a small hub on which all the hardware is located. This is connected to a seperate network interface on the computer. The computer then may or may not be connected to to the campus network, either through a separate wired network connection or through Wifi. This campus network connection allows to store data on shared network locations or enables remote monitoring software to access the PC. This is for isolated use cases with each researcher having their own system they work with. With higher security requirements the system may be completely disconnected from any other network. It all depends on the requirements.

[VinnyAstro]

Ok, thanks for the tip, I'll think about it.