8bit engraving with a CO2 laser

... I'm using the Z-axis for "normal" moving only and do pulsing my paste-jetters and laser-engravers with the E-value (paste-jetter between 1 to 100 pulses/mm, laser-engraver up to 5000 p/mm!), so it's behaving like a normal 3D-printer without any laser-specific change in the software ... this eliminates many problems

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Thanks Viktor, I love your work on the PCBs! That's definitely on my list to try with my K40 but first I'm trying to emulate Downunder35m's work with the 8-bit engraving.

I had an earlier Marlin version running and the Z-table stuff seemed to work okay. Almost everything else seems better with the MarlinKimbra-K40 build except the Z axis is broken.

I'm trying to make the MarlinKimbra-K40 build work because as it's described, it has much finer resolution of laser power levels, making it easier to control etching. I'm also looking for compatibility with the Inkscape/Turnkey Tyranny workflow. (If there's a better Marlin version for this, please advise. I haven't been able to find one.)

It seems so close, there's just something goofy with the gcode handling and the Z-axis. The jogging from the LCD panel works but as far as I can tell, that works somewhat independently from the gcode processing.

Everything seems okay until I send real gcode, then the Z-axis returns to zero. If it makes a difference, the return to zero happens in coordination with a corresponding move on another axis. Put another way, it doesn't return to 0 first and then execute XY moves, it moves X/Y at the same time that Z is moving to 0. I'm greping for things that touch current_position[Z_AXIS] but I'm still not wrapping my head around the deep Marlin voodoo.

Thanks for any suggested direction on this!

... can you post the first 10+ lines of your G-code?

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

No specific gcode file at this point, just testing by sending in commands from the serial monitor.

For example, "G28 Z" properly zeros the z axis. If I then use the panel interface to move the Z axis it will return to home when I issue G commands like:

(This isn't code that executes in order, just various attempts at getting the table to move down under gcode control.)
G0 X100 Y100 F2000
G0 Z(any value)
G0 F150

In every case, the Z axis returns to zero/home.

Do you send G90 or G91 before you send manual directions? This can make a huge difference.

Okay I believe I found the bug in Downunder35m's MarlinKimbra-K40 fork. I don't know what other effects this might cause yet but my z-table is working properly now. In MK-Main.cpp at the beginning of the G-Code Functions section, he changed the first For loop in gcode_get_destination() from:

for (int i = 0; i < 3; i++) {

to:

for (int i = 0; i < Z_AXIS; i++) {

When I instead use:

for (int i = 0; i <= Z_AXIS; i++) {

... everything works as expected. If you aren't using a z axis, everything else would work normally so it's understandable that he wouldn't have seen this.

The only other changes I made were in in the ultralcd.cpp menus. Under the Auto Home section of lcd_prepare_menu(), I added Z to the G28 command in the MENU_ITEM. In the laser focus menu, I changed the laser_set_focus() function to match my z axis direction by changing:

float focus = LASER_FOCAL_HEIGHT - f_length;

to read:

float focus = LASER_FOCAL_HEIGHT + f_length;

and for these commands to enqueue properly, in the same function change:

enqueuecommands_P(cmd);

to:

enqueuecommand(cmd);

Again, without a Z, this stuff wouldn't get tested. Unfortunately it's going to be a week or two before I can circle back to testing the actual engraving workflow but I can't wait to give it a try!

Thanks for everyone's feedback!