Explanation: How the M2 Nano Works?

I think that the question starts with “will there be an Arduino sketch that implements the lhymicro-gl language?” There’s a python implementation of it in LhystudiosDevice.py in meerk40t to learn from. It feels to me like “1000 lines of code” (more than 100, fewer than 10,000) to implement this language on Arduino, where you would have a much larger buffer to avoid stuttering. You can start reading it from the EgvParser:parse() method followed by parse_egv if you are interested. (Obviously @Tatarize can give a better answer, that’s just what makes sense to be breezing through it.)

After the relatively easy task of parsing the language, I’d think that getting the speed codes right would be the primary challenge for faithfully implementing the lhymicro-gl language on an arduino, since it looks like their interpretation isn’t 100% clearly understood, looking at LaserSpeed.py:get_acceleration_for_speed(). Getting the frequencies and divisors set up to mimic the configuration on the 8051 could well be the trickiest part.

This would probably fit on the attiny84 but I’d be worried about it working with softusb; I’d think you would still want a USB interface chip rather than using softusb. Just like on the m2nano, you might want a schmitt trigger as a gate drive for the mosfet for clean engraving. But attiny84 has two PWM ports that aren’t hardware serial ports, and really has 8 GPIO ports free that aren’t RESET or serial.

But an ESP32 is much more capable and only a few dollars. :slight_smile:

Not really MeerK40t for sure, but you could absolutely make a M2 Nano knockoff board that does the same work as the M2 Nano, for a nice little Arduino. I have such a project but it’s little more than planning stage and not too far into that.

I also, have a Arduino Uno and a couple stepper boards my brother bought a while back, so I’m not really lacking the hardware there. But, it doesn’t seem like a major project but I’ve never done them before.

The EgvParser code is actually a lot smaller than the devices code as a whole. I don’t actually think the code would be that massive especially with my better understanding. I’d actually code up the egv parser a lot differently now, since I better understand the states its setting. The speedcodes don’t really need to be right, at least not really. They would actually scale with regard to the CPU used and are basically always just fed into a counter thing. The type of board is set in all the software because it shifts. You’re converting a 16-bit number into an amount of time to wait. And the formulas for that are pretty much linear. You might require small bit of multiplication there. But, even the M2 Nano’s speed codes are all off by 8.9% (comparing the chinese software code with the actual values).

The homing operation is it’s own function too. Go this direction until you detect the end stop, and this direction until you hit something else. There’s also some cursory acceleration and deceleration code that might need to be somewhat duplicated.

For most of the rest I’m not a hardware guru so I’d think @mcdanlj likely has some very solid points.

I don’t think, any part is too hard but I tend to have other stuff to do. It’s part of the reason for the video. Generally explaining what it does makes it easier to explain how easy it would be to do the same thing quite easily, even if I don’t really know the specifics.


Also, the parsing gets easier when you consider things like the ascii code for A is 0x41 and it’s just cutting off that 0x4 bit. Which is one of the charms of ascii. The parsing will undoubtedly have shortcuts like that.

1 Like

Like @Tatarize I have other kettles on the boil, but information for anyone else interested in this project…

attiny84: 20Mhz clock, 8K flash instruction memory, 512 bytes sram data, 5V, pretty robust I/O, only slightly more expensive than dirt ($1-$2 in onesies)

ESP32: 72MHz clock, dual core, wifi and bluetooth, 3.3V, GPIOs reported sometimes 5V tolerant but don’t count on it, 0.5MB SRAM, several MB (several variants in different sizes) flash memory for program, roughly the same price as the attiny84. ($1 for the chip, $2-$4 for the board with flash and wifi antenna, $8-20 for complete dev boards depending on desired functionality; $20 gets you a built-in display and battery controller.) WiFi is better isolated than the best USB cables you can buy! And the API is well documented, supported, and robust; it’s done by sprite_tm (famous for, among other things, installing Linux on his hard drive. Not installing Linux on his computer’s hard drive. I mean, running Linux on the controller on a hard drive… Then for using the ESP32 to make a mini mac. But I digress.)

The atttiny is available in a through-hole part and is easy to solder, whereas the ESP32 boards are 2mm castellated boards and thus slightly more fiddly to solder.

Sadly 99 out of 100 tutorials for getting started with the attiny84 show how to use arduino for it, but I think this is one of those things that would be clearer and simpler with pure C and leaving out the weight of the whole C++ framework. Here’s a blog post with starting example:

I’d still go with ESP32, myself. The ESP32-WROOM-32 is less than $3 from mouser, and still only $4 from digikey. $10 gives you a breakout board with USB on it for programming. Cheaper than arduino.

I think that except for the schmitt trigger, this board from Bart Dring already has everything you want — takes a $10 board, and uses trinamic drivers which are frankly awesome. I’d see whether the schmitt trigger is necessary before adding it.

So if anyone finds this idea interesting, there’s an ideal platform for it! You could reduce the cost substantially by integrating the ESP32-WROOM-32 and stepper driver chips directly instead of building on dev board and step sticks, but it’s already pretty cheap.

1 Like

Well, part of the desire would be to be able to make such things scalable. I’d think you’d want:

  • Ability to duplicate the M2 Nano’s functionality.
  • Then the ability to add functionality to that scheme, zbed, extruder, pwm control.
  • Eventually the ability to have a thousand of them stamped out and sold on the cheap. Duplicating the wire hookups for the M2 Nano.

I’m also not sure you’d need something the speed of arduino in pure C, pretty sure you can leave most of the power on the table since it doesn’t really require math. It’s a great project, but, I dunno enough hardware. And I’d probably just code it on an Arduino since I have one and it’s basic for hardware noobs like myself. I mean with a little more functionality you’re looking at a board that needs like 10 dollars of chips to compete with a boards that run 250 bucks. Mostly since it doesn’t need gcode or to parse anything harder than an ascii stream, the hardware requirements are really low. Though hands on testing might find some things I’ve missed.

1 Like

Well, you can program the ESP32 with Arduino if you want to, and the C++ doesn’t really make it slower. It’s just if almost everything you are doing is setting up timers, I thought it would be easier not to jump through the Arduino hoops. But it’s all available. :slight_smile:

Bart has other boards with more channels. And with the available space on the ESP32, you could actually have a board that interprets gcode and lhymicro-gl. And has a web front end. For cheap. TMC2209 stepper drivers — a huge cut above the old A4988, and allowing sensorless homing, are $2.74 in onesies from Mouser; $1.59 in thousands

Again, the ESP32 itself is cheaper than the Arduino boards, and you can use the Arduino environment to program for it. I just did exactly that for my wife’s Time Turner.

2 Likes

I think I was tired last night because I got focused on whether the attiny84 would be enough to build a replacement board. If you are using a full-blown arduino, or equivalent large avr cpu, or an ESP32, it makes so much more sense to just add a grbl feature that implements lhymicro-gl as a control language; then you’d have both lhymicro-gl and gcode in one board with one firmware. G6 still encodes text lines for the commands; I think that “switch to interpreting lhymicro-gl” would be an M code.

I wonder whether an argument to M452 Select Laser Printer Mode to select lhymicro-gl would be the “obvious” way to implement this?

Joe, who does some of the hardware stuff, is looking into my idle speculation that if you could get the Arduino to be like the CH341 (apparently there’s a compatibility mode thing with a CH340). You could make the board transparent. Since all Whisperer and LaserDrw see is the CH341 chip, if your first point of contact with the board is a CH341 and you can take 32 byte packets that are \x00 (30 ascii bytes) 1crc-byte, you might just be able to hot swap that board without any software noticing it’s not a real M2.

Since lhymicro-gl is such a low level language it’s harder to write. I have implementations of bresenham-zingl bezier curves so that I can draw pixel perfect curves. Because really, with pretty much raw access, and the ability to break a curve into diagonal and orthogonal moves, you can do that sort of thing. People would have to cook up their own bresenham line draw algorithms.

I have seen these sorts of things offered up before. I think Marlin or something had a special raster language or something in some branch. And while that could clearly work I thought much of the charm of the scheme was getting away from gcode interpretation. But, I could see points where it might be nice to have much more raw access in a sort of gcode pocket dimension. Though, I could make MeerK40t just pump out gcode, and short of some rasters it would tend to work quite well.

3 Likes

My first thought was how to just be able to talk the same protocol. It was then realizing that building it on top of grbl or one of its descendents might make it even easier made me wonder whether it could be bilingual…

For Marlin, do you something different than G6 that just merged? It had been sitting around for a long time.

https://reprap.org/wiki/Direct_Stepping

The gcode just points it at raw data pages.

My idea with the M code I was thinking about would be just to switch it from taking gcode to talking lhymicro-gl, as you suggest doing by recognizing the initial data packet, which seems clever.

I thought a single board that could work with meerk40t, whisperer, laserweb, lightburn, etc would be interesting. And, quite possibly, quite cheap.

2 Likes

I could almost already do that combining a raspberry pi, meerK40t, and and an M2 Nano. I have a couple not heavily tested emulation modes for Gcode. Which when I tried to run projects from the gcode driver in Visicut worked fine. I connected to pretend GRBL server that MeerK40t was pretending to be and ran my design. It cut out perfectly fine. I also have another project to do the emulation of Ruida, which currently turns that into svg path data when you connect to the fake Ruida server rather than directly controlling the laser. I bothered to reverse engineer all Ruida commands and all data properties. I even reverse engineered this weird app protocol Ruidas have. ( https://edutechwiki.unige.ch/en/Ruida#Commands ).

I might have Moshiboards also cracked. I dunno if I could write to a moshiboard and have it fooled (haven’t gotten around to writing and trying that, there’s a half-random half-command character set that might be something else) but I could have a board with some memory pretend to be a moshiboard. though here, it would also need it to look like CH341 chip.

The Ruida thing would work, the Moshi is mostly in jest. Ruida code is a lot better than Moshi code. I also bothered to reverse Leetro code, but didn’t bother beyond getting all the commands.

You could convert most the Ruida stuff pretty easily into a kinda of gcode. It’s not ascii but you if you could get a board to respond on UDP:50200 and 50207 it wouldn’t be that much gcode in general.

I think the only real charm in types of laser code, out there is lhymicro because it’s so entirely bare metal, it seems like higher level command things like ruida, gcode, and moshi, are all going to require some heftier processing. A line draw algorithm at a minimum.

1 Like

Hi David,

Is there a way to adjust the stepper motor steps other than the adjustment for the rotary usine the stock M2NANO board?

Example: the K40 stock steps are 0.9 degrees and if one replaces their X and Y steppers, most likely the steps would be 1.8 degrees.

Regards
Bill

@HalfNormal I think the question is: because the commands from the computer to the m2nano directly turn into stepper steps, the only adjustment would be in the software. Therefore, is there configuration for planar X/Y step rate in Meerk40t as there is for rotary?

Thanks for pointing that out! I answered this question when I was getting out of work and did not look to see where it had been posted! I know @Bill-CNC had been active in another area so I had just ASSUMED it had been somewhere else. Need to be paying more attention. :roll_eyes:

2 Likes

I think Joe’s (other MeerK40t admin) hacked board does a bunch of microstepping. Since he replaced the stepper motor chips with mostly compatible better ones. ( https://www.reddit.com/r/ChineseLaserCutters/comments/f9hw79/tmc2208_silent_stepper_driver_chips_in_stock_k40/ ). But, I’m they didn’t seem like there was an easy way to coax something different out of them.

1 Like

If that’s the actual question, you can go ahead and stretch any design or anything in MeerK40t. You can hit F9 and apply any transformations you want. It’ll give you as close to that as is possible but the steps will still be 1 mil. There’s also the rotary settings to do the stretching as a pre-process operation and you could just select everything and adjust that yourself.

But, 1 tick is still 1 tick. But, the official way to make 1000 ticks equal an 2 inches rather than 1in is to stretch the design 2x in that direction.


If the question is more properly about the step size within meerK40t if you replaced your stepper motor. It’s actually all pretty much defined based on the 1000 ticks = 1 inch dynamic. It would require some fundamental work to redefine the sizes of things if a step was 2 mils rather than 1 or a 1/10th mm step like you’d common find in embroidery.

2 Likes

A post was split to a new topic: X and Y axes do not return to the zero position

I was not sure where to post this info but thought because @Tatarize has done a great job explaining the M2nano board that this would compliment the information. It is actually a repost from Scott Marshall that is found in the G+ posts.

1 Like

Did Scott pass away?? I wondered where he went :(?

Unfortunately that is the only conclusion. Years ago phone calls and emails went unanswered. His website went dark too.

1 Like