Low Level Comparison and Value Overwriting

[n_lev]

Hi guys!
Got a bit of a theoretical question.

Say, my project has whole bunch of devices and I read their states as integers from the Siemens PLC. I use S7 driver and configured _address on every one of those datapoints.
I used "Low Level Comparison" as advised to avoid messages going everywhere every second (my poll time). So far so good.
I got a graphical representation for those devices on a page and a whole bunch of dpConnects to change the color on change of state. Since I have "Low Level Comparison" I can see that my dpConnects only get triggered when value in the PLC changes. Great!

But!

I can easily now change the value of the device state (via PARA, script, etc. deliberately or accidentally) so that it is now DIFFERENT to the value in the PLC. My graphics updates to represent this new value. And since I have "Low Level Comparison" that value now never changes back to the one in the PLC, until the value in the PLC changes. As a result I have a very bad situation where my page shows something completely untrue!
Of course, I can disable "Low Level Comparison" and than the value will be overwritten all the time, but that will also trigger all my dpConnects all the time and introduce unnecessary load to the comms between the driver and event manager.

So, the question is, is there any way to prevent this situation where a fake value is written to a datapoint that should get it's value from the PLC?

[n_lev]

I can of course come up with some "innovative" methods like a special control manager that checks if a value was changed by any manager other then DRV and change it back, but it seems pretty cumbersome. Am I just missing something obvious conceptually?

[leoknipp]

Hello,

the described behaviour is the correct behaviour in a WinCC OA system.
The old/new-comparison is made in the driver. The new value is compared to the value which was received before from the PLC. Updates on dp-elements which have an input-address are not send to the driver.

To avoid that a user can set a specific dp-element you can use the _auth-config.
At this config you can define which permission bit is required to modify another config for the same dp-element.

E.g.: if you define that the user needs the permission bit 4 to modify the original value can be set by the driver.
For the user "operator" this permission bit is not set and therefore he cannot modify the original value.

Best Regards
Leopold Knipp
Senior Support Specialist

[n_lev]

Hi Leopold,

I actually found that _auth config just before I saw your response. Seem to work with only one exception, "root" seem top always be able to write value, even if I use bit that "root" doesn't have.

Thanks for your help

[n_lev]

As a side question.

I can't seem to dpConnect() to ":_address.._active" config? No errors reported, just that changing it's value (check/uncheck via PARA doesn't call the callback function). Is that an expected behaviour?

[leoknipp]

Hello,

the "root"-user (user-ID = 0) is a special user which does not belong to any of the user groups.
It's the correct behaviour that this user can modify the configs.


The information for the _address-config is held by the driver during runtime. The event-manager which sends the hotlinks for dpConnect() does not have this information.
Therefore a dpConnect() for this config does not work.

Best Regards
Leopold Knipp
Senior Support Specialist

[n_lev]

Thought so on both counts. Thanks Leopold!