How do you get webPLC values to persist across reboots?


#1

If I have a webPLC program with several inputs and outputs and I want certain variables in this program to persist across a reboot, how do I do that?

I tried using the portalVarXX variables with the retentive flag set but those variables go back to 0 when the device reboots.


#2

Hello Adam,

What devices are you working with here? Is this just the webPLC or is there an anybus device involved?

Deryck


#4

Just the SG gateway.


#5

#6

Hello @adam.todorski,

You can make a variable retentive under Setting > PLC > variables. When you edit the variable there is a check box to set it as retentive.

Regards,
Deryck


#7

I did that:

But the values are not retained (there were non-zero before rebooting):


#8

Hello Adam,

Sorry for the delay I have been working on testing this to see if there would be another option for retentive variables. I am reaching out to my colleagues to see if they know of another option.

To make sure im looking at the right info for your device can your provide the Article number or serial number for your device.

Deryck


#9

Hi Deryck

Thanks for staying on top of this. My device is an ASG1014-C, MAC/SN 0005940601AD


#10

Hello Adam,

After discussing this with my colleague he confirmed using retentive on a variable should keep the info on a reboot.

Would you be able to export your configuration without the User management exported. The user management part will require us to also have your password. Also is there one or two DNP masters connected?

Deryck


#11

Hi Deryck

Here is the config, minus user setup. There is only one DNP3 master talking to the IXXAT device.

To reproduce my issue, load this config and verify that you can write binary commands to the DNP3 binary output address 0 and analog output address 0 (inputs to the device). Whatever you write should be reflected in the first two portal vars, which are set to retentative. Reboot the device then check the status of those variables as well as the DNP3 analog and binary inputs (outputs from the device). The expected behavior is that both the portalvars as viewed in the device web UI and as ready over DNP3 are whatever values you wrote in the first step. What actually happens is the value is 0.

Adam

ixxat_sg_dnp3config.cup (371 KB)


#12

Hi Adam,

Thanks for the quick response. My colleague had already responded with me he managed to recreate the same setup. It looks like it is an issue with your config, after a power-cycle the variable will become overwritten without any time to check the last value before powerloss. The issue come from how you have the data setup.

This example should work since the lower half part is picking the retentive value in the first moment (first cycle) and saves it into another variable. This allows for a longer time time to check this variable. If it contains the value, so it works - if its zero/empty, so the variable lost the value and is not retentive.

Deryck


#13

Thanks Deryck. This is confusing and will make a complex/large PLC program more complex to account for. This violates how DNP3 is supposed to work: a DNP3 output (input to the device) should have whatever the last value which was written to it was as its current value regardless of device reset, etc. I would classify this as a bug because it violates the DNP3 specification.

More generally the fact the all inputs to the device (Modbus, 104, etc) revert to 0 when the device reboots is unexpected and not how any other device I’ve encountered works. I would ask as a feature request that this behavior change to make all inputs retentative (or have the option for this to be the case) in a future release.

Thanks!


#14

The program was written as a proof of concept for the retentive data.

More generally the fact the all inputs to the device (Modbus, 104, etc) revert to 0 when the >device reboots is unexpected and not how any other device I’ve encountered works.

Is this for the modbus slave or the modbus master? Can you share an example showing what you are referring to?


#15

Hi Deryck

The proof of concept was written to figure out how to retain values across reboots for a program which will be much larger. If something special has to be done to account for the first time the program runs and the order the inputs to the HMS device will be copied to portal variables then that will add a lot of complexity.

You ask about Modbus - this would be for when the HMS device is a Modbus slave, but for DNP3 when the device is a slave this is actually part of the protocol. If I have a DNP3 input which I can write values to the device, called an output in DNP3 but called an input in the HMS config UI, and I write a value to one of these fields, that value must persist if the device is rebooted. For example, if I have a DNP3 analog output configured on the device at address 3 and I write the value 2000 to it, then I reboot the device, when the device comes back the value both as reported by the HMS device on DNP3 integrity scans and the value actually used by anything in the webPLC which references that value (remember, a DNP3 output is an input to the device) must use the last value I wrote (2000 in this example).

Let me know if you want to get on the phone to discuss this, it is very import for my application that this device supports this behavior.

Adam


#16

Hi Adam,

Deryck is on vacation today but is going to be back in tomorrow. I can try and escalate this issue to our colleagues in Sweden if you’d like or we could wait until tomorrow


#17

Hi Tim,

Tomorrow is fine.

Thanks,

Adam


#18

Tim, Deryck, any update on this?


#19

Hi Adam,

I though I had followed up with you regarding this. I am messaging my colleagues again regarding how this would be handled regarding the DNP3 protocol and if this could be a bug.

Regards,
Deryck

Deryck


#21

Hi Adam,

I apologize for the delay i am still working on getting a good answer to this issue.

Regards,
Deryck