I have a project where I’m making multiple identical circular parts, with etching on both sides. I use an array and adjust the spacing and shift to get a nice dense arrangement. I also use a virtual array for easy customization. I etch one side, flip the board over (using an alignment technique), then etch the second side and cut out the pieces. When I flip the board over, I also need to mirror the whole design in LightBurn.
If I use a virtual array, when I mirror the design to etch the second side, I think the row-shift value should change it’s sign (ex: positive to negative number) so that the resulting array is mirrored properly. I’ve attached an example file where you can see this.
I know I can “de-virtualize” the array and them mirror properly, but I lose the ability to edit the master and have it propagate to all the virtual copies. virtual array mirroring issue.lbrn (742.6 KB)
Finally, to make this about multiple things… a feature request. If I make a virtual array from a group of shapes, I can un-group the “master” and delete or edit one of the shapes, and the change is shown throughout the array. I’d like to be able to add a new shape to the group and have it “join” the array and be propagated to all the virtual copies. Let me know if this one should be put in a separate post.
Thanks for the super-fast response. That’s great to hear. I’m teaching a class at my local maker space in how to etch a board from both sides and keep things precisely aligned. Once the next release is out I’ll be able to pull out the step of flattening the array which also makes design changes difficult.
@adammhaile - I ran into an odd problem today when I took my mirrored array file into the maker space and used the file on a computer there. Not sure it’s a defect, but it’s certainly not acting the way I expected. I thought it was a bug until I spent a bunch of time figuring out what was going on.
If there are several shapes added to a virtual array,
And the shapes are on different layers.
Then, if one of the layers is set to Show Off
Then if the array is selected and mirrored
The shape on the Show Off layer is not mirrored. This can have surprising effects on the array spacing.
If the shapes in the array are grouped, then they mirror with the array as expected.
Not sure if that’s a bug or just complicated behavior. I’ll remember to always group the “master” shapes in a virtual array, but maybe when shapes are added to a virtual array, they should get grouped as a default?
This file is for a LaserLab class I’m going to teach where the students will make a bunch of poker chips with artwork on both sides. We pre-cut the raw material with a notch on the top edge so the material can be flipped over and stay aligned with a mating shape we fix to the bed of the laser. We etch side 1, then flip the material and mirror the whole design, then etch and cut side 2. I mention all this because when looking at the design with Show On for all layers, it looks like a mess.
I’ve named the layers to indicate Side 1 and Side 2 designs. The picture is zoomed in on the “master” shapes for the virtual array.
Here’s the whole array:
If I select everything and Horizontal Mirror, I get the following:
But if I turn show off on Layer 01, then Select All, then Horizontal mirror, I get this:
Turning Show back On for Layer 01 reveals the problem. The shape on layer 1 that was part of the array master was not included in the Select All. This is what we’d normally expect (unshown shapes are not selected by a select all). But it is surprising behavior in an array.
Is the machine origin the same between the profile you designed this on and the device profile you opened it on at the maker space?
This looks like an origin issue to me.
One that needs to be fixed… but one we are aware of.
In actual usage, we set the Job Origin to Rear Center and that’s where it was whenI first encountered it yesterday. At home, my LB Job Origin was set to Rear Left. But the behavior is the same. I can make the problem come and go regardless of the Job origin, based on whether the show is on or off for one of the shapes in the master of the virtual array.
A wild guess, but I think that somewhere in the code, when a the Mirror Operation is performed, a step happens to ensure all shapes in a group are included, regardless of the “Show” state of their layer. But I don’t think a similar step happens to ensure all shapes in a virtual array’s “master” are included, regardless of the Show state of their layer. After all, they are not in a group and this would need to be something new to support virtual arrays. And I can make the symptom go away if I group the shapes in the Virtual array’s master.
I keep using the term “master” for the shapes that are cloned to make a virtual array. This might not be the right term.
@adammhaile - This may be off topic, or may be an example of the “origin problem”. If so, I can put it into a new post.
I was back at the maker space today. cutting my file. I modified the filled text to have both Line and fill (Line first, then fill). When I ran it on the laser, I get an occasional Y-shift on the transversal move between shapes. In this closeup, you can see that after outlining the letters, during fill (each letter was filled separately) there was space added after the “D” completed and the “E” started.
That offset stayed constant through several more shapes, but additional offsets of the same amount were added in a lot of places, resulting in the fill “walking” away from it’s intended position. Here’s the full board before I stopped the laser (and cut out the pieces that had not yet been filled). You can see the places where the shifts happened.
I tried again, filling the groups together and the shifting happened again, but between groups, not individual letters (I can add pictures of them if it is useful).
Another theory is that this is a problem in our Ruida controller, or maybe the motor skipping steps. I eliminated the step skipping theory because the laser returned to the correct Job Origin after I stopped the job. Skipped steps would have resulted in the laser not returning to the correct place.
Is there a way to capture the file being sent to the laser and then view it? If so, this would let me verify that the problem is in the controller.
Yeah, just looking at those pictures, it’s classic mechanical/motor issue stuff. I would say at the very least you are loosing steps. But also in that first picture you can see how wobbly the vector lines are… you have a lot of resonance in your system and probably a bit of backlash too.
Most likely the skipped steps are happening during the fill.
