Posts by nimius83

Quote from Fubini

Full stop or just a velocity reduction. If it is a full stop: where does it stop? At blending start? Does it work better with slower override?

Did you try to increase allowed (orientational) velocities/accelarations? Especially those in $config.dat (DEF_VEL_ORIS, DEF_ACC_ORIS)? Defaults usually are a bit slow. So orientation control tends to slow the robot down. Does this even have an effect on your problem?

Fubini

Default values are: DEF_VEL_ORIS = 200, DEF_ACC_ORIS = 200. It doesn't seem they are slow, isn't it?

Anyway, robot has a drastic speed reduction at blending start.

I can obtain a smoothy, blended movement by setting the ORI_TYPE as "wrist PTP". But my concern is that setting should be used only to overcome a singularity during the SLIN movement.

Quote from Fubini

What do you mean by that?

Any messages?

Did you check logbook?

Is it really a blending issue?

Does it blend at all?

Did you check with $STOPNOAPROX?

Fubini

Display More

Hello Fubini, I really tried hard to make me understand (in English) but it is always not enough, sorry

$STOPNOAPROX is true but the robot doesn't stop and no message is displayed.

The robot, during its trajectory , has like a little stop instead of blending: the result is an awful movement.

It is surely a blending issue, maybe it happens when mixing movement to E6AXIS, E6POS positions (from SPTP to SLIN and from SLIN to SPTP).

Hello everyone.

I have a Kuka KR C4 controller and KR 50 R2100 robot.

Mine is a simple pick&place application and I only use SPTP and SLIN instructions outside a spline block.

My problem is that the robot gets stuck when it starts a blended SLIN movement after a SPTP, or a SPTP after a SLIN. This happens in many different robot positions and axis 5 is not near to singularity.

I've already read all the other threads about this topic without finding a solution until I found out a workaround: I set the SLIN "orientation type" as "wrist PTP" and it did work, but I'm not pretty sure is the correct way.

My code is the following:

SPTP OutStation CONT Vel=100 % ACC100_APO70 Tool[1]:Gripper Base[0]
SPTP InStation CONT Vel=100 % ACC60_APO50 Tool[1]:Gripper Base[0]
SPTP HighApproach CONT Vel=100 % ACC60_APO50 Tool[1]:Gripper Base[0]
SLIN LowApproach CONT Vel=1 m/s ACC30_APO30_J Tool[1]:Gripper Base[0] ORI=WRIST_PTP
SLIN FinalPoint Vel=0.3 m/s ACC20_APO0 Tool[1]:Gripper Base[0]

where:

- OutStation is a E6AXIS global point;

- InStation is a E6AXIS global point;

- HighApproach is a E6POS local point: XHighApproach=XFinalPoint:{X -300.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}

- LowApproach is a E6POS local point: XLowApproach=XFinalPoint:{X -100.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}

- FinalPoint is a E6POS global point

- ACC100_APO70 is a PDAT: {VEL 0.0,ACC 100.0,APO_DIST 70.0,APO_MODE #CPTP,GEAR_JERK 100.0,EXAX_IGN 0}

- ACC60_APO50 is a PDAT: {VEL 0.0,ACC 60.0,APO_DIST 50.0,APO_MODE #CPTP,GEAR_JERK 100.0,EXAX_IGN 0}

- ACC30_APO30_J is a LDAT:  {VEL 0.0,ACC 30.0,APO_DIST 30.0,APO_FAC 50.0,AXIS_VEL 100.0,AXIS_ACC 100.0,ORI_TYP #JOINT,CIRC_TYPE #BASE,JERK_FAC 50.0,GEAR_JERK 100.0,....}}}

- ACC20_APO0 is a PDAT: {VEL 0.0,ACC 20.0,APO_DIST 0.0,APO_MODE #CPTP,GEAR_JERK 100.0,EXAX_IGN 0}

I have tried both PDAT "APO_MODE" combinations (APO_MODE #CDIS, APO_MODE #CPTP) and different APO_DIST values but with no effect.

At last, the "Wrist PTP" option is working for most robot positions, but not always.

Hello everybody,

I would like to replicate the function "Frame" on other robots, like Kuka.

SET pallet = FRAME(loc.origin, loc.x.axis, loc.pos.y, loc.origin)

The new frame pallet has a different orientation than loc.origin, loc.x,axis and loc.pos.y (let's suppose these 3 points has the same orientation Rx,Ry,Rz)

This difference can be calculated as: SET dif = INVERSE(pallet) :loc.origin

Then, I can move on the pallet:

SET pick = pallet:TRANS(0*x.distance, 2*y.distance):dif

What I don't understand is why the frame pallet comes out with a different orientation, even though the 3 points have the same orientation between them.

Do you have any idea?

Thanks

Quote from SkyeFire

Robot Type? KRC model? KSS Version?

Define "unexpected trajectories".

Post actual code, not abstracts.

Hello,

I usually move the robot between E6AXIS positions in the free-space (with PTP instruction and CONT enabled).

Once the robot has reached the final destination area, the final movements are performed using E6POS position (PTP to approach, LIN to final pos):

PTP welding_zone_free_area (E6AXIS)

PTP free_area_2 (E6AXIS)

PTP free_area_3 (E6AXIS)

PTP pallet_zone_free_area (E6AXIS)

PTP pallet_release_appro (E6POS)

LIN pallet_release (E6POS)

I experienced unexpected trajectories when robot is blending the last E6AXIS (PTP) point with the first E6POS (PTP) (red highlighted in the example before). With other robot brands I never had this problem.

I solved blending the last E6AXIS (PTP) to the first E6POS using a LIN command instead of PTP like this:

PTP welding_zone_free_area (E6AXIS)

PTP free_area_2 (E6AXIS)

PTP free_area_3 (E6AXIS)

PTP pallet_zone_free_area (E6AXIS)

LIN pallet_release_appro (E6POS)

LIN pallet_release (E6POS)

I don't know where I am wrong.

Hello,

I'm having serious troubles with a scara eCobra 600 (controller updated to the latest 2.4 C4 version). After a certain movement instruction (I replicated this at very slow speed), joint 4 rotates fast and then stops in error.

After this error, if I call the normal repositioning sequence (tested million of times), it seems the robot is trying to move joint 2 to 0° (singolarity point) as if it is trying to recalibrate axes. Is this possible?

Someone told me that after certain errors robot tries to recalibrate itself but I don't want to believe that.

Thank you

The digital signal comes from PLC (Profinet). If the condition is already met, program should exit from waitFor() loop but it doesn't! Program is stuck and doesn't go on.

Kuka service told me that it is better to use PositionHold() rather than WaitFor()

Already did it but it doesn't swap

Quote from panic mode

i am too lazy to downgrade to WoV version 4.0.17 but...

one can map one signal at a time, any way you like. this means you can not only swap bytes, you can swap bits any way you like.

Now, if you can swap it in PLC and be done with it - what is the problem?

It takes a longer time in PLC 'cause I transfer double words at a time. I should ungroup all these double words again but I'm lazy as well

Quote from panic mode

you can swap them in WorkVisual too. check WorkVisual manual or help file.

for standard robots it is straight forward - highlight range with the mouse.
if everything else fails, one can map them one by one in any order you like.

I already tried to swap them in WorkVisual but it doesn't work. Kuka service says that maybe this limitation is due to data transfer over Profinet (GSDML). In fact, data to be transferred from/to PLC is grouped in bytes, not in words or double words

Hi guys,

I'm having some problems with waitFor() method:

AbstractIO startInput = pnio.getInput("ReadyToCycle");
BooleanIOCondition startCond = new BooleanIOCondition (startInput, true);
getObserverManager().waitFor(startCond);

It seems that if the ReadyToCycle input is already "true", the program execution is stuck waiting for a new rising edge of the signal to go on.

I use instead positionhold() without any problem:

AbstractIO startInput = pnio.getInput("ReadyToCycle");
BooleanIOCondition startCond = new BooleanIOCondition (startInput, true);
posControl = new PositionControlMode();
lbr.move(positionHold(posControl, -1, TimeUnit.SECONDS).breakWhen(startCond));

Hello,

I'm using WorkVisual 4.0.18 on a IIWA. I talked to people who had the same experience with standard Kuka Robot about profinet communication between a PLC Siemens S7 and robot. For this reason I decided to post this topic in the general Kuka Robot Forum.

However.. I don't have any problem if I swap the two bytes from PLC side and I don't know why it doesn't work in WorkVisual..

Quote from panic mode

it is not enough to make change in WorkVisual... it must be compiled, deployed and activated

Hello,

after any modification in WorkVisual, I usually export configuration to Sunrise Workbench (i'm using a LBR iiwa). I never compile or deploy the project...

I just now tried to deploy project but WorkVisual crashes.

Are you sure that byte swap feature needs to be compiled and deployed first?

Thank you

Hi guys,

I want to transfer a 16 bit UINT from a PLC Siemens S7 to Robot. I grouped a 16 bit signal in Profinet tab in WorkVisual 4.0

Example I want to transfer the following number:

PLC: 0x12 0x34

On Robot smartpad I see:

ROBOT: 0x34 0x12

I tried to swap the two bytes in WorkVisual but it didn't work but it works if I swap bytes in PLC...

For those who might be interested, I received from Kuka indications for how to stop the main application from a background task. The code is the following:

if (pnio.getTask_Stop()){
try {
getTaskManager().getTask(RobotApplication.class).stopAllInstances();
} catch (InterruptedException e) {
e.printStackTrace();
}
}

Hello,

did you try to activate external control from sunrise settings?

Hi guys,

I activated external control to start an application from a PLC (via Profinet) by means of app_Start and app_Enable signals.

If app_Enable turns low application is stopped. Now, I can only "resume" the application. Instead, what I want to do is to "restart" the application from beginning; in other words I want to move the pointer back to the first line of application and then, start it again.

Is it possible to do that from Sunrise external control?

Alternatively, I'm searching for some RoboticsAPIApplication class method to abort/select/start an application but with no results so far.

Many Thanks
Fabrizio