Posts by Motouser


    your job contains special variable $PX and special instruction MOVL + UNTIL + CAPTURE.

    The idea of simply copy a "normal" job from a robot to another (speacially a 7 payload to a 25!!!) is not a very good idea, coping a job like that will be even more risky.

    The IO setting are the same?

    The P var are setted in the same way?

    What about the tool( I see a tool 0)?

    I can continue....

    At the least the two robots have the same controller?

    Thanks for the the moment the speed decreasing and the "PL removal" solve the problem.

    But of course I suspect (as 95Devils said) a cable problem.

    Hi guys,

    this morning a MH225II+DX200 started to fault in a very specific position with alarm 1613[SLURBT] and alarm 1614[0]. It happens randomly but only in this position and the program is a very old one...continuosly working from the dawn of time(about 5 years ago) with no problem.

    The movement involving the S and T axis but the alarms rise for all axes.

    I slow the speed and remove the PL=0 tag....will let you know if it works.......but any other suggestion will be appreciated.


    if I understand right:

    So if you don't have system job, you can still do something with the ladder. In the ladder you can

    set the value of a register(example):

    STR #50076

    MOV 1,M000

    Will move 1 to your register when sout#55 will be on and the REGISTER m000 can be used in a job.

    Now you don't explain how the macro would work so I don't know if you could still "program" your idea without system job.

    It will work as you intend :top:

    Not that I'm experienced with CAM stuff, but you should see Z element variations in the TRANS command, which relates to TCP position relative to base/frame/workpiece.

    As you maybe remeber, my first kawasaki test project was about a certain strange application. Then I move to another one and keep this project aside.

    Unfortunately I don't have a real robot free to test, I can simply simulate it in my CAM environment....but try to understand me....I prefer the real world. :icon_mrgreen:

    Poor @Marco Antonio Asselta I'm messing all his post :away:

    - if the tool coordinate is longer than the physical tool, then the physical TCP will be further from target.

    - if the tool coordinate is shorter than the physical tool, then the physical TCP will be closer to target.

    I was editing my old comment while you are answering:

    that's why it will maybe work, I'm just fooling the real/physical tool.

    In CAM, there are numerous ways that motions can be expressed and they do shoot for TRANS instructions and any approach/depart motions should include a Z element change in the TRANS coordinates, which may look like a SHIFT, but it is not applied relative to BASE, but the TCP position instead, so as I was saying earlier, if the Z base and Z tool axis are parallel, it will 'appear' like it's shifted (SHIFT is relative to BASE), but actually it is along the Z axis of the TCP.

    It's exactly what I need...the post is indeed about a SHIFT in BASE..but I'm more interested in a shift in TOOL coordinates

    So no SHIFT.

    Make sense?

    Unfortunately make sense!

    The thing that confuse me is the existence(in motoman language) of an instruction called SETTOOL: here you can redefine the tool calibration without doing a calibration (like tha AS tool instruction). It's used to recover a program after a crash/deformation of the TCP.

    I use it in particular way: I redefine the lenght of the tcp for a milling process so the tool of program remain the same but if I use another drill I simply adjust the lenght.

    So in the end: in the case of CAM-generated program we must get back on the computer and recreate it with the right measurement.

    I'm very curious about the case of CAM generated program you 'll have a thousands of line made by thousands lmove, example:

    .PROGRAM test()
    BASE uframe1
    TOOL t1
    LMOVE TRANS(....)
    LMOVE TRANS(....)

    In this case the SHIFT approach is useless, what about a new TOOL definition in the middle of program?

    In the begin I have a Tool t1 defined as


    t1 0.0 0.0 100.0 0.0 0.0 0.0


    If I change the definition in tool 0.0 0.0 99.0 0.0 0.0 0.0 will I have a shift in z direction?

    My Coworker seems to be under the impression that this integrator may be trying to dump the backups from our DX100 controller into a non-DX100 controller hence the disparity in file type the integrator is encountering. Does this make sense or is my coworker mistaken and simply didn't provide the correct backup or doesn't know how to generate a CMOS backup

    In some occasions the CMOS backup(maintenance mode) is the only solution to recover a robot from certain error, so I do it regularly or after big change in the software.

    And of course when a new robot arrives is the first thing that I do CMOS backup plus a normal backup of all other struff.

    I always recommend a CMOS backup in maintenance mode.

    I'm asking because we made a few long programs using CAM function on MOTOSIM and when I convert them in relative job (UFRAME), the trajectories are all messed up, even though my uframe is fine.


    so you create a CAM in motosim in which frame and with what number tool?

    Then you convert your job where: in Motosim or in the robot DX100, again using what tool and what frame.

    I use another CAD/CAM simulator, in this environment I have a frame equal to the one on the ROBOT. Then I generate the jbi file that is a relative job. This relative job MUST have the correct user frame but also the correct tool number. So you need a user frame created correctly and a tool calibrated properly.

    The parameter for Euler Angles is turned on with the MultiLayer Function.

    Different purchased options will give the user additional coordinate systems such as Synchronous Jogging for Coordinated Motion, External TCP for External Reference Point, etc.

    Last time I tried you could not use Cylindrical Jogging on the system. The tcp is defined as XYZ abc.

    In the end what is purchased is the MultiLayer Function that is used generally in welding application.

    I confuse that euler angles with the cylindrical /cartesian coordinates system.

    We originally purchased Euler Coordinates which I never really understood why.

    Euler also had compatibility issues with Dynamic Frame so we had to take Euler off the system which honestly didn't hurt my feelings. This is the way it should have been from the beginning.


    just for curiosity.

    Could you elaborate a little bit the phrase "we original purchased Euler Coodinates".

    What do you mean: we can choose/purchase coordinates system? what is Euler coordinates in you robot?

    Is possible that you are referring to the parameter that switch the cartesian coordinate system with the polar system?

    However, I'm reasonably certain that modern Kawsakis run in Right Hand Rule -- however, I haven't touched a Kawasaki in... 15 years? RDK appears to agree with me, and a very quick-and-dirty test after I downloaded the Lite version of K-ROSET also seems to run RHR, although I haven't figured out how to choose specific controller generations in K-ROSET.

    Despite the previous post that I've deleted, I can confirm that Kawasaki robot (at least buyed in the 2020) are RHR and with the base frame rotated 90° so the Y+ is forward and X+ is on the right.

    About the last I knew this weird, but about the RHR :icon_eek: what a surprise. I use yaskawa that are LHR.

    Thank you very much! I seem to understand much more. I just want to ask a final question in regards to the CASE. How would the user choose which CASE to run? Would they simply write a numerical value in the integer variable?

    Yes you can do it ( the way I use involves the Interface Panel, but this is another argument).


    I would definitely love to share my program but I'm not exactly sure how; should I just type out what I have?

    Use attachments under your message box.

    1) No. The only instruction( that I know) that you can link to another variable is the IF statement.

    IF Ixxx=Iyyy


    do something..

    ELSEIF Ixxx=Izzz


    do something


    2) Yes. This is the reason I write on top: if you have a small number of batch

    3) So you have a dynamic change of the FOR's start counter : in that case Using IF..ELSEIF or SWITCH..CASE will partially solve your problem, because the FOR remain unlinkable to a variable.

    If you can share the program, maybe me or someone on the forum could have a look and gives you a solution. At this point I'm quite sure that you don't need a FOR.. LOOP but something else like an incremental variable with at least an IF statement with 60 statements.

    I don't know other options.

    Keep in mind that the procedure of loading a different system section part is a little bit complicated than simply loading the CIO. I don't post it here (even if is easy to find in the manual) because it is not a safe operation modifying the system ladder part.

    However as I said in the previous posts I know that is only available from DX100 or newer.

    My hope was that in the older controller a simply offline editing should have solved your problem, but it doesn't work.