Most lab automation devices these days communicate through ethernet port, with some still using methods like USB. In order to integrate these different devices into larger automation systems, you often need a dedicated network. Many scientists can go a lifetime without having to know anything about networking devices, but knowing a bit about how these networked devices talk to each other can be helpful.
If your IT department is helpful about this kind of stuff, then you can just submit a request for help. I've also been in positions where I needed to set this up on my own to make things work, so here are some quick notes on how to go about setting up and troubleshooting simple networks for running a lab automation system. The advice below is very basic, but it can help you get started setting up your devices and learning about the power behind networks.
Parts of an IP address
But for simplicity sake, let's just say that there are 2 basic parts to an IP address, the network part and the host part. The first two numbers in the network ID generally doesn't change much, and most often the default network part is '192.168'. This is totally fine to use unless your company IT department has a different network part set up for you. but the third number in that Network ID will represent the Local Area Network address (think of a whole neighborhood). The Host ID represents the device address within that neighborhood. So for example in the image shown here, this device is configured to the network '192.168.1' and is given the unique device address of '34.'
Then you also have a subnet option, which is like a second address used to further segregate networks for organizations that have a lot of different hosts. If you are looking for more detail on that, is a link to Oracle documentation guides for configuring networks, which I recommend for nitty gritty details. For the purpose of this usage, we won't worry too much about subnets.
Setting up a basic network
Let's assume that all devices are communicating over the network. If you are using a network switch or hub, you need to declare the IP of that as well. The controlling computer also needs to be set to an IP on that same network. You can do this by connecting the hub to the computer through ethernet, and then finding the appropriate network in your 'Network and Sharing Center' in the control panel. Then you can click on the hyperlink of that particular Local Area Connection to configure. From there, you can use the images below to guide you through setting your IP address on the PC. Here you have the chance to declare your 'neighborhood' in the Network ID, so let's set this neighborhood to '2'.
Configure a Device on the network
If the Network ID of your device does not match the Network ID of your switch /computer, then you will not successfully be able to talk to it. This is a simple concept, but can be tricky to grasp at first. And we also want to be sure that the last digit representing the devices is unique on that network. Here we configured the device ID of the PC as '47.' Note that the subnet here is '255.255.255.0'. This is a default value that we will stick with.
Let's say for the sake of this demonstration, we want to set this device to '192.168.2.99' to ensure that we have a unique Device ID from the PC. Here is an example using electromechanical device control box that was built using Festo hardware, and the Festo controlling software is used to configure the expected IP address of that device. Note that if you if you configure the device to '192.168.2.47' (same as PC), you will have communication issues. This is a simple concept, but IP addresses are so pretty complicated.
To test whether your network is all configured properly, you can do so using you PC. Use command prompt (cmd) to 'ping' the device at the address you are expecting. If you can't do this, you probably have not successfully set the IP address that you were expecting.
open up the cmd prompt, and use the ping command targeted at the IP address that you are trying to reach - ping xxx.xxx.xxx.xxx
You can see that we got a successful response from the device at 192.168.2.99. This strategy will also tell you if the connection is strong or if there is data loss, which could indicate a properly configured system but bad connection (I'd replace cables at that point). if the device is on and networked properly, it will respond. Otherwise, you will get this response below. You can see there that the data is being lost, and there is no response from the machine at 192.168.3.99.. Of course to communicate with a device on that particular IP, you'd have to reconfigure the IP of your PC/network.
Once it responds, you can use integration software to control the device. Example in Hamilton Robotics software Venus, which is essentially a powerful development environment for lab automation integration. Here I'm using the control box to communicate with custom built devices on the system, and in order to do so I need to initiate a connection with that control box. By using the device driver library for this control box (shown on the left), we can send commands to it from our liquid handler. In order to do this, we need to specify the IP address of the Control Box to initiate a connection. You can see this is done by selecting the 'Connect' command from my device driver library, and using the specified IP address to establish the connection in my method. From there, I can use my liquid handler to send commands to other devices via the control box.
You can have other computers on your network this way, and there are plenty of tools out there for ways to automate tasks involved with upkeep of the clients on your network. Keep in mind, if you are storing sensitive data on your server, then you will be responsible for keeping that secure. Letting IT handle your networks comes with restrictions, but ultimately is the most streamlined option for labs who don't have access to data scientists.
It also doesn't hurt that vendors like Hamilton Robotics have some really talented programmers that can help provide working solutions for you. You can make vendors do this stuff for you, but I've found that nothing beats the speed and flexibility of understanding and controlling the network myself. Make sure to document the IP addresses that you set for quick reference!