Recommended Networking for Data Collection

talldude42 · Feb 2, 2021

I wanted to get some opinions and maybe a point in the right direction for products on networking machines for data collection. Im not all that familiar with the networking side of things.

Data would be coming from about machine PLCs. Each machine cabinet has an Ethernet switch. The original thought was to run the PLC to the cabinet switch, from the cabinet switch to a larger ethernet switch at the end of each isle (would need 3), from the larger ethernet switches to the server where the data acquisition software will take the raw data format and convert it.

How does this all sound? Would it be more beneficial to use a wireless setup? If so what would anyone recommend. The longest run from the office would be about 170ft.

RockyLeafs · Feb 2, 2021

Pretty sure ethernet runs are good for 200ft...

When we build equipment we make it SQL/Data Collection 'ready'. We generally make the customer responsible for data collection. The PLC handles the information gathering and the sql collects when needed.
Pretty sure a customer who uses a single server for datacollection on multiple machines uses Inductive Automation Ignition software.
They have a free trial as well. Works for 2 hours and then you can reset it and keep using it. Good for testing, but we've ran into issues with the Ignition software slowing down production (customer requires we ensure sql writes are complete before moving on with a process). So if SQL server is slow they usually see it in their production numbers. Wouldn't hurt to give it a try. They have some good tips on setup and I believe Ignition has HMI support as well.

RockyLeafs · Feb 2, 2021

Also, as far as the networking side...
Each time we build them a machine, we supply a Layer 3 Cisco Managed switch. The machine gets assigned a specific IP address range (for example 10.1.100.xxx for one machine and its devices, 10.1.101.xxx for the next machine, and so on).
Each managed switch is then connected to their server manage switch. Not being in IT i'm not completely familiar with how they do it, but I know they specifically assign port 24 to connect to the Plant Switch for each machine we build for them.

AkaHammer · Feb 2, 2021

Ethernet good to 328 feet we use 300 feet as the rule, that's straight wire when you go thru a switch most all switches now days are also a repeater, so then you can go another 300' etc..

Robb B · Feb 2, 2021

I would not recommend wireless, too susceptible to interference, noise, lost signals, etc. particularly in industrial setting. You may want to do a bit of data rate calculations, list all the data points you want to save in a database, frequency of data. You might find a bottleneck somewhere upstream.

James Mcquade · Feb 3, 2021

i use managed switches.
my best advise is this.
KEEP the plant network away from management !!
they know nothing about plc programming and will want to the software installed on their pc so they can look at things. they will change timers, counters, data registers without knowing what they are changing ad you will have a mess.
Also, this isolates the plc's from the internet so others cannot hack in and snoop. be sure to have a switch on each machine that has a spare port for the laptop to connect to the system.
if you set the system up correctly, you could have a central pc connected to all
machines as a central debug location for maintenance, BUT ! only 1 pc will be allowed to be connected to the plc at a time !
james

talldude42 · Feb 3, 2021

RockyLeafs said:
Pretty sure ethernet runs are good for 200ft...

When we build equipment we make it SQL/Data Collection 'ready'. We generally make the customer responsible for data collection. The PLC handles the information gathering and the sql collects when needed.
Pretty sure a customer who uses a single server for datacollection on multiple machines uses Inductive Automation Ignition software.
They have a free trial as well. Works for 2 hours and then you can reset it and keep using it. Good for testing, but we've ran into issues with the Ignition software slowing down production (customer requires we ensure sql writes are complete before moving on with a process). So if SQL server is slow they usually see it in their production numbers. Wouldn't hurt to give it a try. They have some good tips on setup and I believe Ignition has HMI support as well.

The machines are in house machines. We have not collected data from equipment before. The data from the PLC isnt in the format we need for our office software to use. So the controller compatible data collection software is going to collect, convert to SQL format, so office software can use it.

I will look at the ignition software. Thanks!

talldude42 · Feb 3, 2021

RockyLeafs said:
Also, as far as the networking side...
Each time we build them a machine, we supply a Layer 3 Cisco Managed switch. The machine gets assigned a specific IP address range (for example 10.1.100.xxx for one machine and its devices, 10.1.101.xxx for the next machine, and so on).
Each managed switch is then connected to their server manage switch. Not being in IT i'm not completely familiar with how they do it, but I know they specifically assign port 24 to connect to the Plant Switch for each machine we build for them.

Each machine cabinet has an un-managed switch. The I am currently using the switch connect the HMI to the PLC with available ports to connect laptop so I can connect to both simultaneously. My plan was to connect to that to send data out. Each machine PLC and HMI has a different IP address. Would I be worried about data getting lost or not being able to find the controllers with an unmanaged switch?

RockyLeafs · Feb 3, 2021

With unmanaged switches, from a very brief comment I got from an IT long time ago:
"If the switch isn't managed, the data goes everywhere, to anything...
Managed switch control who what and where that all goes."

If you only have a handful of PLCs you can probably get away with it.
and you can have a PC/server handle the data collection and push that to management through a separate ethernet connection.

I completely agree with keep PLC connections away from management.

talldude42 · Feb 3, 2021

James Mcquade said:
i use managed switches.
my best advise is this.
KEEP the plant network away from management !!
they know nothing about plc programming and will want to the software installed on their pc so they can look at things. they will change timers, counters, data registers without knowing what they are changing ad you will have a mess.
Also, this isolates the plc's from the internet so others cannot hack in and snoop. be sure to have a switch on each machine that has a spare port for the laptop to connect to the system.
if you set the system up correctly, you could have a central pc connected to all
machines as a central debug location for maintenance, BUT ! only 1 pc will be allowed to be connected to the plc at a time !
james

Luckily for me want nothing to do with it. They just want the data lol. Part of data they are looking for is what the parameters settings are for the machines. So they will have the ability to see it but not be able to make changes. That was something I made clear seeing as how last time one of them was screwing with a maintenance computer they deleted PLC programs

The data collection software needs to be loaded to the servor computer where the office software can find it. Now im thinking I can load the PLC software to that computer as well so I can make PLC changes and changes to data collection on the same computer with out having to bounce all over the plant floor. As long as the the controllers are connected through the swtiches I should be able to locate and connect to them on the PLC software correct?

RockyLeafs · Feb 3, 2021

technically if they are all connected on a ethernet network it should work.
Just becareful of duplicate IPs address on you PLC and plant network.

Just FYI, with Ignition you can edit through your laptop even if the software is on a server PC. you simply put in the webpage address in you laptop browser. if you laptop is connect to the server then you'll see it come up.
You can even do screen that can show parameter settings live.
Generally, Ignition lets you pull any data from a PLC and do whatever you want with it. And will even create the tables in an SQL for you. The demo software lets you do all of this, and they have tutorials to do it.

I dont work for inductive automation, i just know their software lets you do everything in the trial version. Just need to reset every 2 hours.

Toine · Feb 3, 2021

RockyLeafs said:
With unmanaged switches, from a very brief comment I got from an IT long time ago:
"If the switch isn't managed, the data goes everywhere, to anything...
Managed switch control who what and where that all goes."

It seems to me that either you or the IT guy were talking about hubs vs switches rather than unmanaged vs managed switches.

I completely agree with keep PLC connections away from management.

And here's another +1 on that one.

Just to give one example of why machine networks should remain separated from networks controlled by office IT staff.

Long ago we commissioned a machine with several components that communicated among each other on a machine network that was supposed to remain separated from the customer network. Customer IT guy thought that was not a good idea. He hooked up the machine network to the plant network. No router in between, no subnet or what have you.

The result from the IT guy point of view he could access every device in the machine network from any desk in the office. That bit was not exactly what we had in mind, but so far no harm was done. One thing to note though is that like most office networks, there was a DHCP server on the customer network which gave out IP addresses to things PC's, IP telephones and the like.

From the machine point of view however it is important to realise that every device on the customer's office network was now also part of the machine network. As with most machine networks, all ethernet devices in our machine had a fixed IP address.

Some time after we commissioned the machine we got a call from this customer. From one day to another something would not work properly anymore. Nobody had a clue, all we knew was that things behaved in a very unpredictable manner. Sometimes it would work. Quite often though it would do weird things. In the end the root cause turned out to be a phone on some desk in the office (IP telephony) had gotten the same IP address through DHCP as some device with a fixed IP on our machine network.

We had not seen this before so we lost a lot of time figuring this one out. Customer lost a lot of production time. Our support engineer lost a lot of hair. I cannot be 100% sure but I believe the IT guy lost a job.

AlfredoQuintero · Feb 4, 2021

Toine said:
We had not seen this before so we lost a lot of time figuring this one out. Customer lost a lot of production time. Our support engineer lost a lot of hair. I cannot be 100% sure but I believe the IT guy lost a job.

talldude42 · Feb 4, 2021

Toine said:
It seems to me that either you or the IT guy were talking about hubs vs switches rather than unmanaged vs managed switches.

And here's another +1 on that one.

Just to give one example of why machine networks should remain separated from networks controlled by office IT staff.

Long ago we commissioned a machine with several components that communicated among each other on a machine network that was supposed to remain separated from the customer network. Customer IT guy thought that was not a good idea. He hooked up the machine network to the plant network. No router in between, no subnet or what have you.

The result from the IT guy point of view he could access every device in the machine network from any desk in the office. That bit was not exactly what we had in mind, but so far no harm was done. One thing to note though is that like most office networks, there was a DHCP server on the customer network which gave out IP addresses to things PC's, IP telephones and the like.

From the machine point of view however it is important to realise that every device on the customer's office network was now also part of the machine network. As with most machine networks, all ethernet devices in our machine had a fixed IP address.

Some time after we commissioned the machine we got a call from this customer. From one day to another something would not work properly anymore. Nobody had a clue, all we knew was that things behaved in a very unpredictable manner. Sometimes it would work. Quite often though it would do weird things. In the end the root cause turned out to be a phone on some desk in the office (IP telephony) had gotten the same IP address through DHCP as some device with a fixed IP on our machine network.

We had not seen this before so we lost a lot of time figuring this one out. Customer lost a lot of production time. Our support engineer lost a lot of hair. I cannot be 100% sure but I believe the IT guy lost a job.

Ok makes alot of sense. We did a quick reference search yesterday and it didnt appear that we had duplicate IP addresses. I have a weekly progress meeting this afternoon and I will go over this information for sure.

And I wouldnt be too heart broken if I pulled in the parking lot and didnt see our "IT" guys car not there.... just sayin

Toine · Feb 4, 2021

I have a confession to make in this discussion. Long ago, well before I made a radical career change and ended up in industrial automation, I used to work in a big corporate IT environment. Yes, I came here from the dark side. It helps me to be able to communicate with these people. And it also helps me understand why I don't want them to mess with my machine network

Recommended Networking for Data Collection

talldude42

Member

RockyLeafs

Member

RockyLeafs

Member

AkaHammer

Member

Robb B

Lifetime Supporting Member

James Mcquade

Member

talldude42

Member

talldude42

Member

RockyLeafs

Member

talldude42

Member

RockyLeafs

Member

Toine

Member

AlfredoQuintero

Lifetime Supporting Member

talldude42

Member

Toine

Member

Similar Topics