Joint speed tracking - motion in danger

hello gentelmen,

Does somebody have time to help me tested some behaviour of the actual trajectory planner(trapeziodal)? maybe there is bug in the TP and I need more independent observations ... 

Its just regular simulation setup with some precise steps to replicate ... the post the picture of the watched scope please

I need help from you please...

If you are ready, create axis.ini sim OR sim axis_mm.ini trivkins simulation UI ... then

• Start Lcnc
• Enable
• home all
• hal scope
• observation time as long as possible but period is fine 40ms
• add joint.0.vel-cmd.. scale 20
• add joint.1.vel-cmd.. scale 20
• split them to they own space
• Load Gcode program(from attachements but watched behaviour is present everywhere)
• hit play button alias program run
• observations the spline created by gcode (nice smooth steady - the first one)
• wait program end OR stop program by program stop/stop radio button
• break point 1(only for repeat command)
• return home G28 or rehome everything
• I press start button again at same code no change, no position change nothing just return to row 1 of gcode
• start program with play radio button
• observations the spline created by gcode (clingy - every other)
• wait program end OR stop program by program stop/stop radio button
• go to breakpoint 1(only for repeat command)

Please paste your scopes ... I hope your velocity splines will be exact same at rerun the gcode!!!

My scope is at rerun different each time ... 

many thanks


 

I have been of the opinion that the current default motion planner has never been completely bug free since the circular arc blending/multi line look ahead was added back in version 2.7. I have often observed quirky behavior for series of moves similar to those you have posted. But the "new" planner offers such a significant improvement in milling speed for most cad/cam generated code as to justify tolerating it's issues.

​​​​​​​But I'm not noticing any differences between runs on my machine simulation

If your concern is about the notchyness of the 2nd set of sign waves. I think your G64 settings are eating your lunch and your high tolerance setting is causing the naive cam detction (Q tolerance which defaults equal the P tolerance) to screw up your motion. Changing from G64P0.01 to G64P0.001 makes a big difference in the smoothness of 2nd set of sign waves and the motion ends up much closer to what your g-code was programmed to be.

 

In fact give this a try. Set your G64 setting to G64 P0.1 Q0.001. I think you may like the results.

Hello,

I was in touch with Luca and there was a bug in the Gcode ..  first was the tolerance(I thought I am working G21)and then was the unit system(G20) which take higher tolerance and creaty the clingy movement ... it my fault to too much truct to CAM postprocessor 

thank you for testing