MeerK40t 0.6.20 released!

K40 Laser Meerk40t
#1
  • Correct several small Make Raster bugs where black was preferred over white for transparent.
  • DXF, color BYLAYER reading. #357
  • DXF ACI corrected.
  • DXF Block Reading #357
  • Mouse Wheel Pan mode in Settings.
  • Modifier Tweaks for Mouse Wheel Pan. Shift axis invert, control zoom.
  • OSX magnify mouse trackpad pinch-zoom.
  • Added Touch Screen Support (wx4.1)
  • Added hard \n in About window.
  • Backported Linux LibUSB Windll corrections.
  • Fix Camera Interface post-close crash #366
  • Added Step & Repeat to Jobs.

The step & repeat is nice, if you’re doing a large grid and you want to do the same thing over and over in a grid pattern. 0.7.0 is still being actively worked on. 0.6.x is supposed to mostly be bug fixes and some stuff that there’s no way to do properly.

3 Likes
#2

Hi,

Thanks for the update. I tried to open a file and the result is not what I expected.I added the K40 whisperer to compare. Do you have an idea what went wrong?

labels-honing SVG File

Schermafbeelding 2021-02-26 220454
Schermafbeelding 2021-02-26 2204541658×826 129 KB

Thanks,
Jos

#3

It will cut fine, but there’s a bug somewhere. I’ll track it down.

You can check in console ‘stroke-width’ will show you the scaled stroke width it finally gets is 310.00095914201273. I think this is in error.I don’t see anything that should tell this circle to do that. There’s a translate, rotate and translate. So it’s a bug.

Specifically: <g id="g1831" transform="rotate(-90,56.483648,105.65717)"> the determinant is 1 and the square root of the determinant which governs the scale is 1. So it shouldn’t scale at all and should remain 0.19999999 and not 310.0. Also, if it starts at 1 it goes to 1550.0048732103073.

It will cut correctly, but the display is messed up because the stroke width goes kinda nutty. Manually calculating it gets the right answer. I’ll have it fixed in 0.6.21 and while it looks insanely wrong it’s actually going to cut the right geometry.

2 Likes
#4

The issue is a bug in svgelements you can attempt to reify the offending ellipse <ellipse style="stroke:#fc0000;stroke-width:0.2" cx="0" cy="0" rx="1" ry="1" transform="scale(35) rotate(-90,0,0)"/>. The function is supposed to take the shape and make it an identical shape but without the matrix. Sometimes there’s no really corresponding shape so it just leaves the matrix in place.

It sometimes it is helpful if you scale a rectangle with width of 10 up by 2 it’s helpful to say it has a 20 width and get rid of the matrix. This doesn’t often work for rotated shapes since a rotated rectangle can’t shed its matrix. It’s not a great system and I think I’d do it differently if I get around to to a different svg project.

In any event one of the things it can do is scale up the stroke width which gets scaled up by the square root of the determinant of the matrix. However it didn’t get rid of the matrix so it pointlessly scaled up the stroke-width while keeping the matrix in place. Which means when it does that again for the actual path, (which can always reify since you move the points), it gets that scale up on the stroke width twice. Which makes it giant.

The cuts are based on the underlying geometry and not the stroke width, so they won’t be affected.

Thanks for bringing this to my attention.

3 Likes
#5

meerk40t
meerk40t797×600 64.8 KB

Fixed in 0.6.21, 0.7.0 and svgelements 1.4.8.

2 Likes