I am currently using RsView32 to set bits in logic in a PLC5. The touch animation action on the object is press tag =1 release tag = 0. The problem is that a various times the bit stays on in the PLC and you have to go online and toggle the bit off. Our feeling is that there is a communication issue that the PLC doesn’t see the set to 0 command from the HMI. I followed a couple of threads on this site that had good fixes (please, point me to any suggested threads that may help) but still looking for a fool proof solution. There is a / v parameter available for set commands. Does this do more than enter a line in the activity log? Can that be used to trigger an event that will set bit to 0? Should we be using that rather than the = 1, = 0 way? Also is there an accepted standard of how the logic in the PLC should be done to resolve this problem? Thanks, for any help.
Rsview stuck on bit
- Thread starter frw312
- Start date
geniusintraining
Lifetime Supporting Member + Moderator
Hardwire a input 
Is this the only bit/tag you are having this issue with or are there others? it would be strange to have only one bit do this and not others, so I would look at the logic
You could also have an error checking logic, some sort of send and answer... or have the button say (example) "motor is running" then if the bit is low have it say "motor if off", this would be depending on your indicator tag...
Is this the only bit/tag you are having this issue with or are there others? it would be strange to have only one bit do this and not others, so I would look at the logic
You could also have an error checking logic, some sort of send and answer... or have the button say (example) "motor is running" then if the bit is low have it say "motor if off", this would be depending on your indicator tag...
Make sure the "capture cursor" box is checked when creating a button. I ran into this a while back, and it appears what happened is the operator was moving the mouse off of the button after pressing it. The software would see the press, but not the release. If the capture cursor is checked, the mouse stays on the button until released. You can check this for yourself by clicking on a button, and with the mouse button still pressed, move the mouse off the button before releasing the mouse button.
Yep, the capture cursor....Also, you can replicate it by pressing a button and holding it down, then doing something like ALT-TAB to move to a different windows process. The bit will remain high. For that reason, it is often desireable to have the PLC reset the bit in the logic. Once you see the bit in the PLC, use an OTU to reset it back to zero. You can do that in the rung that uses the bit or at the end of the program and reset them all.
Hardwire a input
Is this the only bit/tag you are having this issue with or are there others? it would be strange to have only one bit do this and not others, so I would look at the logic
There are several bits that do this and there is no particular pattern to which one get stuck.
rdrast
Lifetime Supporting Member
I seriously prefer to use normal momentary pushbutton objects in HMI's; that is, one's that don't have a separate 'Press' and 'Release' action programmed in, just for that reason.
I don't know why, but momentary buttons just seem to be more reliable in every HMI I've played with.
In some cases, I'll use a direct SET PB, and let the PLC handle unlatching after it has finished processing, in most cases I just use a flip-flop to toggle an internal bit in the PLC reflecting the state.
I don't know why, but momentary buttons just seem to be more reliable in every HMI I've played with.
In some cases, I'll use a direct SET PB, and let the PLC handle unlatching after it has finished processing, in most cases I just use a flip-flop to toggle an internal bit in the PLC reflecting the state.
OkiePC
Lifetime Supporting Member
Another piece of advice for PC based HMI:
Never use the press action. Only use the release action. This let's the user cancel by dragging focus away from the button before releasing (unless you are using capture cursor).
I would for sure not use both the press action and the release action for operations involving the same tag. I get the idea that it's possible for windows or RSView to get the order of the write operation reversed if you do that and the duration of the press is somewhat short.
I also agree with what RDRast says about using momentary buttons, although I have still seen "stuck button syndrome" occur with them. I often put OTU instructions in the PLC to prevent problems that can be caused by that phenomenon.
You'd think that a good hmi software or driver would continuously read the status of a bit that it was trying to modify until it received confirmation that it had changed states, but apparently most comms drivers are not developed to that degree.
JMHO
Paul
Never use the press action. Only use the release action. This let's the user cancel by dragging focus away from the button before releasing (unless you are using capture cursor).
I would for sure not use both the press action and the release action for operations involving the same tag. I get the idea that it's possible for windows or RSView to get the order of the write operation reversed if you do that and the duration of the press is somewhat short.
I also agree with what RDRast says about using momentary buttons, although I have still seen "stuck button syndrome" occur with them. I often put OTU instructions in the PLC to prevent problems that can be caused by that phenomenon.
You'd think that a good hmi software or driver would continuously read the status of a bit that it was trying to modify until it received confirmation that it had changed states, but apparently most comms drivers are not developed to that degree.
JMHO
Paul
Last edited:
rdrast, okiepc,
The bits that get stuck are not the OTE but the XIC for the stop or start logic that fires the OTE. In the threads the suggestion to fire an OTU if the bit stays on or just do it anyway after the XIC is used in logic seems to be the most logical approach. I’m not sure I understand using a toggle to correct the failure to clear the bit as it works okay most of the time and a toggle would turn it back on when the normal logic would have turned it off. Do you mean to use a toggle rather than have the HMI set the bit back to 0 in all cases?
Regarding the capturing the cursor issue: I tested it with a pushbutton graphic and the bit would fail to be reset when moved off the button before releasing the mouse button if the “capture cursor” box wasn’t checked. However when using a “touch” animation method on an object which is what our screen is doing with the nice graphics that simulate a standard panel green / red push button. Moving the cursor off the object doesn’t cause the logic to fail.
thanks
The bits that get stuck are not the OTE but the XIC for the stop or start logic that fires the OTE. In the threads the suggestion to fire an OTU if the bit stays on or just do it anyway after the XIC is used in logic seems to be the most logical approach. I’m not sure I understand using a toggle to correct the failure to clear the bit as it works okay most of the time and a toggle would turn it back on when the normal logic would have turned it off. Do you mean to use a toggle rather than have the HMI set the bit back to 0 in all cases?
Regarding the capturing the cursor issue: I tested it with a pushbutton graphic and the bit would fail to be reset when moved off the button before releasing the mouse button if the “capture cursor” box wasn’t checked. However when using a “touch” animation method on an object which is what our screen is doing with the nice graphics that simulate a standard panel green / red push button. Moving the cursor off the object doesn’t cause the logic to fail.
thanks
TConnolly
Lifetime Supporting Member
I agree with Paul on not using the press action, only the release action.
I use the momentary button, but even with that I have still seen stuck buttons. If you do a search on the forum you'll see that the topic comes up from time to time. The best way to be sure is to program an OTU in your PLC. This can be a little tricky because the RSView writes are asynchronous to your PLC scan and you may unlatch a bit before all of the logic has a chance to see it. The first time I see the bit from the HMI I set an internal bit. The next scan after, when both the HMI bit and the internal bit are true then I unlatch them both, that way I know that the bit has been seen for a full scan despite the asynchronicity.
If you are doing touch animation I would just let RSView only set the bit and let the PLC clear the bit rather than depending on RSView to do so.
I use the momentary button, but even with that I have still seen stuck buttons. If you do a search on the forum you'll see that the topic comes up from time to time. The best way to be sure is to program an OTU in your PLC. This can be a little tricky because the RSView writes are asynchronous to your PLC scan and you may unlatch a bit before all of the logic has a chance to see it. The first time I see the bit from the HMI I set an internal bit. The next scan after, when both the HMI bit and the internal bit are true then I unlatch them both, that way I know that the bit has been seen for a full scan despite the asynchronicity.
If you are doing touch animation I would just let RSView only set the bit and let the PLC clear the bit rather than depending on RSView to do so.
Last edited:
tomalbright
Member
I use the momentary, or "toggle" bits. Still, you can't depend on the HMI's outputs 100% of the time. The trick with the HMI-PLC setup is you want to make sure your HMI is always in the same state - you set a bit it returns back to zero. On the PLC side, I've done Alaric's trick, setting another bit, then unlatching the input. You really have to treat them as two separate devices.
This way, the PLC and HMI bits are always the same, zero when not needed. If you process all your command logic in one scan, this won't be an issue. Bit gets set, output gets set, input gets unlatched... one scan later all is normal again.
This way, the PLC and HMI bits are always the same, zero when not needed. If you process all your command logic in one scan, this won't be an issue. Bit gets set, output gets set, input gets unlatched... one scan later all is normal again.
rdrast
Lifetime Supporting Member
I agree with this idea, the only software design problem I can foresee would be where you have multiple HMI's potentially controlling the same bit. Having others trying to force it into 'THEIR' state would be a problem. That being said, an option to have a 'verify on rest state', or even firing the rest state write 3 or 4 times in succession would go a long way towards preventing the stuck bit problem.
@frw312 -
It can get complicated, but I buffer most of my HMI buttons through separate internal bits, and very often through flip-flop toggles, built with latch/unlatch instructions. The 'Toggle' bit is used in the logic, and the HMI reads that bit to indicate the actual state of the control in the PLC. That at least gives visual indication that a bit is stuck.
Where it makes sense, I forcibly unlatch either the toggle bit, the HMI Control bit, or both either when the logic is fully scanned, or a timer times out.
I see that this could get complicated, especially to make it bullet proof, but in an industrial environment it needs to be that way (that’s what we get paid to do). Using an unlatch after the PLC sees the bit set will work on some of the logic that is solved on the same scan, but in the cases where the HMI is starting motors we need to see the aux input and that takes more than couple scans to see the fdbk. In those cases it makes sense to use a timer. On new applications it would make sense to build logic in the PLC according to the need of each bit that is set. In this case the app already is in service and we need to fix the bugs. The customer had thought it was originally a problem with a touch screen and suspected it might be comm related. We are now seeing that this is a problem that is inherent to HMI design for the reasons discussed so far. I appreciate the feedback from all on this as it has helped us with insight on others examples and how to best resolve our issues in an effective way. THANKS ALL, frw
On the motor starting issue, you're probably using the 'old school' method of latching in the coil with the motor aux input as that directly correlates with the old method of hard wiring control.
A better way, IMHO, is to latch it in with the coil output itself, and have a separate rung that generates a 'motor didn't start' fault based on the coil output and aux input with timer (as you suggest). The non-presence of this fault would be a condition of the coil output in the first place, so if the fault occurs, then the rung is also unlatched. That way, you stay with the one-scan need for the HMI start bit. I never liked programming something on an HMI that required an operator to hold a button in until something started.
tomalbright
Member
I'm having a shuddering fit... part of our job is to make sure it all works, no matter how long or HOW OFTEN the operator jams the button. There's nothing like an operator who tells you "I pressed it 42 TIMES and nothing happened! FIX THE SCREEN!!!!???!!!"
Sometimes you just have to suck it up a little, lol.
Similar Topics
I have a momentary push button that sticks. I don't know how better to describe it. It is normally open, so when I press it, it changes tag...
Hello fellow wirenuts, I am looking to find the P.B. touch indicator option on version 13.00 and failing. It has been a year or so since I last...
Hello, I have converted RSView 32 to FTView SE 14 (I have tested FTView 12 before as well and there were some difficulties so I moved on to...
Okay, something I have not seen before..
RSView SE. I am working on an existing project. There is a value the customer wants trended and it is...
I have a request to integrate a pause button in RSlogix to be able to start/stop a video. Video format is not defined at the moment, so it could...