Posts by Koppel

Hi,

I use the CELL.SRC program to run different programs depending on PLC input.

On the PLC side I do the following:

• Move a PGNO to the KUKA controller
• Verify that the reflected PGNO is what I want
• Send the PNGO_VALID to the KUKA controller and the program starts.
• ... WAIT for a specific input TRUE (that I switch high at the end of this specific Kuka program) that tells the PLC this specific program is now done... and not something else.
• Send a CONFIRMATION to the KUKA controller that I got the message about the program being done.
• ... WAIT for the specific input to be FALSE again... (KUKA program turns it FALSE when it it got the message)

I do this because I have 8 different KUKA programs that are executed at different times by 8 different functions...

BUT there is a problem... sometimes two of these functions are at the same point in life... they both want the robot to do something at the same time.

So first one tells the PGNO should be "7"

The second one tells the PNGO should be "8"

The reflected PGNO is equal to "8" ... this program gets executed but... the second function will forever wait until the program number equals "7" ... but it never will... Its past this point already.

The remedy to this problem has been to to not start a sequence if any of the other 7 sequences are busy... but it feels wrong... there must be a correct way to do it.

So...

Is there a standard way for the PLC and Robot to talk to each other about what program is done... what should be started next. Perhaps even a buffer of different jobs and their order.

I have seen in some threads but I don't know how its done:

I don't understand the problem.
You have 64 safe inputs/outputs. I think they are automatically mapped in WoV.

So you can immediately use them in your Siemens FailSafe PLC safety program.

Output address Q5500.0 is Local E-STOP

Output address Q5500.1 is Drives Enable

Output address Q5500.2 is Motion Enable

...

I think you cannot just monitor the Safety Inputs unless they are used in the Safety program...

So you might have all of the Safety I/O-s in some Tag table and you just monitor them and it seems like nothing is coming through...

But use the inputs in a safety program and then you can monitor them.

Yeah... that's some weird mapping.

I also explained in my post

"... $OUT[2] would be Input I100.1 to the PLC"

The two devices are talking to each other.

One speaks and the other one listens...

In your case both are listening... hence the silence.

Don't worry, you will get there... I know all of this is frustrating but this is how we all have learned - by making mistakes... a lot of mistakes.

1. You should drag one thing to TIA hardware. KRC4-ProfiNet_4.1

I have the following hierarchy.

• KRC4
  • Interface1
    • Port1
• 256 digital in- and outputs_1

And if you open the KRC4 under "Device View" tab and you open the properties pane for that, you can see additional settings.

General > Profinet Interface [X1] > Ethernet addresses > ...

I have checked "IP address is set directly at the device"

And further down there is:

- PROFINET device name: kuka-noname

- Converted name: kuka-noname

- Device number: 1

2. I think I have seen this error... I guess you have used a wrong version of the GSDML file - too old. All the the versions are under Program Files/Kuka/WorkVisual 6.0/DeviceDescriptions/GSDML. Pick the one that you have in the actual controller. Import that to TIA Portal and use it in your hardware configuration.

3. I have not tried with WiFi... I would connect the Kuka controller, the PLC and the PC with a wired network.

No PSEND/PRECV needed

If the connection is done over ProfiNet than:

• You load the GSDML file into TIA portal
• You add the KUKA controller to your hardware configuration
  • Under this configuration you set the start address for your communication... I guess it was 4096 inputs and 4096 outputs...
  • You set your profinet device name and IP address.
• In Kuka Work Visual software you map your inputs and outputs to this ProfiNet range.
  • $IN[1] to ProfiNet input [1]
  • $IN[2] to ProfiNet input [2]
  • $OUT[1] to Profinet output [1]
  • $OUT[2] to Profinet output [2]
  • If your start address was 100 then this $IN[1] to KUKA would be Output Q100.0 from the PLC
    $OUT[2] would be Input I100.1 to the PLC
• After you Deploy the modified WorkVisual project to your KUKA controller, the connection should go GREEN between the KUKA contoller and the PLC. The I/O-s come through.

Since I cannot use $PRO_ACT to determine if CELL.SRC is running, is there any clever way to inform the operator that the Robot is not ready to take commands from the PLC and the operator should check the Kuka Teach Pendant.

If I need multiple equipment to work together and things are not starting up, I would need a hint on the HMI for troubleshooting. Something that would hint towards checking the robot...

... interesting.

Form the signal diagram in the system intergrator manual... it seems its always ON after its initially turned on. Doesn't matter if CELL.SRC is running on if some EXAMPLE.SRC is running... is always ON...

I need EXT_START in the beginning for PGNO_REQ to go up so the robot starts to take interest in receiving program numbers... And I want this to happen in the bacground.

This is how I know that CELL.SRC is running. And if its not running I have a message on the PLC side HMI "CELL.SRC is not running" so that the operator knows to check the KUKA TeachPendent... selects the CELL.SRC, homes the robot and the warning on the HMI goes away.

Ideally I want the operator to do minimum ammount of activities after a cold start.

Does APPL_RUN stay ON during HALT ?

I could then only send EXT_START when both PRO_ACT is OFF and APPL_RUN is OFF

Quote from panic mode

how sure you are that PLC does not simply activate another $EXT_START when it sees that program is not running?

I gess that is it...

I use automatic system start with program number acknowledgement by means of PGNO_VALID.
Certain program steps send a PGNO ... I look at the reflected PGNO and if they match I put PGNO_VALID on... and that starts a program.

And SkyeFire, a cycle start button is also one of the conditions, so no scary "taking off" immediately

If $PRO_ACT is not on, I will put $EXT_START on. And thats the only thing that turns $EXT_START ON.

Is the HALT command turning $PRO_ACT off !?

Fantastic... In my case the CONTINUE before the IF statement would be good enough. There is no precise timing required for the input evaluation. Its decided minutes before.

Hi,

I have a gripper test subprogram that I run immediately after grabbing something... while the robot is stationary. When the gripper closes all the way I know that the grabbing was not successful.

IF $IN[1]==FALSE THEN
HALT
ENDIF

Works like I expected during testing in T1, T2 and even in AUT mode... and stops the program when there is a problem.

During EXT mode it does not skip a beat and the program continues without stopping.

Why?

Ahaa... yes... you are right. The Approximation was lost on the point before the IF statement.... still... any cure for that?

Three interesting things I found out, trying to implement this:

• I have to define all the elements in the geometric operand, apart from Status and Turn.

  
  

  • Using only MyPoint:{X 5} gives an error
  • Must be MyPoint:{X 5,Y 0,Z 0,A 0,B 0,C 0}
• The order of the geometric operand is important.
  • POS:FRAME outputs a FRAME
  • Expert Programming manual says:
    If the left-hand operand has the data type POS, type matching takes place. The position specified by the POS structure is transformed into a frame. That means the system determines the tool frame for this position.
  • This caused my position with the operand to move to the opposite direction because my tool is inverted.
    So MyPoint:{X 200,Y 0,Z 0,A 0,B 0,C 0} did not add 200mm but subtracted
    {X 200,Y 0,Z 0,A 0,B 0,C 0}:MyPoint added the 200mm to the original X component of MyPoint
  • Because if the robot wants to grab something from a table, the coordinate systems of the tool and the position match up. If I dont invert the tool, the robot flange wants to be inside the table. So I have to invert one of them... the point or the tool. There is a lot of points but only one tool... naturally I inverted the tool. I want the Z to point upwards for the things the robot needs to grab.
• When I used the IF statement I lost my approximation "C_PTP" for the first point inside (EDIT: the point just before) the IF statement. Any cure for that?

Mentat, your approach seems convenient for many trays.

Let me work through this

You have a function "GetTrayBaseData" that returns the tray number with predefined offset

You change the base before the prefefined points... with some SWITCH / CASE statements or IF statements.

You need to change the base back to the original after these points.

How do you feel about just modifying the point with a geometric operator ":"

PTP TrayLeftUp:{X 5,Y 0,Z 0,A 0,B 0,C 0}

I could then still use an IF statement

IF $IN[123]==TRUE THEN
   PTP TrayLeftUp:{X 5}
   PTP TrayLeftDown:{X 5}
   GripperClose()
   PTP TrayLeftDown2:{X 5}
   PTP TrayUp:{X 5}

ELSE
   PTP TrayLeftUp
   PTP TrayLeftDown
   GripperClose()
   PTP TrayLeftDown2
   PTP TrayUp
ENDIF

I think its cleaner and easier to understand when I just have two variations.

Also I am a bit scared to change the BASE and change it back again. I could manually jump around in the program during testing and forget to switch back the base.

If I would have many more trays, handling them all with offsets in one area would definitely be more professional.

Hi,

I have used some defined positions in my program

...

PTP TrayLeftUp

PTP TrayLeftDown

GripperClose()
PTP TrayLeftDown2

PTP TrayUp

...

And now some other tray has slightly different (+5mm in one direction) coordinates ( and need to make the program work with both depending if some input "TrayType2" for example is true or not.

What is the most elegant way to solve this.

I could create completely new points for the new tray and use a CASE statement for the different cases - one using the old group of points, and the other using the new ones. But that seems messy.

I could change the base before these points with an IF statement... and then change the base right back after these points.

IF $IN[123]==TRUE THEN
BAS(#BASE,2)
ENDIF

PTP TrayLeftUp
PTP TrayLeftDown
GripperClose()
PTP TrayLeftDown2
PTP TrayUp

IF $IN[123]==TRUE THEN
BAS(#BASE,1)
ENDIF

But how would the pro-s do it?

In my experience you have to go really slow if you work with rigid objects. The robot takes distance to brake. Imagine moving your hand really fast while holding a brick. Even if there is a child running by, you cannot stop your hand immediately. If you only sense the child being in the way by the extra force required to move your hand... the child was already hit hard, and only then will you think about slowing down your hand.

I remember panicmode telling me, its like parking a car blindfolded and detecting a wall when the engine load gets higher... its kinda too late.

Much better to have some interrupt triggered by a spring-loaded gripper... so you have much more time to stop and go back higher.

Fine tuning the holding torque parameters was a pain...

Hi,

KSS version 8.6

To make use of the timers in the area Display>Variable>Timer I have to use a system variable in KRL:

$TIMER_STOP[1]=FALSE

$TIMER[1]=0

$TIMER_STOP[1]=TRUE

But for the counters there is no such thing. How do I make a counter value show up in there?

EDIT: Found a thread from 2014 where "panic mode" gives an answer

how to use system counter in KRC2?

"variable shown in Variable monitor as COUNTER is actually I[]"

And he also suggests to use Display>Variable>Single for the purpose of monitoring a value.

There seems to be a way to monitor custom groups of variables

Display > Variable > Overview

Set up Variable Overview - Configmon

I will look into the subject and write a summary to help future generations.

Thank you,

A while ago I had the same requirement - to create a palletizing program.

You really have to learn raw KRL to do this. So no In-line forms.

I am using a PLC that runs a program when needed... so that might not be what you need.

Declare variables in a DAT file.

DECL GLOBAL INT RobotMove = 1

DECL GLOBAL INT BoxLayer = 1

In the SRC file declare two positions:

DECL POS InBoxUp, InBoxDown

And in the program section you can add "1" after every time the program was running.

RobotMove = RobotMove +1

IF RobotMove == 4 THEN

BoxLayer = BoxLayer + 1

ENDIF

IF RobotMove == 4 THEN

RobotMove = 1

ENDIF

So both of them keep going up... the RobotMove will go 1...2...3...4......1...2...3....4

And the BoxLayer will go to infinity unless you also reset it at some point. 1...2....3.....4.....5.....6

You can calculate individual components of a coordinate for different cases.
Or if you just have a single case then you don't need the SWITCH CASE statements.

SWITCH RobotMove

CASE 1, 2, 3 ;

InBoxUp.x=257

InBoxUp.y=223-(RobotMove-1)*83

InBoxUp.z=(BoxLayer-1)*100

InBoxUp.A=90

InBoxUp.B=180

InBoxUp.C=0

ENDSWITCH

And after the switch statement you can order the robot to go to this point... and that point will have new coordinates every time the program is run.

PTP InBoxUp

In my case the box coordinates are relative to the base of the box... so I just adjust the base to be in the right place and the individual pieces are placed to the correct positions inside the box.

Hi,

KSS: 8.5

Controller: KR C4 Compact

Robot: KR10 R1100-2

In my program I use

BAS (#VEL_PTP, 40)

... to limit the speed.

But this has a negative side effect of limiting the allready lowered speed in T1 mode by another factor when I run through my program.

So basically I end up with:

250mm/s * My limit 40% * TouchPad limit 100% = 100mm/s

I have also limited the ACC_PTP; VEL_CP and ACC_CP using the BAS function. Running through my program in T1 mode to see that everything is OK is super slow.

Is there a clever trick where I still get the 250mm/s in T1 mode regardless of the speed limits I have set in the program... other than commenting out the speed limit. Beacause this results in me forgetting to re-enable the speed limits and things are too fast.

Thank you,

• Thanks for pointing out that the KRL array starts with 1. I used the numbers just as an example.
• Yes, I can access robot I/O-s after I have mapped them in Work Visual.
• I can do the declaration in a global DAT file... but can I also do a value assignment inside the same DAT file?
  The expert programming manual says "Only value assignments with “=” are allowed in data lists."
  Seems like I could do that.