Tool Offset issue with RTCP on KFLOP 5 Axis
I have retrofitted a Thermwood C67 5 axis router with a KFLOP controller as it had a dead controller (we have two other 3 axis machines that I've already got running on KFLOP).
I'm having some issues getting the RTCP coordinated motion happening. I've followed a couple of the other threads on here to create my own Gimbal Kinematics code using axis C and B in their traditional locations, and have it all working as expected/desired up until the point of having a tool offset.
It appears the code that takes the tool offset from the tool table into the TCP calcs is reading it in inches, even though the units are set to mm, and the effect on the Z coordinate is in mm.
With a 0 length tool, the TCP rotates about the collet face as set by the offset in my CKinematics5AxisGimbalCB code.
However when I set a tool length in the tool table and do an G43 H# to call an offset of say 40mm, the TCP that the machine wants to rotate around is well under the bed (I'm assuming 40 inches away), and when i give a value in the tool table in inches 1.57" to give 40mm, the TCP rotates around the tip of the 40mm tool..... sort of.
It seems that at this point the KFLOP gets a bit confused as the offset applied to the Z position is only 1.57mm, and it's trying to rationalise rotating around a point 1.57 inches away to maintain this XYZ coordinate in mm, so the point drifts somewhat and we get some weird jerky movements. I haven't actually tried setting the interface in inches and trying again yet, i'm not at the machine, and everything is posted in mm, so didn't really think of it when I was in front of it.
Is my thinking correct? If so, is there a way to convert the tool offset into mm in the code, or do I need to make an inches post and run in inches for a while?
Also, when running 0 length tool, code runs fine, and jogging slowly works fairly smoothly, but rapid jogs about B in particular result in a some strange movements with the X Y and Z axes moving at different rates and jumping around, i'm assuming this is due to the different nature of calculating the motion when jogging compared to running code?
I will upload some videos, and my code in a little while if that helps too. (currently stored on my laptop, not the desktop i'm writing this on :( )
Oh, and i'm now running v4.34j.
Thanks in advance for any help!
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Here is some video of the machine running some GCODE, with a 0 length tool:
https://youtu.be/dtwHPo6TITw
Here is some video of the strange jogging motion:
https://youtu.be/auQWLkBmV-U
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Hi MattBlight,
Could you please try to replace the function below in the file \GCodeInterpreter\canon_stand_alone.cpp to see if it fixes the issue with the metric tool length? The conversion to Inches has been added. Then re-build the Libraries. I assume you are able to do this as you have successfully changed the Kinematics.
Could you share your Kinematics file?
I expect the weird Jogging is caused by a large missmatch in the Jerks and accelerations between the B and Y/Z axis. Please post your initialization file and the Trajectory Planner settings. When Jogging the velocities of all the actuators are calculated and commanded in order to move in the appropriate manner. But if one actuator (B) moves quickly at that velocity and the other actuator (Y/Z) takes a long time to get up to velocity then the direction moved is incorrect.
Regards
Code:
void USE_TOOL_LENGTH_OFFSET(double length_units, double xoffset_units, double yoffset_units)
{
double Acts[MAX_ACTUATORS];
PRINT1("USE_TOOL_LENGTH_OFFSET(%.4f)\n", length_units);
double xoffset = GC->UserUnitsToInchesX(xoffset_units);
double yoffset = GC->UserUnitsToInches(yoffset_units);
double length = GC->UserUnitsToInches(length_units);
// Things get complicated if Tool Center point changes on-the-fly
// for non-linear Kineamtics. So if tool offset changes Flush
// KFLOP buffer before changes. For optimization
// only flush when some offset changed and TCP is used
if (CM->m_TCP_affects_actuators &&
(CM->GetMotionParams()->TCP_X != xoffset ||
CM->GetMotionParams()->TCP_Y != yoffset ||
CM->GetMotionParams()->TCP_Z != length))
{
if (CM->FlushSegments()) { CM->SetAbort(); return; }
if (CM->WaitForSegmentsFinished(TRUE)) { CM->SetAbort(); return; }
CM->Kinematics->TransformCADtoActuators(CM->current_x, CM->current_y, CM->current_z, CM->current_a, CM->current_b, CM->current_c, CM->current_u, CM->current_v, Acts);
CM->GetMotionParams()->TCP_X = xoffset;
CM->GetMotionParams()->TCP_Y = yoffset;
CM->GetMotionParams()->TCP_Z = length;
CM->Kinematics->TransformActuatorstoCAD(Acts, &CM->current_x, &CM->current_y, &CM->current_z, &CM->current_a, &CM->current_b, &CM->current_c, &CM->current_u, &CM->current_v);
GC->ConvertAbsoluteToInterpreterCoord(CM->current_x, CM->current_y, CM->current_z, CM->current_a, CM->current_b, CM->current_c, CM->current_u, CM->current_v,
&_setup.current_x, &_setup.current_y, &_setup.current_z, &_setup.AA_current, &_setup.BB_current, &_setup.CC_current, &_setup.UU_current, &_setup.VV_current, &_setup);
}
}
4 Attachment(s)
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Hi Tom,
Thanks so much for the quick response. Your code worked nicely. It did some weird stuff when I initially opened it though, the interface switched to inches but was showing the coords as if it was in mm, then when i switched it to mm, the numbers doubled, by what appeared to be my work offset G54 coords. I fixed it by deleting my work offset values, and resetting the units, and re-homing i think... after that it worked perfectly.
I've attached my Kinematics files, I just took your GimbalAB file, removed the axis reassignment for the non-standard axis names, and made it point to B and C.
I was able to successfully do some test machining in some poly-styrene today with excellent results. I'll upload some videos in a minute.
I've also attached a screenshot of my trajectory planner and the init code, my speeds and accels have been adjusted so that I had smooth stops and changes of direction when PID tuning using the step-response dialogue in kmotion. I've got the Jerk set as high as possible as I was under the impression that the trajectory planner operates with infinite jerk, so wanted the PIDs etc to work best in that situation. Is that a good approach? The accels and PID's still need a little work, but they're good enough to get me going for the moment. Any advice here would be greatly appreciated too! I also found with this machine that it runs smoother when i make the tolerance extremely fine, much finer and I get a buffer under-run, it seems good where it is now though.
Cheers,
Matt
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Hi Tom,
Also, just wondering whether it would be possible for you to implement a jog along tool axis (if it hasn't already been done?) ? As it would be handy to pull out of a hole that's being cut on an angle if it needs to be stopped for example.
Cheers,
Matt
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Hi Matt,
Just wanted to update that we haven't forgot about this. It turns out to be more difficult than expected :)
Regards
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Do the forward and reverse buttons that appear when you hit feedhold in kmotion cnc work for 5 axis? If they do you should be able to hold reverse and the machine should follow the correct path back out of the part. When you have rewound to a safe place you can reset and jog from there.
Ben
Sent from my HTC6525LVW using Tapatalk
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
The difficult thing is with the Jogging. Difficult because jogging speed and direction can change unexpectedly, combined with the nonlinear and varying relationships between the axes caused by the RTCP, and with the axes having different response rates.
Another way I was thinking of to pull out an endmill would be to just calculate an XYZ point that would pull straight out say 1 inch based on the B C Angles. It should be simple trigonometry given the B C angles. It should be possible with pure GCode given the B and C angles. But I don't think there is currently a method in GCode to get the current Axis Positions. It seems like that would be something nice to have anyway. It should be easy to add as functions such as CurrrentX(), CurrentY, CurrentZ, CurrentA, CurrentB, CurrentC, CurrentU, CurrentV. Maybe two sets one for Machine Coordinates and one for GCode/DRO Coordinates. With the addition of those it should be possible to create a User Button to pull straight out the endmill. I suppose that could be done with a C Program right now,
Regards
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Hi everyone!
I also have a problem with tcp with floating tool point while jogging and g1 code. Have Gimble BC cinematics.
The tool point is floating about 1,5mm.
Did someone find the issue?
Please, help. I try to set different axis settings...
Have a nice day, thanks..
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Hello . We assembled the machine and launched RTCP in KmotionCnc made automatic tool measurement everything works but there is one thing but when moving from corner to corner of the rotary axis in RTCP mode G1B90F500 , the position of the instrument tip floats within 1-2 mm. With what it can be connected ?
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
check movement of the machine axes involved. Depending on control method, the issue occurs when the difference of synchronous feed amount is approaching infinity. For instance: machine X axis amount 0,0001mm/s in sinchronisation with machine Z axis 1000mm/s and the total distance is 10mm.
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
We do have issues with bad motions when Jogging fast with nonlinear kinematcs but G1 coordinated motion should be "perfect".
What do you mean "floating"? Possibilities I can think of is either one or more axes is not following its command properly or the Kinematics isn't calibrated properly. That is some parameter such as point of rotation, axis of rotation, perpendicularity of axes, chuck length, tool length, etc could be slightly incorrect. To find which is the case perform a feed hold at some point where the tool tip is off position. Does it remain off? If so, then check in KMotion.exe | Axis Screen | Position and Destinations for any errors. If there are no errors something must be wrong in the Kinematics.
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Hello!
Thank for your quick reply!
Here the link to the vid. Today we will try to correct parameters and check the point position.
Also, please see at the screenshot.
Sorry for bad quality of video(
https://youtu.be/Rhq1lOIfkFQ
https://youtu.be/d8H77a1FzKg
1 Attachment(s)
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Your video reveals that the test method is not sustainable.
The ( table ) level should be monitored with two ( at least ) machinetool water levelsAttachment 466500.
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
Hello. Algirdas you are right the sensor with an error, but it doesn't matter to us. Here is a video that clearly shows the problem.
https://www.youtube.com/watch?v=DDMA...Cvln0096q-hTCJ
1 Attachment(s)
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
1 Attachment(s)
Re: Tool Offset issue with RTCP on KFLOP 5 Axis
