outputs turn on at power-up

[travish 0]

I have a ML1500 LRP (1764-28BXB) Processor with Panelview 600 (2711-K6C16) Operator interface. Panel has 2 control relays. CR1 is energized when a 3 pos SS is turned from Off (pos 1) to On (pos 2 maint). CR1 sends Input control power (24vdc and 120vac) to power up the plc and the touchscreen and power to inputs and voltage to the top of CR2. CR2 is energized and latches itself when the operator turns the SS to Enable (pos 3 spring return) If all E-stops are ok. CR2 sends 24 vdc and 120 vac to all outputs. Here is the problem. On start up of the Hydraulic system 60 hp (start button is on touchscreen) the main breaker will occasionally trip. When breaker is reset selector switch is in "On" pos CR1 energizes immediatly. If while the touchscreen is still going thru it's startup diagnosis routine some one turns the SS to "enable" Pos 3 CR2 will energize and the hydraulic system will sometimes start even though the start button was not pressed (screen is still in power up). If i delay turning the SS to enable untill after the screen finishes power-up the hydraulics do not come on ever. It is like the logic is in the last state when the breaker tripped. It does not do this regular enought that I can watch it and see Anyone seen this before? Thanks Travis Rolling_Machine.RSS

[b_carlton 61]

Create a rung at the start of the program XIC S:1/15 OTU B12:0/4 This will turn off the bit which the display turned on but didn't have the chance to turn off.

[OkiePC 14]

Bernie gave you a good fix for your problem. If you are frequently interrupting power to a Panelview +, and you don't want to wait 90 to 160 seconds for it to boot, then buy a Red Lion G3. it will power up and be running in about 7 seconds. You still could have the same problem (just less time to realize it), so Bernie's fix should still be implemented, but machine uptime would increase by about 1 minute per power cycle event. Depending on your process, that could add up to pay for it$elf. Another option is to keep power applied to the PV+ (and the PLC for that matter). They will last longer if they are not power cycled. Unless there are some severe restrictions that would prevent keeping them "alive and ready", I recommend doing this. I, personally, like to keep input devices powered even when there's a safety fault. This makes troubleshooting and programming simpler too. As long as you are breaking power to the outputs and any other control devices in the system it *should* be acceptable to keep the PLC and HMI powered. I say *should*, because I don't know your system and it certainly is possible that I am completely wrong and you must kill power to the HMI and PLC, but if you don't have to, then don't. Paul

[paulengr 44]

You need to change your programming style to avoid this and future issues. The same thing can happen if for instance you have a communication glitch. With hard wired push buttons, the physical button has a "state". Either the contacts are closed or they aren't. And the spring inside makes it always return back to an expected state or you can somehow reach that "zero" state by killing power to the button. Communication devices including PC's, operator interface panels (Panelviews), and even other PLC's don't work like that at all. When a change of state or some sort of command happens, they issue a packet signalling the change. If something happens to that packet along the way, the message is lost. If you are relying on a signal indicating a change of state such as "button pressed" and "button not pressed", then you are setting yourself up for trouble because any time that power or communication issues interfere with the communication, you will NEVER receive that second message. There are effectively just 3 ways to deal with this dilema. First, you can simply code your logic to only respond to one message and not two. For instance, I usually code my button logic with a second rung that says "if the button has been pressed, then unlatch it". Then I program the button on the Panelview to send a "button pressed" (latch) signal but no unlatch. This totally eliminates the problem. I don't want or need the "button not pressed" message that caused the problem in the first place. The second method is a watchdog timer. Set up some mechanism to constantly verify that you have good, working communication. If you lose communication for any reason, then set everything into a "safe" state. This has the advantage that if the Panelview loses communication, then everything safely shuts down. But even small glitches that destroy a single packet STILL can cause the "stuck button" type problem (unless you add an additional timeout delay for this, too), AND it makes your system much more susceptible to even momentary communication problems. The third method is to code extra "timeout" and "startup" routines to always force a safe state even in the event of a communication glitch. It doesn't eliminate the problem...it merely masks it. I prefer the first method. It is a completely different programming style and does not work at all with hard wired buttons but it deals specifically with the design and limitations of operator interface panels. It can't be used in all cases but it does work for 99% of them. The other methods have the disadvantage that you have to have a lot of extra fault logic and carefully check your program for various glitches.

[travish 0]

Bernie, I understant your logic just fine, Thanks I can see how that would work, unless the panelview is holding the contact closed for the power up time. in which case after the first scan the plc would still start the hydraulics on the second scan. Okie, I am tripping the main CB to the machine, therefore I am losing all power Paul, Look at the way I did the "manual/auto latch" Rung 6,7 & 8 is that what you are talking about in option #1. If I press the auto/man button once it goes into auto mode, if I press the same button a second time it goes into manual mode. At power up the button should not be pressed so by default the plc has the machine in manual mode at power up. By breaker tripping problem is caused by a 60 HP motor on a 100a breaker. The panel that the breaker is in will not accept a larger breaker than this. But my logic problem has me really concerned that some thing can start up at powerup by itself. I have never seen this before, maybe because never had problems with breakers before. Travis

[b_carlton 61]

Let's review what is happening. In a normal HMI momentary button press the HMI sees that the operator has touched the button on the screen. It then sends a 'turn on the target bit' communication to the PLC. At some time later the HMI sees that the button has been released. It now sends a 'turn off the target bit' communication to the PLC. Between the 'turn on' and the 'turn off' of the bit it stays on simply because nothing is turning it off. The HMI is not actively holding it on. And, unless there is some controlling logic which has that bit as an output (hint about what I suggested to add), it will not turn off by itself. In this particular case the operator presses the 'start' button. The HMI sends the 'tun on' communication to the PLC. The PLC attempts to turn on the 60 HP motor. But something goes wrong. In tripping the system removes power from the HMI and the PLC. (Another good reason to provide continual power to the HMI and PLC. Just cut off power to motion output devices.) The operator still had their finger on the button. There was no chance for the HMI to turn off the bit inside the PLC. When power is restored the PLC scan sees that the bit from the HMI is on and behaves as instructed. This is why, with your power setup, we place the unlatch of the bit on the first scan.