mellis
Member
dmargineau,
OK, now I have a clear picture of what you are doing.
XIC STOP BST XIC START ONS XYZ NXB XIC OUTPUT BND XIO FIRST SCAN OTE OUTPUT
Comments
The ONS does nothing useful as far as asynchronous scan of the Panelview is concerned. Asynchronous scan problems are related to mulitple references to the same address in the program. If the program will respond badly if the same address is true in one place and false in another on the same scan, you have an asyncronous scan problem. Putting a oneshot after the address reference does nothing to help this. Buffering the address by copying it to another address at the start of the scan as suggested in the Caution section will help. However, the logic shown has no weakness to asynchronous scan of the STOP and START bits so this really isn't relevant.
If your block transfers are triggering so slowly that you can "miss" a pushbutton, that's a different problem. If that is the case and you increased the pushbutton "down" time on the panelview so that you don't miss a press, now the ONS on the Start serves a purpose. It allows you to Stop even if the Start is still on. I've seen this configuration several times.
The First Scan XIO also only does anything useful if the Start bit is stuck on for the first scan. Since the Output OTE is always turned off by the prescan, the only way the rung can be on for the first scan is if the Start bit is on.
Here is my preferred way to do this:
XIO STOP BST XIC START NXB XIC OUTPUT BND BST OTE OUTPUT NXB OTU STOP NXB OTU START BND
Both pushbuttons in the Panelview are NO momentary. NC pushbuttons make a difference when wired, but over a network it doesn't matter.
The basic idea here is that the Panelview doesn't have to "turn off" pushbuttons at all, the PLC does it right after they are responded to. You can leave the pushbutton delays long if you need to without any overlap problems. And, you will never have a pushbutton "stuck on" no matter what happens to the Panelview or the network it is communicating over. And I definitely have seen Panelview pushbutton bits (and other HMIs) get stuck on. Wonderware seems to be especially vunerable to this.
An alternative to the OTU instructions (if they just drive you crazy) is to simply clear the entire input space from the Panelview at the end of the scan. FFL can be handy for this. That has slightly more potential to "miss" a button press, but in practice it is not that much of a problem.
One last thing, I am NOT picking on you. Your comment caught my attention and I wanted to understand what you were saying. If I have misunderstood you at all, please clarify. I'm always open to new ways of doing things and I hope the discussion proves useful to someone.
OK, now I have a clear picture of what you are doing.
XIC STOP BST XIC START ONS XYZ NXB XIC OUTPUT BND XIO FIRST SCAN OTE OUTPUT
Comments
The ONS does nothing useful as far as asynchronous scan of the Panelview is concerned. Asynchronous scan problems are related to mulitple references to the same address in the program. If the program will respond badly if the same address is true in one place and false in another on the same scan, you have an asyncronous scan problem. Putting a oneshot after the address reference does nothing to help this. Buffering the address by copying it to another address at the start of the scan as suggested in the Caution section will help. However, the logic shown has no weakness to asynchronous scan of the STOP and START bits so this really isn't relevant.
If your block transfers are triggering so slowly that you can "miss" a pushbutton, that's a different problem. If that is the case and you increased the pushbutton "down" time on the panelview so that you don't miss a press, now the ONS on the Start serves a purpose. It allows you to Stop even if the Start is still on. I've seen this configuration several times.
The First Scan XIO also only does anything useful if the Start bit is stuck on for the first scan. Since the Output OTE is always turned off by the prescan, the only way the rung can be on for the first scan is if the Start bit is on.
Here is my preferred way to do this:
XIO STOP BST XIC START NXB XIC OUTPUT BND BST OTE OUTPUT NXB OTU STOP NXB OTU START BND
Both pushbuttons in the Panelview are NO momentary. NC pushbuttons make a difference when wired, but over a network it doesn't matter.
The basic idea here is that the Panelview doesn't have to "turn off" pushbuttons at all, the PLC does it right after they are responded to. You can leave the pushbutton delays long if you need to without any overlap problems. And, you will never have a pushbutton "stuck on" no matter what happens to the Panelview or the network it is communicating over. And I definitely have seen Panelview pushbutton bits (and other HMIs) get stuck on. Wonderware seems to be especially vunerable to this.
An alternative to the OTU instructions (if they just drive you crazy) is to simply clear the entire input space from the Panelview at the end of the scan. FFL can be handy for this. That has slightly more potential to "miss" a button press, but in practice it is not that much of a problem.
One last thing, I am NOT picking on you. Your comment caught my attention and I wanted to understand what you were saying. If I have misunderstood you at all, please clarify. I'm always open to new ways of doing things and I hope the discussion proves useful to someone.
...Every now and then maybe we should challenge the way we've been doing "things" just because that's the way it's been done since the beggining of time (PLC2/3/5 era)...
