Perspective One-Shot button

Ignition
1

I could really use some defogger and greatly appreciate any help you could offer.

I've been scratching my head about something that's been bugging me. Let me ask you this one about one-shots in perspective. I’ve read many suggestions and comments here on the forum and I still have a mental block.

How would you set one up if you had to, using the perspective one-shot button including the ladder logic behind it without needing a timer in the plc to reset the write back or a crazy fast scan class?

I’m using the one-shot button in ignition to set from ignition and reset in a plc. Of course I have to set up a timer to reset the bit for the readback because of the “race” that happens and without it the plc already changed the tag before the next read. It just seems like a cheesy way of doing it, using a timer. Shouldn’t we be able to write from ignition and it knows that it wrote the value so when it sees that it was reset in the plc, it knows it was changed since it knows it wrote it. Why doesn't it know this on the next time it reads the tag value. Why should I have to have a timer with a preset time greater than the tag scan class to reset the bit in the plc. I mean, I get why I have to but it seems like it should be able to do this without a timer in the plc. It just seems like I’m missing something.
Am I missing something?

2

I don't understand why you need ignition to "know" that the bit was set to true in the PLC?
If you send the OPC write, the PLC will set the bit true unless the connection drops. If the connection drops, ignition will log a fault with the driver. If the bit gets immediately reset by the PLC, then the PLC scanned the bit and it was processed.
What function does the confirmed write perform for you?

3

So what I'm seeing is that if I write the value to the tag and the plc resets it without the timer, it's written back quickly enough to beat the subscription making it look like nothing happened on the button and it will just time out.

It's almost like the button needs maybe another prop. Like an acknowledgement prop tied to a different tag for the read back so we're not writing and reading the same tag.

4

I just don’t use the one shot button in perspective.
Use a standard button, on click handler sends opc wrote to tag path. Button fill colour is bound to the tag, tag will get written, then it will be turned off on the plc, then the subscription will update.

5

Also, I'm trying to utilize the one-shot with the read back instead of just a normal momentary button. Every hmi I have or have worked on has momentary buttons on the hmi. I was trying to try a different “best practice”. I'm tired of the old “it's always been that way”

6

This is the flaw in your thought process. "Knowing" is state, which requires memory. Writes are, by default, fire and forget. A requirement of how OPC is supposed to work. If you need state, you need a state machine.

The "optimistic writes" property of tag groups may help in this case, but can get you in other trouble.

Consider using system.opc.writeValue() to send the bit, instead of a bidirectional binding. The latter will almost always get confused with instant resets in the PLC, as you have noted.

7

Interesting, I read what you wrote here in another post, by you, but for some reason it makes more sense now. Thank you

8

Also, don’t use timers to reset HMI bits in the PLC as most bits don’t need to be persistently on for multiple scans.

I use the following logic (Rockwell but can be applied in any platform)

XIC my_PB ONS my_PB_OS OTE my_PB

This logic will keep the PB on for one scan, which should be all that is needed to execute the associated logic, and isn’t dependent upon where you put it in code like other methods that reset the bit using unlatch instructions.