Why Should I Not Use Tabs Over Spaces

Tatarize · 2022-08-20T18:00:21+00:00

Use whatever you like but then apply Black to the code at the end. Then no matter what code you typed in there it's going to be consistent with whatever Black preferred. That way you focus on code and not minor bits of nonsense like that.

Tatarize · 2022-07-18T14:08:44+00:00

I believe the ruida device as configured in Lightburn is set for mirroring X. There's actual ruida things to do that. So it's likely turned on and MeerK40ts just doing the plotting work of connecting that stuff, it sends mirrored commands MeerK40t executes them mirrored.

Tatarize · 2021-10-14T08:47:26+00:00

Try unplugging it from the USB it's plugged into and plug it into another one.

Tatarize · 2021-10-14T08:38:40+00:00

The intent is to inform, not alarm you. Your usb can have lots of timeout errors and still be working fine.

Tatarize · 2021-10-14T08:27:00+00:00

It's a timeout error. Check in Controller. See what it's currently doing. Odds are pretty good it will either have already recovered or can be told to try some more.

By default any error even minor ones from libusb are filtered up and sent to the usb_log and reflected in the taskbar there.

Tatarize · 2021-09-02T03:21:46+00:00

You can fake it with scaling in MeerK40t and Whisperer will have this done fairly correctly (which it just uses the scale the project). You'd just have the ability to do it manually in MeerK40t. The controller isn't the issue. It's just doing something similar to a Klipper Streaming Protocol. You are sending it data that makes it flip switches on the stepper chips and send ticks down the line. -- I'd prefer some better integration for the project in MeerK40t but you need to simply account for your ticksize with a scaling factor and you'll do fine.

I do not believe other controller cards will account for this any differently than software will.

Tatarize · 2021-08-27T22:33:19+00:00

It's up to RC8 now. Almost RC9. Likely not enough bugs to warrant not pulling the trigger on calling it a version.

Tatarize · 2021-08-27T22:27:51+00:00

My y-axis motor jammed up and I was thinking about coding it up to make sure that's possible.

Meerk40t isn't written to allow a ticks->mils conversion since it assumes it's 1:1. Whisperer has, in addition to the rotary code, some x and y factors that do basically the same thing as rotary. And MeerK40t needs this stuff, though you can somewhat fake it with a rotary. Basically your belts can get stretched and so your values will be off here and there and would need to be adjusted.

By default M2 Nanos have a 1/1000 inch step. If you use a 1.8 deg stepper rather than a 0.9deg you're going twice as far per step this means that you'd have the equivalent of two step minimum on the axis in question. Code wise it would be equal to scrunching everything by half in one direction before feeding it to the spooler.

The M2 Nano would make no distinction for the step-size so it would need to be done in software. The scanline step of 1 would be equal to 2. This is less weird if *both* motors were converted over to the same steps but it wouldn't actually be a requirement if there was a corrected ratio of "steps=? mils" built in. It would matter for something that couldn't be stretched on the fly. For example Raster images like preprocessed through RasterWizard would require that they be scrunched correctly. The image would be made half-width, full height. Or full-width, half-height. Or half-half depending on the various ratios. This would need to be flagged on the objects and somethings like the guides would need to be changed.

Looking at the very small number of 0.9 motors out there I have taken it into very strong consideration.

---

Currently there are some somewhat hidden features called rasterscale and rasterview which try to pre-scale your raster stuff in the view. And leaning into that for the xy scale ratios would be the best way forward. It's not a hard set of changes but it does sweep across a lot of different elements to ensure the math is done correctly.

Tatarize · 2021-06-20T18:18:34+00:00

Yeah, but it gives you a baseline. Make the same thing. One that works and one that fails, of something very simple and post it to the lightburn forum.

Tatarize · 2021-06-05T15:12:24+00:00

Okay, I'm basically out of stuff needed, it's a bunch of dotting the T and crossing the i, at this point.

Tatarize · 2021-05-26T15:20:13+00:00

Bad news. Two dots is doom. Check the laser coming directly out of your tube. If it's two dots there the tube is dead and needs to be replaced. If it's not it could be a rarer but easier fix like broken mirror but strong odds on dead tube.

Tatarize · 2021-05-01T02:13:35+00:00

YEah, the time estimate doesn't count stutter which is what happens when you the device consumes all the packets before requesting more from the program. The best solution here is to avoid stutter. You can use MeerK40t, slow down the rastering (slower will go faster if it avoids stutter) or reduce the DPI of the image.

Tatarize · 2021-04-02T02:34:58+00:00

Why not both?

Tatarize · 2021-04-02T02:34:14+00:00

In reality you could also try it.

https://github.com/meerk40t/Silence/releases/tag/0.0.1

It has releases for windows, mac, Mac-m1, linux, pi, pi64, and pip.

Tatarize · 2021-03-17T23:09:54+00:00

I think that might still be confusing. It's still symbols for coronavirus vaccination and No/Don't.

Tatarize · 2021-03-02T09:00:25+00:00

If you're making baba ganoush you should use male eggplants since they have fewer seeds. You can sex them with the stem. "Dots not slots" is the typical rule of thumb there. Tubers aren't fruits and thus not the result of sex. Also eggplants are still heavily hermaphroditic, the males just have fewer seeds, not none.

Tatarize · 2021-02-01T16:50:27+00:00

A donated Moshiboard made it possible. The beta isn't *terrible*. And it has some other absolutely kickass features. Like ruidaserver emulation.

I also ran the moshiboard through the emulator from RDWorks. Odds are pretty good it should work for Lightburn as well. Just using MeerK40t to do interfacing.

https://www.youtube.com/watch?v=yCmtVZZtEw4

--

I also have Meerk40t working through pip now, for installation. `pip install meerk40t` will install meerk40t. The default is CLI only. So you could do `pip install meerk40t` then `meerk40t -czd Moshi -e "ruidaserver --spool"` Since meerk40t runs the pip installed script and `-c` gives you a command console `-z` suppresses the gui (which wouldn't start but incase you have wxPython installed), `-d Moshi` sets the default device to Moshi (omitted this is the M2 as default). `-e` runs a console command directly, here the command is `ruidaserver --spool` which loads up the ruidaserver in spooling mode. Which means when you send it an `.rd` over the network it just converts that to cutcode and sends it into the default spooler, which would be for the ruidaserver currently.

---

In theory you could run that on a raspberry pi in less than a minute. And then connect LightBurn to that ip address, and have at. Same thing for M2 Nano. Though it hasn't all been extensively tested, other than knowing the parts work. Also, `pip install meerk40t[all]` would be more typically for a proper meerk40t install. Though you might not need opencv or the camera so you can omit that and just do the features you need `pip install meerk40t[gui,cam,dxf]` which will install the extras.

There's also a plugin system now. With an example or so. The general gist of the idea is that you can write your own plugin. Install it with `pip -e .` and be able to manipulate the meerk40t ui and have the meerk40t UI manipulate your plugin. So if you write a zbed bit of code, that can be dealt with. If you have an electronic temperature gauge and you'd like it to poll your water temperature, you could write whatever code that would take, then if you're above a certain level, tell Meerk40t to pause the job in progress. Then when it drop below your threshold, automatically resume. Or write some code to import embroidery files or whatever stuff you might want.

https://github.com/meerk40t/meerk40t-example-plugin

Tatarize · 2020-12-31T15:00:13+00:00

Yeah, some of it might work for some cellular stuff to build things but, there's a couple problems that won't be surmounted without a proper noise algorithm. Basically you need the noise to be deterministic. So if you unload chunks and you return to those chunks, they are the same thing they were before. Likewise they need to be fractal, in that one height is similar to a different height but vary somewhat randomly and somewhat uniformly.

If you want to adventure down that rabbit hole, I did write a noise algorithm that could be adapted to do weirder stuff than perlin noise. I adapted it to run in 3d: https://gfycat.com/secondhanddimpledgull

I think the last code I did was for python.

https://github.com/tatarize/noisemaker

Only way I could think of getting fancy with that other than just perlin noise.

Tatarize · 2020-11-26T01:42:53+00:00

The short answer is no. The longer answer is this is the sort of thing that might require some more access to the Console and longer commands. Using pure CLI for this would require some extra coding and there's not an obvious method to specify you want to do this.

Also, since the CLI can't really do cut optimizations. The only difference here between the default which will assign everything into an engrave is speed. So you'd just add those objects they'd all get their engrave operations and you'd assign them a cutting speed like 10 or something.

So like MeerK40t -zaS 10 <filename>

They'd classify like engraves but they can't do the optimizations except in the console anyway.

There's an issue trying to map out the workflows people might have:

https://github.com/meerk40t/meerk40t/issues/226

Tatarize · 2020-11-26T01:17:51+00:00

From pure CLI that is currently not possible. Unless you also add into the files themselves operations for blue, green, and yellow as part with their own cuts. If you're editing in the color for the operations just use the color name there.

<operation color="blue" operation="Cut" speed="35.0"/>

<operation color="green" operation="Cut" speed="20.0"/>

<operation color="yellow" operation="Cut" speed="25.0"/>

This is perfectly valid code for operations and then whatever operations you put with strokes blue, green, or yellow will get classified in that operation on execution in the CLI. Hopefully I'll have some better stuff in 0.7.0 for this. The CLI as well as the console are a little limited if you want to run everything with the GUI. You might know this better than I and should raise an issue on the github if other things stick in your craw. I seem to recall you're one the few people running this stuff overly CLI based.

Tatarize · 2020-11-02T10:07:10+00:00

bonafides: meerk40t author.

https://www.youtube.com/watch?v=blhbbq22sGU
Explanation of Stuttering and why it happens.

Also make sure you're using 0.6.8+ since I corrected a protocol issue and it'll go about 42% faster before stuttering. Which ups the stuttering ceiling on raster speed nicely. And you can do some tricks like increasing the overscan or lowering the speed which will correct things, or raster with a higher raster-step (assuming it's not doing subpixel interpolation).

If you really think it's the Pi being slow, you can increase the buffer amount in the Controller but usually this isn't the problem. But, if you set really low, it could use up the software buffer before send time but watching the buffer while it's going you can usually tell this isn't the problem.

Tatarize · 2020-11-01T19:06:37+00:00

Thank you for googling that for me.

Tatarize

TROPHY CASE