linuxcnc trajectory planner

awesome to see this active again!! glad you are ok and back at it 

@Lcvette,

Thank you for your kind words !.

Had a weird experience. The scene was as follows.
1. Run linuxcnc with the "linuxcnc" splash gcode. Added G64 P1 to the top of gcode file. Then i pressed run.
2. Ok machine run's the file. In the background the traject optimizer was busy and a few moments later was ready.
3. Then load the produced file : ~/cmake/ "validate.ngc". into linuxcnc.
4. The gcode preview shows that "arcs" where converted to "lines". So how is this possible. Did i made a typo in the code?
5. Then i was reading online :

link
when the maximum deviation of an arc from a straight line is less than the G64 Q- tolerance, the arc is broken into two lines (from start of arc to midpoint, and from midpoint to end).

Conclusion for the test environment :
The interpreter had transformed the G2 & G3's into G1's. And the optimizer was then reading this false information.
So now to avoid this mismatch the files to blend are loaded with a empty G64 P, Q value, ensuring a valid input to the optimizer.

Then inside the optimizer the G64 P & Q values are set for now.

Ok, Then finally :

 

 

The vertical lines are for testing. It are spline control points. I had to visualize them to track the previous error.
Ok for now this is looking better.

nice! yeah not sure how to get around linuxcnc applying the G64 rules pre optimizer. may need something edited during initial load?

Hi Lcvette,

I didn't know linuxcnc would do this. When coding and testing i got my head scratched and thought : alien obstruction

not sure how to get around linuxcnc applying the G64 rules pre optimizer
Yes, indeed. We are screwed.

Tested this in top off a linuxcnc gcode file :
G64 P10 Motion blending tolerance
G61 Exact Path Mode
This then resolves the issue.

Wich means this is not applied :
when the maximum deviation of an arc from a straight line is less than the G64 Q- tolerance, the arc is broken into two lines (from start of arc to midpoint, and from midpoint to end).

Another error i was getting:
"same Y word..".
Cause, when running the "validation.ngc" file, when start is pressed, the file overwrites itself.
To avoid this, the filename now get a random number attached.

In the mean time, we learned a lot today.
 




 

i have also noticed on my fanuc , mitsubishi machiens it seems when in a probe move there is no smoothing on any axis motion, its a much harder point to point move you can hear the differance on the machine axis when making prob moves onto a surface.
so dont think that the main stream controls use motion smoothing on probe moves as it seems they do not, when you are probiing it tends to not be that fast also, aprox 1000mm/min feed is common.
for the reasons mentioned before. as probining its key you always have a known probe detection trigger distance etc as this is what you calibrate a probe cycle for..

also
dont for get threading on lathes (G33 and g76) is another one you will skip for smoothing as it must follow the spindle encoder like tapping.

At least for Fanuc, smoothing should be applied to probing moves, it not being applied means that the MTB didn't set the 6200 parameters as they should have and trapezoidal acceleration/deceleration is applied to skip moves vs bell curve acceleration/deceleration.

Hi Rob,

But probing is just a straight line feed that triggers a sensor event? How is this related to smoothing?

Attached a validation gcode file. You could test this in linuxcnc. It's result of a G64 P20 Q0.
To visualize this, the fillets are drawn as G1 linestrip.

This was hard work, because what you see is a filletized path using clothoids.
To use them in 3d space, i had to add logic to project 3d planes to xy planes and back to do the clothoid calculations.

At one point in the original gcode file it sees a transition from arc on xy plane to a line that goes z up.
This is a situation where segments points are not all in the same plane.
This situation is then reverted to use a bspline.

So far no tiny segments are filtered out.

For the source code, Clothoids-1 is added. This cmakelists file has to be reviewed as it is quite a mess now.

The clothoids lib integration was quite a lot off alien obstruction. But at least is works now !

repository

 

 

Just cloned your repo and tried to build linuxcnc. I get this error:

Hmm, ok.
Do you have the Eigen lib? : sudo apt-get install libeigen3-dev

In the next upload, there will be a check in the cmakelists for that.

So installing the clothoids-1 is for now a manual task. So it's annoying i know. I feel with you.
You can build the clothoids-1 in their own dir using a build dir. Then you can do a system wide: sudo make install.
Or copy the files over into the rtlib. Preferr to build the clothoids before the motion and planner.
I know this has to be changed soon.

Good luck. When spot install problems, let me know.

In the mean time i did some tests.
This are situations where the G64 P20 Q0 is used. Extreme situations to verify the blend algoritme for robustness.
Will show now a few pictures sets. Each set is before blending, and after blending with radius 20mm.
This are files using low dimensions so 20mm is just a incredible high value.

before:
 
after:
 

Here you can see the interpreter has given around 20.000 gcode lines. Not the entire file.
Therefore you see the buffered output is filletized as a result. When this then is machined, the next
load will occur.

before:
 
after:
 

before:
 
after:
 

 

Ok, installing 'libeigen3-dev' solved that error.

So this next error would come from not having compiled/installed the 'clothoids-1'?