stefanix / lasaurgrbl Goto Github PK

Symptoms: gcode lines get dropped or scrambled leading to flattened curves and spikes in the cuts.

Suspicion: serial flow control and/or transmission buffers drop characters leading to lines being disregarded or inadvertenly changed

suspicion that some of the jitter at high speeds comes actually from stepping inaccuracies of the bresham algorithm. Increasing the temporal resolution may improve this. But this has to be tested well as we might hit performance or rounding issues.

While the command does work it shows some strange behavior regarding its arguments. For example "M112X0Y0F10000" should stop any processing and move to 0,0 at F10000.

It seems to move it to 0,0 plus an offset and at whatever speed was current.

execute a M9 if air/gas still on after end of gcode program

Currently G92 sets a new origin/home which also mean that the machine forgets the physical home position. Instead G92 should keep track of the offset so that the origin can quickly be reverted to the physical home position. (grbl 0.8 seems to be already doing this)

We need:

• set current location as origin
• reset origin to home

After a new origin is set it's quite likely the machine may hit a limit (if sent an out of bound gcode program). In this case the reset origin to home should still be possible.

Currently the firmware uses the nominal laser intensity (whatever is set with the S-code) for all motion. This is kind of like assuming the the 'saur always moves at the requested feedrate. Due to acceleration and deceleration lasing speed can be much slower than requested and laser intensity should be adjusted proportionally to the actual speed.

M3, M4, M5 sets gc.laser_enable but nothing happens with this variable. Also on laser_init the laser is disabled, meaning the bin is not grounded (need to double check). See laser_contol.c

WORK AROUND is to simple wire the enable/disable wire to ground.

this would be useful for debugging

When I try to compile this files using flash.py:

In file included from stepper.c:45:0:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h: In function ‘homing_cycle.clone.0’:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h:230:28: error: __builtin_avr_delay_cycles expects an integer constant.

avr-gcc: stepper.o: No such file or directory
avr-objcopy: 'main.elf': No such file
avr-size: '.hex': No such file
avr-size: '.elf': No such file

very often the machine refuses to process because the safety system kicks in. Give better feedback why the machine is in pause or stop mode (e.g: door open, chiller off, e-stop pressed, limit hit).

This is necessary for example for controlling air/gas assist.

See list thread: https://groups.google.com/d/msg/lasersaur/m4eivJrvJWU/6NxwFyjGgtkJ

typically at above 3000mm/min

hi@stefanix , have you or any guys tried to use Marlin instead of GRBL firmware? does your open source laser machine support auto focus laser head or THC for plasma machine
any reply appreciated

The processing of many short lines is much lower with the new acceleration code in the norcham branch. Typically circle with 3mm diameter at 0.2mm tolerance do not cut faster than 600mm/min (flow starts to choke).

simplify
block->nominal_speed = feed_rate
in planner_line

get rid of:
double inverse_minute

will have to test if this is problematic when usb is connected before the machine is turned on.

The PWM does not stop when paused. Safety-wise this is not an issue because the laser disable pin triggers.

See this thread: https://groups.google.com/d/msg/lasersaur/bJ2l5-dlsJo/ATC1Rfqnfu8J

Have the machine send continously send a ready ping this way the "cancel" and "send to lasersaur" buttons can go into a deactivated state until the machine sends a ready signal.

Hey guys, I'd like to use my arduino for milling (which I already do with GRBL) and at the same time to laserplot (to engrave wood or exposure photosentitive PCBs). I wonder if GRBL/Lasaur would be suitable for that?

Under 15degC the laser appears to take a bit to gain full power. Add a gcode or gcode program that puts the laser in pre-ionization state.

A better behavior would be to keep the gantry running and have the hard-logic safety system take care of disabling the laser (which it already does). This way the gantry can be tested without circumventing the chiller interlock.

A warning should be propagated to the LasaurApp interface.