# Masterflex pump ethernet hookup



## mburtis (Sep 1, 2018)

Figured I would post this in case anyone has any input or if nothing else maybe if I figure it out I can post the results and help somebody else out. 

So we use these masterflex peristaltic pumps for chemical dosing. I'm playing with a new version that is supposed to be ethernet capable. I'm trying to hook it up to a automation direct brx plc, so far I can ping it from the plc with success. I haven't managed to make it do anything yet though. In all fairness I'm just shooting in the dark as I don't know what I'm doing.

The programming contractor was in today and messed with hooking it up to the main allen bradley network as well. He called their customer support and they sent him an add on file of some sort for Allen Bradley. He was able to see it in rs view but didn't get much farther than that. 

The documentation seems pretty lacking. The manual gives a bunch of what appears to be ascii commands, and there is a supplement document that seems to give bit registers or something. No real guidance past that. 

I did try to connect to it directly from my laptop with the telnet but I didn't have any luck but I also had never heard of telnet before. 

So anybody ever messed with these before and could point me in the right direction?

Link to the pump manuals



https://pim-resources.coleparmer.com/instruction-manual/a-1299-1174.pdf





https://pim-resources.coleparmer.com/instruction-manual/a-1299-1166-ed-04-en.pdf


----------



## paulengr (Oct 8, 2017)

Getting Ethernet IP working is a pain with anything.

If you can Ping that establishes that the cabling is good. Set up static IP addressing. No sense in trying to find the pump on the network. Telnet by the way is one of the first and oldest Internet protocols. It is almost literally just opening a TCP connection and reading/writing from a text terminal. It existed way before web browsers and even before Gopher which was the predecessor to web browsers. Today it is being turned off in favor of ssh which is similar but adds encryption and verification of identities.

So first problem is that the data is mixed as far as some bits, some ints, and some floats. From an AB PLC or a Productivity this is easy. You just create a data object with the exact same format to send and receive data then set up your Ethernet/IP interface. On a BRX good luck. I have no idea how that’s going to work. Your programmer better know how to unpack the data.

So when you set it up the PLC talks to the pump on the same port RS-Linz uses. It basically does some negotiation to say “ok, send me the status data every X milliseconds and I’m sending you command data every X milliseconds”. Once this is set up over TCP they switch to UDP packets and it just happens, when it works. It’s all relatively simple. Find an ODVA Ethernet-IP manual and study exactly what is going on because you will never debug it easily without knowing what to expect. You CAN also poll via discrete messages across the TCP port as far as status and you can theoretically at least send ASCII commands the same way to the Telnet port but that is a Royal pain programming wise. Ethernet IP makes it easy.

Lots of things can go wrong with this. I’ve seen all kinds of stupidly bad Ethernet IP implementations. What you need is two things. Get a TP Link Ethernet switch with at least 4 ports and here is the key: port mirroring. These are about $25 on Amazon. Put the switch between the PLC and pump. Install Wireshark on your laptop. Now set up port mirroring to one of the ports that is not used from the web console of the switch. Now unplug your laptop and plug it into the mirror port. Run Wireshark and start sniffing packets. From here you can quickly find and see exactly what the packet content is. This is very simple to do and helps solve all kinds of annoying problems from badly written Ethernet IP stuff and wrong specs to having to put the pump info “remote network” mode and stay there. Start always with just getting status. Once that’s working and you can see it “running and stopped) then and only then, switch to control. Once it’s up and going just remove the extra switch.

And for future advice, DO NOT do this. Every time the pump gets obsoleted or changes versions you need to get a programmer to change the program and start all over. Simple discrete control and 4-20 mA works universally. Every pump out there will take a 4-20 command, give a 4-20 status, and accept a 2 wire run and usually give you dry contacts “running” and “faulted” status. It works universally across all pump types and brands and takes about the same amount of physical wiring as Ethernet IP.

What Ethernet IP lacks is “device profiles”. In USB at one time you needed device drivers for every device. Not any more. When a PC connects to a device it reports back say “I’m a mouse”. Further messages say “I have 3 buttons”, “I have a scroll wheel” “I have lights” etc. So it just works without special software. This does not exist with Ethernet IP. So you can’t just set up the PLC to connect to a “metering pump” device profile. It requires different programming with every make and model out there.

Technically device profiles exist. AB in particular set them up then REFUSES to use them. They created their own Jacky proprietary way of doing things so nobody else is bothering either. So Ethernet IP is no better than Modbus as far as this goes.


----------



## splatz (May 23, 2015)

Assuming you can ping with your laptop, did you try just pointing a browser at the IP? It says there's a browser based network setup utility. 

What did you use to telnet from your laptop, putty? 

You probably want to disable that timeout where it shuts down communications if the connection isn't made within 20 seconds, at least temporarily. 

Run a portscan from your laptop to port 23, make sure it's open, then attempt to telnet with putty. 

It also says although all three connections (bluetooth, USB, serial) can monitor at the same time, only one can be used to issue other than monitor commands. I'd try the Get Active Connection comand. 

I am not familiar with this equipment, you might not get a prompt in telnet when the connection is made, but putty will tell you if it times out without connecting. Just type in a get command and see if you get something on your screen. You might not even see what you're typing, depending on you you have putty setup and whether the device echoes input (there's a thing called local echo you may or may not need / want, a vestige of serial communications that may carry over to telnet.) 

Is there a utility to use to program it with USB? 

Did it get it's address from DHCP?


----------



## mburtis (Sep 1, 2018)

I'll give a few more details. 

Yes there is a USB network utility application. Technically this utility is suppose to work via USB or ethernet. At one point I did have this working through ethernet but most of the time it won't find the pump, but USB works reliably. It just allows set up of the pumps IP address, subnet, dns servers, etc. 

_Side note_ researching all this crap lead me down a rabbit hole that means now I understand in layman's terms how the internet works way better than I ever wanted to. Almost makes me sick. 

Now that I have the pump configured you can type the IP into a browser and it brings up the set up utility. We tried that yesterday just to see what would happen. The pump has settings for cloud monitoring and bluetooth which are shut off right now. Ive played with with both telnet on and off. 

As far as the telnet stuff, I just went in and turned it on under the windows programs. I have no idea what putty is... like I said I had no idea what I was doing other than googling and punching random commands in. 

I'll have to look into the port mirroring switch and wire shark. I've heard of them before but never messed with them. We have enough ethernet stuff around here I need to learn how to troubleshoot it and how it actually works. 

I was hoping they would just be a plug it in and it works type of deal like the hmis I've been working with. I have several other pumps that I need to expand our SCADA control of so I was hoping maybe these would be pretty slick and I could avoid pulling umpteen wires to each pump. Starting to think it might be easier to put in a little plc close to the pumps and hard wire the pumps to that then ethernet that plc back to the main network. 

I was experimenting with the brx just because I have it around for a bench setup just to learn and experiment. The plants are all controllogix so maybe we can get it to work from them. 

As always thanks for the great information and I'm off to Google about half of it so I understand what you guys are talking about.


----------



## paulengr (Oct 8, 2017)

mburtis said:


> I'll give a few more details.
> 
> Yes there is a USB network utility application. Technically this utility is suppose to work via USB or ethernet. At one point I did have this working through ethernet but most of the time it won't find the pump, but USB works reliably. It just allows set up of the pumps IP address, subnet, dns servers, etc.
> 
> ...


Telnet is a native Unix communication system. From UnixLinux command line you just type "telnet XXX" and it just works. Internet was never native to Windows. Microsoft came up with their own system, NETDDE and NETBIOS. It was a total commercial failure. In desparation they hacked the Unix standard internet library (NETBSD 4.2) and just compiled it into Windows WINSOCK. FTP and PING and a few others made it over but they screwed up Telnet. So the alternative Windows program is a free/open source one called Putty.

Also some terminology. "Ethernet/IP" is positively on of the most poorly named protocols out there. "IP" does NOT stand for Internet Protocol. It stands for Industrial Protocol, get it? Ethernet by the way is one of the two high speed packet protocols created under IEEE. The other one is/was Arcnet which fortunately has mostly disappeared out of existence. Only AB still promotes it as their "Contolnet" protocol. Of all the protocols implemented on top of Ethernet the only big one you ever hear of is I believe called Ether2 which is where they place a standard Internet Protocol (IP) packet into an Ethernet packet. That is by the way the whole magic of the "internet"...it is a protocol that is so fundamentally simple that basically all previous network standards could support and carry "internet packets", allowing communication across BITNET, X.25 packet networks, Ethernet, etc. As far as what all those are...don't worry about it. Most of them no longer exist or at least not in any way that you'd recognize. IP more or less made them all irrelevant.

In ControlLogix to get it working you first create two UDT's that have the EXACT FORMAT of the data packet from the pump manual using the UDT's as data objects. Then you create a GENERIC IP message block/device using the data from the pump manual and it just works that simple.

Stepping back a minute to explain how this works, IP (Internet Protocol) has theoretically multiple protocols but right now lets focus on the big two: TCP and UDP. With UDP you basically send a packet from one port of one address to another destination port of another address and that's it. There's no retransmission or anything...you do all those details yourself. For instance you can send a UDP packet to the local DNS server asking for the address of "google.com" and it responds back with an IP address. TCP is more like a phone call. Again you set up communication between two ports but in this case you can then send data as a stream of packets. The TCP protocol automatically handles details like retransmitting any lost or dropped packets or letting you know if the connection broke. All packets must be sent in order. This is actually a problem...with say industrial devices if say an update on data from some remote IO was lost (dropped) then we really don't care about retransmission because a newer more updated packet is on it's way. We don't really care unless the whole thing is dropped or failures get to be excessive. Hence TCP makes sense for say HTTP connections where we connect to a web server and download a web page or an image but not IO. Keep this in mind for a minute.

With Ethernet/IP (Industrial Protocol this time) there is some tricky terminology. An "explicit message" means you connect to a TCP port and send a message requesting some data or sending some data, and in return you get a response back. This is pretty much identical to how Modbus works as well. In fact with Modbus we can just stop right there. It's THAT simple.

But in addition via the TCP port we can set up what is called implicit messaging. This mans that data is sent between a "scanner" (a complicated word meaning a PLC...whoever sets things up on the explicit message) and an "adapter" (the device being communicated with). Its complicated by the fact that you can get data flows going in both directions (reading and writing) so the terms "scanner" and "adapter" are just plain confusing. It makes more sense if you go into the Ethernet/IP setup under the system configuration menu of the BRX software. This is where you can create an EthernetIP server ("adapter") that makes the PLC effectively act like a "device". Not what you want but just to let you know it's there.

So getting back to this I'm going to tell you something here that the Allen Bradley folks say you should NEVER do. If you do this, they are going to hunt you down and drive a stake through your heart. It is really, truly that bad. Create an EIPMSG (Ethernet/IP explicit message) in the BRX system. Set this up to trigger once a second from a one shot set up to the seconds value from the system timers so it just triggers once a second. Fill out the form, and there's a lot. First is the IP address of the pump. Next is the class, instance, and service. You get those right from the Masterflex pump manual (do the read function for now). Then click on Data Block and create the data block you need to match what is in the pump manual. That's it. This should start communication flowing and give you some idea that it is working. There are several different data values you can grab...just pick one that works for debugging.

Unfortunately though that's as far as you can go. BRX processors can act as adapters (servers communicating data to other PLC's) using explicit or implicit mode but they can't do Implicit Ethernet/IP communication to a load. So the above is exactly how you will have to do it with the BRX and that is the ONLY way to do it. It's not as high performance as implicit IO to be sure but it's a peristaltic metering pump...truly, how fast does it need to be. In ControlLogix you can set it up as a "generic" device and do "generic" communication, both explicit and implicit IO. You can do this with the Productivity series PLC's too, just not with BRX or Click.

To be fair though the entire Automation Direct/Koyo PLC line is fantastically better at doing Modbus/TCP if this is the direction you want to go in and Modbus/TCP is fantastically easier to set up. So as per the above where you set up the EIPMSG block, you do the same thing except with a Modbus message block and then you're done! That's all there is to it. Modbus doesn't have Implicit messaging and multicasting and all the other overhead of Ethernet/IP. It's very simple which is why EVERY PLC model out there and almost every device that does Ethernet including Allen Bradley uses it.

Why does Ethernet/IP even exist? Back to that quick history...Allen Bradley was concerned about the competition, specifically Profinet. Networking was taking off in a big way and specifically serial protocols (Modbus, Profibus, Allen Bradley RIO) simply weren't cutting it anymore. Allen Bradley looked at Arcnet and Ethernet. They chose Arcnet specifically because it looked most like what they are familiar with, RIO. They took standard Arcnet and jacked it up to 10 MBps over the stock 5 Mbps but otherwise pretty much left that alone. With their RIO experience they implemented a much more complicated protocol on top of it and they called it ControlNet. As time went on though Controlnet showed its ugly side. The entire PC world went away from Arcnet because it had serious latency issues, and then FAST Ethernet (a whopping 100 Mbps) along with cheap twisted pair was pretty much the nail in the coffin. So as Ethernet cards dropped to $10, Arcnet was over $1200, even worse when it's a nonstandard Arcnet card (aka Controlnet). Then "Ethernet" started popping up everywhere. Siemens created Profinet. Modicon came out with Modbus/TCP (which still exists today...see modbus.org which unlike ODVA is truly free and open source). In fact Modbus/TCP is so simple that most senior computer science majors in college should be able to knock out code to read/write Modbus/TCP in about an hour or two. It is THAT simple. Ethernet/IP CAN be that simple but it's not, and the documentation is absolutely atrocious.

The first response from AB was simply to denigrate Ethernet and claim that their technology was superior, or at least good enough to justify $1200 for adapter cards, plus it was on a 100% proprietary protocol at a time when you could basically write your own PC software drivers for free. They spent over a decade on a huge marketing effort claiming Ethernet was dead and that eventually, somehow, Controlnet was going to take over. It was truly that bad and when AB finally did jump into Ethernet, it took them over 5 years to catch up. Some would argue they are still catching up. Among other things Controlnet let you do some crazy things. Ethernet is a "segmented" system. Except for "hubs" (which nobody uses anymore) each device can only truly see one other device on a network. You can see "broadcast" packets that are retransmitted via the switches but you don't actually see any real "broadcasts" where all devices are electrically connected together. Arcnet isn't segmented...it's all one network. Since all devices could see all packets, multiple PLC's could "share" an IO stream. One controls it and sets it up but any other PLC can "peek" at the data and "share" the data stream. This is only useful maybe 1% of the time but it's an easy feature to implement on Controlnet. On Ethernet it's inherently difficult. But the big "feature" that AB repeated over and over again is that it had fixed timing. The marketing people and engineers drove this point home and whenever anyone challenged this mantra, it was a "deer in headlights" moment. They literally had nothing to say to justify this, except some vague claim about servo drives. Of course at the time they didn't do servo control over Controlnet so the argument was stupid. It wasn't until over a decade later that AB attempted servo control on anything other than SERCOS and again it was pretty much a "me, too" product. By this I mean if you say send me updates every 100 milliseconds, the protocol creates a time slot on the network and you get packets every 100 milliseconds, PERIOD. Not one millisecond more or less. These were the two issues that AB hung their hats on, for over a decade. Well once FAST Ethernet came along these arguments were pretty much a joke...I mean the protocol operates at full duplex at 10 times the speed, effectively 20 times faster. If the network bogs down and drops packets you get packet jitter but more importantly, dropped packets. When you are just downloading stuff over a web browser, communication problems are annoying but nothing bad happens. If this happens to a control network, it's a disaster! So naturally control networks should NEVER come anywhere near any communication limits. Many have learned this lesson the hard way with Ethernet. The other aspect is jitter...even before you reach 100 Mbps (or more these days), eventually your packet stream will get delayed in a buffer as other packets arrive a split second sooner. Average speed might be 100 ms but some arrive sooner or later than others. In servo calculations if you simply ASSUME 100 ms, this can cause the servo to act "noisy" and you get some jitter. A better way is to actually measure timing (which is also an optional part of Ethernet/IP) so that the servo can do all the calculations including packet jitter. After 10 years AB actually did this and finally SERCOS has begun to vanish. So arguments about timing and multicasting were silly....basically it was a "who cares, we got 100 Mbps" argument. Finally AB threw in the towel on that, too. They did a very hacky thing. Explicit messaging is basically all TCP and just like Modbus/TCP. Implicit messaging is just sending raw data at fixed rates which is the Controlnet claim. And to top it all off you can optionally send the UDP ("Implicit") data over Multicasting which allows the Ethernet switches to automatically broadcast the same packet stream to every PLC that wants to receive it. Very clever but VERY complicated for the uninitiated.

It has slowly taken hold. Every vendor is implementing Ethernet/IP to some degree, but not like Modbus/TCP.


----------



## mburtis (Sep 1, 2018)

So one of the first avenues I explored with the brx was explicit messaging but either the manual doesn't give me the information to fill in the the fields (class, attribute, etc) or I'm to dumb to know that is. The manual just gives goofy ascii commands, like STX<QX>CR which is suppose to return what the active connection to the pump is QX1,2,or 3, for Bluetooth, USB, or ethernet. Maybe explicit messaging isn't even supported?


----------



## splatz (May 23, 2015)

mburtis said:


> So one of the first avenues I explored with the brx was explicit messaging but either the manual doesn't give me the information to fill in the the fields (class, attribute, etc) or I'm to dumb to know that is. The manual just gives goofy ascii commands, like STX<QX>CR which is suppose to return what the active connection to the pump is QX1,2,or 3, for Bluetooth, USB, or ethernet. Maybe explicit messaging isn't even supported?


Take a look at this: 

Productivity Series - EtherNet/IP - Overview | AutomationDirect 

A lot of the terms on both the automation side and the IT side are confusing, in fact poorly chosen, but just FYI. UDP is usually referred to as a connectionless protocol; with Ethernet/IP, they call implicit messaging, which is transported over UDP, the "connected" messaging. 

Ethernet/IP is a higher level protocol, the protocol is what lets the PLC and the pump drive brains format packets in an agreed-upon, standard manner so that they can communicate. Ethernet/IP lets the settings and states in the pump appear as I/O to the PLC. 

There is nothing in a regular PC (Windows, Linux, Unix, whatever) that "speaks" Ethernet/IP. There actually is software that adds this capability to a PC so you could have an Ethernet/IP conversation with that pump drive from your computer, but I have not tried it. That would give you something like an HMI straight to the pump. With additional software, the PC could also do the automation that the PLC does. Or, it could do data aquisition / logging. Whole other can of worms there though. 

But you aren't speaking Ethernet/IP when you telnet in. You're in a very simple command line interface that has ASCII commands with limited functionality. It would be pretty much impossible for a human being to type in Ethernet/IP protocol / language. But that's OK, you're not really going to assign an operator to sit and run the pump from a command line. You're going to program a PLC and HMI so that the system runs automatically based on the program and the operator input from the HMI. The telnet ASCII interface is handy for some checking, troubleshooting, etc. 

The nitty gritties of what's in the packets between the PLC and the pump in the Ethernet/IP protocol - that's the part that's not really human typeable or readable, you could run wireshark or other sniffer and try to dissect the packets but it's incredibly laborious. Sniffers are the last resort when you can't get things to work, I very seldom have to resort to a sniffer, like once a year. Sometimes when tech support determines you've done everything right, they'll want wireshark captures to give their developers - the guys that write the firmware of the pump drive or whatever - to see what's going on.


----------



## gpop (May 14, 2018)

I thought this was as simple as loading the driver into rslogixs. Set the port then using a gsv command.


----------



## splatz (May 23, 2015)

gpop said:


> I thought this was as simple as loading the driver into rslogixs. Set the port then using a gsv command.


Thanks to the developers at Rockwell and Masterflex, that's how it works. Or how it's supposed to work. 

The pump drive driver lets the PLC know what info is where in the payload of the Ethernet/IP packets, which is in the first document in the OP. The guy that writes the driver has to know this, and it's what you'd use to dissect the packets if you ran a sniffer. If it all works, the PLC programmer just has to get the driver loaded and the devices connected, then the pump drive I/Os are available to the PLC.


----------



## mburtis (Sep 1, 2018)

gpop said:


> I thought this was as simple as loading the driver into rslogixs. Set the port then using a gsv command.


I'll have to investigate this. I haven't messed with the pump from the rockwell side yet, like I said the outside programmer messed with it the other day but I was busy rebuilding a factory talk screen so wasn't really paying attention to what he tried. I'm not familiar with this instruction but then again opening rslogix 5000 is still an accomplishment for me somedays. So where would this driver come from ? The pump tech support did send us an EDS file for the pump, looked it up and still not real sure what that does for us. 

Somedays I wish I could be an industrial pneumatic control tech in the 60s.


----------



## mburtis (Sep 1, 2018)

OK so I messed with this today with the programmer again. Apparently the Eds file created a bunch of tags and it's basically seeing it as an i/o module, which is great and how I hoped it would work. HOWEVER it still won't establish a connection to configure the module or do anything with it. IN ADDITION I can not get the pump network utility to find the pump via ethernet. I tried about everything I could think of and everything tech support told me and it still won't connect via ethernet but connects just fine via USB or via web browser once the iP address is known.

We called the pump tech support but they basically sucked. You know when you call someone and you can tell you interrupted their online solitaire game and all they want to do is hang up, yea that's these guys. They basically told me their was no way they could know why the setup utility wouldn't work with ethernet (this is with it direct cabled from computer to the pump) and that they didn't have any advice until I called AB to figure out how to make it work with the plc. 

Meanwhile I'm like it won't even connect straight to the computer through your software and you want me to call the other jackasses about getting it to connect to theirs, cmon. 

I spent the afternoon starting to hard wiring it to the bench plc so I can play with that programming. I'm sure it's probably something simple but their customer service makes me want to send them a note telling them right were they can stick their 11k worth of pumps.


----------



## gpop (May 14, 2018)

Little confused on the "once the IP address is known". Most of this stuff works when the first 3 numbers of the IP address match unless you have a dns server.

I would start with a simple 4 port switch between the plc and the pump then plug in my laptop and ping them to make sure they are at least talking to the switch. The module should hopefully be showing in logixs as you said it made a tags (does it have a question mark on the module or warning message). If it does not have a warning you should be able to go to your tags and see live data. 

If it has a warning click on it and check the settings. 

Not sure about the tcp only being available for 20 seconds by default.


----------



## mburtis (Sep 1, 2018)

I just meant that once I set the ip address up I was able to type it straight into a web browser and bring up the setup utility.

I know when we tried to configure the module we kept getting a connection error. The EDS created the tags and rsview could see the IP address but it won't talk. It's like it's there but not responding.


----------



## gpop (May 14, 2018)

Do you get a error code. Nothing is easy when your using generics with allen bradley. Does this link give you any idea's


https://library.e.abb.com/public/1f7e360e8e964f558c5af527d2cb1624/LVD-EOTN109U-EN.pdf


----------



## paulengr (Oct 8, 2017)

gpop said:


> I thought this was as simple as loading the driver into rslogixs. Set the port then using a gsv command.


Not even close. SSV/GSV is for accessing the PLC's system memory and has nothing to do with the device's memory.


----------



## paulengr (Oct 8, 2017)

splatz said:


> Thanks to the developers at Rockwell and Masterflex, that's how it works. Or how it's supposed to work.
> 
> The pump drive driver lets the PLC know what info is where in the payload of the Ethernet/IP packets, which is in the first document in the OP. The guy that writes the driver has to know this, and it's what you'd use to dissect the packets if you ran a sniffer. If it all works, the PLC programmer just has to get the driver loaded and the devices connected, then the pump drive I/Os are available to the PLC.


Rockwell expects someone to write Code for their PLC. Since it doesn't exist, it falls on you. Their response is that essentially they think the rest of the world revolves around them.


----------



## paulengr (Oct 8, 2017)

mburtis said:


> I just meant that once I set the ip address up I was able to type it straight into a web browser and bring up the setup utility.
> 
> I know when we tried to configure the module we kept getting a connection error. The EDS created the tags and rsview could see the IP address but it won't talk. It's like it's there but not responding.


You are jumping around WAY too much here. First you wanted to use BRX, now you are jumping around various Rockwell software packages. Let's stick to ONE plan.

First things first. You need to use the Masterflex configuration utility and set a FIXED IP ADDRESS. No more DHCP, period. Make sure you know what the gateway, mask, and IP addresses do and set them accordingly. They need to be set up correctly on all 4 devices: PLC, PC, switch, AND pump. Second, make sure you have that switch I suggested buying and that you are plugged into the network between the pump and the PLC. This is not an optional step. Amazon takes 2 days to send you one, sometimes less. Take that Cisco/Netgear thing you probably have from Walmart and use it for practicing layups with the closest trash can.

Before going on further you should test everything first. Download a freeware program to your PC called Angry IP Scanner. Run it with your PC plugged into the IO network with your PLC. Scan your whole network. Make sure you can see everything that should be there and nothing that shouldn't be there. In fact on an unfamiliar network this is the first step I do, especially before assigning an IP address. You have no idea how frustrating it is to have a switch kick your device off the network (or a device you don't know about) because of an IP conflict. VERY, VERY frustrating because switches don't always do what you expect when this happens.

Now you can also use RS-Linx to look at devices and it will display more than just generic data if you have the right EDS file but that's not really doing anything useful other than a different version of what Angry IP does, and RS-Linx mostly just causes confusion so lets skip that.

Jump into Logix 5000. You can do this stuff offline but it's much easier to see what is happening online. We aren't going to be doing any control so don't worry about causing the production line to stop or anything crazy like that. If you are THAT worried about it, keep a spare PLC and power supply handy. Make sure that you are talking with a PLC....all green lights at the top and in remote mode.

Also at the same time now is the time to fire up Wireshark. Set it to FILTER only traffic to and from the pump IP address. You will also potentially need to watch multicast addresses as well but let's just get through the first steps. If you want to get a feel for wireshark then just ping or run the configuraiton tool and watch the packets streaming back and forth.

If the EDS stuff works, you should be able to do the following. Go down the tree on the left hand side of the screen inside Studio 5000. Right click on the Ethernet port and click "New Module". On the menu that pops up, in the right hand pane where it says "Module Type Vendor Filters" check the box OFF. Scroll down to where you see Masterflex or Cole Parmer and check that one ON. This gets rid of the extra entries. Then scroll down through the devices and find your pump and click Create. You might also be able to use the search bar. On the screen that pops up under General fill in the IP address that you set up earlier and give the device a name. The name will also match the tag names that get created in controller memory. If you name it "Pump" you will find "Pump.Data...." tags. Under Connection give it a response packet update rate such as 100 milliseconds. It defaults to 10 which is a little crazy except for high speed digital inputs. From there once you save everything it should pop up in the "tree" on the left side and you should be able to double click and open it and see diagnostic/status information or a triangle that tells you what is wrong. Theoretically you can also click on the "device discovery" tab and do it that way too but I've never used this. If you make a mistake, no big deal. Just change the configuration data. Everything is easily edited except for the device name. That messes up the tag tree so the only way to fix it if you change your mind is create another device and delete the unused one.

If the device doesn't show up instead of CREATE you can try to IMPORT a module and point to the EDS file. This may or may not work but if the EDS file is right, it should just work or at least give you an error to track down. Usually if I'm at this point the EDS thing isn't working and it's time to move on.

If the whole EDS thing won't work, it's not the end of the world but it's a little more complicated. From the "create module" screen go to the search box and enter "generic" and press enter. Select the "Generic Ethernet Module". Everything is similar except two things. You aren't going to get nicely formatted data now...you have to select a generic array data type, and you have to select the assembly numbers manually, both the input and output numbers. Everything else is the same as with and EDS file. Don't worry about "Configuration" on the assembly list. And if you only use inputs or outputs, leave the other one blank. Things work the same otherwise. If you don't like the really generic data format you can create a UDT and copy the data into that to make it "pretty".

At a minimum you should be able to read pump status...at least the device should show up in the tree like it's there with the PLC online. If not the module status info should give you hints as to what is wrong. When it comes to CONTROLLING the pump there is usually something you have to do from the pump configuration software to tell it to take remote commands from the Ethernet port. So at first all you want to do is verify that reading is working anyway before jumping into control.

Another option, along the lines of how we have to do things with the BRX processor, is to create a MSG command. Once again you can fill things in and read data via "explicit" messaging rather than the implicit messaging that I described above. You will have to trigger the MSG block via a timer and do things rather manually but other than that, it's more or less the same as using the regular IO system. It may not be pretty but at least it works and may help you troubleshoot the rest of the system.

Another option is to simply write your own EDS files. Rockwell has examples and it's actually not too hard to do. You have all the documentation needed to do this from Masterflex. If you fire up a text editor (Wordpad) and point it to the EDS file you already have it will be very obvious how they are configured. It is just a text file describing the data formats of the various assemblies. Then you just have to "IMPORT" the device stead of creating one.

In the mean time while you are doing all this, as I said earlier, have Wireshark fired up and the switch configured for port mirroring. That way every time the PLC does anything at all you can see each and every packet so that you can tear it down and figure out exactly what is happening. If you can't figure this out, study up on the Ethernet/IP documentation that's out there. It is not too hard to figure out what the packet format is and once you know how things are supposed to be working it's very easy to pick apart the traffic between the PLC and the pump. Quite often this is the only way I figure out why something isn't working.


----------



## mburtis (Sep 1, 2018)

So we were attempting this on two different setups. I have my little brx bench setup I thought I would play with just as a learning opportunity. As far as the ethernet setup I've basically gave up on this for now, unless the attributes are in the EDS I have no idea how I would set up the explicit messaging. Not really important at this point.

The other system is the actual allen bradley plant network. The outside programmer has been mostly working on seeing if he can get this working.

Starting next week I'll work on getting the switch and Wireshark and digging into the allen bradley stuff myself and see what I can find following the help that's been provided.

What makes we wonder right now is that I can't even get the masterflex setup software to connect to the pump via ethernet wired directly from the laptop. This is where if I can figure out Wireshark it might help so I can see if anything at all is happening. The USB connection works fine.

I do have the ip address configured statically at this point. Tech support told me that it had to be dhcp to connect via ethernet, so I tried that too but it still wouldn't connect so I set it back up to what I wanted. To the best of my understanding everything is set up right. Our network is setup like A.B.C.unique number and the subnet is 255.255.255.0. Since this is point to point the gateway and dns servers shouldn't really be needed, just the IP address and the subnet right ?


----------



## gpop (May 14, 2018)

paulengr said:


> Not even close. SSV/GSV is for accessing the PLC's system memory and has nothing to do with the device's memory.



Funny we do it all the time with vfd's. Just put module in class name then select the module in instance.


----------



## paulengr (Oct 8, 2017)

gpop said:


> Funny we do it all the time with vfd's. Just put module in class name then select the module in instance.


If it is in the tree you can do it that way but the data is already in the system tags but it’s the same as a MSG.


----------



## paulengr (Oct 8, 2017)

mburtis said:


> So we were attempting this on two different setups. I have my little brx bench setup I thought I would play with just as a learning opportunity. As far as the ethernet setup I've basically gave up on this for now, unless the attributes are in the EDS I have no idea how I would set up the explicit messaging. Not really important at this point.
> 
> The other system is the actual allen bradley plant network. The outside programmer has been mostly working on seeing if he can get this working.
> 
> ...


You can use DHCP but what happens if the address gets reassigned to another device? Usually you will get the same IP but every tine the DHCP server gets rebooted the IP cache gets cleared. If you have a DHCP server built into the switch some of them let you assign IPs by port. Others support option 87 relaying and there are special servers that will take the port data (from the option 87 data) and assign a fixed IP but otherwise this is asking for trouble.

If you want to attempt to check the service discovery thing yourself look for a Bonjour or Avahi browser tool. All those discovery tools use mDNS.

Also forgot to mention. Unless you lock down the AB PLC it will default to attempting to use multicasting which is an entirely separate range of addresses. There is an easy way to figure out what the PLC is doing with this. Surprisingly open a web browser and point it to the PLC IP using http (not https). This will show you all the IP connections it is using and it’s more useful than the diagnostics you get from real RS-Linx (Classic, not Enterprise).


----------



## mburtis (Sep 1, 2018)

I wasn't about to hook it up to the real network without a static ip. In fact I had to change the ip address at first because the initial one was already assigned to something that's not on my list, so I have no idea what. One of these days I need to go through and identify all the IPs on the network.


----------



## mburtis (Sep 1, 2018)

OK so I actually dug into the rockwell side today. I went through and set up the pump with a static IP. I had to do this via USB at first because it wouldnt find the pump in the set up utility via ethernet. However now it will find it via ethernet. 

What the set utility looks like. I set the tcp timeout to 999, the manual says you can disable the timeout but not how. I have the Bluetooth, telnet, and cloud monitoring shut off right now. 









It seems like adding the module went fine but the module isn't responding. I get a code 16#0204 error. On the plus side the tags show up fine and the tag for a connection fault is active so that's something I guess.









I really have no idea where to go from here. The pump is showing up in rslinx now, I looked at the driver diagnostics to see if that would give me a clue but I would have to know what I'm looking at first. It appears it's sending packets and recieving packets but very few replies, I don't know if that means something or not. 









I'm guessing I need to configure something in the module or something with a driver or I really have no idea.


----------



## paulengr (Oct 8, 2017)

It says TCP timeout. That is very different.

See this. It's for an ABB drive but the procedures are the same.


https://library.e.abb.com/public/1f7e360e8e964f558c5af527d2cb1624/LVD-EOTN109U-EN.pdf



So if you had a problem like the pump didn't like the format of the PLC message, you'd get a different error. Instead it is basically saying communication between the PLC and the pump isn't working. See above comments for the ABB drive which also applies here. So far it sounds like you can communicate to the pump from a PC but not the PLC. Make sure they are on the same network, correct ports, correct IP's, masks, and gateways or it isn't going to work. Something about your network setup isn't right. Again Wireshark might also provide some kind of hints. As of right now the PLC might be sending packets but the pump isn't receiving them.


----------



## gpop (May 14, 2018)

The yellow triangle you can see on the module (2nd pic) shows that its not talking. Click on it and then hit property.
Post pics of the property's (all tabs). Also it looks like you have added the same pump twice. Disable one of them.

The tree structure for the modules doesn't look correct as it would normally have a Ethernet card then a plus sign to open all the modules on the Ethernet port. Maybe you have added the modules in the wrong place rather than assigning then to the Ethernet port. attached a link to a older style card so you can see how the module tree normally looks when you assign modules to Ethernet cards. 


https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1756-um051_-en-p.pdf


----------



## mburtis (Sep 1, 2018)

Ok well I thought I was onto something this morning but no such luck. I was going through looking at all the properties of the other modules under the same Ethernet port and realized it was a different network. A few years ago when we upgraded the plc the contractors reconfigured the networks and built a remote I/O network at both plants and then there is a hmi network. They were not overly clear about this setup and we typically do most of our work on the original hmi network that is a 192.168.254.xxx network, so we had kinda all forgot these networks existed. After realizing the network the Ethernet port we were adding modules to was on a 192.168.16.xxx network I thought I had found the golden ticket.

I left the pump I was working with yesterday out at the other plant and I didn’t feel like driving out there so I attempted to hook up the second identical pump at the main plant. This plants I/O network is 192.168.17.xxx. So I set the pump up to a static IP of 192.168.17.30 after scanning the network.

I went online with the plc for this network and created a module under this Ethernet port. This is the onboard port in the controller, there is another Ethernet card in the plc configured for the hmi network.










It still has the same communication error. After I first hooked it up I ran angry IP with my laptop hooked into the same switch and it showed up on the right IP along with everything else. I also opened rslinx hooked into the same switch and could see all the other modules on this network but not the pump. After a while of messing with it I ran angry up again and it was giving me all sorts of garbage so I don't know what that was about. I just ran it again after being on the other network for a while and everything came back up fine. I could access the pump via the setup utility as well. Here are the property tabs.














































this is a shot of the properties for the Ethernet port showing the ip setup.










this is a shot of the pump set utility, it won’t accept 0s for the dns servers and changes them to this on submit. Since this is a wired network I dont think they should matter anyway right?










and just for fun a shot of rslinx plugged into the same switch as the pump










I also aplologize if the pictures are ginormous, I took them on the iPad and apparently apple doesn’t believe is resizing pictures ?


----------



## paulengr (Oct 8, 2017)

I believe your problem is you assigned the pump to the Ethernet port on the PLC but not following if this is the correct network or not.

Your PC problems sound pretty typical. Windows tends to buffer/cache a lot of things. Whenever you go in and manually change the IP settings, once you save it, disable the port then re-enable it. Or sometimes just unplugging, waiting a few seconds, and plugging back in clears it. I run all my AB software inside VMs so this is an even bigger deal for me since the VM only sees the internal virtual switch and is never truly disconnected. Also shut down and restart programs as they will often still be attached to old (dead) settings and ports inside Winsock the Windows network drivers.

You don’t always have to do this but then you may get strange unstable behavior. It’s not limited to Windows either. Linux does the same thing with Firefox but most Android software is pretty good about, probably because networks are ephemeral in mobile environments.


----------



## mburtis (Sep 1, 2018)

Alright it now works. It appears I had it about 99.9 percent there yesterday. Yesterday I had reassigned everything to the right network and actually had everything set up right. However yesterday I couldn’t get the pump to show up in rslinx. This mornin the outside programmer came in to help me. I scanned the network with angry IP and the pump showed up, started rslinx and it wouldn’t find the pump. We deleted the eds file and reinstalled it. I don’t think this actually helped but figured it couldn’t hurt. Then we added an Ethernet device driver to rslinx and put in the laptop IP and the pump IP and manually refreshed rslinx. The pump showed up in the new driver and also showed up in the Ethernet/IP driver. Now it all works as it should. I think yesterday my rslinx was being goofy because it was still showing the other network as well so I don’t know, maybe my computer just needed restarted.

So long story short, the setup for these pumps really is dead simple, load the eds file, add the module, and it works. However because of my Neanderthalness or random computer issues it was rather fickle. Confusing everything by putting it on the wrong network at first didn’t help anything either. Regardless I’m now monitoring the pump to see reliability and I gained a lot of confidence working with the various softwares so I’m still going to call it a win.

Thank you to those that helped out.


----------



## Almost Retired (Sep 14, 2021)

mburtis said:


> Thank you to those that helped out.


i truly believe you did the best thing when you restarted the laptop.
i hit save for what ever is open, or as required, then close everything
then restart usually once a day. sometimes more if i am on this site all day
i can actually tell the difference when the restart was needed (usually i am doing it more often than needed)

i am a firm believer in restart, it clears all the stuff that has accumulated from what you have been working on since the last time you restarted


----------



## mburtis (Sep 1, 2018)

I think there may be something to restarting the laptop. I shut it down yesterday when I was done messing about and fired it back up this morning. I was also hopping back and forth between networks and programs and etc yesterday so it wouldn't surprise me if that was part of the issue.


----------



## paulengr (Oct 8, 2017)

With RS-Linx on serial drivers it forces you to stop the driver if you make changes then start again. On the Ethernet drivers it does not force you to do this but you need to stop then start.

Also there are the “harmony” files. This is basically 2 files that is all the configuration data. Every so often they get messed up and you need to delete the harmony files 

ALSO every so often the RS-Linx configuration settings sometimes get scrambled. “Backup” the settings regularly so you can restore back to a known stable setup if/when you need it.

Once you get to a stable RS-Linx configuration you are fine but if you have to change the configuration, every time you do, it can get corrupted.


----------



## mburtis (Sep 1, 2018)

I appreciate the tips. My experience with all this software is limited so I haven't had the chance to learn all the goofy tricks of making it behave and the simple fixes to try first when it won't work.


----------



## paulengr (Oct 8, 2017)

mburtis said:


> I appreciate the tips. My experience with all this software is limited so I haven't had the chance to learn all the goofy tricks of making it behave and the simple fixes to try first when it won't work.


All you have to do is call Rockwell Technical Support with your credit card handy. Or pay $50,000 per year and you get full online access to their tech notes. Wish I was making this up.


----------



## mburtis (Sep 1, 2018)

You would think that when you pay 30k a year for licenses and support they could throw in some free training or tech support, you know the stuff everybody else gives away for free anyway. Their hardware is powerful enough but I truly don’t understand how anybody justifies buying it, except for big high dollar projects like a chemical plant maybe. How can you legitimately look a customer in the eye with a straight face and tell them they need a $150,000 plc plus thousands of dollars of yearly software to accomplish a basic system, oh and recommended life is only like 7 years now or something ridiculous like that. Maybe I’m cheap but id rather drop 4k at automation direct and put a spare on the shelf and be able to call and get someone who is helpful on the phone for free. Maybe the higher end controllers come into their own for high speed applications or motion control or things like that, this Is a water plant not a space ship, what we really need is data collection and Allen Bradley seems to suck at that.


----------



## paulengr (Oct 8, 2017)

mburtis said:


> You would think that when you pay 30k a year for licenses and support they could throw in some free training or tech support, you know the stuff everybody else gives away for free anyway. Their hardware is powerful enough but I truly don’t understand how anybody justifies buying it, except for big high dollar projects like a chemical plant maybe. How can you legitimately look a customer in the eye with a straight face and tell them they need a $150,000 plc plus thousands of dollars of yearly software to accomplish a basic system, oh and recommended life is only like 7 years now or something ridiculous like that. Maybe I’m cheap but id rather drop 4k at automation direct and put a spare on the shelf and be able to call and get someone who is helpful on the phone for free. Maybe the higher end controllers come into their own for high speed applications or motion control or things like that, this Is a water plant not a space ship, what we really need is data collection and Allen Bradley seems to suck at that.


Allen Bradley has really three strong points. First one is that they were one of the first ones out there. The result is that everyone knows and is mostly familiar with their hardware and software. With the largest market share in North America it’s kind of like buying Caterpillar equipment. It’s decent quality and very overpriced with NO factory support (effectively) but you can get local tech support basically anywhere in North America. Every automation tech knows AB just like every diesel mechanic knows CAT.

The second that goes hand-in-hand with the first point is that once you can connect to it, by far all their PLCs are easy to troubleshoot. Can’t say that about Siemens S7. Or all the Codesys PLCs. Automation Direct comes close but they didn’t get online programming “right” until the Productivity Series.

Third is big name recognition. If you put in an AB and it has problems you won’t get blamed for it unlike say Siemens.

So stack those up against downright hostile factory customer support, highly variable quality local support, major availability and backlog problems ever since SAP (a decade ago), software that works pretty much when it wants to, and the highest prices in the industry. You can make it work but it pretty much makes you fight it all the way.

Disagree about limitations on Automation Direct. Their low and midrange PLCs don’t do tag based addressing. Neither does AB. So that’s a draw. None of their PLCs have any kind of productivity stuff for code. No true subroutines with variable passing and not even cut/paste multiple lines of code. So this slows down doing a lot of boilerplate code. On a positive note their instruction sets exceed AB in capability out of the box. Only one IEC 1131 language. But they definitely do motion control on board, good HMI stuff, much more flexible IO. But they have their goofy stuff too. Like no RTBs for AC IO (better than AB though for DC). The higher end PLCs have “two” Ethernet ports but the second one is a proprietary IO-only port similar to TwinCAT or Profinet. If you come over from AB at first the instruction set seems very, very limited. The Click has just 37 instructions compared to about 100 even for the Micrologix. But they have just one “compare” instruction, one “timer”’instruction, one very flexible copy/fill instruction, and one “math” instruction. AB has dozens to do each of these 4 instructions. For instance AB has a “clear” instruction, a “fill” (array) instruction, move (copy single value), bit distribute, and a more generic array copy or compute instruction. So neither is more powerful but programming both is like switching from English to Spanish. And online programming on the Clicks and BRX is a strange experience. When you start editing it drops offline. Then you stop the PLC and download then run again. But most of the time the Stop/run is quick enough no one notices.


----------

