AUT EXT: PGNO declarations help? [SOLVED]

PGNO_VALID is just an INDEX for robot INPUT.

About configuration:

if your PLC can control robot input $IN[42] then PGNO_VALID = 42
if your PLC can control robot input $IN[77] then PGNO_VALID = 77

About use:
when instruction says PGNO_VALID need to be set to true, it really means that INPUT with that index need to be set to true.
Btw, this signal simply means "it is ok to read the PGNO right now"

The PGNO variables are used by the pre-packaged programs CELL.SRC and BAS.SRC. They are designed to be widely configurable. Instructions on how to configure them are detailed in the "Automatic External" section of the manuals.

PGNO is an Integer variable from multiple $IN inputs signals (from 2 to 32). PGNO_FBIT is an integer that defines the first $IN for PGNO, and PGNO_LENGTH defines the number of $INs that PGNO uses. PGNO_TYPE defines if PGNO is treated as a Binary, Unsigned Integer, Signed Integer, etc. PGNO_PARITY defines the $IN used for a parity bit, and if it is 0 then the Parity check is skipped. PGNO_VALID is simply a $IN that is set True from the external PLC to tell the robot that the input data on PGNO is now valid and should be checked. PGNO_REQ is the $OUT that the robot sets when CELL.SRC is running and waiting for PGNO and PGNO_VALID.

correction, max value for PGNO_LENGTH is 16.

That's what I get for going from memory. I actually had a set of robots where I had to hack PGNO to be a 32-bit value, but that was due to a rather ridiculous set of requirements.

MultiProg and KSS are two different products, so of course there will be differences somewhere.
One is PLC programming software so things are geared towards plc logic, other is system built to be supported by scripted programming.

Btw. I don't think it is a good idea to refer to manual for Multiprog while working inside KSS (and the other way around...).

those things are already declared by the KSS. You are NOT supposed to redeclare them...
Just use HMI on the robot to map AutoExternal signals.

of course it is possible to change them manually too by editing files by hand but - you are way too green (and dangerous) do it this way.

So my recommendation would be to please stop screwing around and get training or read the manuals. I don't know how things are where you are from but here it is a law that people working with robots must be trained due safety concerns.

Btw, you received responses on this same thing already:

https://www.robot-forum.com/robotforum/kuk…t-signals-help/

Quote from n0909

Yes thanks panic mode ,
And I'm aware of the laws involved in safety and we have booked in for the trainings few weeks from now so should be okay.

Appreciate your response and thanks for your help.

Cheers
N

I tried to find the other post, but it deleted. It was worked actually?:)

And what was the solution, if you fixed it?:)

Thanks for your help in advance!:)

Cheers,

M.

forum underwent some upgrades etc. so some of the old posts or links to them may be gone. i would suggest to start own topic...

use of EXT mode is straight forward and well documented. Basically KUKA offered clean and quick to deploy solution in a form of a ready template program CELL.SRC that need to be adapted (just insert calls to your programs) and AutoExternal interface where one can specify type of handshake interface and freely choose any I/Os for handshake signals. the idea is to use it pretty much as is. there is no deep insight needed, no restructuring or need for restructuring code or declarations....

basic steps would be something along these lines:

1. modify CELL.SRC so that there is a separate case statement for each of your programs that PLC should be able to select. add the programs calls into corresponding Cases in your CELL.SRC program. template comes with only 3 cases, if needed more, just duplicate one of cases and change numbers.

2. determine total number of (non-zero) cases that will be called. this will influence which PGNO_TYPE you may use and how many bits are needed for PGNO. most commonly used is PGNO_TYPE 1. not many PLCs these days force you to use BCD. And 1-of-N is very limited since one can choose max 16 programs when using 16 bits for PGNO.

3. make sure there are sufficient I/Os available allowing signaling to/from PLC. and make sure to confirm that they really work as intended - turn on output on one end (KRC or PLC) and verify that other node receives it (PLC or KRC). repeat for other signals as needed.

4. parity fell out of favor many years ago as I/O became dirt cheap and plentiful, plus most people that program of configure robots and PLC do not seem to be familiar with term "parity" or how to write program on PLC end to compute it. besides, using parity only allows detection of a single corrupt bit in PGNO and therefore it is common to simply use reflection. this one one gets exact bit-by-bit copy of PGNO echoed to PLC.

6. signal PGNO_VALID is a boolean. it is used by PLC to tell KRC when to read the PGNO value (after confirming that PGNO is received correctly). But in KSS this signal can be assigned to any of the robot inputs. therefore AutoExternal configuration uses INT value to select which input is used to receive actual TRUE/FALSE value. essentially it will read $IN[PGNO_VALID]

7. Documentation clearly states order in which signals are exchanged. it is very straight forward really if one considers how every robot program is started and this is pretty much always the same - regardless of operating mode. it is only 4 steps : enable drives, clear faults, select program and issue start. in case of EXT mode that program is meant to be CELL and some of those steps are accomplished through I/O signals rather than HMI. after this, all that is left for PLC to do is tell what PGNO should be started as CELL subprogram...

I have attended and completed basic and advanced training on the KUKA KRC2 and as I move forward with my first project I still run into mistakes and incomprehensible things.

Really appreciate your help PanicMode it helped me a lot, but i have one or two more dark spots.

So,

I would like to use BCD (PGNO_type 2)
I would like to use 16 bits, cause i will use 4-digit numbers.(Am i think right?)

The problem... i don't know why should i use cell.src?

1 DEF CELL ( )
 …
6 INIT
7 BASISTECH INI
8 CHECK HOME
9 PTP HOME Vel= 100 % DEFAULT
10 AUTOEXT INI
11 LOOP
12 P00 (#EXT_PGNO,#PGNO_GET,DMY[],0 )
13 SWITCH PGNO ; Select with Programnumber
14
15 CASE 1
16 P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 )
17 ;EXAMPLE1 ( ) ; Call User-Program
18
19 CASE 2
20 P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 )
21 ;EXAMPLE2 ( ) ; Call User-Program
22
23 CASE 3
24 P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 )
25 ;EXAMPLE3 ( ) ; Call User-Program
26
27 DEFAULT
28 P00 (#EXT_PGNO,#PGNO_FAULT,DMY[],0 )
29 ENDSWITCH
30 ENDLOOP
31 END

As you write and as i saw in the manual, i can just change in case 1 the " ; EXAMPLE1" to "myprog1" or something like that.

i would like to use the signal like this:

DEFFCT material_length()
    ;To $Config.dat
    
    ;SIGNAL X1_length $IN[80] TO $IN[83]
    ;SIGNAL X10_length $IN[84] TO $IN[87]
    ;SIGNAL X100_length $IN[88] TO $IN[91]
    ;SIGNAL X1000_length $IN[92] TO $IN[95]
    
    RETURN X1000_length*1000+X100_length*100+X10_length*10+X1_length
ENDFCT

But we talked about this earlier. I have to copy this to config. dat, then what should write into the cell.src cases?Which programs?:)
Where i would like to use those inputs?

I hope i write everything clear

Thanks four your helps in advance!:)

Quote

I would like to use BCD (PGNO_type 2)

I would like to use 16 bits, cause i will use 4-digit numbers.(Am i think right?)

yes, that will allow you to select up to 9999 different cases. that is a lot of cases... which is a lot of copy and paste... i have seen/worked on project with few hundred of cases. and it was a royal pain to maintain the code as programs are added and deleted. in such case custom solution may be reasonable.

Quote

The problem... i don't know why should i use cell.src?

well... that sentence right there is a pretty good example why one should use it...

maybe it was not with KUKA certified trainer or training, or he had a really bad day, or perhaps you were not really into it, etc.

obviously i am not a client but i could just hear them asking a lot of questions.

so, how would you answer their questions if they are something like:

* how would your solution compare to standard solution? can you list pro and contra for each?

* how many robot cells have you installed so far? how many are in production for long time with no collision or client complaint?

* how many people have adopted your way of doing this and prefer to use it over standard solution based on CELL.SRC?

* if one is to try downloading some official documentation about your implementation, or simply trying to register few people for some training, who should they turn to? is this offered globally?

* what is the limit your insurance will cover? when can you provide proof?

* did you come up with that code all by yourself? some of our guys think that that you got off the internet, perhaps robot forum...

* did you try to compile it? are you sure? because that is obviously not a valid KRL function. you are obviously trying to return value that has no type defined.

* did you really think that CELL.SRC is practically the whole solution? are you aware that this is just a tiny piece (one that user should adapt) and that there are other elements of it? do you know what and where they are and how they function?

* are you really sure that presented code is a suitable substitute for standard solution? i did not see anything about BCO, handshaking, powering drives, clearing messages, starting program, checking program data integrity etc. out techs told us that they don't like BCD. they say that with BCD some bit combinations are invalid. how does your solution deal with that? for example if one of digits is 'B1101' instead of 'B0101' or 'B1001'...

* how portable is your version? i see that one has to alter $CONFIG.DAT and we don't want to do that on 200 robots. chance of mistake is big. and why is it called 'material length'? we expected something to manage cell interactions and program selection, not take length measurements:

DEFFCT material_length()
    ;To $Config.dat

    ;SIGNAL X1_length $IN[80] TO $IN[83]
    ;SIGNAL X10_length $IN[84] TO $IN[87]
    ;SIGNAL X100_length $IN[88] TO $IN[91]
    ;SIGNAL X1000_length $IN[92] TO $IN[95]

    RETURN X1000_length*1000+X100_length*100+X10_length*10+X1_length
ENDFCT

well that should do it... i have done custom version numerous times but wonder how others feel about it, need some good ideas for the next project.

Thanks for your help Panicmode

So, if i think right, the program what i would like to run in aut ext, have to be pasted to cell.src.

The whole program doesn't finished, but i wanted to try the "data_transfer" between the PLC and KRC.After this, i think i can't try it in T1, can i?

PGNO_TYPE=2
 CASE 2
        ;*******************
        FOR I=0 TO  PGNO_LENGTH-1  STEP  4
          N=0
          J=1
          FOR M=I TO  I+3
            IF $IN[PGNO_FBIT+M] THEN
              N=N+J
              IF REFLECT_PROG_NR==1 THEN
                $OUT[PGNO_FBIT_REFL+M]=TRUE
              ENDIF
            ENDIF
            J=J*2
          ENDFOR
          IF (N>9) THEN
            PGNO_ERROR=2
            PGNO=0
            EXIT
          ELSE
            PGNO=PGNO+N*L
            L=L*10
          ENDIF
        ENDFOR
      ENDSWITCH

As i think right this program( TP\ p00.src) contains and write everything what i need to try the connection.

(Only in Aut_ext?)

Have to define PGNO_FBIT_REFL, PGNO_LENGHT and PGNO_FBIT:
PGNO_FBIT: 80

PGNO_LENGTH:16

PGNO_FBIT_REFL:0

And as i see,will i get the PGNO? That would be my lengths in DEFFCT?

Before i insert this code to $config.dat, should i declare something?

I mean:

SIGNAL PGNO $IN[80] TO $IN[95]?(and what more, if need?)

Or i can just write this code to $config.dat and use with the function name(material_length) in the main program.

DEFFCT material_length()
    ;To $Config.dat
    
    ;SIGNAL X1_length $IN[80] TO $IN[83]
    ;SIGNAL X10_length $IN[84] TO $IN[87]
    ;SIGNAL X100_length $IN[88] TO $IN[91]
    ;SIGNAL X1000_length $IN[92] TO $IN[95]
    
    RETURN X1000_length*1000+X100_length*100+X10_length*10+X1_length
ENDFCT

Thanks fou your help in advance!

M.