Posts by IlFincoITA

    Hi! I've just discovered that in WorkVisual Editor typing F9 it adds a sort of bookmark. Since I didn't see any documentation about that I want to know if it is really a bookmark...

    There is also another thing that boders me. In KSS 8.5.7 HF1 I always find a line at the beginning of .DAT files and it is like:

    ;DECL MODULEPARAM_T LAST_TP_PARAMS={PARAMS[] "Kuka.VelocityFieldEnabled=True; Kuka.ColDetectFieldEnabled=True; Kuka.MovementParameterFieldEnabled=True; Kuka.IsAngleEnabled=False; Kuka.PointName=Away_Prel_TColla; Kuka.FrameData.base_no=0; Kuka.FrameData.tool_no=1; Kuka.FrameData.ipo_frame=#BASE; Kuka.isglobalpoint=False; Kuka.MoveDataPtpName=PDAT49; Kuka.MovementDataPdat.apo_mode=#CDIS; Kuka.MovementDataPdat.apo_dist=500; Kuka.MovementData.vel=1; Kuka.MovementData.acc=100; Kuka.MovementData.gear_jerk=100; Kuka.MovementData.exax_ign=0; Kuka.VelocityPtp=100; Kuka.BlendingEnabled=False; Kuka.CurrentCDSetIndex=0; Kuka.FrameData.point2=; Kuka.MoveDataName=CPDAT273; Kuka.MovementData.apo_fac=50; Kuka.MovementData.apo_dist=500; Kuka.MovementData.axis_acc=100; Kuka.MovementData.axis_vel=100; Kuka.MovementData.circ_typ=#BASE; Kuka.MovementData.jerk_fac=50; Kuka.MovementData.ori_typ=#VAR; Kuka.VelocityPath=1; Kuka.SplineBlockPointName=Dep_ScartoBlendeZ2_DX; Kuka.HelpPointName=P3; Kuka.MovementData.cb={AUX_PT {ORI #CONSIDER,E1 #CONSIDER,E2 #CONSIDER,E3 #CONSIDER,E4 #CONSIDER,E5 #CONSIDER,E6 #CONSIDER},TARGET_PT {ORI #INTERPOLATE,E1 #INTERPOLATE,E2 #INTERPOLATE,E3 #INTERPOLATE,E4 #INTERPOLATE,E5 #INTERPOLATE,E6 #INTERPOLATE} "}

    ;DECL MODULEPARAM_T LAST_TP_PARAMS={PARAMS[] "Kuka.SplineBlockPointName=Verso_Dosatura_Colla; Kuka.FrameData.base_no=1; Kuka.FrameData.tool_no=1; Kuka.FrameData.ipo_frame=#BASE; Kuka.FrameData.point2=; Kuka.isglobalpoint=False; Kuka.MoveDataName=CPDAT189; Kuka.MovementData.apo_fac=50; Kuka.MovementData.apo_dist=500; Kuka.MovementData.axis_acc=100; Kuka.MovementData.axis_vel=100; Kuka.MovementData.circ_typ=#BASE; Kuka.MovementData.jerk_fac=50; Kuka.MovementData.ori_typ=#VAR; Kuka.MovementData.vel=0.25; Kuka.MovementData.acc=100; Kuka.MovementData.gear_jerk=100; Kuka.MovementData.exax_ign=0; Kuka.VelocityPath=0.25; Kuka.BlendingEnabled=True; Kuka.CurrentCDSetIndex=0; Kuka.VelocityFieldEnabled=True; Kuka.ColDetectFieldEnabled=True; Kuka.MovementParameterFieldEnabled=True; Kuka.IsAngleEnabled=False; Kuka.PointName=DepCollaZona1_SX_P13; Kuka.MoveDataPtpName=PDAT39; Kuka.MovementDataPdat.apo_mode=#CDIS; Kuka.MovementDataPdat.apo_dist=500; Kuka.VelocityPtp=100 "}

    Those lines are so long that a warning always appers to remind me the max lenght of one line. It is unclear to me who is writing those lines... but this annois me so much.

    Hi! Probably I expressed myself badly. The Robot doesn't stop in P4 beacuse of an error but it ends it's movement to P4 slowing the volocity perhaps to zero then continue to P4a.

    I expected that a SLIN followed by a SPL inside a spline block was a continous movement without interruption. I've altready used this instead of approximeted LIN motion. Don't know why it is not working here.

    Hi! I have a SPLINE. The Robot is in P1. All the points have the same Z and only different X and Y.


    SLIN P4

    SPL P4a

    SPL P5

    SPL P6


    My problem is that the robot Stops in P4 .briefly then continue drawing the path in the attached picture. The ponis are not close. I tried to move P4a in different positions but without any success. I would expect a continuous movement. Where am I wrong?

    Hi! I'm programming a Robot that works with a cartesian exe. To avoid collisions I've thought that before the Robot start a movement that invades the cartesian exe it checks if the signal area free from axe is OK than wait 0.5 s and check againt that signal. The same evaluation is written into the exe's program. As soon as the robot starts it turns OFF the signal area free from robot to cartesian axe (see attached image).

    Is this a good practice for these cases? What do you usually do with your programs?

    No it's been reported to me that the HMI interface is completely useless. None of the hardware or software keys/menus works.

    Even in the picture the motor or running program are still green but the robot is actually stopped.

    Hi! It is happening some time that the robot during the normal duty stops and the program is freezed. You can't do anithing but tur it off and on again. No button seems to work. It is not clear if the controller is freezed at Windows level too ( these information are reported to me from operators). The even strange thig is that after reboot some variable doesn't retain the values memorized during the previous job. For example the variables incremented during a palletizing process.

    The only error visible (due to the freeze) is "LogManage LogNotAvailable".

    Has anyone ideas on how to try to solve this issue maybe reinstalling the entire system on a new drive...

    Hi! on my way to attend a Kawasaki course for integrators in few weeks I've just installed the K-ROSET simulator software. I've planned to use this Easter holiday to give it a shot... but here I am with this problem. I've just tried to load the RS010N Floor Handling demo.

    Has anyone some suggestion?

    Sorry... I need to explane more... let's put into this way I don't know how to calculate a point based on another shifting it's position along the X axe of a TOOL

    MyPrel_Point:{x 30,y 0, z 0, a 0, b 0, c 0} shifts it's position alog the X axe but based on the frame...

    Sorry but I can't get it. I have my paiont where I grab a piece and this point is "MyPrel_Point" I want to approach that point writing someting that arrive to that point using it's X TOOL coordinates alingment axis by an offset.

    In a LIN_REL I'll write LIN_REL {X 30} #TOOL but this point is relative to the actual position. I want to do the same thing but making a motion that is relative to "MyPrel_Point" is it possible?

    Wich is the exact message I don't know in this moment. The point is then reachable symply using another configuration. So the point is reachable. My guess was that using this statement "IF (XPrel_Pz_Nastro.A >= 140) AND (XPrel_Pz_Nastro.A < 160) THEN" I would have solved this problem the problem is that with different touched up point it doesn't work.

    OK thanks a lot. I'll try the inverse function.


    This is what I did... Shift_X, Shift_Y and Shift_A are coming from a vision system. Unfortunately I didn't thought to use the same calculus using the frame I didn't have experience before. Basically the client touch up by himself the XPrel_Pz_Orig. He has many many pieces different to handle. The not reachable point is always the PTP XOver_Prel_Pz_Nastro.

    ;fold CALCOLI

    XPrel_Pz_Nastro = XPrel_Pz_Nastro_Orig

    XPrel_Pz_Nastro.X = Shift_X

    XPrel_Pz_Nastro.Y = Shift_Y

    XPrel_Pz_Nastro.A = Shift_A


       IF (XPrel_Pz_Nastro.A >= 140) AND (XPrel_Pz_Nastro.A < 160) THEN      

    XPrel_Pz_Nastro.T = 43


    XPrel_Pz_Nastro.T = 35         


    XOver_Prel_Pz_Nastro = XPrel_Pz_Nastro

    XOver_Prel_Pz_Nastro.Z = XOver_Prel_Pz_Nastro.Z +100

    XOut_Prel_Pz_Nastro = XPrel_Pz_Nastro

    XOut_Prel_Pz_Nastro.Z = XOut_Prel_Pz_Nastro.Z +150


    Hi, it happens that I use a previously touched up point and add to this poin some calculations. Most of then are related to it's Z axe rotation. In some cases, due to this change, the robot is no longer able to reach the point with the touched up configuration. Tipically it could reach the point with a changed .S or mor aften .T parameter.

    I've partially solved this matter changind the .T parameter along with the angle required but is few cases the robot still stop sayng the point it is not reachable.

    Is there any way to handle this error and for example generate a signal to throw away this point and redo a calculation on to another one? Because I whant above all that the robot doesn't stop.

    OK I agree that KUKA safe operation is there for something like this. One could use light barriers either. My point is... let's take the case of a cartesian robot (axes robot). Since it's movements are restricted based on it's position we can assign signal that, in a non safe (for humans) eviornment, could tell us that the robot is out of a certain area. I was looking for something like this. Workspace is the closest thing out of the box. It's submission to wich tool is currently selected in a non unique way is small problem

    Hi! Here is KSS 8.3.39

    In the manual I found that flange is always included... "Cartesian workspace: The defined output is set if the TCP or flange is located inside the workspace".

    This make cartesian workspace useless... if I'm not wrong...

    I could achieve the same thing reading the current tool and cartesian position and verify if it is inside a difined area...