Last I remember the start number for PGNO is the lowest bit for PGNO. That is, in your case, if PGNO=IN[33..40] that IN[33]=1 and all others 0 means PGNO=1.
Thanks for the clarification. Any idea why I get the message "Wait for not input 33"? Should I pulse the PGNO i.e. make IN[33] go HIGH and then LOW?
each PGNO type has its own peculiarities.
the idea is to specify program number and once it is accepted by the robot - reset the PGNO to zero
IF ($MODE_OP==#EX) AND ($OUT[1021]==TRUE) THEN ;$OUT[1021] is PERI_RDY CWRITE($CMD,STAT,MODE,"RUN /R1/CELL()")
ENDIF
That's not good coding. As written, the SPS will keep re-firing the CWRITE dozens of times per second. You need to add a check of $PRO_STATE1 to that IF statement.
That's not good coding. As written, the SPS will keep re-firing the CWRITE dozens of times per second. You need to add a check of $PRO_STATE1 to that IF statement.
Thanks. If I used $PRO_ACT==FALSE, would it effectively do the same thing?
Thanks. If I used $PRO_ACT==FALSE, would it effectively do the same thing?
It should, IIRC. $PRO_ACT should only apply to the Level 1 interpreter. $PRO_ACT should be the same as using ($PRO_STATE1==#P_ACTIVE) or ($PROG_INFO[1].PRO_STATE==#P_ACTIVE).
Thanks. If I used $PRO_ACT==FALSE, would it effectively do the same thing?
Actually NO.
$PRO_ACT is expecting an Input and not TRUE or FALSE
That is why you have
$IN[1025]=TRUE
$IN[1026]=FALSE
So the code works now. I am able to select and run CELL.SRC in EXT mode and I send it a program number and it runs the motion program. However, just before I send the program number, I get "Incorrect program number". But I checked P00.SRC and there is no such message in the code. And I can clear the error in EXT mode, and then my program number is accepted and starts running.
Each time after my program is finished and control goes back to CELL, I get this message "Incorrect program number".
your handshaking is not correct. it does not meet expected sequence or timing. normally one gets this message because PGNO_VALID is turned on at the wrong time. don't recall behavior when using PGNO type 3, may not be needed.
A thought: I'm using PGNO_TYPE 3, which means it allows program numbers 1 to 8. Should I have 8 cases in CELL.SRC even though I'm not using all of them, and I'm only sending program number 1 all the time?
that depends on number of bits used for PGNO. it is true if 8 bits are used but one can configure different size for PGNO. you do not have to have all cases as long as they do not get called. even then you should just get message that program number was not valid.
The message shows sender as P00. But I studied P00.src carefully and did not find where this message is being generated.
P00 generates messages but the actual text of the message is not there, it is in KXR file. P00 triggers message display using key. actual text is derived from the key based on HMI language. here is a look into one such file:
your handshaking is not correct. it does not meet expected sequence or timing. normally one gets this message because PGNO_VALID is turned on at the wrong time. don't recall behavior when using PGNO type 3, may not be needed.
The SI manual says for PGNO_TYPE 3, none of these are evaluated: PGNO_VALID, PGNO_REQ, PGNO_PARITY.
Actually NO.
$PRO_ACT is expecting an Input and not TRUE or FALSE
That is why you have
$IN[1025]=TRUE
$IN[1026]=FALSE
$PRO_ACT is an output, though:
Each time after my program is finished and control goes back to CELL, I get this message "Incorrect program number". But each time, I can clear it and then have my motion program run.
The message shows sender as P00. But I studied P00.src carefully and did not find where this message is being generated.
From P00:
IF PGNO_ERROR==0 THEN
IF (PGNO_TYPE==3) THEN
P00_MSG (15)
.
.
.
CASE 15
$MSG_T.KEY[]="ProgNumberWrong"I'm pretty sure this is it. If CELL.SRC reaches the DEFAULT switch case, it calls P00 with #PGNO_FAULT, which leads into this code.
This should only happen if your signalling is incorrect. For example, if you send PGNO_VALID when all 8 of your PGNO bits are 0. Or, given you're using PGNO_TYPE 3, if you had more than one PGNO bit True at the moment PGNO_VALID went True.
A thought: I'm using PGNO_TYPE 3, which means it allows program numbers 1 to 8. Should I have 8 cases in CELL.SRC even though I'm not using all of them, and I'm only sending program number 1 all the time?
No. You should only have a CASE for each program to be called from CELL. If you only have 2 programs you call from CELL, you would have CASE 1 and CASE2, and DEFAULT. If you somehow sent a PGNO that wasn't either 1 or 2 (or, in your case, the first or second PGNO bit), the DEFAULT case of the SWITCH statement will execute and throw the error shown above.
@SkyeFire answer post #30
shame on me
Happens to all of us. I know I've had to be corrected by you, Fubini, or Panic Mode often enough. 
to err is human. to not err is ... inhuman? 
From P00:
Code IF PGNO_ERROR==0 THEN IF (PGNO_TYPE==3) THEN P00_MSG (15) . . . CASE 15 $MSG_T.KEY[]="ProgNumberWrong"
Can't find this code in my P00 (see attached).
There's this in my P00:
IF PGNO_ERROR==0 THEN
IF (PGNO_TYPE==3) THEN
MsgQuit("ProgNumberWrong", "P00")
ELSE
MsgQuit("ProgramNotAvailable", "P00", PGNO)
ENDIF
ENDIFThis should only happen if your signalling is incorrect. For example, if you send PGNO_VALID when all 8 of your PGNO bits are 0. Or, given you're using PGNO_TYPE 3, if you had more than one PGNO bit True at the moment PGNO_VALID went True.
As I mentioned in post #29 PGNO_VALID is invalid (pun intended 
) for PGNO_TYPE 3. This is also clear from P00 code.
It's surprising that not many people have experience using PGNO_TYPE 3, even though it is the simplest and easiest.
If CELL.SRC reaches the DEFAULT switch case, it calls P00 with #PGNO_FAULT, which leads into this code.
This should only happen if your signalling is incorrect.
My signaling should be correct for PGNO_TYPE 3, otherwise I shouldn't be able to run my motion program, right? But I can run my motion program! It's just that this niggling message "Incorrect program number" pops up, which I can clear too, and resend my program number and repeat. But I'd rather not have this message pop up.
The LOOP..ENDLOOP of switch..case in CELL keeps running even when I haven't sent it a program number, and so the switch selects the default case. Could this be the issue? Because, after I send it a program number and then clear the message, it starts running.
@SkyeFire answer post #30
shame on me
i'm surprised panic mode didn't tear you apart on your huge mistake. Us mere mortals have suffered multiple deaths at his hands for much smaller errors LOL... all you get is a really soft "to err is human"... NOT FAIR! LOL
Can't find this code in my P00 (see attached).
Hm. Could be a version difference.
It's surprising that not many people have experience using PGNO_TYPE 3, even though it is the simplest and easiest.
Not... really? It demands a unique $IN for every program you want CELL to call. Binary coding is only slightly more complex, and much more flexible and efficient. Type 3 is mostly (in the circles I move in, at least) considered an outdated and primitive leftover from the Wire Age, when every signal had its own wire and "network" communications were considered too new to be entirely trustworthy.
Not... really? It demands a unique $IN for every program you want CELL to call. Binary coding is only slightly more complex, and much more flexible and efficient. Type 3 is mostly (in the circles I move in, at least) considered an outdated and primitive leftover from the Wire Age, when every signal had its own wire and "network" communications were considered too new to be entirely trustworthy.
I guess for someone new to Kuka AUT EXT communication, type 3 is less hassle not having to deal with 3 extra signals PGNO_REQ, PGNO_PARITY, PGNO_VALID. And it's still good enough if we will only ever need a handful of programs. Regarding unique $IN, do you mean for binary coding, you can have fewer than 8 bits for PGNO_LENGTH? So for example, with Type 3, 8 programs need at least 8 bits, whereas for Type 1, 8 programs only need 3 bits?
I did figure out what is happening with my setup.
It's to do with the order in which the PGNO bit is cleared.
I'm thinking I should add a wait to allow the resent PGNO bits to be read before P00 runs again.
If IN[33] is what makes your program number 1 run in CELL.SRC, then keeping it HIGH even after the program finishes will produce the message "Wait for not Input 33"
Otherwise the program would just repeat itself over and over again.
If you want to tell the PLC that the program has started and there is no need to keep sending IN[33] to robot, you can check the signal $IN_HOME.
It is fair to assume that when robot is not $IN_HOME anymore the program has started. And when the robot is back $IN_HOME the program has finished.
You could also add some "handshake" at the end of your robot program to make sure that a specific program has finished and not just any random program. So you can create some signals / assign some inputs and outputs to set high when the program has finished.
PROG_1_DONE = TRUE
WAIT FOR PLC_Acknowledge
PROG_1_DONE = FALSE
Display MoreIf IN[33] is what makes your program number 1 run in CELL.SRC, then keeping it HIGH even after the program finishes will produce the message "Wait for not Input 33"
Otherwise the program would just repeat itself over and over again.
If you want to tell the PLC that the program has started and there is no need to keep sending IN[33] to robot, you can check the signal $IN_HOME.
It is fair to assume that when robot is not $IN_HOME anymore the program has started. And when the robot is back $IN_HOME the program has finished.
You could also add some "handshake" at the end of your robot program to make sure that a specific program has finished and not just any random program. So you can create some signals / assign some inputs and outputs to set high when the program has finished.
PROG_1_DONE = TRUE
WAIT FOR PLC_Acknowledge
PROG_1_DONE = FALSE
Thanks! Good suggestions, I will try them out.
I find that I can use the message "Wait for not Input 33" as a sort of notification that the program has finished, and the robot is waiting for a reset and resend of PGNO. It's a good stopping point.
I'm using APPL_RUN to check if the program has started. I guess APPL_RUN and $IN_HOME are almost synchronous. Either of them would work.
I guess my focus right now is to make P00 (#PGNO_GET) in the CELL loop, wait until I have resent PGNO so it doesn't pop up "Incorrect program number". It's more of a nuisance than anything else, because after I resend PGNO, I can clear "Incorrect program number" and the program runs normally.
You need to be a member in order to leave a comment
