Posts by robotninja

    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.

    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?

    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.


    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.

    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.


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

    Then, P00:

    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:

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

    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:

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

    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.

    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.

    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_TYPE==3) THEN
            MsgQuit("ProgNumberWrong", "P00")
            MsgQuit("ProgramNotAvailable", "P00", PGNO)

    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.

    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 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.

    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.

    "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

    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.

    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?


    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.

    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.


    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.