Hi
I am writing to a .Cmd-dpe. This is read by a PLC, but I am in charge of resetting .Cmd to low. Either when I get a feedback OR on a delay.
Now this is implemented with a dpConnect to the feedback and a startThread waiting for a fixed amount of time. Whoever first, will reset .Cmd.
But the issue is that all of this code is startet in the clicked-event of a button. If for some reason the button is removed from the screen both the thread and the dpConnect is not executed. This .Cmd will never be reset.
Does anyone have a good solution to this problem?
Best regards, Dag-Are Trydal
Command Feedback/Timeout via Thread
Search
-
Dag-Are.Trydal@nov.com
- Posts: 37
- Joined: Fri Feb 26, 2016 11:52 am
-
Gertjan van Schijndel
- Posts: 634
- Joined: Mon Aug 02, 2010 10:37 am
Re: Command Feedback/Timeout via Thread
Why do you need to reset this command element? Is it not sufficient to only reset the flag in the PLC?
-
Dag-Are.Trydal@nov.com
- Posts: 37
- Joined: Fri Feb 26, 2016 11:52 am
Re: Command Feedback/Timeout via Thread
I agree that that would be the best solution. But the PLC program/interface is fixed, and I am not allowed to change it.
Have tried a dp-function (_dp_fct) statical function. But even thoug I selected the function to be "Change 0->1" and result to "false" it is not allowed as pointing to yourself is characterized as a loop.
Right now I see only two solutions:
1.
Write to a intermediate datapoint. Have a dpConnect in my main panel that forwards to the .Cmd-datapoint, and is in charge of re-setting. This does however not solve the problem if the UI is closed all-together.
2.
Write to a intermediate datapoint. Have a dedicated manager that forwards to the .Cmd-datapoint, and is in charge of re-setting. This might be more robust, but still it for some reason .Cmd is high it will never be reset before someone clicks my button.
Have tried a dp-function (_dp_fct) statical function. But even thoug I selected the function to be "Change 0->1" and result to "false" it is not allowed as pointing to yourself is characterized as a loop.
Right now I see only two solutions:
1.
Write to a intermediate datapoint. Have a dpConnect in my main panel that forwards to the .Cmd-datapoint, and is in charge of re-setting. This does however not solve the problem if the UI is closed all-together.
2.
Write to a intermediate datapoint. Have a dedicated manager that forwards to the .Cmd-datapoint, and is in charge of re-setting. This might be more robust, but still it for some reason .Cmd is high it will never be reset before someone clicks my button.
Re: Command Feedback/Timeout via Thread
Hi there,
You can use a control manager that connects to your command and response datapoints. After certain amount of time, you can just reset your command dpe. Consider having a global place to keep currently active commands.
Check "dpQueryConnectSingle" function which will possibly help you with the implementation.
You can use a control manager that connects to your command and response datapoints. After certain amount of time, you can just reset your command dpe. Consider having a global place to keep currently active commands.
Check "dpQueryConnectSingle" function which will possibly help you with the implementation.
-
Gertjan van Schijndel
- Posts: 634
- Joined: Mon Aug 02, 2010 10:37 am
Re: Command Feedback/Timeout via Thread
An intermediate datapoint is not needed, a userbit can be used to indicate an outstanding reset.
For in-/output addresses the driver sets a transition bit during the outstanding write, which is reset when the value is read back from the PLC or if the value is not read back after an IOTransitionTimeout (driver config entry), in this case the value is also set back in the datapoint (but not sent to the PLC).
For in-/output addresses the driver sets a transition bit during the outstanding write, which is reset when the value is read back from the PLC or if the value is not read back after an IOTransitionTimeout (driver config entry), in this case the value is also set back in the datapoint (but not sent to the PLC).