Posts by robotninja

Quote from Patrik Paukov

Siemens have something for KUKA robots and B&R for ABB.

I have only seen sales presentation, but it should work in way, that you teach positions and write logic directly in PLC. Not sure if it send data directly to servo, or if there is program running on robot.

And I also have seen Siemens + Yaskawa (custom programmed), where on robot side there was program running in loop and asking PLC for next position, which were stored in PLC, also with logic.

Thank you, I will look into Siemens. How about Schneider or Rockwell?

Hi panic mode good to see you again.

This is for a work project, not a hobby project. The physical constraints of the application necessitated development of a custom mechanical design for a robot arm. That's the mechanical team's responsibility. My responsibility is control and software. That's why I am looking for a generic PLC based robot controller and software that might have some built-in templates for doing 6dof articulated robot inverse kinematics, dynamics and control algorithms. So that I don't have to start from scratch.

As I mentioned in my OP, I'm still ramping up on ROS.

Quote from panic mode

it should be not hard to make the PLC get streamed data from ROS to control the axes.

Do you mean, model the robot in ROS and use ROS algorithms and stream the servo control signals from ROS to the PLC?

Quote from panic mode

and then we are still talking about a lot of hours of integrating it all (mechanical, electrical, software...). with open source, someone has done some work but you ultimately need to know how to finish it and turn it into a product and that means advanced skill and lots of hours to make something that can move.

next comes reality in terms of the performance - what kind of positional accuracy, path accuracy, speed etc. do you expect? what do you know about inertia, vibrations and elasticity? what about longevity? why do you think that someone who is just learning, can buy generic of the shelf parts and make something that not only works but compares or competes with top class design that was meticulously refined by a huge team of engineers over many decades?

All fair points, and I have been educating the mechanical team (who don't have any experience with the huge amount of integration that goes into a robot) on the time and effort it will take.

Our manipulator arm will certainly not meet or compete with top class design.

Quote

top class design that was meticulously refined by a huge team of engineers over many decades?

That is exactly what I have been repeating to everyone, just so their expectations are calibrated.

Are there any PLC-based generic robot controllers and end-to-end software suite that can be used to control a custom articulated robot (i.e. robot arm with 6 or more axes)?

I'm aware of ROS open source software. But there is a steep learning curve that I'm still on.

I'm looking for an off-the-shelf PLC solution that has all the functions and control algorithms already developed for applying to any user-defined 6 or 7 axis robot arm that uses standard servomotors and drives.

Typically, industrial robot companies like Kuka have their own hardware and software integrated. I want to integrate an off-the-shelf controller and software with my hardware i.e. robot arm.

So, basically, I'm looking for a ROS type system but more developed and more "plug and play".

Folks, I'm happy to report that I have this working now

The "finishing touch" needed was a wait in P00.

CASE 3
;*******************
IF PGNO>0 THEN
WAIT FOR  $IN[PGNO_FBIT+PGNO-1]==FALSE
ENDIF


WAIT FOR $IN[200]==TRUE ;This is $EXT_START


K=0
REPEAT
    FOR I=0 TO  PGNO_LENGTH-1
        IF $IN[PGNO_FBIT+I] THEN
            IF K==0 THEN
                K=I+1
            ELSE
                PGNO_ERROR=0
                K=0
            ENDIF
        ENDIF
    ENDFOR
UNTIL ((K<>0) OR (PGNO_ERROR==0))
PGNO=K
ENDSWITCH

So now, after completion of the motion program, control goes back to CELL, and I see a message "Wait for Input 200". It stays in this idle state until I start my PLC sequence for sending it a PGNO. No more pesky "Incorrect program number" messages, because it knows to wait until it has received a new PGNO. It's silly to begin with, that they haven't written the code to handle idle state. Seems like an improvement item.

I'm glad to find that the code is customizable to my specific needs.

Well, that was just one idea. I'm sure there are other alternatives.

Regardless of PGNO_TYPE, CELL loop is always running, and P00 is always looking for a PGNO input. There is no spot in the code to "do nothing until" - except if I choose to use the "Wait for not Input 33" for this purpose. So if I want to run my motion program just once, and let the robot idle for a while before I decide I want to move it again, I'd have to make some modification if I don't want to see those messages. It's not really "hiding messages", it's just creating a wait so that the code doesn't misunderstand in a hurry and throw this message.

Or, I guess I could make changes in SPS so that CELL itself is run just once until called again.

CELL.src:

LOOP
    P00 (#EXT_PGNO,#PGNO_GET,DMY[],0 )

Then, P00:

CASE 3
    ;*******************
    IF PGNO>0 THEN
        WAIT FOR  $IN[PGNO_FBIT+PGNO-1]==FALSE
    ENDIF
    K=0
    REPEAT
        FOR I=0 TO  PGNO_LENGTH-1
            IF $IN[PGNO_FBIT+I] THEN
                IF K==0 THEN
                    K=I+1
                ELSE
                    PGNO_ERROR=0
                    K=0
                ENDIF
            ENDIF
        ENDFOR
    UNTIL ((K<>0) OR (PGNO_ERROR==0))
    PGNO=K
ENDSWITCH

Here, P00 waits until $IN[33] is cleared. But then it immediately runs through the rest of the code, and ends up with K=0 and PGNO_ERROR=0. It returns these values back to CELL.src

Then back in CELL.src:

LOOP
    P00 (#EXT_PGNO,#PGNO_GET,DMY[],0 )
    SWITCH  PGNO ; Select with Programnumber

        CASE 1
            P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 ) ; Reset Progr.No.-Request
            BasicLoop() ; Call User-Program

        CASE 2
            P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 ) ; Reset Progr.No.-Request
            ;EXAMPLE2 ( ) ; Call User-Program

        CASE 3
            P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 ) ; Reset Progr.No.-Request
            ;EXAMPLE3 ( ) ; Call User-Program

        DEFAULT
            P00 (#EXT_PGNO,#PGNO_FAULT,DMY[],0 )
    ENDSWITCH
ENDLOOP

The DEFAULT case is selected, which is the #PGNO_FAULT in P00:

CASE #PGNO_FAULT
    .
    .
    .
    .
    
    IF PGNO_ERROR==0 THEN
        IF (PGNO_TYPE==3) THEN
            MsgQuit("ProgNumberWrong", "P00")
        ELSE
            MsgQuit("ProgramNotAvailable", "P00", PGNO)
    ENDIF
...

This generates the "Incorrect program number" (i.e. "ProgramNumberWrong").

I can clear the message and it keeps popping up until after I resend PGNO bits, and PGNO>=1. Then it disappears. The motion program runs. Then, "Wait for not Input 33" shows up. Then, the bits are cleared, then "Incorrect program number" pops up. Then, I resend PGNO bits, and so on.

It's not a showstopper, but I would like to get rid of the "Incorrect program number" popup because it's a bit silly why it pops up, now that I understand the code.

I was wondering if I can fix this by assigning an input which I turn on from PLC after resending PGNO bits. Then, in P00 I can add a WAIT FOR this input to turn on:

CASE 3
;*******************
IF PGNO>0 THEN
    WAIT FOR  $IN[PGNO_FBIT+PGNO-1]==FALSE
ENDIF

WAIT FOR $IN[PGNObitsON from PLC]==TRUE

K=0
REPEAT
    FOR I=0 TO  PGNO_LENGTH-1
        IF $IN[PGNO_FBIT+I] THEN
            IF K==0 THEN
                K=I+1
            ELSE
                PGNO_ERROR=0
                K=0
            ENDIF
        ENDIF
    ENDFOR
UNTIL ((K<>0) OR (PGNO_ERROR==0))
PGNO=K
ENDSWITCH

This way, the code doesn't process K until new bits are available. Would this work?

Quote from Koppel

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 More

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.

Quote from SkyeFire

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.

1. In the CELL loop, P00(#PGNO_GET) reads the PGNO bits and spits out a PGNO which is used for the SWITCH..CASE, and the motion program is run.
2. If I clear the PGNO bits at the end of my PLC sequence, after APPL_RUN=TRUE, then at the end of the run, back in the CELL loop P00 looks for a valid PGNO, does not find one, and throws the error "Incorrect program number". I repeat my sequence and then acknowledge the message, which clears it and the motion program starts again.
3. If I clear the PGNO bits at the beginning of my PLC sequence, i.e. clear PGNO bits and then send PGNO bits, then at the end of the run, back in the CELL loop P00 waits for the specific bit to be cleared. "Wait for not Input 33" etc. Once I restart my sequence, the bits are cleared, but P00 doesn't catch my newly sent PGNO bits right away. And it pops "Incorrect program number". When I acknowledge it, the PGNO bits are read and motion program starts again.

I'm thinking I should add a wait to allow the resent PGNO bits to be read before P00 runs again.

Quote from MOM

@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

Quote from SkyeFire

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
ENDIF

Quote from SkyeFire

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.

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.

Quote from SkyeFire

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.

Quote from panic mode

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.

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". But each time, I can clear it and then have my motion program run.

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?

The message shows sender as P00. But I studied P00.src carefully and did not find where this message is being generated.

Quote from SkyeFire

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?

Quote from aknezevi.proton

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?

Quote from panic mode

"Incorrect program number" is displayed when number that PLC is selecting is not used in CELL.SRC.

for example CELL has cases for program numbers 1,2,3,4,5 but PLC sends program 9

Does PGNO_TYPE 3 work differently? The last few tries, I'm not getting "Incorrect program number" but some other message (see post #17).

$IN[33] to $IN[40] i.e. 8 bits are mapped as PGNO.

Type 3 is simple enough it seems. So I sent [33-40] = [00000001] for PGNO=1 but it gave me the message "Wait for not input 40". When I changed the bits to [10000000] it gave me the message "Wait for not input 33".

Well, now I'm getting a different message.

After switching between T1 and EXT, the error message "Incorrect program number" is gone.

But, I'm getting "SIMULATE 3 Wait for not Input 40".

This is weird because I have mapped $IN[33]-$IN[40] as the program number, and I am using program number 1, so it is [0 0 0 0 0 0 0 1] i.e. Input 40 is TRUE.

The details on the message are:

Possible causes

1. Cause: KRC_Interrupt is set

Solution: Call KRC_Continue

So I added this code inside the LOOP..ENDLOOP:

IF ($MODE_OP==#EX) AND ($OUT[1021]==TRUE) THEN ;$OUT[1021] is PERI_RDY
    CWRITE($CMD,STAT,MODE,"RUN /R1/CELL()")
ENDIF

Now, I can get the SPS to select and run CELL.SRC when I switch from T1 to EXT. It doesn't seem to need $EXT_START.

$PRO_ACT is TRUE.

My PGNO_TYPE is 3, so according to the manual PGNO_REQ, PGNO_PARITY, PGNO_VALID are not evaluated.

So, how does this alter the sequence of PGNO? I mean, when should I send the PGNO from the PLC?

Right now, I'm getting an error "Incorrect program number" from P00. I read through P00.src, but I didn't find where this error is generated in P00.src.

Quote from panic mode

personally i do not like that so i have my own code that is called inside LOOP/ENDLOOP and therefore acts even after startup. so in my add-on code i check mode. when mode is EXT and wrong program is selected, program is deselected and then CELL.SRC is selected (or whatever my main program is).

I like this.... I will do this as well. Just to confirm, this code would go in the USER PLC fold, correct?

How do you check if wrong program is selected?

Thanks!

Quote from panic mode

That is possible of course because that is not good enough.

triggering start will not work if preconditions are not met. first you need to follow the sequence and get robot into operational state (clear messages, enable drives...).

Yes, of course the preconditions are met. As I wrote in post #8 above, I have $PERI_RDY on, and I also have the other signals in their correct state - $STOPMESS off, $MOVE_ENABLE on, $DRIVES_OFF on. I'm at the point of $EXT_START.

I just cannot figure out what is wrong.

Quote from panic mode

where do you get that idea? did manual or I state that program need to be closed after performing BCO?

stop inventing things, just read and follow instructions.

Not inventing things... there is a lot of conflicting information out there, even in the manuals. Or there just isn't enough information. Manuals do not explicitly say to select CELL.SRC and do BCO run. Nor did KUKA tech support. They said the code in SPS.sub should automatically select and run CELL.SRC if robot is in EXT mode.

The signal diagram is not explicit about having to manually select CELL and do BCO in T1. All it says is $EXT_START triggers CELL to run.

IF $MODE_OP==#EX THEN

    CWRITE($CMD,STAT,MODE,"RUN /R1/CELL()")

  ENDIF

Does it make a difference if I switch from T1 to EXT, or have it in EXT mode at cold start?

I have tried multiple times selecting CELL.SRC in T1, doing BCO run and then switching to EXT, and then sending $EXT_START pulse. But nothing happens. $PRO_ACT never turns on.

I have not modified SPS.sub at all. CELL.SRC only to add my motion program in the switch cases.