Pretty cool!
Oh hey that is some super valuable information, thank you for going to the trouble.
Speaking of layers one thing that irritates the Jesus out of me is when lightburn slices the images they are saved??? to knowwhere?
I would love to be able to save a dump of the GCODE hello techs you listening???
If you had access to the Gcode and slices it would be nothing to manually add code for a z hop down.
Why in heavens name are the slices and Gcode not available?
I don’t think galvos work that way.
if you can issue a command to a rotary and you had access to the produced gcode then you can make that little stepper sing and dance the way you want it to sing and dance.
Glavo does its job nothing to do with the galvo but it has everything to do with making the stepper do a waltz…
1 Like
I don’t think there is any gcode involved with these types of machines. Rotary is handled by the BJJCZ board. I’ve messed with these boards and read all the tech available for them, I don’t see any way it could output anything except pulses. But the pulses are controlled through LB obviously. How LB does it is above my head so just speculating.
LightBurn Galvo does not generate or run G‑code. It uses the JCZ SDK to send a precompiled job to the controller, so there is no G‑code or saved “slices” to export. Z control on galvo is not supported now and would require SDK support on compatible JCZ boards plus new logic in LightBurn.
I am thinking of building a simple Arduino based Z axis that steps a set distance at set time intervals, triggered by a manual start button.
That’s pretty easy, you can build your own sketch or tweak/use the available grbl sketch and run it with g-code. As I’ve mentioned before, that’s the route I’ve taken. Right now I run the Z axis on the column and the Y axis on the table with G-Code, and run the X Axis on the table or the rotary off the BJJCZ board. I’ve added some opto isolated SS relays to the controller and eventually will tie them into the I/O’s on the BJJCZ board. Just haven’t had the case open since I built the controller. Too many projects going on.
I don’t see why that’s necessary. The major use case is moving the Z for deep engravings. The BJJCZ doesn’t need to handle this. LB uploads a “job” that is only one layer. It runs through that, the BJJCZ is idle, then LB commands a small rotary movement which is actually hooked up to the Z. Then LB uploads another layer as a new “job” as far at the BJJCZ is concerned, and tells it to run immediately without further user approval. 256 layers= 256 short jobs in sequence.
Thank you for the clarification, why one would want it, great way to edit a slice at any particular point, you have access to it, I edit slices a lot of times when resin printing to get rid of troublesome islands that are not cleared of picked up saves me a lot of resin and failed prints particularly on complex prints.
CnC having the ability to add commands to the code.
For me its a first not being able to access a slice or the code thats being generated.
If I understand want you mean, It might be possible if LightBurn could split the total layers into batches. With some added logic to group layers, trigger a G-code move after each batch, and then send the next compiled job, it could run the cycle automatically. LightBurn’s developers would need to confirm whether the total layers can actually be divided into batches within the current framework.
But it in theory seems possible.
The issue is JCZ SDK is proprietary software and I don’t believe they give access to this sort of thing.
LightBurn does not use a BJJCZ SDK - They have one, but it’s Windows only, and was basically just EZCad without a user interface, locked in to all the issues that come with EZCad.
I reverse engineered the control protocol with the help of one of our other devs, and wrote LightBurn’s code to control EZCad2 cards from scratch. There was some initial conferring with the guy who wrote Baylor, but everything he had (in Python) I had already figured out, with only a couple small exceptions.
The protocol is binary, not GCode, and very specific to these cards.
I have a branch ready to go with Z jogging and focus control working. The biggest reason we don’t have Z control released yet is that doing Z-per-pass within a job is the FIRST thing everyone is going to ask for, and that is going to require re-architecting the sender we have.
EZCad2 cards perform motor moves in what’s called “immediate mode” - You send a command, the board performs the command and you monitor it for completion. When running a job, you send a whole bunch of commands in “stream mode” and the controller buffers them and executes them in sequence. You wait for the sequence to complete after you’re done sending.
You can’t mix immediate and stream commands, which means that the thread I have to send jobs needs to be updated to handle multiple “streamed” jobs with immediate commands in between. It’s on our list to do, but it’s not a simple or quick thing to do.
4 Likes
This is doable - it’s how rotary and split-marking works, but it means that we have to have a window open that knows about the job splitting, and runs the sequences with the motor moves in between.
The current code we have to generate the job needs to be altered to split the job every time the Z changes, and then command a motor movement, and resume. This will lock out the UI completely while the job is being sent, which it doesn’t do at the moment. I could make it work this way - IE, if you have any Z movement in the job it will mean putting up a “waiting for next Z event…” window or something, but I’d really rather not do it that way.
If I do it the way I want to, where all the external motor sequencing is handled by the job sending thread, then we’d also be able to run rotary or split-marking jobs faster, because it wouldn’t be ping-ponging between threads for every slice.
2 Likes
Thank you very much for the update and clarification. I appreciate your time and effort watching how this is slowly but surely moving along.
Cheers and avagreatday,
Greetings from the colonies downunder!!
That makes sense, thanks for the explanation. It’s worth noting and I am sure you guys are aware that both ComMarker and xTool are already moving toward full Z-axis and surface-tracking workflows, ComMarker with motorised Z and autofocus, and xTool with 3D curve modelling and real-time focus adjustment.
With UV and sub-surface marking taking off, and a big rise in 3D coin and relief engraving, automated Z and layered job control are becoming highly wanted features among fiber laser users
I understand that you want to do the job properly right from the start and not just provide users with a simple way to move the Z-axis … and that absolutely makes sense.
However, it’s important not to forget that for the vast majority of users, simply being able to move to specific part heights would already be a huge help. Many end up switching to other software just because of that feature.
For me personally, it would be a big advantage to be able to move to and save part heights directly in the software. Especially for users who use LightBurn professionally, this is a real drawback.
I personally would really appreciate an early release, even if it only allows for simple Z-height movement - and I believe many other users would welcome that as well.
I think this is really the last basic thing thats missing in Lightburn when it comes to galvo systems.
Please free us ! =D
1 Like
Forever a beta user lol… when you ask the question you may get a reply I hope you do and I think there are enough fiddlers out there that wouldnt mind having a crack at it.
I see many of these new kickstarter machines coming out on the market offering a z move feature.
What is of interest to me is the the board that is in most fiber lasers the only alternative?
Is there something other than, which might resolve a lot of issues?
I don’t think there is anything else. Feeltek and ezcad3 support Z axis control, but lightburn doesn’t work with those boards and I believe there is no interest from the board makers to assist lightburn to work with them (I think Lightburn has asked)
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.