weirdness ... a MicroLogix 1100 – wearing a 1794-AENT Tee-Shirt ...

if I hadn't seen it – I wouldn't have believed it ... (note: if you're really not into PLC "weirdness" then skip this post – you've probably got better things to do) ...

a few days ago, I came across a weird way of setting up a CompactLogix (1769-L35E) to communicate over Ethernet with a MicroLogix 1100 processor ... the idea was to transfer three integer data values using a Message command ... and it worked ... but ...

the thing that was most interesting was that the original programmer had added the MicroLogix 1100 to the CompactLogix I/O Configuration as a:

1794-AENT FLEX-IO Ethernet adapter ... (screen shot below) ...

personally I would have bet more than pocket change that this arrangement could not possibly work – mainly because (as far as I know) an AENT adapter would have nowhere to store the integer values once they arrived ...

I wasn't "onsite" - but my customer assures me that the system that this is installed in does indeed function OK ...

in fact, the customer's program shows about five of these "FLEX-IO" remote setups – specifically, five 1794-AENT Ethernet Adapters – which are actually MicroLogix 1100 systems instead ... and there are ZERO modules shown attached to the FlexBus connections ...

anyway ...

when I had some spare time, I set up a quick test with my lab equipment and this is what I found ...

DISCLAIMER: I do NOT recommend this setup – I'm just documenting it as general knowledge for the forum at large ...

from the CompactLogix code, rungs 1 and 2 shown below are just to develop three data values which vary each second – to make it easier to confirm the data transfer ...

the MSG command writes the three integer values to the field device – which once again, is actually a MicroLogix 1100 processor ...

when I used RSLogix500 and went online with the MicroLogix, I saw that the data was indeed being transferred – although "Alert" icons (! flags) were continually popping up on the I/O Configuration folder - and on the 1794-AENT device ...

[continued in next post]
.

this shows how the MSG command has been set up ... (note that I've changed a few details to protect the original programmer's work – but the ideas should be the same) ...

nothing special here ... I've got a hunch that the Message command (bless its little heart) doesn't know (or care) that it's actually writing out to a MicroLogix processor – and not to the FLEX-IO device at the target IP address assigned to the name "PUMP" ...

[continued in next post]
.

the screen shot below shows how the 1794-AENT adapter has been set up ...

I'm just guessing here, but I've got a hunch that the original programmer wanted the CompactLogix to communicate with the remotely located MicroLogix systems – but didn't quite know how to add those to the I/O Configuration tree (they're not an option on the selection tool) ... so ... maybe he figured that the AENT would at least allow him to set up an IP address ...

and as I said earlier – it works! ...

my lab mockup shows a constant stream of error messages and fault status reports – but at least the data DOES get transferred ...

[continued in next post]
.

going one step further, I started poking around and found an ETHERNET-BRIDGE device which does show up in the I/O Configuration tool ... I deleted the 1794-AENT – and then added the ETHERNET-BRIDGE in its place ...

this setup works fine – with no Error or Fault flags ...

THE POINT OF THIS THREAD ...

just because your screen shows something installed (example: a 1794-AENT device) – and even though the system is working with that particular setup – that does NOT necessarily mean that "what you SEE – is what you've GOT" ...

personally, I'd have bet money (more than pocket change) that the program that my customer brought in for show-and-tell was just a "development" copy – that had later been corrected and updated before it was actually placed into operation ...

now back to work ...
.

I'm curious... is the IO Configuration even doing anything then? There is a MSG instruction, that is all you really need to handle that type of communication to the Micrologix. I have multiple CompactLogix setup that simply exchange data periodically with a handful of ML1100 and 1400 processors. They didn't need any IO Configuration, just setup a MSG instruction like pictured and point to the correct data tables.

In this case, is it simply the fact that the IO Configuration is being used to store the IP Address of the Pump PLC, and then that Pump being called instead of the IP Address? The actual communication is being handled by the MSG instruction, the IO Configuration isn't actually sending any IO?

Yeah, I'm kind of confused also. While this is interesting that this apparently works, what's the point? What can this do that an ordinary MSG instruction can't?

excellent questions ...

I just went back and deleted ALL devices in the I/O Configuration ... the data STILL gets transferred by the MSG command ...

personally I'm just wondering why "anything" was added - but the original programmer (so far) can't be consulted as to WHY the AENTs were added ... this is the part that was causing most of the confusion as we were trying to track down the control signals - since we were working offsite and offline with a program which indicated "remote I/O" - when the device was a processor instead ...

quick question: has anyone ever worked with an ETHERNET-BRIDGE device? ... I've never run into one before ... I'll do some research later - but no time available right now ...

Is it possible that adding the AENTs to the I/O tree never did ANYTHING? At least nothing bad?

My guess is that the original programmer didn't understand how to manually type in a CIP Path, and thought that he needed a device in the I/O tree in order to select the target of the MSG instruction.

The connection is entirely bogus; it's throwing error messages because the MicroLogix is rejecting the I/O Connection requests and responding with the wrong values to the identity queries.

In the vernacular: "Dave doesn't live here man, stop trying to deliver his mail."

A co-worker recently did something similar when he was trying to get a PanelView Plus working with his GuardLogix. He guessed that maybe there had to be something in the I/O tree, so he added a PanelView Standard. The attempt of the GuardLogix to make an I/O connection with that bogus object actually interfered with the PanelView Plus ability to make a CIP connection.

MSG instructions do not use any of the device's Identity information to establish their connection or transfer their data. They don't care what type of device the target is, only that it supports the type of transaction (Data table read, tag read, CIP object service, etc) and the arguments that go with it (data table size, tag name, CIP object attributes).

All the MSG instruction cares about is the IP address associated with that device. I wonder how many other devices you could use in its place (like another ENBT, for example) and get the same results.

jkerekes said:

Is it possible that adding the AENTs to the I/O tree never did ANYTHING? At least nothing bad?

Click to expand...

sure ... as near as I can tell from where I sit - the data transfer APPARENTLY has been working OK for quite some time now ... I'm going to ask the customer to check the AENT devices shown on the I/O Configuration and see if they are displaying "error" flags while operating ...

when I take them out - no "error" flags are displayed ... (at least on my lab equipment) ...

Ken Roach said:

My guess is that the original programmer didn't understand how to manually type in a CIP Path, and thought that he needed a device in the I/O tree in order to select the target of the MSG instruction.

Click to expand...

I think Ken just came up with the answer "why?" that I was looking for ... with the AENT you can "browse" the path ... without the AENT (or with "nothing" added) then you can't browse ...

the MSG automatically converted the path as shown in the screen shot below - as soon as I took everything out of the I/O Configuration ...

.

Ron Beaufort said:

excellent questions ...

I just went back and deleted ALL devices in the I/O Configuration ... the data STILL gets transferred by the MSG command ...

personally I'm just wondering why "anything" was added - but the original programmer (so far) can't be consulted as to WHY the AENTs were added ... this is the part that was causing most of the confusion as we were trying to track down the control signals - since we were working offsite and offline with a program which indicated "remote I/O" - when the device was a processor instead ...

quick question: has anyone ever worked with an ETHERNET-BRIDGE device? ... I've never run into one before ... I'll do some research later - but no time available right now ...

Click to expand...

I am no expert in it, but we have a PC that is connected to our ControlLogix using ETHERNET-BRIDGE. The PC is used for managing sorter bins, as well as having some HMI capabilities. It creates a CIP connection that acts as inputs and outputs on our PLC. I don't know a lot about how the PC side software works but I know it does rely on SQL Server for its functions. I hope this gives you a lead as to how it is used.