Laser mode for spindle commands

[troisiemetype]

Hello,

I'm opening this new issue to complete thinkings about issue #114.
As I said there, I am about to buy a small (20x30cm) CO2 laser cutter, that will be the first step before to craft a bigger one (about 1x1m). I would like to use TinyG, as I know it handles Gcode well and the movement is smooth. And, above all, it so easy to setup that I even don't want to try anything else!

The only problem is, as said in the other issue, the move stops and go at each spindle change (M3, M4, M5, and S new values). So I wonder what could be done in the code.
I figured that the move_type should be changed to MOVE_TYPE_SPINDLE_SPEED as it already exists in the planner.h typedef.

So I've created a laser mode ($lasm) in the config table, that can be 0 (normal behavior) or 1 (intended behavior: don't stop move at spindle changes). This setting is accessible throught the cm singleton. (and the print function has been added to canonical_machine.c, which I suppose was the right place for it)

I've then duplicate the mp_queue_command() to a new mp_queue_spindle() that is called by cm_set_spindle_speed() and cm_spindle_control(), and do exactly the same, but sets the move_type as MOVE_TYPE_SPINDLE_SPEED instead of MOVE_TYPE_COMMAND if laser_mode is enable.
It also sets the move as replannable (=true), and gives arbitrary high values to entry_vmax, cruise_vmax and exit_vmax (took from the $xfr for now, instead of better), so the plan_line.c / _plan_block_list() could handle as if it where a "zero move".

I've also changed the stepper.c / _load_move() so it can handle the MOVE_TYPE_SPINDLE_SPEED, and added a st_prep_spindle(). I supposed it was not really necessary since it does the same as the st_prep_command(), except for the move_type.

Now I suppose that mp_queue_spindle should call plan_line.c / _plan_block_list(), but I can't test it (neither debug it) (I can't unmount the tinyG that is mounted on my router, I use it quite every day) and I'm not sure it would be sufficient for this function to be ok. But as this is a static function, I wonder if cm_spindle_speed() shouldn't be place in plan_line.c t stay coherent with what already exists. I also wonder if "lying" on the vmax and velocities of the block wont crash some functions, like mp_calculate_trapezoid(), mp_get_target_lenght() and mp_get_target velocity().

I also have a question: as TinyG v9 is in development, is it a good idea to work on this part of the code, or is it wasted time? (well, it's never really wasted time, as I have understood improtants concepts, but kinda). I don't know the G2 code yet, but should I preferably work on this part? Maybe this option is already implemented, totally or partially? Plus, as I'll only deal with X and Y axes (and maybe Z, latter) en the laser cutter, Gshield would probably be sufficient.

I've forked the master repository so the few I've been writing is visible at https://github.com/troisiemetype/TinyG/tree/laser-mode.

Thank you for the advices you can give about that. And sorry if I go trough open doors, as maybe I do without even seeing it!

Pierre-Loup.

[jtronics]

Hello Pierre-Loup,
do you get the M and S comands work?
Thanks martin

[troisiemetype]

Hi,

What do ou mean by getting M and S to work? They do work, but I've been lost tryng to implement this laser mode: how I understand it to be done is one thing, really doing it is another. There's to many calls to functions to deal with, that plan or retrospectively plan movement...
So I just use it as it is: I've set up a high jerk (10000), and as my gantry is light, it works...

Hope it answers your question!

[jtronics]

yes, that was my question.
I hoped, that you get the laser-mode working.
I also tried to change the firmware, but I didn't get it work.