Prevent vision screen from loading the last saved values

We have a vision app that is pointing at plc opc tags, the last save of the window has all of the dropdowns set to -1 to force the operator to make the correct selections.

We are finding that if the operator is running the machine with the app, and then the engineer opens a second app from their desk to watch whats going on, it defaults the dropdowns to -1 mid run which is messing up the data.

I know we could change everything over to client tags and then point those to the OPC tags but I was wondering if there was a less intrusive way to prevent the screen from changing the first time the app is opened?

Let me know if this is too vague and you need more info. thanks!

1 Like

Unidrectionally bind your OPC tags to the dropdowns, only write values to PLC on confirmation via script. With this you can run a script on window open to set values to default for operators and check the login level (so engineers don't have the screen reset), and it won't write anything to PLC without explicit intent.

2 Likes

... What Ryan said ...

Thanks, I’ll look into it.

If using indirect tag binding and relying on that for the path to write back, consider moving the indirect tag binding to a custom property on the input field or dropdown. Then unidirectionally bind from the input value to the custom prop. Then the confirmation script can simply assign the current input value to the custom prop to trigger the correct write.

(Having the current PLC value present with the user input value allows you to style the component to show differences before confirmation.)

3 Likes

Thanks, so if I am understanding correctly. I high level breakdown would be to keep the binded tags but for read only, nothing gets written back to the tags until they hit the start button or something similar. if it was scripting on the dropdowns, it would do the same thing when the dropdown data changed (trigger the write) when it gets reset or cleared after a run. Thanks!

1 Like

I deployed the change and it works awesome and fixed that issue. I appreciate the help!

But like all good deeds, here comes the punishment. Now the operators tell me they liked setting all of the values before navigating to other screens and coming back before they run the line. So now, they setup the page and when they come back they have to set it up again.

I was thinking to get around this have local client tags that the dropdowns would link to so they could save the values before navigating to other screens and write the client tag values back to the opc tags when the line starts. The problem is now, should I use an expression on the client tags to read the opc tag when its running and the client tag when its stopped?

Any other suggestions? Thanks!

You can use two client tags for each. One bound bidirectionally to the gateway tag, and the other unidirectionally bound to the first client tag.

Then the entry field would bidirectionally bind to the 2nd client tag. The update and cancel scripts would copy from one client tag to the other.

No option for indirection in this setup, I think.