Sorry it's CTRL+V instead of CTRL+P
Posts by Motouser
-
-
BTW:
I did forward and inverse kinematics of kuka robots
JUST AN INFO(OFF TOPIC):
You mean that you are an official KUKA programmer that programmes THE Kinematics Algorithm inside the KUKA robot or I simply misinterpreted.
-
Thank you for your options,
Can you give me example for option 1 that you said?
About option 2, are you sure there are function parameter for infinite rotation? Because i didn't listen about it.
Yes it exists, but involves some parameter that need the Yaskawa assistance.
Basically the MRESET is done automatically.
But if I remember remain a limit: you can go to a max value of 999999999 after that it's possible that could rise an alarm like 1656(AXIS ENDELESS INFO NOT GENERATED) or the controller will stop briefly to do a real MRESET.
-
This is how to attach an image:
1. Do a copy of your image(CTRL+C)
2. Do a paste in your message(CRTL+P)
Then will appear under Attachments this box
3. Select Insert All
-
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:
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
.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.
-