Hello @easytarget and @cprezzi,
I’m implementing an automatic height control on my machine. So far I’ve been progressing well on the hardware and interface and I can maintain somewhat 0.7mm distance between the tip and the workpiece surface even if the workpiece is quite angled compared to the machine bed. I need this as I don’t have control how level the workpiece will be: it can have millimeters of difference between the edges and the center. My control system is able to send adjustment steps to Smoothie using G43.2 commands (see this link: motion-control [Smoothieware]). My issue is the planner needs to be done with some amount of G-codes before the G43.2 gets executed. For any arc path this shouldn’t be an issue as multiple G1 codes are used to form a segmented arc. I feel my issue will be more with long straight lines where any compensation will take a long amount of time before it takes effect.
As a side note, I tried to compensate outside the Smoothie, that is between the output of the Smoothie and the Z-stepper driver. That didn’t work good as I didn’t have the right voltage from my control hardware. I would also loose quite a bit in terms of z-position as the Smoothie wouldn’t know where Z position is anymore.
What I was looking after is breaking the long lines in smaller chunks, a bit like what is done for the arcs. So instead of having a nice G1 command, I would have hundreds. This way the planner queue is moving much faster and gives the system a chance to compensate for Z surface variations.
I’ve been digging through the GCode generation and the file importing but I can’t quite nail down where the arc to line conversion is happening.
Can one of you provide me with some insight where the arc conversion is happening?
Or if you have better ideas, I’m open to any suggestions.
I tried to use the mm_per_line_segment = 1 setting in Smoothie which effectively fills up the planner by chunking the lines in 1mm segments. However with a planner size of 32, that means that I can correct by one “increment” only each 32mm. So nevermind my previous request, I would have to hack into Smoothie so my external commands are inserted into the planner queue. Other option is reducing the queue which is going to throw off realtime behavior.
Hm. I guess the easyest way to do this would be to make a G-Code pre-processor (after generation, before sending) which breaks down G1 lines to short segments and then inserts your z-correction in between the segments.
Disclaimer: this is no longer a LW4 issue but changes needed to Smoothie.
I had some code in there that would just execute the steps right away, bypassing the planner queue altogether. I don’t care about acceleration, it’s more about immediate correction using a rather passive Z-axis. But for some reason I have yet to discover there’s another queue in that firmware. I can do aborts just fine any time using M-code which I think (I hope!) are immediate, I have to find a way to mimic that for my small moves.
Some thoughts; my solution for this is in firmware; specifically I’m going to be running RRF firmware with an IR proximity sensor on the head. I’ll be able to probe and apply a correction map (plus visualise it) via the web control panel just as I currently do for my delta 3d printer.
This is also an option for Smoothie; check out the RECTANGULAR GRID COMPENSATION section of the following: zprobe [Smoothieware]
I looked into grid compensation, but this is not really what I am after. My issue is that the workpiece could warp slightly during the cutting process.
Well a vacuum hold-down table is an awesome project by itself. But in my case it wouldn’t work. To your IR sensor idea, I can well see that work but you may want more than one, and check if it is affected by smoke or even the laser itself. I went for capacitive control as it is already widely spread on the industrial side and my laser head already has the capacitor part of the circuit. In any case, without a vacuum table you may benefit from my strategy to compensate for warped workpieces.
Well this is fun: I just discovered that a M112 command on Smoothie is queued. The web site https://smoothieware.org/stopping-smoothie is both indicating “queued” and “Instantly stops” but its really the former.
Just to close this topic: I ended up modifying Smoothie switch module so that it moves the Z-axis on_idle when receiving a digital input on the control board. I tried updating the Z position as it was a tool length change but failed miserably. It probably would work better with a servo setup instead of a stepper setup. LW4 doesn’t see the moves in terms of position but I can tell from the console there is activity.
