Thank You Panic
Its definitely been one of those " pull out my hair " issues.
Still confused as to why intermittently my $IN is triggering the Interrupt to run to begin with.
Program 32 not available comes up on the KRC4 Pendent
-
DougCoffman -
May 23, 2016 at 7:44 PM -
Thread is marked as Resolved.
-
-
I do not believe its the interrupt causing the problem and being triggered.
Your original screenshot clearly says that robot read PGNO value 32 and because there was no CASE for it that is the reason it fails (jumps to DEFAULT case and display exact error message your screenshot shows)
Interrupt has nothing to do with it.If you want to confirm that interrupt is triggered you can add debug message to the code:
Codemsgnotify("Interrupt 10 triggered") ;FOLD WAIT Time=0 sec;%{PE}%R 8.3.34,%MKUKATPBASIS,%CWAIT,%VWAIT,%P 3:0 WAIT SEC 0 ;ENDFOLD RESUME
I believe something in your code is modyfing PGNO variables in a way it gets a wrong number.
Archive may help. -
THANK YOU KR16
I will put that MSG code in my Interrupt program and see if I can track whats actually happening -
kr16
The only thing that bothers me is I only have one place in the PLC that handles the Binary setting for the CASE #, and with the PGNO_LENGTH = 5 that makes a max possible of 31 being the highest possible program call..
One step at a time.
First I am putting the MSG display in so I can track the Interrupt condition and time of being executed.
Second I have changed the location of the RESUME in the Interrupt Program.
So we will see what happens with these two changes. -
I do not believe its the interrupt causing the problem and being triggered.that is easy to test - remove interrupt and see if you get same problem...
Your original screenshot clearly says that robot read PGNO value 32 and because there was no CASE for it that is the reason it fails (jumps to DEFAULT case and display exact error message your screenshot shows)that is a true. the issue is that PGNO receives value that is not corresponding to 5 bits sent from PLC (in fact with only 5 bits, BCI representation only may have values 0-31).
the only thing that can corrupt PGNO value are:
- wring AutoExternal configuration
- user code manipulating PGNO
- corrupt P00.SRC
- P00 gets interrupted during computationfirst three are seem to be already checked. last one i have seen before and - interrupt was the issue (used just like shown here).
-
Panic / kr16
At this point I just want it fixed... LOL..
I have changed the Interrupt program. And also put a MSG display in the Interrupt Program also, So if it is an Interrupt 10 being issued then at least I will know thats whats causing it. I will keep you guys posted on what the results are. its been running for about 30 mins and it normally will run between 4 to 4:30 hours before stopping so if it runs throughout the day then we are good and it was the Interrupt, if not then its back to search and find thanks for all the input and advise also gents.. -