I am trying to acces a RMC200 thru iec 61131 adresses (%MD256.0)
as the indirect addresses might be too small for my application.
and all data is not accessible thru DF1 or Modbus communication.
Is there any drivers that can do this?
Thank you in advance for you help.
The datasheet lists 3 options that you might work:
Each of these protocols has their own addressable memory areas and conventions and I couldn't tell you how completely they map to the format you're asking about.
Already using this. i am using Ethernet IP as Rockwell protocl. (slc500) it works great, they use indirect addressing so i can build my own map for comm. but with upcoming systems i will run out of space for the Hmi. i have 1024 word i can allocate and acess thru this indirect memory.
plc comm already uses almost half of it. and settings PID and axis setup stuff requires more space than plc com. it is not refreshed often but needed to be accessible when tuning and troubleshooting.
So i wondered if we could use native comm they call IEC61131. to fully acces the controller.
I've used older versions of these before, and they emulate a SLC-500 pretty well (with the legacy "CSP" protocol). From the user manual:
The CSP protocol is also known as "DF1 over Ethernet". It uses the same addressing format and function code types as the serial DF1 protocol. This common component is called PCCC.
CSP can be used to read and write any registers in the RMC. In the Allen-Bradley PLCs, MSG (message) blocks are used to read and write any registers in the RMC using CSP. See Using Allen-Bradley Controllers via Message Block for details.
There should be a DF1/CSP address for your IEC address.
Please explain this part. Makes no sense to me.
about 40 axis is taking a lot of words!!
that is the available data in DF1
this is only a part of what is available thru IEC
having access to iec will unlock all controller information without limitation.
Plc need to use indirect map.
Hmi can easily acess anywhere and spare indirect only for plc.
I see that the CSP access method always targets "Float" files in the PLC, even when the data is DINT. I don't think there's any way to tell IA's driver to re-interpret those as integers. A derived tag, perhaps. 
Why? The CSP (SLC 500) protocol implementation doesn't need to use indirection.
Use indirection only for the parts you need to monitor quickly.
that works fine. it just limit the amount of data we can tranfert to plc. i deal with it easily.
i can'T access averything with slC500 configuration axis PID are not acessible by default i have to map them! didn't find any other way
Hmm. The register map object reachable via EtherNet/IP class 3 messaging looks like it can access the entire controller. However, my class 3 client driver in my EtherNet/IP suite doesn't support custom services. They can only be supported with scripting via the Scanner option. (The scanner option can also do the I/O connection to the RMC.)
I am not sure i understand what you mean. can you be more precise please.
i have the setup to test any suggestion
My EtherNet/IP driver for Ignition, here:
.. provides fairly generic I/O and class 3 messaging features for common connection types. In particular, generic EtherNet/IP devices that support ordinary class/instance/attribute access are fairly easily configured. As are I/O connections described in EDS files.
The custom services as described in §6.7.10.6.8 in the RMC200 user manual are not directly supported. But could be scripted with my module. It would not be trivial.
that means more developpement for us?
Yes. (I sell services in addition to modules, if that is a path you wish to pursue. Contact me privately for that.)
For now i would prefer to get away without extra developpement
i will evaluate all options i can find.
thank you for your time and interest in helping us.
not all protocolcs can have full acess to rmc memory.!!
is it possible to use an active x with ignition?
EtherNet/IP explicit messaging with Class 0xC0, services 0x4B, 0x4C, 0x4D, and 0x4E are not shown in either table. Experiments would be needed. (Or call and ask Delta to clarify.)
No.
It might be least-cost to use DMCP described in §6.7.4 with a java socket and long-lived threads (but there are memory leak risks associated with managing long-lived state).
