Posts by robotninja

Quote from SkyeFire

Serious question: how precise and how accurate does this robot need to be when reassembled?

It needs to be extremely accurate and precise, within a few millimeters, because:

1. It will operate in a constrained space with objects around, so it needs to do its job on the intended object, without damaging unintended objects.
2. It will need to be guided through a digital twin model and a force feedback arm, so these would work properly if the robot itself is very precise and accurate.

Quote from SkyeFire

I... won't speculate. But that does put a very different spin on things.

You may want to examine the option of having actual absolute encoders on the joints, instead of on the motors. Something like a DRO for a mill or lathe, just wrapped around the joint. Not necessarily to replace the motor encoders/resolvers (getting high enough resolution could be an issue), but to provide a nearly-infallible cross-check.

The coarse version would be to add some kind of "homing switch" to each axis. So on reassembly, the first action would be to "home" out each axis, rather like most 3D printers do at the start of a print job. The potential downside there would be if the spatial constraints of the new location prevent a joint from reaching the Home position, but having a few uniquely identifiable Homing sensors around the joint arc could fix this. Have a semi-automated Homing routine that "sweeps" across the Homing sensor both ways, at high then low speed, to try and null out the backlash issues.

I suppose the "gold plated" option would be to have a laser tracker target nest mounted on the wrist, and on reassembly use a laser tracker to re-tune the DH parameters and Mastering for the "as-reassembled" condition.

Serious question: how precise and how accurate does this robot need to be when reassembled? Will anyone be within reach of the robot while it operates?

Great thoughts!

No personnel will be within reach of the robot.

Quote from Lemster68

How big will it be such that it needs to be disassembled for shipment rather than leaving it assembled?

It's for separate deployment at different sites, not for one time shipment. You pack it up, take it to the next deployment site, unpack it and use it. And the joints are also potentially going to have to be passed through a tight opening, and deployed in an area where the robot is not directly visible. (We're looking at digital twins etc. for providing user interaction). So, it's not going to be a typical industrial robot deployment, where the robot is unpacked, installed, mastered and operates in that fixed spot forever.

Quote from SkyeFire

Frankly, without an in-depth knowledge of what you're trying to do, it's hard to say. But the "just push it into Mastering position" feels like a cheap, lazy cop-out to me, by people who haven't really thought about what they're doing and how it can go badly wrong.

The idea is to make a robot arm that can be taken apart and put back together at different deployment sites.

Quote from SkyeFire

Depends on the fine details of your encoders and how you're tracking them. The most obvious pitfall would be if a motor got moved without power and somehow landed within the tolerance band of the encoder, but some N motor rotations off. That is, the encoder can't tell you if you're at 271.123deg on Rotation 1, or Rotation 300. And your encoder will have a tolerance band, because no servo holding is perfect, power on or off.

Does it make any difference if we were using resolvers instead of encoders?

Do all robot companies have similar mastering devices? I saw quite a few patents of mastering devices from a google search. What about smaller robots like those from Universal Robots? How do they do their mastering?

SkyeFire , thank you for your valuable reply.

A related question here, as I mentioned in my OP, does it matter if this mastering is done without having the motors powered on?

After aligning the witness marks manually, the system is powered on, and the encoder readings are saved. Does this work?

Or, does the process of aligning the witness marks have to occur by jogging the motor?

Thanks for your suggestions, everyone.

We finally went with Beckhoff, as they have the kinematics models as well as native EtherCAT support for drives.

I myself have some experience with robot mastering using an EMD toolkit on Kuka. However, I'm now working in a team of engineers who have no experience with robots, and we're trying to design a custom robot. They don't seem convinced on the need for doing mastering the proper way (i.e. using an equivalent of an EMD toolkit).

I feel like I'm not providing a solid and convincing explanation of why mastering is critical for precise positioning.

I myself understand that mastering calibrates the mechanical zero and the electrical zero. The crucial part of using an EMD toolkit, is to have each motor move its load (i.e. rest of the arm plus whatever tool payload) when setting the zero position.

My coworkers are suggesting to simply manually line up each pair of axes to matching witness marks with the motors powered off, and then powering up the motors and recording the encoder position as zero.

I tried my best to explain that manually moving de-energized motors to line up the axes doesn't serve the purpose of mastering. I tried explaining that the zeroing with load is not the same as zeroing without load (giving the classic Kuka example of a fishing rod). Am I wrong?

Is it possible to achieve true zeroing by simply manually lining up the de-energized axes, and then recording the encoder values?

Is there a resource/textbook that explains mastering with solid theoretical backing?

Thanks!

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.