MicroLogix 1200 to CompactLogix 5380 via ENI

I'm currently working on introducing a new ProSoft Gateway into another part of the network so I'll be tied up for a bit this afternoon. I'll return to this this evening and give it more thought and maybe I'll have a more fresh perspective.

two cents here,

One thing that would help clarify your level of connectivity is can you see both your 5380 and the Micrologix in RSLinx (This is assuming you have made a driver for those two devices and that driver is currently running)?

Also I have a pic of a setup that is working from CompactLogix to Micrologix I can share, might help.

Lovell, thanks for weighing in.

While RSLinx is open, I have an Ethernet (not the Ethernet/IP Driver) running where I can see both the 5380 and the 1200.

In fact, I am online with both of them at the same time at the time of writing this. It's a little frustrating that I can do that and view each program in it's entirety, but I cannot figure out how to get them to do it on their own.

I was going to leave the post at that, but thought I'd try something. It seems that using the Ethernet Driver (where I have to designate each address I want to see), I can see the 5380 and the 1200. What I have just done is added the Ethernet/IP Driver and all of my .1 devices showed up automatically (also the .60 address of the 5380). All well and good, but when I tell RSLinx to browse a remote subnet and enter the address to broadcast on the .60, the list is populated with all the devices there with the ENI being substituted for the 1200 at the same address.

Is this common for Ethernet/IP? I wonder why the Ethernet Driver with the IP keyed in shows the 1200 but the Ethernet/IP only shows the ENI. Probably showing my inexperience and ignorance there.

EDIT: After looking at the images Lovell posted, my setup is nearly identical (N7 vs N10, and the Path is 4, IP vs 2, IP since I have Dual-IP Mode active). Got to be something else I'm missing. I've got other Message instructions within the 5380 and read values from a neighboring CPLX, that was simple since I could just add the other controller to the process tree.

If the NET_ENI is communicating properly with the Micrologix, it should not appear in the RSLinx tree - it should only show the MicroLogix.

See, now it does when I'm not using the Ethernet/IP Driver (using just the Ethernet driver). It's only when the Ethernet/IP Driver is used does it show the ENI. The other way all I see is the 1200.

Are you saying that regardless of the Ethernet driver, the ENI should not show?

EthernetIP driver may not show the device, only the ENI - I am seeing what your seeing on my test bench.

The icon is a bit of a rabbit hole; I'll try to make it simple.

The "Ethernet Devices" driver sends a series of messages to the devices in its Station list to inquire about their identity and name. When correctly configured and connected, a 1761-NET-ENI passes those messages on to the MicroLogix and informs RSLinx that there's a MicroLogix present.

The "EtherNet/IP" driver sends a broadcast "List Identity" packet out, and everything that supports EtherNet/IP replies with its top-level Identity object information. The Net-ENI just responds with its own identity, because that's all that RSLinx Classic asked for.

If you "see" only the Net-ENI icon with the Ethernet Devices driver, that indicates there is a serial configuration problem. You can go online with the MicroLogix over Ethernet, which proves the serial configuration is OK.

I believe it is normal to "see" only the Net-ENI icon when you are browsing with the EtherNet/IP driver.

So don't get distracted by the icons; the problem is very likely elsewhere.

Ken Roach, thanks for the clarification. I was becoming a little concerned when Lovell brought it up, but I figured it was exactly as you explained. Seems that's how Ethernet/IP populates so much more quickly than Ethernet Devices even though you specify exactly where it should look.

Since I've finished with my ProSoft Gateway Install I'll keep plugging away at this tonight either till I figure it out or pass out from exhaustion.

Ken, I also wanted to express my gratitude for all the information I've gotten from your posts over the years. Some of your posts really helped me out in my earlier days.

What does your message rung contain? What are the conditions to read? Do you have reset logic if you get a read error?

What is the current status of your instruction?

Lovell,

As per your request, I figured it would be easier since I have a little more time to do stuff like this right now to attach screenshots.

EDIT: Keep in mind that the reason the rung is shown in edit is because I've literally been tinkering with it most of the day. Which reminds me... I should stop to eat I suppose.

I've also had a free-running timer to true/false the Message instruction, didn't seem to make a difference.

Notice that the RawGasAcc rung is functional but thats one of the messages to the other CompactLogix Controller. The FlareSetFlow rung is the one I can't get to work.

Take a break to eat, drink, excrete, and rest. This is engineering, not combat patrol.

We can hear my TED Talk on why self-retriggering MSG instructions make the infant Jesus cry later. It's probably not the root of this problem.

The 16#0000_0315 error code is important. It doesn't mean "I never got any kind of response from the device so it's offline or mis-addressed". It means "The CIP Connection request returned a message that turned me down".

A very common reason for that is when you put the 1761-NET-ENI into the I/O tree of a ControlLogix as though it was another ControlLogix-family device that you were going to exchange I/O or Produced/Consumed Tags with. It doesn't support that kind of cyclic I/O connection.

But if it's getting that kind of cyclic I/O connection request from the ControlLogix, it gets confused and queasy and refuses other kinds of messages from the same source.

The fact that your CIP Path shows the IP address and not a Module Name suggests you didn't do that misconfiguration, but it's worth talking about.

Another try: Create a new MESSAGE type tag to serve as the control tag and use that in a fresh rung.

While it's uncommon, MESSAGE tags can get their internal (not usually visible to the programmer) data corrupted.

One common source of that corruption is if you're trying to be clever and programmatically change the target path. I've done that but it takes extreme care.

Similarly, fussing with the .DN, .EN, or .ERR bits of the MESSAGE control tag can corrupt it. You absolutely should never write to a control bit in a MESSAGE tag except when you set the .TO timeout bit to manually cause a timeout error.

EDIT: I've composed the following all while the last number of posts have been added. Those posts have confirmed some of the assumptions I was making below about whether or not your laptop can browse both controllers at present, and whether the CompactLogix had already data sources routing information to it. So please mentally substitute any of my assumptions on this with what you've since confirmed. And yes, what you are seeing with the two Ethernet drivers is perfectly normal. The Ethernet devices driver is just a little bit "nosier" when chatting with devices, as Ken has pointed out, but we won't hold that against it...

GrownUpGerberBaby said:

...Within our Machine Network...there are two more Stratix Switches that are integrated into the Intellicenter MCC...we also have another route to the .60 network from one of the Itellicenter Stratix Switches. So essentially a loop around the 5380 to tie our .1 to the .60 network...So, in a little roundabout way, travelling through several Stratix and Netgear switches, my laptop connects to the MicroLogix in very much the same path as the 5380

Click to expand...

This painting lark isn't at all easy, is it?...

This would not be the first time a setup's initial description has quickly gone from "this device and that device" to "all these devices". Industrial Automation Control Systems (IACS) utilizing Converged Plantwide Ethernet (CPwE) architectures are very useful and flexible, and can appear relatively straight forward when things are just plugged in and working. But they can be quite complicated to configure and do require a level of understanding when diagnosing issues traversing them. I'm not saying you lack the necessary understanding, but perhaps might not be appreciating "possible" factors here that could be hindering your progress.

There is in all likelihood Layer 3 Inter-VLAN Routing configured here between some of these Stratix/Netgear switches. As that is how your laptop connects "through several Stratix and Netgear switches" to bridge to the MicroLogix.

"If" I am to assume that your laptop's routed path can indeed browse to both the MicroLogix and CompactLogix controller (as you have configured the MSG instruction), which are both essentially connected to the same Netgear switch, then my point of focus in this network would be the ports on the Netgear switch that the CompactLogix and Anybus AP directly connect to. Something is apparently impeding this path. Do you have access to the Netgear switch configuration?

Also, is the Anybus AP new for this data collection setup or was it existing and working?

If existing, did the CompactLogix communicate to the AP prior to this new setup?

I'm trying to ascertain if the path through the Netgear from the CompactLogix to the AP was ever functioning before? If not then maybe it's the Netgear configuration for these specific ports that needs to be reviewed.

GrownUpGerberBaby said:

...I did a PING just now; 4 packets sent, 4 received, 0% Loss and an average latency of 34ms.

Click to expand...

I could assume what and where you PING'd from, but can you please qualify "I did a PING..."? - do you mean fom your laptop via its normal routed path through several switches, or do you mean while connected directly to the Netgear switch that the CompactLogix is also on? Ideally, and if possible, you should PING from the actual Netgear port that the CompactLogix normally connects to. This will verify if the actual path from the CompactLogix to the ENI is valid, at least at the basic TCP/IP level.

Another assumptive thought...

As you've mentioned, the CompactLogix has already successfully received data from several other sources, so this would indicate that the routing of these data sources to the Netgear switch and CompactLogix is correctly configured and working.

And because your laptop can route as far as the Netgear switch and out to the MicroLogix, and assumedly to the CompactLogix, that seems to only leave the two ports I've mentioned.

So has the CompactLogix and AP ever "met before"?

There was something else you mentioned way back in post #3 that I had meant to come back to and ask you about...

GrownUpGerberBaby said:

...I'm very new to Messaging between controllers and was spoiled with the CompactLogix controller I mentioned above due to the ability to add it to the Controller Tree...

Click to expand...

Can you explain what you meant by "it" here? Were you referring to adding "a" CompactLogix controller into "a"nother CompactLogix controller's I/O Configuration? It's just that your statement could be interpreted as meaning adding "a" CompactLogix into "its own" I/O Configuration? That would not be a good idea and could trigger an error such as the "Invalid Segment Type" error you had previously. But say it ain't so?

Another simple and easy step you might take, amidst all these more precarious ones, is to delete the MSG instruction, and its instance tag (of MESSAGE data type) and start over. Sometimes, when playing around with a MSG instruction's settings while trying to get it to work, we can end up corrupting data within the MESSAGE tag's structure.

EDIT2: Oh boy, Ken. I'm just too busy trying to sort Christmas and you guys out! But it's always good when two people with "reasonable experience" corroborate each others thinking.

G.

Ken, took a short, much needed break. I appreciate your response. I don't know why i haven't thought to try that yet. Sometimes beating your head against the wall just becomes familiar to the point of comfort I guess.

EDIT: Ken, as I was typing this response, I started thinking about earlier today I thought I might have noticed that the Message Data file started leaving things in that I had removed from the prompt i.e. I believe that the string still read as having 0,0 after I removed 1,0 in the form of IP$00$00 when I clicked the ... next to one of the data points. I could very well not even know what I'm talking about either and didn't pay it any mind.

Back to Geospark, you've been at this as much as I have today and I certainly appreciate it!

For the Anybus, it is brand new to this particular application. They are relatively new to us, but I've had great success utilizing them on Ethernet only devices. The 1200 is existing from the days before my system and controlled/controls the Flare for Landfill gas (Why my system is here is a topic for another thread).

My 5380 (5069 if you'd rather) and the other CompactLogix 1769 (not mine) are barely a year old to this site so no messaging had been performed prior.

As for the PING, I did it from the normal routing spot, but could try again from the actual port that the 5380 connects to the Netgear.

Back to the Anybus, the CompactLogix would not have encountered the AP nor the Client before since I've only installed the 1200 side yesterday and the AP was initially installed to replace the damaged camera run mentioned above.

Now for the burning question from Post #3, what was meant by "it" was that I was able to add the 1769 (other controller) to the Controller Tree.

I'll try the PING from the 5380's port on the Netgear and see what kind of access I can get to the innards of it.

Since you and Ken are very much in the same mindset on the MSG deletion and beginning again (it won't take but a few minutes anyway) I'll pursue this avenue as well.

I wished we were all getting together on better terms, but I guess I screwed up pretty good to have the both of you chime in to help me out! I appreciate it!