Feature Request: Trajectory Planner

[petervanderwalt]

Hi Nikolay!

First off, GREAT project, and big ups for pushing the envelope when others say "it cant be done" and "you need realtime" - i have immense respect for your attitude to prove them wrong (;

Secondly, I have a Pi3 hooked up to a testbench (DQ542MA drivers and motors on the bench, with a custom cable to quickly swop between PyCNC wiring and Grbl to run some comparative evaluations (:

I have configured the instance of Grbl to be the same as the default config shipped with PyCNC (since i assume the config you have here on git is reasonably optimal already - i figured best to compare apples to apples by changing Grbl to match, thus not messing with your proven settings.

I did have to adjust table_size to match the gcode as one of the files has some moves over 200mm...

I am also running Pypy as per your readme.

pi@raspberrypi:~/PyCNC $ pypy -V
Python 2.7.13 (1aa2d8e03cdf, Mar 31 2017, 10:21:21)
[PyPy 5.7.1 with GCC 4.7.2 20120731 (prerelease)]

On long moves, things are working stellar! No complaints. But I am attaching two sample GCODE files - where I can hear the motors vibrating quite a lot when ran through PyCNC, but runs smooth when run through Grbl.

My assumption is that since Grbl has a move planner it handles the short moves, as long as the serial can keep up (; - but since PyCNC is a new concept to me (mind blown) I am not sure why it can't keep up.

I did repeat my batch of experiments with INSTANT_RUN = False too, same result

Hope this helps you debug it (or figure out that I'm doing something wrong lol)

ZIP of two sample gcodes testgcode.zip

[Nikolay-Kha]

Hi,
Have you set up correct acceleration for your machine in config file? STEPPER_MAX_ACCELERATION_MM_PER_S2 variable. If you don't know this value for your machine just try to decrease it from 3000 mm per square second to some lower value, i.e. 2000, 1000 or 500.
GCode slicer from 3D printer also generates such short moves and it works fine on my hardware.

The reason why grbl behaves normally with the same parameters is definitely a planner. Actually planner is not just a collector of gcode commands, it also put them in trajectory to avoid full stops between commands when it is possible. PyCNC doesn't have planner and it brakes down motors between commands to zero instant speed and then accelerate again. Such stops between commands might create vibrations in some combinations of hardware/acceleration/speed. So try to change acceleration, it should remove vibration with some value, but lower acceleration would make machine slower.
Probably planner would be nice thing to do in future...

[petervanderwalt]

"correct acceleration" is mostly irrelevant for the purpose of my testing to evaluate it scientifically, pushed to the max (low accelerarations sadly isnt a valid way out anymore - the world wants speed, and for certain jobs like laser raster, and trochoidal milling you simply cant go without smooth trajectory). Which is why I am running it as a bench-test (ie standalone motors, not on a machine: being not installed on a machine, I dont have to factor in carriage enertia, loading, and acceleration.

I was spot on with my suspicion though (; - PyCNC doesnt have a planner - which exactly explains the symptoms I saw (;

So, what would it take to get a proper planner integrated? (I am seriously looking at PyCNC as a replacement for Grbl/Smoothieware. Smoothieware already chokes up with Lasers (short raster moves) even on its 120Mhz 32bit mcu... so we are really pushing the ceiling on what can be done with MCUs as is. Your novel approach made me hopeful ) (;
Considering that even Grbl is working on S-Curve planner, Smoothieware already has some S-Curve work in the queue, and TinyG has supported S-Curve for many months now - would it be possible to consider S-Curve? If not i'd be happy with regular planner already (coding that is sadly outside my skillset)

[Nikolay-Kha]

That is just a matter of time. I'm not sure when I have enough to do this. May be someone wants to contribute such planner.

[petervanderwalt]

Hoping that's soon (:

[petervanderwalt]

(: Just checking in if you forsee any spare time in your near future yet (:
Really looking forward (:

[Nikolay-Kha]

I don't know. May be on New Years Eve holidays. Maybe early, maybe later. Sorry, I really don't know.

[petervanderwalt]

Awesome! Will sit back till then (;

…

On Fri, Oct 20, 2017 at 2:10 AM, Nikolay Khabarov ***@***.***> wrote: I don't know. May be on New Years Eve holidays. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ad_gtxNHkoEst5sJm09LnISfWcoqjLQJks5st-T3gaJpZM4PJPN1> .

[petervanderwalt]

(: Just doing my check-in at 262 days (Or 8 months, 19 days hehe) since I last checked (:
Any chance we have basic acceleration yet?