# MRC200 reading thru IEC Adresses

**URL:** <https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023>\
**Category:** Ignition\
**Created:** [May 28, 2024, 5:41pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023 "2024-05-28T17:41:33Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![martin.larochelle](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@martin.larochelle](https://forum.inductiveautomation.com/u/martin.larochelle)\
**Post date:** [May 28, 2024, 5:41pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/1 "2024-05-28T17:41:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [May 28, 2024, 6:12pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/2 "2024-05-28T18:12:33Z")

</div>

The datasheet lists 3 options that you might work:

- Modbus/TCP
- Omron FINS
- EtherNet/IP (likely only by 3rd party module from @pturmel)

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.

---

<div class="post-metadata">

**Author:** ![martin.larochelle](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@martin.larochelle](https://forum.inductiveautomation.com/u/martin.larochelle)\
**Post date:** [May 28, 2024, 6:30pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/3 "2024-05-28T18:30:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 28, 2024, 6:31pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/4 "2024-05-28T18:31:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 28, 2024, 6:32pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/5 "2024-05-28T18:32:35Z")

</div>

> [@martin.larochelle](#):
>
> i will run out of space for the Hmi

Please explain this part. Makes no sense to me.

---

<div class="post-metadata">

**Author:** ![martin.larochelle](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@martin.larochelle](https://forum.inductiveautomation.com/u/martin.larochelle)\
**Post date:** [May 28, 2024, 6:38pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/6 "2024-05-28T18:38:55Z")

</div>

about 40 axis is taking a lot of words!!

that is the available data in DF1

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/5/a57e294d9747368f4411c594484a7b6229c02503.png)  
i need to map the register i want to acces in the indirect data map from 0 to 1023.  
plc use 10 write, 10 read (i maybe ca reduce it to 8)  
hmi uses about 16 (we want a bit more)  
that makes 36 words per axis. so 1400 word total.  
plus some status for the controller itself that are not accounted here.

this is only a part of what is available thru IEC

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/e/bed992de5fcf2edb62317354a9f7e7707a037c58.png)

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.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 28, 2024, 6:40pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/7 "2024-05-28T18:40:17Z")

</div>

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. 🤷‍♂️

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 28, 2024, 6:41pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/8 "2024-05-28T18:41:21Z")

</div>

> [@martin.larochelle](#):
>
> in the indirect data map

Why? The CSP (SLC 500) protocol implementation doesn't need to use indirection.

Use indirection only for the parts you need to monitor quickly.

---

<div class="post-metadata">

**Author:** ![martin.larochelle](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@martin.larochelle](https://forum.inductiveautomation.com/u/martin.larochelle)\
**Post date:** [May 28, 2024, 6:41pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/9 "2024-05-28T18:41:36Z")

</div>

> [@pturmel](#):
>
> hat 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 thos

that works fine. it just limit the amount of data we can tranfert to plc. i deal with it easily.

---

<div class="post-metadata">

**Author:** ![martin.larochelle](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@martin.larochelle](https://forum.inductiveautomation.com/u/martin.larochelle)\
**Post date:** [May 28, 2024, 6:43pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/10 "2024-05-28T18:43:25Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 28, 2024, 6:53pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/11 "2024-05-28T18:53:38Z")

</div>

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.)

---

<div class="post-metadata">

**Author:** ![martin.larochelle](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@martin.larochelle](https://forum.inductiveautomation.com/u/martin.larochelle)\
**Post date:** [May 28, 2024, 6:57pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/12 "2024-05-28T18:57:20Z")

</div>

I am not sure i understand what you mean. can you be more precise please.

i have the setup to test any suggestion

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 28, 2024, 7:02pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/13 "2024-05-28T19:02:16Z")

</div>

My EtherNet/IP driver for Ignition, here:

> [@Automation Professionals' EtherNet/IP Communication Suite V2](https://forum.inductiveautomation.com/t/automation-professionals-ethernet-ip-communication-suite-v2/68190):
>
> Automation Professionals is pleased to announce its latest EtherNet/IP Communications Suite driver module, a major upgrade to its EtherNet/IP Class1 Communications module, as a Public Beta. As of April 15, 2023, this is now a Production Release. The primary new feature is its new Generic EtherNet/IP Client Driver, a drop-in replacement for IA's Logix V21+ driver and its Omron NJ/NX driver. It does work with older Logix processors, and also works with Rockwell's MicroLogix 8xx family (ethernet…

.. 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.

---

<div class="post-metadata">

**Author:** ![martin.larochelle](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@martin.larochelle](https://forum.inductiveautomation.com/u/martin.larochelle)\
**Post date:** [May 28, 2024, 7:07pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/14 "2024-05-28T19:07:03Z")

</div>

that means more developpement for us?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 28, 2024, 7:11pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/15 "2024-05-28T19:11:24Z")

</div>

Yes. (I sell services in addition to modules, if that is a path you wish to pursue. Contact me privately for that.)

---

<div class="post-metadata">

**Author:** ![martin.larochelle](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@martin.larochelle](https://forum.inductiveautomation.com/u/martin.larochelle)\
**Post date:** [May 28, 2024, 7:12pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/16 "2024-05-28T19:12:26Z")

</div>

For now i would prefer to get away without extra developpement  
i will evaluate all options i can find.

---

<div class="post-metadata">

**Author:** ![martin.larochelle](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@martin.larochelle](https://forum.inductiveautomation.com/u/martin.larochelle)\
**Post date:** [May 28, 2024, 7:30pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/17 "2024-05-28T19:30:13Z")

</div>

thank you for your time and interest in helping us.

---

<div class="post-metadata">

**Author:** ![martin.larochelle](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@martin.larochelle](https://forum.inductiveautomation.com/u/martin.larochelle)\
**Post date:** [May 28, 2024, 8:27pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/18 "2024-05-28T20:27:27Z")

</div>

not all protocolcs can have full acess to rmc memory.!!

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/6/96e2d5704a2ec689df48b3bb66c20052a7b8f3db.png)

[https://deltamotion.com/support/downloads?category=rmclink&subcategory=software&listtitle=Software%20-%20RMCLink%20(.NET/ActiveX)](https://deltamotion.com/support/downloads?category=rmclink&subcategory=software&listtitle=Software%20-%20RMCLink%20(.NET/ActiveX))

is it possible to use an active x with ignition?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 28, 2024, 8:33pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/19 "2024-05-28T20:33:14Z")

</div>

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.)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 28, 2024, 8:33pm UTC](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023/20 "2024-05-28T20:33:33Z")

</div>

> [@martin.larochelle](#):
>
> possible to use an active x with ignition?

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).

[Next page](https://forum.inductiveautomation.com/t/mrc200-reading-thru-iec-adresses/91023.md?page=2)
