Simulation looks good.
In real life during one of the SMOV in the middle of the program. The robot does not have to, but it moves the robot around a lot while the turntable winds to find the next start to weld point and hits the workpiece and setup.
I am not a work right now but I think is is during the point where is shifts the angle to straight up.
Is it because of the SMOV commands? I will have to check but I do not think I have ever seen this with MOV commands.
04-11-2025, 08:42 AM (This post was last modified: 04-11-2025, 09:23 AM by Borgis1.)
I seem to not have known about some of the "features" of SMOV and the way a lay up my random start points are really messing with the robots SMOV.
I can work around this and consider this not a bug anymore.
Just because I wonder and may find a use for this. Is there a way to filter out exaggerated moves (limit by amount of pulses I decide for example) and revert to regular MOV commands.
It looks to me like the robot is trying to switch the configuration, but I could be wrong. Are you working near the ext.axis limit?
We have EXTAXES_USE_SMOVL flagin the Motoman postprocessor:
Code:
# Specify if we want synchronized motion for Linear moves:
# if True (default): Will output: SMOVL C00008 BC00008 V=166.7 +MOVJ EC00008 -> Synchronized motion (for the turntable)
# if False : Will output: MOVL C00008 BC00008 V=166.7 +MOVJ EC00008 VJ=100.00 -> Non synchronized motion (for the turntable)
EXTAXES_USE_SMOVL = False
Also, if you want to filter such movements, it is necessary to modify the MoveL and add_target_cartesian functions
Since you answered I got curious and found something
I do not shift configuration
The robot is nowhere near the limits.
I had yaskawa employee fixing my endless rotation on a couple of robots, and I calibrated them together to be able to use SMOV.
When running with pulse I had no problem up until this crash.
Fast forward a weekend with some pondering
I got in a job where I want to use user frames and I try to find the in's and out's of manually setting the customers needs for angles. Usually I go from Fusion or more often grasshopper to robodk to robot. I need a bit more advanced path layup and want to go directly from grasshopper. This works very well on some other robots. But this one robot with SMOV is NOT.
So I track the fault down to tool calibration and robodk which I use for checking / simulating my code.
Toolcalibration in machine Ry is -36.000 degrees.
The machine will bend the B joint if tool calibration Ry is 36.000, but simulation in Robodk is good.
If I set Ry -36.000 in Robodk, the simulation will bend and the machine will be good.
Could you please check if the simulated robot matches the real robot, e.g. in the zero joint positions (jt1 = j2 = ... = jt6 = 0) including the position of the torch?
Is it possible that the torch is mounted with a 180 degree rotation around the Z axis of the flange?
Or perhaps joint 6 was zeroed at a position different from the jt6 zero of the simulated robot?
