MicroLogix1400 Ethernet to I/O Explicit MSG Example Needed
Posted 09 July 2010 - 01:40 PM
Hm... I was about to post something very similar. I'm messaging to ethernet radios, and am not sure exactly how to set up the message.
Please excuse my ignorance, I haven't done PLC stuff in almost 2 years. When you say distributive IO, are you talking about ML IO modules connected to the 1400 over ethernet? Or some other type of product? I'm trying to gauge how relevant the responses to this thread will be so I don't start a new one if not needed.
This post has been edited by IamJon: 09 July 2010 - 01:43 PM
Posted 09 July 2010 - 02:14 PM
Right now I'm confused as to where I put the IP address for the radio I'm sending to(never mind, multi hop tab), and what communications command to use (I assume CIP generic).
Ok, so what info do we need...
For me, I am writing digital and analog values. If I'm on CIP generic, I can go to Service drop down.
Can I use "write analog out" for my analog Int data files?
Can I use the "write analog out" for my digital if I have them all in the same word?
This post has been edited by IamJon: 09 July 2010 - 02:27 PM
Posted 09 July 2010 - 02:38 PM
Channel 1 on the 1100 is Ethernet. Check under your Channel Config.
Comm command I think should be CIP Generic.
Data Table Address - put the first WORD of your data, not bit (as read in instruction help) Mine is N7:1
Size - 1 for one 16 bit byte.
Extended Routing Info file - create a new data file for this. Must be a new thing?
The help doesn't say anything about the service, and the multi hop seems to only be peer to peer with Clx devices.
Posted 12 July 2010 - 01:54 PM
A lot of folks will assume, or wish, or think, or guess that because the MicroLogix 1100 and 1400 have some CIP Generic Messaging capability that they can program in I/O functions using the features that are intended for peer-to-peer and operator interface functions. This still doesn't make the MicroLogix controllers into I/O scanners.
Some I/O class devices can be controlled by CIP explicit messaging from MicroLogix / SLC-5/05 controllers.
I recommend very strongly against these messaging methods because they use the MicroLogix Ethernet port for a function it was never intended to perform, which places the reliability and speed of the I/O communications at risk when other factors change, like the number of windows open during an online programming session or the number of engineering workstations browsing the network or the number of tags on scan in an HMI window.
In the words of the great Hank Hill: "It ain't right."
The other reason I don't recommend this is because it's hard to do. Because the MicroLogix wasn't made to run I/O connections, and the I/O products aren't made to receive command from MicroLogix controllers, any features that the devices can in fact communicate with are poorly documented.
Allen-Bradley AC drives have a special feature called the "PCCC Object" that allows them to receive control commands from controllers like the SLC-5/05 and MicroLogix 1400. There's a command timeout parameter you have to write a value to in order to make this function operate. The function's not even meant to work with the SLC-5/05.... it's made so that software programs like Drive Executive can test-run a drive during tuning !
You would have to specify the exact I/O module make and model, and point to a detailed user manual for the Benshaw device before you could go further. I would be looking at messaging to the Assembly Object or the Register Object on any generic EtherNet/IP device you wanted to control with a MicroLogix 1400 controller.
Posted 15 July 2010 - 06:31 AM
Yes, but...again, this is a definite RTFM exercise.
Instead of trying to use CIP Generic for the Benshaw starter, it is much easier to use the PCCC mode. Take a look at the Ethernet manual, page 92. Program everything for a read from a PLC-5. Use N62:1, N63:1, and N64:1 for the currents for instance.
To do the same thing with CIP Generic, you'd use object class 0x69, instance 1, attributes 10, 11, and 12 (page 63). Use get attribute single (service code 0x0E). Note that everything is in hexadecimal, so attribute 10 will be configured as 0x0A, not "10" which will return attribute 16 instead.
This is for a Benshaw MXD3 Ethernet communications board.
Trying to use CIP Generic is a royal pain. Very much reminds me of DeviceNet in general where you spend an obscene amount of time tracking obscure registers and data mappings. In order to avoid problems with word sizes and such, every attribute read returns 30 BYTES of data. So point it to an integer (N) type data file and use only the first word since that one will have the result you want since it is returned as a UINT (16 bit unsigned word) according to the Benshaw manual.
You can do the exact same thing with ANY Ethernet/IP device. It just takes time to research exactly which service code, class, instance, and attribute you want. You can also control (set attributes) using the same mechanism with a different service code. As has already been mentioned, there's no real interlocking or protection in case something goes wrong when you control a device this way.
The assembly objects are much larger and return whole blocks of data. By manipulating the TCP/IP object (among others), you can configure a device to multicast a stream of assembly objects, and that's exactly how Ethernet/IP IO works. But since you don't have the capability of receiving Ethernet/IP IO messages on a Micrologix, you can't do anything with it even if you did manage to get Ethernet/IP multicasting working. I don't know much else about assemblies simply because I'm not a manufacturer and I'd have to pony up several thousand dollars to pretend to be a device manufacturer to get access to the complete Ethernet/IP spec. including the sections describing assemblies and profiles. Profiles are default assemblies for common cases.