thanks
- 7 months later...
Hi conny_g,
I've also just upgraded my UM2 with laser cutting/etching capabilities (405nm laser, several Watts of power, mounted with https://www.thingiverse.com/thing:3022126). I followed a quite different approach though for PCB mask etching. I'm using the print-head cooling fan PWM to directly control the laser power output. Then I create a gcode file, tracing the outlines of the PCB layout (through eagle ULM). In my case, I'm not using photosensitive film (as I think you do), but a plain PCB, spray-painted in black and then blasted away where I want to etch (so also effectively using positive resist). I'm also getting a 0.09mm (better-than 4mil) resolution with that. I think I'm mostly limited by the step-size of the UM2 and the 3:1 rectangular beam profile. Working on adding a pinhole in the beam to get a round beam profile (not sure how well that'll work). Using paint rather then resist also allows me to just remove the paint if something went wrong, re-paint it and try again. This is very easy to build and yields great results fast, so I would suggest to you to use this technique for PCBs (with your low laser-power maybe still with photo-resist, rather than paint though).
As you already figured out however, gcode doesn't really support drawing shaded bitmaps (and it is hard to hatch larger areas with a 0.09mm beam). So I might still be interested in developing the solution you proposed. It could also be better suited to cope with the non-square beam profiles that we often see in diode lasers. One solution would be to use rectangular instead of square pixels, another to move adjust the write time for each pixel such, that it effectively becomes square (which would lower the resolution a bit, limited by the longer side of the beam).
Ideally, we could merge the two approaches and build one controller that can run in either mode without having to switch stuff around. This might be possible if we used the fan PWM to give the sync signal, which can then be send from the gcode. As a bonus, the firmware-modification would be unecessary.
Let me know what you think, maybe contact me via PM.
Hi Razanur,
good work, congrats ?
I had two different versions of a head initially as well, one version used the thumb screws to attach it to the side.
The second version was an alternative head that allowed change a part of the head
https://www.thingiverse.com/thing:945899
The 3rd version is the magnetic mount of
https://magnetic-tool-changer.com/
(participated as beta tester there)
That allows to attach/detach the laser head at any time, without screwing or anyting.
Regarding color vs. photo resist. I am quite happy with the photo resist, it's very refined product and it's easy to expose it with the 150mW diodes which are cheap and available. The multi-Watt ones are much more expensive and harder to get in decent quality.
Thought about trying the color method, but on one hand it's a bit of a mess to remove that much black color afterwards and on the other hand I am absolutely happy with the photo resist stuff. I belief it's more accurate than spray color and supports efforts of high resolution better than spray paint.
Regarding the vector edging vs. pixel rastering I believe I can achieve higher resolutions with rastering as I can control the energy going into one pixel very precisely. And I can expose the exact image of what I want to do without having to convert it to vector edging, leaving the areas (unless I hatch it which is the same than rastering...).
For that reason I don't experience much of an issue with the oval/rectangular shape of the dot. I have set it to 45 degrees vs. the raster direction and that way in essence it has the same size for X and Y, simply making the focus larger. Which I can compensate with reducing the energy (gaussian beam, effective dot converting the photo resist is then smaller). If you move in all directions you see the effects of the "bar" in one direction vs. the other.
Then with the vector there is acceleration/deceleration ramps that change the energy going to the color/photo resist strongly so the lines are thinner/thicker, depending on the speed. Unless you go "full power'" anyway which will always create a large "effective" footprint (see the gaussian thing above). With the rastering every pixel is identical.
And with the vector method I had strong oscillations in the corners as the laser is on while it't going around the corners. Depending on the speed, of course.
After considering all this I stuck with the rastering approach. Tried the vectoring some time later and I didn't like it better, so still going with rastering now. The rastering takes long (3 hours for 1 side of Euro PCB), but I like the perfect result over the time factor.
With the software + controller the vector approach is still possible. I have two modes built in, one is the "bitstream" mode, the sync signal given by printer starts the pixels being generated while the head moves along the defined path. And the "direct" mode where the sync signal actually controls the laser beam, sync on = laser on, sync off = laser off. That way I can vector any path directly with G-Code (just an amendment of the G-Code is needed: G01 X100 Y200 B1 -> the B1 is "beam on").
For simplicity I had started with the fan output originally as well, but I disliked that I needed to switch plugs or connection between fan or laser so I started to use the EXP3 port and can just leave the laser stuff connected.
I don't have an issue with the firmware mod, it's making the solution more flexible and it's not a big /complicated mod. Even if you have to update the firmware from the repo again and resync the mod.
For the "bitstream" thing you need an external controller and for that you need a sync signal. So there is not really a way around the firmware mod. I had tried to integrate the pixel generation in the firmware, but I got conflicts between the movement control (using interrupts) and the pixel generation (using ints as well). Possibly you can get that resolved, but I am quite sure that this will bring the poor Atmega to it's limits and I didn't feel like having to resolve all sorts of strange side effects changing the usage of the Atmega that much.
So an external pixel controller was so much more safe and transparent.
So for me all that is pretty much working and finished, currently. The most important next step is to unify the software parts in OctoPrint with a nice UI behind it. Currently it's just python command line scripts.
And I am working on the drilling solution in a similar way. Magnetic attachment of the Dremel, python scripts to control the drilling.
Also that would benefit strongly from controlling that with Octoprint.
Already spent a few hours in the last months to delve into plugin development for Octoprint and I think am now ready to do the next step soon.
First: I think you did something amazing and I probably want to go in a similar direction. I just wanted to add my personal views/perceptions on some points, maybe also for the benefit of people reading this in the future.
2 hours ago, conny_g said:The 3rd version is the magnetic mount of
https://magnetic-tool-changer.com/
(participated as beta tester there)
That allows to attach/detach the laser head at any time, without screwing or anyting.
That is pretty neat! I think it might not be suitable for the big, heavy laser I'm using though.
Quote[...] the 150mW diodes [...] are cheap and available. The multi-Watt ones are much more expensive and harder to get in decent quality.
That is a very valid argument. However, with more power you can also cut, engrave etc. I'm not sure, how much power is exactly required to remove the paint.
QuoteThought about trying the color method, but on one hand it's a bit of a mess to remove that much black color afterwards and on the other hand I am absolutely happy with the photo resist stuff. I belief it's more accurate than spray color and supports efforts of high resolution better than spray paint.
As far as I can tell, there is no proximity effect whatsoever for the spray paint method, where I would expect a small a proximity effect in the photo-resist solution (the resist is transparent, so reflections from the copper also develop nearby resist). So from theory, but also from the results I've achieved so far, I don't think there is much of a difference.
QuoteRegarding the vector edging vs. pixel rastering I believe I can achieve higher resolutions with rastering as I can control the energy going into one pixel very precisely. And I can expose the exact image of what I want to do without having to convert it to vector edging, leaving the areas (unless I hatch it which is the same than rastering...).
I think both techniques have their strong and weak sides. Since most (all) PCB design softwares use-defacto vector descriptions to begin with, I don't really see your point here to why it would yield higher resolutions. Also, there is a well-working plugin for eagle to produce nice gcode files already. For pictures with shading etc, I think you totally have a point.
QuoteFor that reason I don't experience much of an issue with the oval/rectangular shape of the dot. I have set it to 45 degrees vs. the raster direction and that way in essence it has the same size for X and Y, simply making the focus larger. Which I can compensate with reducing the energy (gaussian beam, effective dot converting the photo resist is then smaller). If you move in all directions you see the effects of the "bar" in one direction vs. the other.
Hmmm, it appears you have a very different beam geometry than I do. My beam is currently rectangular with one side about 3x longer than the other. As I said, I think it is much easier to compensate for weird dot geometries in the raster/pixel scheme. The only way to compensate is to use a pinhole (which especially for low power (150mW) should be no problem whatsoever (albeit extra work)). I don't really understand how rotation and defocus can make a gaussian profile out of a non-gaussian profile. Could you maybe explain this a bit further?
QuoteThen with the vector there is acceleration/deceleration ramps that change the energy going to the color/photo resist strongly so the lines are thinner/thicker, depending on the speed. Unless you go "full power'" anyway which will always create a large "effective" footprint (see the gaussian thing above). With the rastering every pixel is identical.
If you really have a gaussian profile you have a very valid point. However, in my case my beam is a pretty well defined rectangle, so this is not an issue. Also for PCBs you basically only want discrete paint removed/not removed. As my beam is currently smaller than the apparent step size of the UM2, this does not seem an issue to me. Again, if you want shadings etc, go pixel ?
QuoteAnd with the vector method I had strong oscillations in the corners as the laser is on while it't going around the corners. Depending on the speed, of course.
I did a few test patterns and with speeds of ≤ 300mm/s, I see no residual ringing whatsoever. Also check the picture I appended: I think it is high-res enough, that you should be able to specifically point out any artifacts - and I don't see any oscillations.
QuoteAfter considering all this I stuck with the rastering approach. Tried the vectoring some time later and I didn't like it better, so still going with rastering now. The rastering takes long (3 hours for 1 side of Euro PCB), but I like the perfect result over the time factor.
I think this is advantage no 2 of the vector approach; its much faster and potentially uses less etchant. Advantage no 1 being, that you can implement is much easier for beginners/as a first test and cheapter (unplug fan, plug-in laser, extract gcode from eagle, replace a few commands, run).
QuoteWith the software + controller the vector approach is still possible. I have two modes built in, one is the "bitstream" mode, the sync signal given by printer starts the pixels being generated while the head moves along the defined path. And the "direct" mode where the sync signal actually controls the laser beam, sync on = laser on, sync off = laser off. That way I can vector any path directly with G-Code (just an amendment of the G-Code is needed: G01 X100 Y200 B1 -> the B1 is "beam on").
For simplicity I had started with the fan output originally as well, but I disliked that I needed to switch plugs or connection between fan or laser so I started to use the EXP3 port and can just leave the laser stuff connected.
That's super nice. I think I should also go with the exp-port and introducing the 'B1' command. Does this port also support PWM directly? I would like to set the laser power from the gcode directly for the vector mode (as you then only have to update the gcode on the SD card, nothing else).
QuoteFor the "bitstream" thing you need an external controller and for that you need a sync signal. So there is not really a way around the firmware mod. I had tried to integrate the pixel generation in the firmware, but I got conflicts between the movement control (using interrupts) and the pixel generation (using ints as well). Possibly you can get that resolved, but I am quite sure that this will bring the poor Atmega to it's limits and I didn't feel like having to resolve all sorts of strange side effects changing the usage of the Atmega that much.
So an external pixel controller was so much more safe and transparent.
Well, you could use the FAN output as sync. Otherwise, I totally agree. I would also go with an external controller. In the case of vector mode, I would just forward the PWM signal (either from the ext or the FAN) from the main board.
QuoteSo for me all that is pretty much working and finished, currently. The most important next step is to unify the software parts in OctoPrint with a nice UI behind it. Currently it's just python command line scripts.
And I am working on the drilling solution in a similar way. Magnetic attachment of the Dremel, python scripts to control the drilling.
Also that would benefit strongly from controlling that with Octoprint.
Already spent a few hours in the last months to delve into plugin development for Octoprint and I think am now ready to do the next step soon.
That's good to hear! I would definitely love to see a write-up and some pictures of your rig! I'll try and see if I can drill the holes by cutting them out with the laser, but I'm still a bit sceptical about that.
Edited by Razanursaved the post too early.
Recommended Posts
conny_g 251
@musyne,
it's not yet "compact" enough to make it easily doable in all details. That would be my long-term plan after I straightened out the software part with Octoprint.
Generally the solution consists of:
That's all the components in overview. Currently working (more long-term due to time constraints, will take a few months) on creating a Raspberry Pi hat to sit the control circuit on top of the Raspberry Pi and to add the python scripts to Octoprint as a plugin. That would make it much easier to use.
Link to post
Share on other sites