HMI message trigger from Prox sensor

[JZerb]

so im not sure if what i have come up with is the proper way to accomplish what im looking to do so hopefully someone here can straighten me out.

attached screenshot.

what im trying to do, using a ML1400 and a Panelview 800, is use a prox switch to trigger a screen to display on a panelview. so, the machine comes down and stops at the I:0/4 XIO, which is a NC prox sensor, and when that happens i want to move 10 (the screen number on the Panelview that i want to display) into the N7 register that will control what screen is displayed on the Panelview. Once that screen is displayed i need to move 0 into that same N7 register so that the screen control gets turned back over to the HMI so a button can be pressed to acknowledge the message on screen.

problem is, if i dont use the Latch and Unlatch setup i posted, once the acknowledge button is hit on the HMI, since the machine is stopped and still on the sensor, it just pops the message up again. i havent been able to figure out a way only have this action happen once when the sensor is made, unless what i have written is the way it should be done, but i have my doubts.

 

[Crammed77]

Well Ok, I will have a quick bite.

It is very rare for me to have the PLC control the Panelview screen switching. Infact, I have only done this once for a very old application that I had to convert from a Cutler Hammer display. The PLC already had all of the base logic to switch screens for various methods of controls and it was easier to suit the Panelview project to the PLC.

I will always make use of the screen status word back into the PLC so that the PLC knows what screen the Panelview is on. This can be used for all sorts of different functions.

If I need to show the status of anything I will use simple multi-state indicators, panels, text boxes, and shapes with animations, and that sort of thing. If these are to be shown on various screens, simply copy them across. I will often also make use of the alarm functionality, especially if it is a bigger project.

All of my messaging and indication is controlled, latched, and reset within the PLC. This way you can use one-shots or whatever you want to control how the status of the machine is displayed.

I will also separate as much as I can any of my machine logic and Panelview logic within the code so that it is all logically laid out as best as I can. I do this simply by using separate tasks, ladders, or routines as well as separate data words / arrays for all of my bools and dints to buffer the data through.

 

[ASF]

Just put a oneshot on your popup trigger

 

[jrsnydley]

+1 asf

 

[JZerb]

so i had it setup with a one shot to trigger the message originally and this was my issue.

if the machine was on the sensor, and you were to turn the machine off and then back on you get stuck on the message screen that popped up when the machine powers back up and then once you hit acknowledge on the screen it quickly takes you to the screen that its supposed to but then pops the message back up on screen, almost like it gets stuck in a loop. once you hit the manual Reset button and the machine is out of an alarm state, everything works as it should.

again i dont assume this would ever happen out in the wild, but we try and test here for each and every possible scenario that could ever happen, pressing many buttons at once, shutting power down during a sequence, etc etc.

 

[cwal61]

If I understand the logic you posted then you latch B3:6/0 bit when machine leaves the proximity switch. Once the machine returns to the proximity switch you unlatch the bit and open the screen. Once the screen is open then move 0 to open screen command.
That looks fine to me. If I understand correctly.

The Problem? Machine off
This causes the screen to open on power up because you lost your input and regained it when power is returned to the machine. The same logic as normal operation.

My suggestion would be to monitor your MCR input with a time delay to allow inputs to return to their true state at start up. A power on delay bit would allow the change of state of your inputs to not effect the HMI screen open logic.

You could insert XIC MCR timer done bit in rungs 1 and 2.

 

[JZerb]

If I understand the logic you posted then you latch B3:6/0 bit when machine leaves the proximity switch. Once the machine returns to the proximity switch you unlatch the bit and open the screen. Once the screen is open then move 0 to open screen command.
That looks fine to me. If I understand correctly.

The Problem? Machine off
This causes the screen to open on power up because you lost your input and regained it when power is returned to the machine. The same logic as normal operation.

My suggestion would be to monitor your MCR input with a time delay to allow inputs to return to their true state at start up. A power on delay bit would allow the change of state of your inputs to not effect the HMI screen open logic.

You could insert XIC MCR timer done bit in rungs 1 and 2.

i changed the logic so it was done without the latching/unlatching scenario and just went back to what i had originally, but didnt post a screencap of, with the ONS after the XIC attached to the sensor. the issue i was having was on power up, which you touched on above with the MCR input (something ive never had to deal with in the past so i will have to read up more about that). i do have a control power delay timer in the main rung of the program that just prevents power to the drives coming back up too quick if they loose power, so i ended up just using that in Rung 1 of the logic and all seems to be working well.

im assuming that whats happening when the PLC and the sensors receive power they briefly send a signal, some sort of power up self test, and thats what was messing me up before i put the timer DN XIC in the logic.

 

[ASF]

My suggestion would have been to preface the sensor with a "not first scan" bit, but your control power delay does the same thing. Many ways to skin the cat, as they say.

One word of caution - I've always found the approach you've taken there to reset your screen control to zero, to be flaky. I had one instance where the called screen was a popup with an "OK" button that closed the popup - if the operator was too quick to press the "OK" button, the "current screen" global connection never reported that the screen had opened to the PLC. So all of a sudden, the called screen has been closed, but the screen control won't let you call any others, so you were stuck until you cycled the power to the PLC and the HMI.

I tend to put a "if current screen equals called screen, reset all screen calls" condition in, but then also add an unconditional 5-second timeout. If any screen is being called by the PLC for more than 5 seconds, block all screen calls until you see a value change on the HMI "current screen" global connection again.

 

[JZerb]

My suggestion would have been to preface the sensor with a "not first scan" bit, but your control power delay does the same thing. Many ways to skin the cat, as they say.

One word of caution - I've always found the approach you've taken there to reset your screen control to zero, to be flaky. I had one instance where the called screen was a popup with an "OK" button that closed the popup - if the operator was too quick to press the "OK" button, the "current screen" global connection never reported that the screen had opened to the PLC. So all of a sudden, the called screen has been closed, but the screen control won't let you call any others, so you were stuck until you cycled the power to the PLC and the HMI.

I tend to put a "if current screen equals called screen, reset all screen calls" condition in, but then also add an unconditional 5-second timeout. If any screen is being called by the PLC for more than 5 seconds, block all screen calls until you see a value change on the HMI "current screen" global connection again.

so i attempted to find a 'not first scan bit', but i couldnt. i guess i could have used an XIO with S1:15 and that could have worked (?)

 

[ASF]

Yes, that's what I meant