I do not like to laser anything with ‘C’ in it. That smells very bad. It is Polycarbonate.
generally a good practice as the C stands for chlorine and is highly toxic… but that doesn’t stop everybody 
PC doesn’t absorb 450nm wavelength real well (some absorption but not great). have you tried putting a coating on the plates before lasering them? dry erase markers work well for that.
Atom
If I watch the burning a few seconds it is clear. The laser starts and stops like the gcode is written. Often the laser starts with less power, around 2% or 3% I would say. It reaches the 35% from the command, M3 P35, around 1mm or 3 mm after start. There is neither a problem with the material, nor with the positioning. The laser just doesn’t work. The CNC part works like a charm. gcode in, done. Do you know the cable assignment?
To replace the module with a different one. Just using the PWM signal, power from a power adapter.
I don’t know what software you’re using to generate the g code, but in lightburn I’ve had good luck putting 100 millisecond dwell at the start of each burn for cuts and 5 milliseconds for engraving depending on the material. it seems that some materials have a startup time before the engraving stabilizes
1 Like
Hi folks,
just spontaneously decided to create some halloween decoration for my windows by lasercutting from black cardboard. Made an SVG from Inkscape, put it into Luban, and have the same problem: laser starts too late in some cases. Laser power is set to 100%, work speed to 800 mm/min, Jog to 3000 mm/min. Most recent Luban version. Preview looks fine. I suppose there’s a bug in the firmware…
Anyone contacted support on this already?
Cheers
Hauke
Edit: Now comes the funny thing: The problem occured when running a test burn on A4 white paper. Slightly rescaled it for the blck final cardboard --> No problem! strange…
Since no one has mentioned it, this might be a problem with the drive circuit for the laser diode. There’s too long of a warm-up time between onset of signal and adequate current to the laser diode. If I had to guess, there’s a capacitor that has to charge before the diode has enough power. If that capacitor is cheap, it’s internal resistance would cause it to charge more slowly (and also be less efficient, but that’s more about excess heat). If the capacitor is larger than it needs to be, it means the time constant to charge is longer. If it’s both of these, it will be worse. If the power supply feeding such a cap is barely adequate, it will start up more slowly than if there’s some headroom in current delivery.
Independent of any of this, it seems that the circuit turns off when the diode is off, which means it has to reinitialize when it turns back on again. It’s not a great idea to leave a high-energy circuit charged when the machine is off, but you can certainly keep it charged for, say, 10 second before going quiescent.
I haven’t seen anything like a schematic, so this is somewhat speculative.
This might be able to be mitigated in firmware with a calibrated delay to give the circuit time to warm up.
Here’s a question for you, since you seem knowledgeable in these things - any idea if that would explain being able to see laser output but it not cutting / engraving? Or mostly limited to instances where the laser visible turn on is delayed?
These two seems like different manifestations of the underlying problem. Instead of thinking that when the laser turns on, it’s a sharp transition from “off” to “on”, there’s some function that represents the laser power output. Properly scaled, it starts at zero, goes to one, and takes some finite (and overly long) time to do it.
The difference between black and white paper is a difference in laser power delivered as heat to the paper. Black has lower albedo than white, which is almost a tautology as “albedo” basically translates as “whiteness”. In other words, a white paper reflects more of the incoming laser light, which means it heats up slower and crosses the charring threshold later. Black absorbs more energy, crossing the transition sooner.
Same for visible light. You see the laser beam because of Tyndall scattering, that is, there’s dust in the air and you’re seeing light reflected off of it. The eye has really wide dynamic range and isn’t finely calibrated for absolute intensity (relative intensity is a different matter). So you’ll see a beam at wide range of powers, including those not sufficient to burn.
1 Like
Albedo is a new word for me, awesome. Taking what you said, and Googling - seems like the next step would be figure out the driver capacitance and circuit parameters to find the laser bias current. I have all the equipment, but at the moment don’t really want to disassemble it.
From there maybe we could derive some recommended delays, dial in the functionally working 100ms startup pause I use, but haven’t tuned at all.
Ideally the result would be a formula that given a material albedo, the laser parameters, and speed and power, you could calculate the delay?
Or is that a bit ambitious and not how it works.
Based on the albedo comments, I wonder if using black whiteboard marker on the material that @Dirk1000 is using would make it work?
i sugested this very thing a while ago, this was Dirk’s response:
Oh, it could work, but it probably too much work. There are three basic ways of approaching this problem:
- Obtain and install a better driver circuit for the laser driver. If it’s really a relatively slow ramp to full power, it’s a half-assed circuit. Given how much other half-assed stuff is in these devices, that would be typical for them and ought to be unacceptable for us. It should be covered under a warranty replacement, but that’s only if Snapmaker were to acknowledge that their product is low and inadequate quality.
- Go the physical modeling route. Measure a bunch of physical quantities in the laser head and the material, and be able to compute an initial delay to compensate for a bad circuit. This is a bunch of work, but would have the advantage of also allowing calculation of ordinary output power. Yet without access to source code for the firmware, it’s too hard to realize these other benefits.
- Go the direct measurement route. The result for this particular problem is a single number, the duration of a delay between turning on the laser and moving the head. It’s easiest just to measure this by trying a number of settings and comparing the results.
A pretty direct way to measure this would be to print a ruler, with the rulings labelled not by distance but by the delay. Use the laser to put numbers on the test piece and it becomes somewhat self-documenting. You’d want a g-code generator for this with [first, increment, count] information for multiple passes. Start with a wide range and identify the transition zone where the line goes from unacceptable to acceptable. Zoom in on the range, and repeat until the transition point is identified with adequate precision. It shouldn’t take more than two or three passes.
For the image itself, I’d suggest a baseline perpendicular to the rulings and separated from the start of the line by a small gap. The eye is good at seeing the relative distances in the gaps, much better than if it has to infer a baseline. And if the onset delay is way off, it could infer the wrong baseline. Remember to start the baseline drawing before the rules, because the start of that line may not appear because of the power problem this measurement is trying to address.
Getting the delay, once measured, into g-code is a whole separate problem that would also need to be solved. And that’s why it would be best to have acceptable electronics in the laser head.
1 Like
Well, I mean, overly complicated software solutions to avoid fixing hardware are something of a specialty for me. Let’s do it haha.
I do have the firmware source, and there aren’t any bugs I see that would explain the delay. There is a power lookup table that converts 0 to 100% power commanded from gcode into a PWM timer register value. Those values could be tweaked, but 100% is fully on, so nothing extra to be gained there.
I have written a post processor before, if we figure out parameters getting a program to modify the gcode is no issue.
I like the ruler idea - forgo the theoretical derivation and just do a direct measurement on the material. Generating that gcode is also pretty easy, I’ve already done similar things, would be easy enough to do.
I’m a bit busy this weekend but I’ll try and mock something up to get started soon.
1 Like
Where did you get it? I haven’t found a download anywhere.
You can find it in this thread:
I connected a wire to control the output of the PWM.
Grey is GROUND and ORANGE 24V. YELLOW is 3,2V and BROWN 5V.
Does anybody knows which PIN is which function? Or I will have to try.
Thanks. My naive expectation is that it would a bit more formal. Time to lower my expectations yet again.
They did claim that they would open source it completely when all the backer rewards were fulfilled (see post 7 in this thread): FYI:Source code of Snapmaker Firmware
Which actually has happened according to the SM team: https://www.kickstarter.com/projects/snapmaker/snapmaker-20-modular-3-in-1-3d-printers/posts/2967921
So hopefully we’ll soon see it as a repository on their github page soon: https://github.com/Snapmaker
I wouldn’t hold my breath.
The PWM arrives on RED. Saddly the PWM looks OK. So it should be the driver. Fixing software is more easy. The power 50% and 17%.
xchrisd Is there a way to get support for that? The circuit of the driver?
1 Like