For some reason whenever I initiate a job (even something like a test grid) the Z axis starts moving upwards. It continues until it hits the limit, canceling the job due to error.
Im not sure why this is happening. I have tried disabling z axis all together and ensured no offset is enabled but the problem persists.
I don’t see any g54 commands in the gcode.
Also…I noticed it is also doing it when I initiate the “mark current position” while setting up the auxiliary positioning directly in the machine. I mention this because i do that directly in the machine not using LB.
The idea of using aux positioning from the touchscreen raises flags for me, but I have no fact to validate the concern. I strictly avoid touching my controller (Ikier K1, nearly clone of L2) and have no use whatsoever for the crosshair laser. I don’t see a reason to give up 50mm of my working width.
I don’t know if moves commanded from the touchscreen communicate back to LB, but I see no reason to risk it when all the controls are available from within LB itself…including pointer offset.
I recall having some fits with the Z axis when I was learning the ropes with my K1. I believe enabling both “optimize Z moves” and “relative Z moves” corrected it. Now, the only time Z moves after focusing is if I have a Z offset set in one or more layers.
I agree and have it turned off normally. I turned it on here to see if the Z axis would still misbehave even when LB wasn’t a factor (at least I think LB isnt a factor for this test with aux positioning).
I did verify Z axis is turned off and Optimize/relative Z moves are both turned on. It still does it either way with Z axis turned on or off.
It behaves perfectly normal whenever manually moving each axis around with the LB controls, but the Z still goes rogue anytime a job fires.
I did also check to be sure I see no Z queues in the Gcode and no Gcode programed to run at the start or end of each job.
For what it is worth I did also go back through making sure all the wiring and pins look good. I also verified the functionality of all the limit switches.
I’m noticing that you’re using the incorrect device profile for your laser.
Can you first fix that and then retest?
Push Devices button in Laser window, then click on the name of your laser, then Edit. Change the device type to “GRBL”. Make sure it’s not any variant of that. Then finish out the wizard.
Retest and report back what happens. I don’t necessarily expect anything to change but would like to confirm.
I don’t see anything in the g-code that would prompt the behavior you’re describing.
SOLVED!
Considering what we knew (above) I figured this was either hardware or Laser Firmware related.
I didnt see any issues with wiring or motors and they behaved perfectly fine manually moving around so I concluded this MUST be either the board or the board firmware.
Atezr has been really slow to respond and I dont see any firmware on their site but the Ikier K1 Pro is the same exact unit rebranded.
I decided to take the chance and update the laser using the Ikeir firmware update.
That solved the issue entirely. I didnt have to make any further changes in LB.
I didnt see and firmware options with Atezr so I used the Ikier firmware because they are the same machine. I dint recall the version number (1.4 i think) but it is whatever the current version is.
