11/10/2014 9:55 AM | |
Joined: 9/23/2005 Last visit: 9/19/2024 Posts: 4347 Rating: (1446)
|
Hi, maybe there is something wrong in your OB40 (parameters of FC90 call?) that leaves to OB1 delay your execution. This trigger the sistem watchdog and leaves the CPU to STOP. 1 - Suggestion: perform a investigation about what causes this delay. Is it a project fault, a system fault, etc. If there something wrong, correct it. 2 - Once nothing wrong, I suggest you check the watchdog time, if it is match with your application. 3 - Check if placing a OB80 you can get addtional information / by pass the event. |
Denilson Pegaia |
|
11/10/2014 10:47 AM | |
Joined: 11/6/2014 Last visit: 12/13/2022 Posts: 5 Rating: (1) |
Hi, Thanks for taking time to reply.
There are no parameters passed to FC90 from OB40, just a static call of the FC. Perhaps not the best way, but does acheive the desired result. .
The error is trying to tell me it is a project fault, but the area it points to is not being executed. I will try & upload diagnostics buffer tomorrow. .
Maximum limit is 150ms, max observed is 14ms. I changed to 500ms & it still occured. .
I have placed OB80, but not all the captures as examples. Will see if I get a chance to do so. |
11/10/2014 5:48 PM | |
Joined: 7/7/2010 Last visit: 9/20/2024 Posts: 15213 Rating: (2417)
|
If you have a time interruptOB running, increase the interrupt call time by at least 2 times its current value. If you are calling a time interrupt OB more often than 3 ms and do anything other than very simple math, you may cause a crash. If you are communicating with direct I/O addresses using the :P addressing method, unless necessary for your process, try not doing that -- to at least determine if that is causing the process to take too long. If your PLC is not running firmware 2.2, please upgrade to that version of the firmware. If you have V10.5, verify it is running the latest service pack, update, and hardware support packs. Consider upgrading to V11. If you are using anything other than standard cyclic OBs, do not call them very often, or do very little work in them. The PLC cannot tolerate much extra work outside the standard PLC scan without causing it to start queuing up interrupt calls until it crashes on watchdog fault like you are seeing. In your FC90, are you using a peek or poke or indirectly addressing in any way? Is it possible you are accessing a remote device before it is ready, which could cause it to retry too many times until it faults on watchdog? |
science guy |
|
11/10/2014 6:22 PM | |
Joined: 11/6/2014 Last visit: 12/13/2022 Posts: 5 Rating: (1) |
Hi, A hardware interrupt is triggered, approximately every 45-50ms. There are quite a few rungs in the routine (~19), with a combination of array indexing & some math, as well as motion instructions. Not all rungs are being scanned though, it is mode dependant. Firmware is V4 with Portal V13 update 5. What does not make sense, is that it is intermittent when it happens, & the max captured cycle time is ~14 ms when running. If it were an issue with the program code, then it would be regular. Unless of course, the bit that blocks the code being executed is coming on. My suspicition is the interrupt buffer is getting full ( or something like that). There do not appear to be any functional issues with the machine operation or performance either. |
11/10/2014 6:57 PM | |
Joined: 7/7/2010 Last visit: 9/20/2024 Posts: 15213 Rating: (2417)
|
There are quite a few rungs in the routine (~19), with a combination of array indexing & some math, as well as motion instructions. Not all rungs are being scanned though, it is mode dependant. Firmware is V4 with Portal V13 update 5. What does not make sense, is that it is intermittent when it happens, & the max captured cycle time is ~14 ms when running. If it were an issue with the program code, then it would be regular. Unless of course, the bit that blocks the code being executed is coming on. My suspicition is the interrupt buffer is getting full ( or something like that). There do not appear to be any functional issues with the machine operation or performance either. Since you are running with average scan time around 14 ms, instead of running your motion control and indexing and such in the hardware interrupt, instead, trigger an action to run in the normal PLC scan. If the performance is sufficient, you are done. If not, you can insert more and more logic into the interrupt routine, provided it takes way less than 14 ms to run. With the latest firmware and portal version, that is a big step in the right direction! I was going off of the original post. As to the indexing, mathand motion instructions, those are where I'd look for optimizing. Figure out what you _must_ put in the hardware interrupt OB and what you can put in a regular OB or FB/FC called from a cyclic OB, enabled by the hardware interrupt. If / when you resolve, please post your results. As to the diag buffer overrun, yes, I agree. Anytime you have an interrupt taking a long time to do things before you let it go, you run the risk of another hardware event triggering the very same hardware interrupt OB while it is still running. Maybe it is a debounce issue or an intermittent noisy limit switch. |
science guy |
|
11/10/2014 7:22 PM | |
Joined: 11/6/2014 Last visit: 12/13/2022 Posts: 5 Rating: (1) |
Since you are running with average scan time around 14 ms, instead of running your motion control and indexing and such in the hardware interrupt, instead, trigger an action to run in the normal PLC scan. If the performance is sufficient, you are done. If not, you can insert more and more logic into the interrupt routine, provided it takes way less than 14 ms to run. With the latest firmware and portal version, that is a big step in the right direction! I was going off of the original post. As to the indexing, mathand motion instructions, those are where I'd look for optimizing. Figure out what you _must_ put in the hardware interrupt OB and what you can put in a regular OB or FB/FC called from a cyclic OB, enabled by the hardware interrupt. If / when you resolve, please post your results. As to the diag buffer overrun, yes, I agree. Anytime you have an interrupt taking a long time to do things before you let it go, you run the risk of another hardware event triggering the very same hardware interrupt OB while it is still running. Maybe it is a debounce issue or an intermittent noisy limit switch. Having the code in a normal task is a very valid comment. I will double check those times to be sure & experiment with that. We do have tight margins,hence the interrupt. I actually did suspect the input switch, the filter was at its minimum, I think I need to increase it again. |
11/10/2014 10:37 PM | |
Joined: 7/7/2010 Last visit: 9/20/2024 Posts: 15213 Rating: (2417)
|
If your hardware limit switch is causing problems, you might consider a high hysteresis limit switch meant for motion control type applications such as you seem to have. In this way, it goes from off to on and has to move quite a bit before going back to off. These are usually 3 or 4 times more expensive than standard limit switches, but often have crash protection, are very robust, and may even have redundant channel options for safety related functions. I mention that for future projects and for the long term success at your customers facilities. |
Last edited by: huggy_d1 at: 11/10/2014 10:39 PMLast edited by: huggy_d1 at: 11/10/2014 10:39 PMscience guy |
|
11/10/2014 10:46 PM | |
Joined: 11/6/2014 Last visit: 12/13/2022 Posts: 5 Rating: (1) |
We are using inductive proximity switchs, same as on other machines with AB PLC's with no problem. Not ruling out a better type, but the likelihood of debounce on this is quite slim..
|