Control Logix Guru's need your Insight

Ok first off, i have uploaded the PLC program in a zip file, plc is a control logix. The issue i'am having is in a routine called (rtn_Pumps) i have a mode selector for a pump based on push buttons. The modes are PB_Run, PB_Standby, and PB_Off which if you see in the logic are the bits that you can use to go from one mode to another. However on Rungs 1,2,3 within that routine im using PB_Run_HMI, PB_Standby_HMI, and PB_Off_HMI, these three are coming from a momentary pushbutton from the hmi application running RSview SE that write directly to there corresponding PB_Run, PB_Standby, PB_Off tags. i also put a Always_Off branch on rung 4 in the pumps routine so i can easily for testing change between modes

Ok now that i got that out the way, i have tried numerous thing to fix this issue but, still the problem is not going away.
when i say press a pushbutton on the HMI their are times when the PLC doesn't see the pulse and never actually initiates, to further elaborate, say i'm in standby mode, if i wanted to go to Off mode i sometimes have to press the Pushbutton twice for the pulse to be seen by the plc, what i think is happening is say you press a standby push button, depending on where it is in the scan, the plc might might miss putting it into that state because of the asynchronous scan sequence of the control logix plc.

Even though it works most of the time, it still bothers me a lot that this is happening. If anyone can see the program and maybe tell me something i may have missed please let me know.

Without reviewing the program, I can offer a patch solution for your problem. Change the HMI pushbuttons from "momentary" to "set", then unlatch the three pushbutton bits unconditionally at the end of the rtn_Pumps subroutine. This is how we had to emulate momentary pushbuttons back in the day when HMIs didn't offer the "momentary" option for pushbutton objects.

I even tested this with a counter such that the counter would count every time it say the pulse for a mode transition, so when i tested it, their where times when the plc didn't even see the pulse, and if the PLC doesn't see the PLC then that's the most obvious issue, which leads me to believe its an HMI settings issue, i played around with the display settings tag update rate which is currently set for 0.05 secs, and the actual push buttons hold time, which i set to 50ms from 250ms, still that did not resolve the issue

One thing you can try is to increase the "Hold Time" of the momentary pushbuttons on RSView.

By default this is set to 250ms, try 500ms or higher until the issue ceases.

Otherwise make them maintained pushbuttons, then use PLC code to unlatch them when the correct state has been triggered.

Edit: I wouldn't leave the tag display update rate set to 0.05s. That will slam the network. There shouldn't be an issue with the default 1s, and I can't really see a benefit to going below half a second.

dbh6 said:

when i say press a pushbutton on the HMI their are times when the PLC doesn't see the pulse and never actually initiates, to further elaborate, say i'm in standby mode, if i wanted to go to Off mode i sometimes have to press the Pushbutton twice for the pulse to be seen

Click to expand...

Maybe your touch cells on the HMI are going bad?

I haven't played with RSView SE - Just RSView studio for Panelviews....but with a panelview you can set the "hold time" for a momentary pushbutton to always hold the bit true for a minimum duration.

Otherwise, it sounds like a communication issue.

Ok let me clarify even more, it is not a touch panel, the rs view SE is a project which i created from scratch, and is running on my computer

@ bit bucket 07, i tried what you insisted, and although it works when i tested it, it even more frequently misses now

@ Berdan, i tried the hold time at different ms set points and still the issue is still there.

dbh6 said:

@ bit bucket 07, i tried what you insisted, and although it works when i tested it, it even more frequently misses now

Click to expand...

Okay, then let's assume that you are truly having a bit status change occur midway through solving your pump subroutine. In that case, I would do as brendan recommended and only unlatch each maintained pushbutton bit when the bit is on and the associated mode selection has been accomplished.

It seems that you were only making your problem worse by decreasing the dwell time for momentary pushbutton bits, rather than increasing it. As for decreasing the tag update rate, that should only affect scheduled reads and increasing the update frequency by setting the time to 0.05s will only aggravate the problem by forcing redundant read messages and overloading your comm port.

Wait. I just had a look at the PLC code.

Why are you unlatching the PB's from the HMI in rungs 1, 2 and 3, before the mode bits have a chance to trigger the correct sequence in rungs 4, 5 and 6?

I would remove the OTU's completely for now - this seems to be your issue.

If you want to have the OTU's in there to prevent these PB_HMI bits having a chance of being stuck on, then they need some more conditional logic before them so that the correct mode has a chance to trigger before the OTU.

What does the CLX-to-PC(topology communication path and hardware) look like?
A brief description ( CPU/Backplane/1756-ENBT........LAN/NIC)would suffice.
Also, what revision RSLinx and type of driver are you using?

At the very least, the unlatches need to occur after the mode selections, if not at the very end of the subroutine.

You don't really need to unlatch the bits at all if your momentary pushbuttons are working as they should.

@ brendan the reason why i have them is i wanted the HMI momentary push button to have one tag, then write to the actual mode control pushbutton tags in the PLC that way i will surely know that their is no way the mode would change unless the pulse had changed from the PLC. As for the unlatching on rungs 1, 2, & 3 the signal to control the modes will already be sent by the time it comes back to the next scan and turns of the signal bits, i think its the same as having your unlatch bits after the pump logic

I also modified the program where the momentary PB's write to a tag to the PLC, and after executing the pump logic, unlatch all the PB's either way i tried still same issue

@ bit bucket 07, let me try without unlatching it in the code and if that doesn't work, putting the unlatch bits at the end of the routine. Be right back

@dmarginue the plc (1756 ENBT) is communcating to the PC via rslinx enterprise, the firmware for the CPU is V.20, and rslinx version is 2.59, the PC that the HMI does not have rslinx but online rslinx enterprise, and you setup the communication to point to the PLC by going through the ethernet driver and pointing to the CPU.

The problem with your logic, is that the OTU is unlatching the PB_Run_HMI bit, which in turn makes the PB_Run bit FALSE before the PB_Run bit has a chance to start the "Run Mode" in rung 4.