Reading Schneider M580 Variables by Name from Ignition (Modbus TCP vs OPC UA)

Ignition
1

Hello everyone,

I am working on a project that integrates Ignition with a Schneider Electric M580 PLC.

I would like to understand the best approach for accessing PLC data from Ignition.

My main questions are:

  1. If the PLC is exposed through Modbus TCP only, is there any way to browse or read variables by their symbolic names, or do I need to know the Modbus register mapping (%MW, %M, etc.) and create tags manually?
  2. If OPC UA is available on the M580, can Ignition browse the PLC variables directly by name without requiring Modbus address mapping?
  3. For an existing M580 project where I do not have complete documentation of the register map, what is considered the best practice:
    • Using Modbus TCP with a provided register list?
    • Using OPC UA?
    • Using Schneider OFS / EcoStruxure OPC Server?
    • Another approach?
  4. Are there any licensing, hardware, or software requirements on the M580 side to expose variables through OPC UA?

I would appreciate any recommendations based on real-world Ignition projects.

Thank you.

2

The Modbus protocol doesn't have any notion of browsing or symboling names. If you go that route you must have a mapping and create the tags.

OPC UA is a better option if you want browsing and symbolic names but I wouldn't be surprised if there was a cost associated with it. Hopefully somebody else can answer that definitively.

3

Thank you for the clarification.

If I decide to use Modbus TCP, and the existing PLC project mainly uses symbolic variables without a predefined Modbus mapping, would I need to assign Modbus-accessible addresses (such as %MW or %M) to all the variables that I want to read from Ignition?

Also, in an existing production system, does adding these address mappings have any impact on the PLC logic, memory usage, or application performance, or is it generally considered a safe and common practice?

I'm trying to understand the best approach when working with an already deployed M580 applicatio

4

I'm not sure, these are Schneider-specific questions, somebody with direct experience will need to answer that.

5

Also, in an existing production system, does adding these address mappings have any impact on the PLC logic, memory usage, or application performance, or is it generally considered a safe and common practice?

No, adding these mappings on the Ignition side will not impact the PLC. But I have noticed with other modbus TCP devices that the modbus comms stop working for no apparent reason. Restarting the connection to the device usually fixes it.

But - OPC-UA is definitely the better option. Any time you want to add a tag to ignition you just browse for it. With Modbus TCP you have to add the mapping and verify the modbus address on the PLC side, mess with the register formatting (float, unsigned vs signed, BCD blah blah blah).

Modbus needs to go the way of the dinosaur.

6

Don’t use modbus.

7

We've been using Schneider's OPCUA driver for ages, it works well. It reads symbolic tags from the PLC and converts to OPCUA for Ignition to use. Not sure of license pricing, but link is here: https://www.se.com/us/en/product-range/66388-ecostruxure-opc-ua-server-expert/#software-and-firmware

8

I have a working UMAS driver (Which is a modbus dialiect by Schneider), which supports tag browsing and symbolic tags. I was really impressed by the performance, which is the first to even come close to the Beckhoff ADS performance ... if you're interested ... could whip up a module for ignition for beta-testing in a day or two. (In generall I could do that for any of the drivers listed here: ToddySoft Connect — Industrial Protocol Drivers — ToddySoft ... the ADS however is finished beta-testing, will start officially selling that in a week or so)

9

Answering your initial questions:

  1. M580 support the Schneider UMAS protocol (which is based on Modbus, but uses some "special" message types) With that you can list up all tags in the system and access them by symbolic names. In my test-rig I didn't need to do any special setup.
  2. Well ... Use UMAS :wink:
  3. No additional license fees on the PLC-side ... it's the PLC native protocol and included with the PLC

I should also mention, that I've got a Schneider M580 here in my bench and I've validated the driver against exactly that model.