Hi,
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 answers...at 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.
Hi,
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
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. 
Poor @Marco Antonio Asselta I'm messing all his post 
- 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 this.....in 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(....)
.ENDIn 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
.TRANS
t1 0.0 0.0 100.0 0.0 0.0 0.0
.END
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?
So more details. My coworked had sent a cmos backup already. Our robot controller is a dx200 where the integrator is trying to dump that backup into a dx100. Sounds like thats the issue?
No comment 
WARNING: This is an ironic comment
Wow....your code is my kawasaki programming nightmare 
: AS language mixed with BLOCK language.
Have a good luck
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.
Hi,
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.
Hi,
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 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).
QuoteI 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.
Display More1) I'm not very familiar with the SWITCH CASE function so this question may sound quite simple. The I001 can be changed by going into variable and writing a specific value from 1-60 right? This would then look for the corresponding case value and run it?
2) The line SET I001 4, I understand that now it'll pick up from part 4 to 60 but what if I want to change that. For example, if I wish to do it from part x to 60, where x is any number from 1-60? (It doesn't necessarily have to be 4)
Would I have to write an individual case for each part?
3) This is a follow up from the last point but let's say it completes the first case and runs through from part 1 to 60. Does that mean it'll now start from part 4 due to the SET I001 4 lineor does it go straight to ENDSWITCH? I only want it to run another part if the user enters that in the variable.
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
ENDIF
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.
If you have a small set of "batch", a possible solution is:
*BATCH
SWITCH I001 CASE 1
FOR I000=1 TO 60
NEXT I000
SET I001 4
....
CASE 4
FOR I000=4 TO 60
NEXT I000
SET I001 1
....
ENDSWITCH
JUMP *BATCH
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.
