Hello,
I’m trying to write to a Red Lion EtherTRAK E2 via Modbus in Ignition 8.1. The OPC Item Path starts with HR and I am able to read the tag but not write to it.
Anyone have any experience with this?
Do you have any security settings configured on the tag?
No, everything is public. I have tested both analog and discrete tags with no luck. Unfortunately I’m not well versed with Modbus or Red Lion so I am reaching out to Red Lion for support as well.
As long as the tag has Read Only False, then I can’t imagine why it wouldn’t write if the tags are correctly reading.
Maybe check into this
This could also be caused by the ability to read single registers as a single register, regardless of it being part of a multi-register tag, like a 32 bit integer or similar. You can read the integer as two 16 bit integers, but you can very seldom write to only one of those registers by itself, only both at the same time, because the device knows they are part of the same register data type. What settings are you using in the modbus driver, and also can you share the OPC paths you have tried?
I set up the Modbus device according to the manual–no settings specific to my project other than the device name and IP address. One specific tag I’m testing with is an Analog Output with address AY300 in Red Lion. The OPC path I am using is [Device Name]HR300. I can read the tag but not write to it.
What sort of error are you seeing?
No errors. The value I enter sits in the numeric entry for about 3 seconds then reverts back to the current value of the tag. I was just using ModScan and Wireshark to test outside of Ignition and am getting similar results, so I suppose this is probably not an Ignition issue.
That is the normal behavior when using "optimistic writes" and the optimism is unfounded.
Optimistic writes are disabled.
What happens if you try to write a value in the designer's tag browser?
Nothing.
Not sure if you’re familiar with Red Lion, but I’ve discovered that I can write to the tags if I am online with the PLC but have the program stopped in Red Lion Workbench. With the program stopped, I can write from Ignition and see the values change in SixNet Toolkit. I’m assuming this means that the program is overriding any changes I try to make with my writes, but I have no idea why that would be happening or what is causing it.
Ooo! That would explain all of your symptoms. You will have to drill into the Crimson (?) software for that unit.
Sorry, I’m not sure what you mean…just for clarification, I’m trying to write to virtual I/O processed entirely by the CPU at this point. The configuration for this processor is set up with Sixnet I/O Toolkit, and the actual programming is done with Red Lion Workbench. I think Crimson is for Red Lion’s HMI? This is my first time dealing with Red Lion and I didn’t write the program.
Ah, ok. I thought Crimson covered the DA30D as well, misled by another link. (Been a while.)
Anyways, something on the PLC side overwriting would have exactly your symptoms.
This works fine for me writing to a Redlion via modbus.
OPC - Float - Item Path: {deviceId}{registerType}{register}
{deviceId} = ns=1;s=[site_RedlionDA50]
{registerType} = HRF
{register} = 1002
The modbus address in the Redlion for this example is 41002
Edit: In the OPC UA device connection I do have:
Reverse Word Order - enabled (default: false)
Is it necessary to set address configurations for the device in the Gateway? If it isn’t necessary are there benefits to doing it?
No.
One: mapped address ranges are browsable in Ignition, enabling drag-n-drop to Ignition tags in the designer. Also enabling some debugging with the gateway's Quick Client interface.
But you should limit drag-n-drop in the designer, so I only count the latter as a benefit.
You didn't ask if there are downsides, but note that all error logging in the driver will report problems using the underlying protocol addresses (zero based), not using the mapped aliases, so troubleshooting will be more difficult. Particularly when trying to correlate with external tools like Wireshark.
(My alternate driver doesn't use address mapping, and provides OPC browsing of the native address ranges.)
@Nol in the Red Lion workbench, Tag1 is labeled as a DINT. In the Sixnet Toolkit it’s labeled as an FOUT. How would you go about addressing this in Ignition?
Solution:
I added float addresses 0-5000 to the Gateway and scrolled until I found the tag. It ended up being at address 3577. Maybe somebody with better Modbus understanding can parse that out.
Edit: Looks like it still doesn’t work if I try to map it directly using OPC-Float-[OPC Server]-[Device Path]HRF3577. Any ideas?