This device uses a Modbus write to verify security before you can pull data from it. I need to write "xxxx" to register 10434 before it responds to any Modbus reads. If it gets reads before the write, it closes the connection.
I went with using a UDT for this device (as I have more than one) and cant seem to force a write before the other reads get queued and get the connection closed.
On the Ignition Server side; I just see the connection moving from Disconnected => Connecting => Connected => Disconnected
I need to write the password to Holding Reg 10434. The DSLC will terminate the transaction otherwise. Which looks like this in the logs at level "TRACE"
I have confirmed this is what is stopping the connection by using a Modbus master simulator, and "Blind" writing the password to that register and then I was able to read data out of the DSLC. There isn't a way to change the security settings on the DSLC.
Question:
How would you has anyone dealt Modbus security like this?
Huh. You'd have to disable all of the Ignition OPC tags for that device every time it is disconnected. When re-connected, use system.opc.writeValue() to blind write that passcode. If that returns successfully, re-enable the rest of the tags.
Probably wouldn't be hard to add that sequence to my alternate driver, but it wouldn't be soon.
Yes, as noted, but disabling the entire device will prevent you from performing the password write. You will need to disable all of the OPC tags instead.
I'm wondering (depending on tag count), if it would be easier to set up 2 connections per device and the first one does the write, then enables the second connection once it's completed to begin polling. Might be easier to implement than enabling/disabling all the tags, and would allow easy addition of other tags in the future.
Yeah, I considered that, but unless I misinterpreted this comment of the original post. I think he's saying he used the Modbus master simulator to do the write, then was able to read with Ignition, but it wasn't clear, so I'm not sure.
I did think about that; I tried to use my Modbus Master Simulator to "trick" it in to letting me have access. I did the password write from the Simulator on the same machine as the Ignition server but no luck. The Simulator got data but Ignition did not. I might have better luck if I try from Ignition itself rather than a 3nd party software
Do you think as @bschroeder suggested a driven tag would work possibly. If he sets up a memory tag as the driving tag that on disconnection gets set false, then a script monitoring the connection going to a connected state initiates a direct OPC write to the tag, then turns on the memory tag to allow other tags to poll. Then to keep the connection alive, just periodically repeat the OPC write to try to keep the connection alive.
@Jacob_Leonard Is there a modbus register that can always be read to determine the security state? This would help if there is one.
Yes, with the slow rate set to zero. That will likely work. It is important that the password register not be a tag at all. It must be sent with system.opc.writeValue().
What worries me doing this is that any tags that aren't disabled (or the driven tag turned off to prevent polling) will keep trying to poll and will disconnect your device. So ideally, you won't have anything connected initially, then once the connection is good without anything trying to poll, you send the system.opc.writeValue() as @pturmel mentioned, then re-enable your tags (or turn on the memory tag to allow the other tags to be driven to poll).
I believe every time the connection disconnects, you'll have to re-write that OPC tag to get it to start working again. Which is also why I think you may need to periodically send it no matter what to ensure you don't time-out.
I tried with using driven tag groups, then with just disabling all opc ua tags in the data type; then as a last ditch effort, I deleted the datatype entirely. The connection still refuse to stay alive.
I plan on reaching out to the rep to see if there is anything I am missing anything. But I think that this isn't a Ignition problem anymore.
Also, I have come to the realization that the password changes every power cycle. So this has become probably become a impossible task I was wrong about that.
