Hi, We are trying to link a Schneider TM251MESE plc to ignition with modbus tcp communication. We are able to create a connection between the plc and ignition, but we are unable to link the ignition tags to plc, since we cannot seem to replicate the PLC mapping with modbus addresses. We are reading zeroes for everything but the first few coils (around MODBUS address 000001). Is there anything in the Ignition gateway settings or in Ignition designer that can help us read integer values that are not zero? (i.e. from %QW03 or %IW08).
I have been able to read registers by adding the āHRā prefix to my tags. For example float 8265 is now [DEVICE_NAME]HR8265 . I had zero luck with the mapping aspect, typed in the tag manually.Also the device needs to be setup and in advance.
The free Modbus tester from SE will help you track your tags.
Schneider Modbus Tester
Bit memory can only be accessed as bits in Modbus, per its spec. Modbus devices that support read-modify-write can treat bits of holding registers as booleans.
Your PLC would have to expose your %QW as an HR, and the %IW as an IR. %Q is accessible as C, and %I is accessible as DI.
https://docs.inductiveautomation.com/display/DOC79/Modbus+Addressing
1 Like
I forgot to mention in the initial post that we've tried HR and IR to read %QW and %IW respectively, but the resulting tag values are 0 unfortunately. %Q as C does seem to work, though.
For a Schneider PLC, we are not entirely sure where this is done. At the moment we are trying the add the device's MODBUS TCP slave configuration in SoMachine. Is that what you are talking about?
You missed my point. You cannot do this with Modbus. You will need code in the PLC to copy bit memory to word memory. Modbus word accesses cannot read bit memory. At all.
Unless that Schneider CPU model has some feature that can alias the two together (not that I've heard of such a feature).
You can try a third party software like the Kepware-EX, this might get the job done, they have a 2-hour demo package. You could also try read the tags via Python. Were you able to read the tags with Modbus reader?
We've tried using KEPServerEX as our 3rd party OPC server, but we're running into the exact same problem, where we can read %QXx.x things but not holding registers or input registers. We're not sure if we are addressing them correctly (is it 040001 or 400001 for %QW1, is it 400006 or 400011 for %QW11, etc.), since we only read zeroes, but this is a minor issue.
If this is true, then it's the real problem we are facing - we want to read 'bit memory' as 'word memory', but the PLC doesn't do this automatically. It's misleading since the documentation seems to imply we can just read bit memory as words...
Here are some screenshots:
Do we need to configure a Modbus TCP slave device shown here in SoMachine (we are not sure how to configure this)?
These are some values we are trying to read through MODBUS/OPC UA, viewed from SoMachine:
And here is the value we are reading from Ignition Designer:
Some properties in Ignition Designer:
And the properties in KEPServerEX:
If the PLC is exposing %QW1 as Modbus 400001, then it really is word memory (the ā4ā prefix) and Ignition address HR1 should work just fine. I donāt know enough about the Schneider to advise further.
1 Like
Iām connecting M241 to Edge through Modbus TCP IP.
In PLC, Iāve copied everything I need to access into word memory, so Iām dealing with MX (byte), MW (word), and MD (double word).
Itās important to note how Schneider does the addressing: MX100, MW100 and MD100 are completey different locations (on the other hand, in Siemens I believe theyād be the same). However, these addresses overlap, e.g. MW1 is made of MX2 and MX3. The same relation is between MW and MD (factor of 2), and between MX and MD is a factor of 4.
For Modbus driver, you can look at MW at basis, since it is basically what you get from the PLC if you put in HR. In my case, the MW201 corresponds to the data of HR202, there is an offset of 1 for word values.
This also means that MD205 is HRF412 [(205+1offset)*2].
MX200.0 is HR101.0, MX200.7 is HR101.7 and MX201.0 is HR101.8, the last one being the second byte in the word.
As you can see, you always have to take into account the offset and how the bytes and word are written in memory. This offset problem might have been avoided with different driver configuration, but I didnāt have the time to test this, so at this point Iām not making claims either way.
Now Iām going to introduce my problem. 
Iām using control elements like numeric text box with bidirectional binding to the tags with addresses as described above. I can read all the tags, however I can only write HRF and HR (floats and integers) back into the PLC. If I try to write a tag with e.g. momentary or one shot button with HR102.0 (MX202.0) address, I get a āError writing ā0ā to tag [edge]{the rest of the tag path} Badā.
Does this also happen if you create a boolean tag with that address? Is there an error in the gateway logs at the same time?
Yes, the tag is boolean type with item path [ROB5]HR102.0.
The is an error in the logs for every write attempt:
MaskWriteRegisterRequest - Received response with ExceptionCode: 0x01 (IllegalFunction).
Okay this means that the device youāre connected to doesnāt support bit-level writes on registers via the MaskWriteRegister function.
Youāre going to have to use a derived tag or scripting function that reads, masks, and writes a new word back down instead. Thereās an old post discussing the derived tag setup here: Troubles making a Derived Boolean Tag work as a mask for a Short Tag and thereās probably multiple posts discussing the scripting approach floating around.
2 Likes
Or consider using bit memory (%Q) for bits and word memory (%M) for words, as Modbus' original architecture is designed to do. That will avoid the race conditions that manual implementation of Read-Modify-Write cycles suffer.
Iām just going to post a quick followup. I took a step back and went to driver configuration. I checked āZero-based addressingā and āReverse word orderā and all addresses fell into place. Now MW200 is HR200 and MD200 is HRI400.
In PLC I copied DI into MW100 and I put other statuses into MW101 and commands into MW102. These words were brought into Edge as OPC tag integers HR100, HR 101 and HR102. Then following Kevinās advice I used derived tags to read and write bits from my status and command words (OPC tags). For derived tags I just C/P read and write expressions from Kevin and adjusted bit offset. Now everything works ok.
1 Like
Okay, weāre a bit farther on the issue. We are able to read and write integer values from Ignition so long as we specify the PLC memory address in SoMachine (i.e. adding āAT %MW201ā to an integer definition), and we are using KEPServerEX as the OPC server. Our new problem is that we cannot write boolean values (i.e. %MX401.1) the same way. On Ignition Designer, whenever we try and toggle any boolean variable, we get āError writing to TagName.value:Badā. The same sort of issue happens in KEPServerEX and from Ignition Gateway where we cannot write booleans. Would anyone happen to know why? We are certain the address is correct (we can set booleans by just defining them as words and then writing the appropriate decimal number corresponding to the bit).
Same reason I told @ena_bj maybe?
To my knowledge, you must specify the address in variable tables in PLC, if you want that variable to be visible on Modbus, since that address in variable table is also a Modbus address. I used word memory, which corresponds to holding registers.
The problem you have now is the same as mine, the fix is a few posts above.
Yep, our fix was the exact same using derived tags (shouldāve read those posts carefully). Sucks that we canāt do bit-level writes by default. Thanks to everyone for all the help!
Hi Mr Pturmel
Recently Iām trying to establish connection between my M340 Schneider and Ignition through Modbus, I am using the EGX150 Schneider through RS485.
For some %MW tags I was able to retrieve the readings correctly, but for others same tags I canāt. The reading is totally different from PLC.
Based on your post I set like 1.HR221 and 1.HR241 for respectively tags %MW220 and %MW240, but the readings seem to be not correct (adding 1 in the address number).
See below the picture:
Ignition screen - bad reading
Schneider M340 PLC - correct reading highlighted
Any idea why the readings seems inconsistent ?
Thanks a lot.
Try the āReverse Word Orderā setting on the driver?
2 Likes