MPScara G92 and machine coordinate issues

Update for the Z motion: it compiled with the change to raw.z, and with the microstep correction, it shows that it moves with both arms. Now I have to go finalize the design for the end effector to prove it works, but as it stands, the marlin scara seems to all work correctly.

I'll update to whenever I can get the end effector made and working. Just have to deal with possibly fine tuning cura again after losing all profiles in it since they store them in a stupid location that got deleted.

Thank you so much for the work you've done so far for the niche scara kinematics.

Another update:

Got the parts printed for the Z and now have to deal with the stupid world of hobby capacative sensors. I planned to use the M12 sensor from an old (back when the Ender 3 pro was only 1-2 years old) off-brand TH3D EZABL sensor kit. Well, the optocoupler board bit the dust over a year ago, but the sensor works fine at 6V-24V. With the SKR 3, there is no provisions for such a sensor like the BTT Octopus that I have on another printer.

With that said, the issue simply comes down to it being NPN and all internet searches being the most useless thing in the past six years thanks to ai and SEO. I would prefer not to buy a 5v rated sensor or even a relay since all I have are 24V coil switches, but I have this pack of relays that I could not get to work to save my life since they are definitely more suited to PNP (Relay Here) The pictures attached are the sensor, and don't ask me why the guy from ebay made/got the sensor with the wrong wire colors.

If this can be solved without new parts, that would be wonderful, otherwise I will accept having to buy a sensor and have an extra lying around for no good reason, or buy a relay to deal with this.
This relay I found may work if it comes to it: (Opto Here)

Also, do not worry, I know the Z axis looks ugly. At this point, it just needs to work and that is all. I would try to sell it at some point but people fear custom designs like the plague, and I understand why.

Edited 1 time(s). Last edit at 03/01/2026 04:56PM by Chip Bark.

After finally giving up on the old prox switch and getting a returned clone bltouch that only had the issue of a bur at the solenoid side of the probe, the scara now has a working Z axis and homes the Z correctly.

The attached is the current firmware changes and the first marks with a sharpie. For no tuning and all of the horrible slack in the drives, it is fairly straight. The stair step X for -100 is likely slack, but in the wrong direction so it can be ignored. It also helps the Y resin gear broke a tooth right near the limit switch so it can't home without assistance.

At this point, the machine is free to have any firmware experiments with, but without a complete rework of the drives, it is not worth fooling with. Would love to sell it, but no one would pay for such a POS.

With the cross-talk Z, I didn't notice it lifting or dropping while doing the 100mm move commands, so it seems to work as is.

Again, thank you for all of the help getting this firmware to work. A side question for the polar kinematics: what is involved with a rotating tower style? Is it just defining the deadzone radius and the correct linear travel or is that side of the firmware too under developed still? I know it was fully removed a few years ago with only a polargraph remaining.

Glad it at least got to draw some lines before heading to the scrap heap

The stair stepping is odd... the other lines involve coordinated shoulder/elbow motion too, but they look perfectly smooth.

If you get that gear fixed (and add adjustable idler pulleys, essential for good belt tension), the calibration procedure I use is:
1. Precisely measure the arm segment lengths.
2. Make it draw a rectangle, and if the sides aren't straight and parallel, use M665 to adjust the Y (elbow) home offset, re-home and draw another one.
3. Adjust X (shoulder) home offset to also get it square to the edges of the bed.

Here is the final version of my SCARA code: [github.com]
It took a few days of going in circles, but I think I arrived at the optimal solution. Though considering the number of open pull requests and the dates on the oldest ones, I expect it will be a few years before it gets integrated, and will probably get broken again by then. Sad.

Regarding the polar kinematics, I think the code in polar.cpp does what you want (stationary bed, rotating arm with linear radial motion, like a tower crane). Look for #define POLAR in Configuration.h to enable it. Interestingly, I think the same code will work for a rotating bed with non-rotating arm for radial motion. Just depends on whether (0,0) is at the center of the bed or the arm axis. Makes me wonder if the SCARA code could be repurposed into driving a mechanism like a hard drive, where the rotating bed/disk is one axis, and fixed-length arm on a rotational axis moves the end effector closer-farther from the center of the bed.

Edited 1 time(s). Last edit at 03/11/2026 08:01AM by dekutree64.

I think the stair step was a one off due to either the X jumping from slack to no-slack while the Y was dealing with a rough / slowly deteriorating resin gear.

If I get around to it, a 5:1 or 6+:1 planetary stage from the N34 before the vertical shafts should help a lot with accuracy because I can change the crown gears to nicer bevel gears, even if it means yet more backlash. This would mean the whole column stays the same.

The downside with this design is how to measure the centers since the shoulder is inaccessible with wiring and such. Either way, I may post the files on grabcad/printables some time and let people play with it if they want.

As for the polar, that is good news that is should just work. My design so far has the slew ring motor and two Y motors rotating opposite to extend the axis in a way that would look like a scara but isn't.

And yeah, it is great the pull requests have been made, but even open source projects have long wait times for implementation. In my case, I have 6 printer designs on the back burner, one of which being a fun little tripteron while another is some kinematics I have not seen any hobby printer do yet.

Quote
Chip Bark
The downside with this design is how to measure the centers since the shoulder is inaccessible with wiring and such. Either way, I may post the files on grabcad/printables some time and let people play with it if they want.

Yeah, you may have to partially dismantle it to get good measurements. Remove the distal arm, stick a longer rod through the elbow axis, and measure from that to the large pulley on the shoulder axis. Then subtract the (measured) large pulley radius and elbow rod radius to get the true length.

Also measure the distal arm while it's off the machine using a long rod through the axis, so you can hold the end of the ruler against it to get a good parallel line to the laser emitter rather than holding it at a funky angle trying to measure from the center of the axis while it's fully assembled.

Quote

As for the polar, that is good news that is should just work. My design so far has the slew ring motor and two Y motors rotating opposite to extend the axis in a way that would look like a scara but isn't.

Is the radial motion more like a rack & pinion or parallelogram scissor lift? The former would be polar, the latter is SCARA (see Reprap Morgan)

Quote

And yeah, it is great the pull requests have been made, but even open source projects have long wait times for implementation. In my case, I have 6 printer designs on the back burner, one of which being a fun little tripteron while another is some kinematics I have not seen any hobby printer do yet.

lol, it is addictive designing machines. So far I've done my SCARA printer, a small CNC mill (which can also be used manual), and a headstock to get an old lathe functional, along with various others that weren't good enough to actually build.

Printers (or lasers) are fun because you can mostly ignore stiffness and just make some cool kinematics, but the mill has been by far the most useful of the bunch. Have you made a CAD model of your unusual kinematic system yet? I'd love to see it.

It will certainly be fun measuring the scara. May be best to measure the gear diameter and reference one side, but that will happen one day.

The arm motion is a form of cheating. it has one arm rotate CCW (when above) while the other is 1:1 tied to it going CW to create a linear movement. Think of a parallel robot arm on its side. Then the slew ring base allows it to swing CW or CCW for the angles. The model so far is very lightweight with 100:1 on all axis and full DC servos for what should be <200mm/s speed. If that motion won't work, then I can use scara as a last resort. I have many SW sketches in the model to try and verify that motion will work for linear movement.

And yes, designing is addicting. Since 2015 when I started SW after never using it in my life, I have over 20k files (includes step/parasolid etc) ranging from random stuff to a full tube chassis car design, rc car attempts, and CNC mill designs, along with over 100 3D printer design attempts with only 6 ever being made. If I had the money and space, I'd make more real.

As for what I internally call the cheapskate printer (new 2020 t-slot frame for cheap with ender 3 bed), I don't want to give away the design yet, but the best way to describe it partially is a positraction ultimaker, but without the crossed arms. I'll let you work that out and question why printers never tried it because it is too stupid simple. Attached is a very low res pic of V3. The design is clear in that picture, even with how blurry.

I was and still am quite out there with printer designs. I have a far too big cantilevered polar printer design from 2018, before I ever knew what polar printers were. An older design was to use a scissor lift bed even though no one had the firmware for that back then.

If I had a simple way to post all of my adventures through time in SW in one place, that would be neat, but I'm not going to go out of my way to make a website or anything crazy like that.

Edited 2 time(s). Last edit at 03/12/2026 05:06AM by Chip Bark.

Went and made a quick animation to show how the linear axis on the polar is to work. Distal shoulder tied 1:1 to the center shaft with the red dot (to show rotation) that is 1:1 opposing the proximal arm via 2 Y motors, all 100:1. Don't see why this wouldn't work in polar, even if it brings a possible question of 'why not use scara'. The end effector would be linked to the arms to stay at a constant angle regardless of the arms' angles and not tied to any motors.

With this design, one could link several arm segments together past the distal by using a pair of spur gears to flip rotation and thus 1:1 all future arms like a weird scissor lift.


Also, to the forum mods: apologies up front, but if any of this needs to be moved to a new post, I certainly can.

I think you could use polar or SCARA, but both will require modifications to work.

For polar, set r = DEGREES(ACOS(r / PRINTABLE_RADIUS)) since the physical radius is not directly proportional to the motor rotation.

For SCARA, change it so crosstalk is applied the other way around (elbow motion affects shoulder, rather than shoulder affecting elbow like usual). It's expecting to need coordinated motion to move in a straight line, but since you have an extra shoulder that moves together with the elbow, the real shoulder's motion needs to be cancelled out so it doesn't move even though it thinks it should.

That image of your secret printer is only clear to you, so no worries about anyone stealing it :p And ultimaker is synonymous with crossed rails, so I don't know what you mean if it doesn't have them.

Edited 1 time(s). Last edit at 03/13/2026 06:42AM by dekutree64.

That is good information to have. I'll stick with polar for this for two reasons: The slew bearing works much better for it over scara and it allows the system to, in theory, work with three work spaces.

I highly doubt it, but it would be really nice to have marlin let me choose between three options: first cut size (24" x 60"), second cut size (33" x 33"), and finally a full circle cut using G2/G3 command(s) at a set radius. Of course, lightburn would have to know a work area to begin with along with no communication between it and marlin to know or choose a work volume.

With the whole thing being portable, it seems possible to be able to set it on a plate of steel to set it as the origin of the large circular or square cuts that go much larger than the typical one-sided work areas. Again, highly doubt marlin can do such a thing without reflashing each time, but a person can dream.

As for the secret printer, yes it is not the crossed-arms, just plain rails like a corexy. But the motion is dumb like a ultimaker. Like I said, it is a positrac version of it since they drive their rails directly. Vague, I know. If I attached a picture of the prototype rail, it would make perfect sense. However, since electronics and parts aren't cheap, it will not be built for a long time.

It shouldn't be a problem to use the full reachable area. The bed size defined in Marlin is fairly meaningless to polar/SCARA machines, so it's fine to disable soft endstops (which aren't currently enforced for SCARA anyway) and ignore it. Just don't command any positions outside the maximum radius, or straight line moves that would pass through the middle dead zone (if there is one... your animation looks like maybe not). I think you can set up different virtual bed origins with G54-59, if that's what you want.

Regarding the secret printer, I think I finally see how the Y rails work, and if so that is brilliant. I want to build it :p But I can't afford components either (aside from the fact that it would be rude to do it before you finish yours).

Edited 1 time(s). Last edit at 03/14/2026 02:23AM by dekutree64.

Don't worry, the animation was just to show the motion is linear only. It will not crash through the frame since it needs a 200mm deadzone radius to function.

Also, if you ever wanted to attempt that secret printer, I recommend looking on used sites or ebay for Ender 3's or similar since that is where most of the annoying parts are. The heated bed from it costs more alone than the whole printer used. Control board is the cheap BTT SKR mini, but for mine, it is N23 motors with linear rails from my own E3 when I tried upgrading it just to find out the delrin wheels worked a little better for it. The frame is a 10 pack of 2020 v-slot, so nothing crazy. It is called the cheapskate for a reason. But now you see why it makes no sense that a commercial printer hasn't done this already, especially because it can be done on the ol' RAMPS board that people still (for some reason) use to this day as if the SKR mini isn't cheaper or close to it. The stupid TFT costs more than the board.

I'll have to look into those Gcodes since it will need to possibly talk to lightburn or just use a set of switches at worst.

My SCARA uses SKR Mini E3 v1.2, and I do love the simplicity and low cost. But it would be nice to have swappable drivers so I could use a closed-loop BLDC extruder. I made a stepstick-compatible BLDC driver for that and other potential projects, such as a linear motor printer (perhaps only for X, with ultimaker-style Y axis where a regular motor drives a long rod with two pulleys). I originally wanted Y to use inverted linear motors where the electromagnets are stationary and only push around the permanent magnets for minimal moving mass, but there are some annoying problems with that. I hate drag chains, so I don't want to do moving electromagnets on Y, but since I have to get wires to the printhead anyway, I could include the X motor's wires in the bundle.

I think G10 is used to set the positions, and G54-59 to switch between them. I've only ever used G10 P0 L20 [X Y Z] on my mill, which sets the current position equal to whatever XYZ values you specify. I think P0 corresponds to G54, so P5 would go with G59. I can't remember what L20 means, just that it doesn't work without it. G92 has a similar apparent effect (sets the current position equal to specified values), but is used more as a temporary offset which can be cleared with G92.1, whereas the G10 position is written to eeprom so is permanent until you change it again.

Regarding the G10 and such, I remember when trying to get the RRF firmware to work, some forums brought it up as a substitute to G92. It sets the toolhead position in space, not the machine position. So like on my foreign clone of a clone of a clone 6040 mill, you can zero the tool or zero the machine or both. The L20 was indeed required, but I'd have to read into again. G54-59 I believe was just a set of saved workspace planes in some fashion.

As for the linear motors and BLDC, it is very nice to see someone else get away from the steppers too. I saw a fun video that showed how a stepper and belt pulley is a factor in corexy or normal ringing because the pulley teeth cause the printhead movement to be just different enough on a high/low spot to make the move be microns different but visible in the print. Cable pulleys fix that. I forget which brand it was, but the recent printer that had linear motors on it was a breath of fresh air to see until you look into that being done back in the 60's on a laser with vastly higher speeds and accuracy. Hobby printers just try to reinvent the wheel. Thinking about it, I need to try a design using Gates Micro-V belts, or in other words, serpentine since it has no teeth and thus no issue. Simply needs a lot of tension instead.

I saw in marlin there is a section dedicated to external closed loop controllers with feedback pins. This may help you with the BLDC especially since you can just use the step/dir breakout driver board to go to the controller and then return back with the handshake and position pin, regardless of what the controller is controlling. My oversized (but not big, 300x300) printer uses the step/dir breakout adapter to controller XY closed loop steppers, but I never knew about the feedback thing so marlin doesn't even know they are CL. It did mean they have some very funky steps/mm.

On my big printer design (500x1000), the current iteration uses ~80mm inline skate wheels for everything. Nothing but one small belt to drive two wheels per carriage. Takes up a ton of space, but it simplifies so much.

If it was easy, I would love to have some forum/site where I could post all the files to a lot of my old designs to let people try and finish them or take inspiration for their own designs. Grabcad is the best option, but at the same time, their user base is quite unique and not geared toward 3d printing.

Edited 1 time(s). Last edit at 03/14/2026 03:24PM by Chip Bark.

Not so much reinventing the wheel, rather trying to build a million dollar wheel on a $20 budget And yes, Magneto X is what got me interested in linear motors.

The trouble with any friction-based drive like wheels or V belts is that you need a linear encoder to prevent slip/drift, and then you might as well use a linear motor since that's the most difficult part of it. There are smooth mechanisms that don't rely on friction, like a winch type drive where the cable is wound onto a spool as it pulls the printhead toward it, but that would need a software correction for the non-linear distance per revolution as the cable moves axially along the spool with each wrap. Either that or set it up so the motor and spool (or maybe just the spool, with the motor turning a rail like your design) move in the axial direction with each revolution, so the cable exits at the same point throughout the whole movement range. But that's an awful lot of trouble to correct a few microns of belt tooth ripple.

For sharing of designs, it would be best if you could post a few images of each one, and a bit of text if there's anything that needs explaining. It would be more work than just dumping cad files, but much faster for people to scroll through and see each one versus downloading cad files, figuring out what program can open them, learning the basics of using that program, and opening them one by one. And if you do a hackaday log post for each one, people can discuss them and it all stays organized.

Edited 1 time(s). Last edit at 03/15/2026 01:00AM by dekutree64.

I certainly understand designing on a budget, but there is a limit, like how 8-bit boards are still used with 32 being cheaper in more cases. Like the Teensy 4.1 is vastly faster with clock speeds, but I only know of one guy that makes a cnc style breakout board for it and you have to solder all of the screw terminals. Really, the biggest gripe is how people and commercial have stagnated with designs. No trying servos (I don't count that pitiful N17 board from MKS on the back of a motor as a servo) or BLDC, no trying other kinematics even just for the fun of it. The fun part is, you can find full CMM machines cheaper than some vorons that is way better, excluding the air bearing issue with compressed air needs. Obviously space constraints etc, but there is fun in the idea of it. Plus, the granite surface guarantees a flat bed.

With the cable, you may be able to cheat that and instead use a open end cable with a constant retraction force on one side while using the pulleys for drive and tension, vaguely similar to a forklift mast leaf-chain being fixed to one end. Many ways to do it, but I see your point. I know marlin has a I2C linear encoder option, but the ideal solution is a cnc glass encoder since those are now cheap enough to use, though not $20 hobby cheap. I would love to use those, but I have no clue how to hook one up to a marlin system. With the serpentine belt, I don't think slip is an issue purely because of how much tension it needs, how much surface area of pulley contact it has, and how much HP they're rated for before slip. I'm all for HTD or similar belts, but it is good to experiment.

I find the biggest hurdle with trying new designs isn't the hardware or kinematics, but really the lack of peripherals or interface options with firmwares. If marlin could do RS485, that opens up more closed loop options with less wiring, or other things like EtherCAT etc. I know some can do CAN, but that is about it only for tooling, not drives.

The other massive issue I have is the US 110V system. So many cheap drive options are 220V limited, and I have to really worry about amps. The 500x1000 printer is a nightmare because the whole print bed HAS to be custom made with nicrhome due to the wattage limits, along with all N23 motors being 1.5A max since there is 8 of them.

The hackaday thing is the .io website, correct? If so, I'll look into it at some point.

Yes, the .io website. The .com is more of a news site.

IMO, Pi Pico 2 is the best successor to Arduino. Similar $5 price tag and not-too-greedy company behind it, but much more powerful. And the board layout with a zillion ground pins is really convenient to work with.

Also in my opinion, any closed-loop features are outside the scope of Marlin. Its only job should be processing the gcode and sending out synchronized motion commands to the motor drivers. Then it's up to the drivers to get the motors where they need to be as quickly as possible, whether that's via open loop stepping or closed-loop rotation or linear motion. That's why I made the stepstick design, so you can plug it straight into to many existing motherboards and have it work without any firmware modifications, and without having to figure out where to mount separate drivers like with breakout boards.

The linear encoders on aliexpress look like they output pulses like a regular UVW encoder, but they're sent over differential pairs, which I think will need a little PCB with some opamps to convert them into usable 3V signals for the stepstick. But that's good, because otherwise there would be risk of electrical noise causing phantom pulses on the lines and throwing off the position.

Another potential solution would be to use magnetic tape and some linear hall sensors, but I doubt it would be as accurate. And while noise on the lines wouldn't cause any persistent loss of position, it would cause a bit of jitter.

Or there's the plastic raster strip that inkjet printers use. It comes in up to 360 lines per inch, and the sensors give 4 pulses per line, which works out to 17.6 micrometers per pulse. Not great, but with two sensors positioned so their pulses come at different times, you could double that.

Makes sense with keeping marlin out of the control loop for feedback. I always think of how a proper cnc mill uses both motor encoders and linear encoders to ensure position. The marlin I2C encoder board uses a custom magnetic strip just like a paper printer but with more lines. Another simple option is a simple rotary encoder on the carriage with a wheel (if applicable to the design) to get the same results.

I feel marlin's best choice for future development will be with the direct stepping mode to use an external board or something like the BTT CB1 boards to eliminate onboard planning calcs. I always wondered why marlin or RRF can't have the board load a file, plan it all out, then run it from a calculated motion plan to eliminate on-demand calculations, but I dare not ask how any firmware does the nitty-gritty. If I could get past the file reading issue for a plc, then it is very, very basic runtime since it does nothing but send out commands to external drivers to figure out the moves and get handshakes on move completions.

And yes, the Pi boards are a great alternative for good prices, except the actual main rasp pi 3-5's. Those have gotten a little too expensive. I'm still curious to see where arduino goes since they got bought out and their latest board is begrudgingly focused on ai.

Neat, I hadn't seen that Marlin I2C board before. Too bad the sensor seems to be out of production, and I don't know where to find 2mm/polepair magnetic strip. There's one Chinese seller (8849machinerystore) of 10mm/polepair on ebay for $25/meter, so that plus a couple bucks for hall sensors would do a whole printer, although I'm not sure it would be accurate enough (it says 15-30um). It is an interesting idea to make a separate PCB with sensors and CPU. No concern for noise on analog sensor or incremental pulse lines, and you could use CAN bus to report the position if it's a problem for I2C or SPI (and if your driver has a CAN transceiver).

You certainly could pre-compile the gcode into a raw motion plan format, but the file size would probably be annoyingly large, and you'd lose the ability to talk to the machine via gcode for configuration/calibration/debugging. I'd bet the file size is why it wasn't done before CPUs were fast enough for real-time gcode interpretation. And there's certainly nothing to be gained now that they're even faster.

And yeah, the Pi microcontrollers are a totally separate thing from their computers. I consider the new Arduino owner to be an evil impostor, so it's unfortunate that they also own the code framework now. It's the only thing that makes microcontroller development compatible across platforms, so hopefully it will remain largely unchanged into the future.

Edited 1 time(s). Last edit at 03/16/2026 05:12AM by dekutree64.

I agree with the arduino part. They may have said they won't mess with what was built before them, but I give it a year or two so they let people forget before messing things up.

With the controllers, I also wonder why they haven't bothered to do a LinuxCNC style controller with a Linux system. If it can handle an industrial grade CNC, it could certainly handle a 3D printer along with full feedback loops. I think a lot of it comes down to the printing world being so stuck in the ways of arduino and only nowadays the Pi which is also like how we've been stuck with I3 clones for nearly a decade. How many clones of clones of clones has the ender 3 and pro had?

Finally, got the hackaday thing set up and boy howdy is their UI not friendly. But, there is now a chronological list of 68/118 of the designs within the T name. I excluded CNC designs or T3 attempts for redundancy or non-applicable nature. None of that gets into the other lists of projects from rc tanks to a full car.

Again as said prior, thank you for the help with the scara firmware.