Reprap Forum - Polar Machines, SCARA, Robot Arms

Re: SCARA Plasma Marlin-ArcDroid

alexpqn — Fri, 24 Apr 2026 17:17:57 -0400

Hi everyone, I'd like to know if anyone has made any progress in building something similar to ArcDroid?

Re: MPScara G92 and machine coordinate issues

Chip Bark — Wed, 18 Mar 2026 06:52:49 -0400

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.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Mon, 16 Mar 2026 05:08:07 -0400

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.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Sun, 15 Mar 2026 06:16:40 -0400

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.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Sun, 15 Mar 2026 05:31:10 -0400

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.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Sun, 15 Mar 2026 01:19:09 -0400

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.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Sun, 15 Mar 2026 00:56:20 -0400

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.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Sat, 14 Mar 2026 15:22:22 -0400

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.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Sat, 14 Mar 2026 03:07:44 -0400

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.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Sat, 14 Mar 2026 02:22:38 -0400

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.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Sat, 14 Mar 2026 02:11:58 -0400

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).

Re: MPScara G92 and machine coordinate issues

Chip Bark — Fri, 13 Mar 2026 05:48:02 -0400

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.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Fri, 13 Mar 2026 05:33:06 -0400

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.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Fri, 13 Mar 2026 01:10:48 -0400

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.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Thu, 12 Mar 2026 03:32:41 -0400

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.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Thu, 12 Mar 2026 03:03:27 -0400

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.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Wed, 11 Mar 2026 14:40:33 -0400

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.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Wed, 11 Mar 2026 07:51:10 -0400

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.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Mon, 09 Mar 2026 22:25:07 -0400

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.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Sun, 01 Mar 2026 16:54:57 -0500

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.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Mon, 23 Feb 2026 21:21:39 -0500

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.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Sun, 22 Feb 2026 23:44:37 -0500

Sorry, should have double-checked. It's raw.z

Re: MPScara G92 and machine coordinate issues

Chip Bark — Sun, 22 Feb 2026 23:05:18 -0500

Fixed the Z microstep error. Annoying in a way how it has an array earlier for microstep modes but then each motor has a defined step elsewhere. Side gripe: very annoying that VSC pulls 100% cpu just to build marlin.

Either way, using a lowercase Z, which I tried prior too, still errors:

Marlin\src\module\scara.cpp:173:7: error: 'z' was not declared in this scope
  173 |       z - (THETA1 + THETA2) * (8/(M_PI*2))); //Convert from radians to 8mm per leadscrew revolution
      |       ^
*** [.pio\build\STM32H723VG_btt\src\src\module\scara.cpp.o] Error 1

Here is the same error when copy and pasting your code straight into it instead of prior when I just typed it in for no real reason:

Marlin\src\module\scara.cpp:173:7: error: 'z' was not declared in this scope
  173 |       z - (THETA1 + THETA2) * (8/(M_PI*2))); // Convert from radians to 8mm per leadscrew revolution
      |       ^

Re: MPScara G92 and machine coordinate issues

dekutree64 — Sun, 22 Feb 2026 22:54:12 -0500

Excellent! I wish I'd thought to verify the motor directions sooner.

I'm not sure exactly why the home position is reading -1,-1, but maybe it rounds toward negative infinity if it goes just a touch below zero. What matters is that the home angle values match the physical angles of the arm when it reaches the endstops, and that the arm lengths are measured precisely. When you have it fully calibrated, the resulting home position will be somewhere near 0,0, but not exact.

I think enabling the soft endstops will prevent the runaway motion. I just don't tell it to go anywhere it can't reach.

The fast Z movement is because Z_MICROSTEPS is set to 0 in the Configuration_adv.h you posted yesterday, presumably left from my configuration (I have a T8x2mm leadscrew, so 100 steps/mm is plenty without microstepping). Although it is odd you're only getting 8x more movement than requested rather than 32x. Your steps/mm calculation looks right to me.

The compile error is because z should be lowercase.

It would be a waste of your elaborate mechanical construction, but for the proposed usage it would be easier to have a manual Z adjustment on the end effector rather than using a motor for it.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Sun, 22 Feb 2026 19:41:39 -0500

Big news: after changing the motor directions and the cross-talk back to 0.5f, it moves full X and Y (635,0 & 0,635 respectively) correctly with both arms moving in tandem and no crashing into the tower. When giving a G1 X634, Y634 F1000 command, it moves in what looks to be a very steady diagonal line like it should, other than the slack in the gearing.

Found two things with this: When it homes, it sets home to (-1,-1) and max is (634,634). Not critical, but if I command it to move from 634 -> 635, it freaks out due to boundaries and runs off at mach 2 for a crash. X will likely do the same, but it explains last night's issue since if it assumed a 0 at center, -400 X was 'out of bounds'.

Now for the Z. Without implementing the cross-talk Z yet, it is acting beyond wrong even for cartesian movement. With a corrected 1600 steps/mm (200 steps/rev * 32 microstep / 8mm/rev lead * 2:1 reduction), it is trying to move well over that. If I ask it to move 1mm, it moves a full rotation at the distal pulley, so the motor is doing 2 full revs for 1mm. When homing, the motor runs at about 2-4 revs/sec which is far, far too fast or reasonable. The strange thing is the Z moves fine with RRF, and looking at that config.g, I still had the steps for it wrong at 2800. Regardless, marlin is making the Z odd.

When trying to implement your Z cross-talk code into scara.cpp which was the only place the motion.delta.set showed up, the error is as follows (line 169 - 173):

Marlin\src\module\scara.cpp:173:7: error: 'Z' was not declared in this scope
  173 |       Z - (THETA1 + THETA2) * (8/(M_PI*2))); //Convert from radians to 8mm per leadscrew revolution
      |       ^

Attached is a video of it moving with G1 XY 634 F2000 (It is slow, but it looks like it can handle F10k later) and a video of it homing with the Z issues quite audible and visual. Also, got to love AC lighting and the wonderful wave pattern it makes with cameras.

Still, big progress with it now moving correctly more or less. I only wanted the Z to allow for bed leveling since this was to be portable (25 lbs and cumbersome, but it is portable) for a laser/plasma which needs no Z movement, but helps for a skewed work plane.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Sun, 22 Feb 2026 04:03:29 -0500

Hmm, maybe only X should be inverted then. EDIT: I just checked and you still have Y inverted from my configuration, so set X true, Y false, and both home directions positive.

From what I can tell in the code, software endstops aren't really used on SCARA. When it's enabled, any XY positions outside the arm's reach will be "pulled in", but that's it. Personally I think it would be better to also enforce the XY min/max values, and "push out" any positions too close to the shoulder axis (to the MIDDLE_DEAD_ZONE_R value that's currently only defined for MORGAN_SCARA), and perhaps just hold the current position if the target is almost directly on the axis where pushing it out would cause numerical accuracy problems. But I'll probably leave it alone for now and focus on getting the critical fixes integrated into the main branch first.

1:1 on the Z intermediates is good. In that case, I think you can just do this

    motion.delta.set(
      DEGREES(THETA1),
      DEGREES(THETA2 - THETA1 * SCARA_CROSSTALK_FACTOR),
      z - (THETA1 + THETA2) * (8/(M_PI*2))); // Convert from radians to 8mm per leadscrew revolution

Delta requires movement of all motors for Z, so hopefully SCARA will call its kinematic function for Z-only moves too. Homing may still be a problem since we disabled the SCARA bit in do_homing_move so each axis motor moves separately (Z probably won't get the correction). But if we re-enable it, then it's impossible to disable the elbow motor while homing the shoulder, so the arm can crash into itself depending on where it starts from. Same with quickhome (which moves both motors simultaneously), plus then the elbow may get a wrong value if it reaches its endstop first and then the shoulder continues moving and crosstalking it to a different angle. I suppose in the worst case you could use quickhome and manually position the arm in such a way that it will reach the shoulder endstop first.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Sun, 22 Feb 2026 02:16:21 -0500

I am glad to have the machine be a guinea pig since it didn't work otherwise. Attached is a section view to show all three reductions. 7:1 for both X and Y, 2:1 for Z and 1:1 for all Z belt moves. Ideally the Z motor would be on the distal arm, but I was determined to use three N34 motors just to use them, thus this horrendous mess of bearings for a tri-axle concentric design.

With that, the motors assuming false inverting is CW from the motor, then due to orientations, X is CW on the arm, Y is CCW by default. I'll invert the motors when I can and invert its homing to match since it homes correctly.

After that, with cross talk being likely 0.5, it will be a fun time getting X and Y to move together for Y moves. I wonder if it would be good to re-enable the software endstops since the 0,0 on a corner is the ideal goal?

As for the Z and the double cross-talk, it really makes me with the firmware, both marlin and RRF, has options to simply say: if X AND/OR Y AND Z, add motion accordingly, else just Z. But alas, I doubt the firmware would be happy with an if statement in the motion calcs like that. If all else fails with Z, I can ignore it entirely for the purpose of the laser, or use the motor for something else on the machine. No clue what other function it would use a stepper for since a print head is only good for large flat parts. I dare not do that without a heated bed.

All the while, I get to keep working on the Tpara design slowly but surely since hopefully its firmware will go more straightforward, but something tells me it won't.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Sun, 22 Feb 2026 01:48:19 -0500

Quote
Chip Bark
One question I had when going through config.h was SCARA_HOME_DIST_TO_NOZZLE. I put the number in as the direct diagonal distance from shoulder axis to nozzle at 0,0, but if it needs to measured some other way or if it is ignored fully, then so be it.

lol, I intentionally didn't explain that so I could use you as a guinea pig, and apparently the comment above it is not clear enough after all :) It should work with 352.6486, or you can ignore it and just set THETA2 to (90+130.976) or 220.976 like before. I calculated THETA2 that way since it's easy to measure the shoulder-to-nozzle distance on my printer after homing, whereas measuring the exact elbow angle is not. But I'll probably just remove that value entirely. I added handling of the M665 values for MPSCARA since then, so now it's easy enough to start with the nominal elbow angle and adjust while printing rectangles until the lines are straight and square, rather than trying to get it perfect by measuring the printer itself.

Quote

Another point is, like with the confusion on RRF firmware, the offset theta: is it based on X axis to the right (when looking down on the machine) or is it on Y towards up? RRF is the former, but I want to say Marlin was the latter.

Positive X is right, positive Y is up, zero angle points to the right (along positive X), positive angle rotates counterclockwise. So there is still a problem with the configuration if it's moving in the opposite directions. Is it possible your motor directions are wrong? You could try setting INVERT_X_DIR and Y to true, or to be more certain, compile it as a non-scara printer and see if positive X and Y moves cause counterclockwise motion like they should.

I think you're right that your machine should have 0.5 crosstalk. I didn't realize there was a 2:1 reduction between the intermediate axis and the elbow. Mine is 40:60 from intermediate to elbow, and crosstalk factor 0.333, so I think the formula is 1-elbow/intermediate, which is 1-0.5=0.5 in your case. And MPSCARA has equal teeth on the intermediate and elbow, giving 1-1=0 crosstalk. Crosstalk factor 1 is for designs where the elbow motor rides on the proximal arm, so 100% of shoulder motion is applied to the distal arm as well.

Now that I think about it, your Z axis probably has crosstalk too, since it uses a similar pulley system to the elbow. And it will be even more confusing since elbow motion affects it too... What are all the reduction ratios involved? Motor to shoulder intermediate, shoulder intermediate to elbow intermediate, and elbow intermediate to end effector. The code for it should go in inverse_kinematics where it calls motion.delta.set. But Z-only moves may not work properly, and would be difficult to figure out where all you'd need to insert the correction...

X_HOME_POS and Y shouldn't do anything. When the SCARA_OFFSET_THETA are defined, it uses the forward_kinematics function to calculate the cartesian home position from them.

Re: MPScara G92 and machine coordinate issues

Chip Bark — Sat, 21 Feb 2026 21:55:12 -0500

Thank you very much for the files. Going through them and making the changes for this machine has allowed it to finally home and move under command from the tft. But now a new issue has come up, of course this is all testing.

In the picture, all black text is what is the goal for it to be. Red text is what it is doing. Right now, it lets me move any amount positive or negative, homed or not. Not sure if that is specific to scara, but I did comment out all bed_center_0 defines. Next, X moves in what looks to be straight with a cross-talk of either 0.5 or 1.0 (36T:72T reduction, so I think it should be 0.5, but it is currently 1.0). Y however just rotates and X is stationary or barely moves if at all.

With the picture, the red text matches the tft screen where 'up' (Y+) is Y- and X+ is correct on screen, but the arm goes the wrong way: X- moves rightward. Z needs tuning elsewhere since it sounds like it is bound up when it isn't, but that isn't for the scara aspect.

X_HOME_POS and Y was set to 0 with max at bed size to try and set 0 at the corner, but I guess it isn't happy with it.

One question I had when going through config.h was SCARA_HOME_DIST_TO_NOZZLE. I put the number in as the direct diagonal distance from shoulder axis to nozzle at 0,0, but if it needs to measured some other way or if it is ignored fully, then so be it. Another point is, like with the confusion on RRF firmware, the offset theta: is it based on X axis to the right (when looking down on the machine) or is it on Y towards up? RRF is the former, but I want to say Marlin was the latter.

Another freak of nature thing it is doing which I find very odd is that at ~400mm commanded X, it moves normally for a bit then suddenly rockets off at way too fast a rotational speed until crash. Y does the same but at ~200mm. No clue why. It is as if the inverse kinematics is randomly ignored after a point and just runs a set speed on the motor. It doesn't accelerate when doing so, just jumps up to the new fast speed and full sends it to a crash. Note that all motion tested has been purely with the tft and no terminal or terminal in the tft. Large moves are simply a few 100mm moves clicked in succession.

In the end, the tft isn't critical for the UI since lightburn is the ideal final user interface once all is working, but if it can't work pure marlin, it won't work otherwise. At least now there is progress being made. Now I get to hope some stragglers will wonder over to my other post regarding a planetary gearbox design of mine for these N34 motors.

Re: MPScara G92 and machine coordinate issues

dekutree64 — Sat, 21 Feb 2026 02:07:00 -0500

Ok, I've got the latest version running now. Try changing the preprocessor check in do_homing_move from ANY(MORGAN_SCARA, MPSCARA) to ENABLED(MORGAN_SCARA), and the one in set_axis_is_at_home from ANY(MORGAN_SCARA, AXEL_TPARA) to IS_SCARA. My clean pull gave a failed to home message the first time I ran it, and I think that's what fixed it.

If that doesn't work, here's my full source code and change log. Most of the configuration edits are specific to my printer, and some are just my personal preferences. You'll have to copy the src/lcd folder from the main Marlin repository because someone got the bright idea to put 50MB of image data in there, so I had to exclude it to keep the filesize reasonable here.

There's a force setting of BED_CENTER_AT_0_0 in Conditionals-5-post.h if IS_KINEMATIC is true (which it is for SCARA). Comment that out and I think it will work with center at bottom left, but I didn't actually test it.

Changes to Configuration.h:
Modified MOTHERBOARD, SERIAL_PORT, and BAUDRATE
Changed X,Y,Z,E_DRIVER_TYPE to TMC2209
Modified SCARA settings
Modified DEFAULT_AXIS_STEPS_PER_UNIT, DEFAULT_MAX_FEEDRATE and DEFAULT_MAX_ACCELERATION values
Enabled CLASSIC_JERK (won't compile SCARA without it)
Modified Y_HOME_DIR
Modified bed size and min/max pos
Disabled software endstops
Modified HOMING_FEEDRATE_MM_M
Enabled SD_SUPPORT
Enabled CR10_STOCKDISPLAY

Configuration_adv.h:
Edited values around line 944 (SENSORLESS_BACKOFF_MM and such)
Disabled ENCODER_RATE_MULTIPLIER (my STM32F103 is pretty slow and often misses encoder pulses, making the menus very difficult to navgate, and even worse if it can suddenly jump 100 units when you don't expect it)
Disabled SHOW_BOOTSCREEN
Changed EVENT_GCODE_SD_ABORT to M18 (disable steppers)
Edited trinamic driver current and microstep settings
Enabled sensorless homing and modified x/y stall sensitivity
Enabled IMPROVE_HOMING_RELIABILITY

Conditionals-5-post.h:
Disabled QUICK_HOME in the IS_SCARA section
Added SCARA_CROSSTALK_FACTOR default settings EDIT: Upon further review, morgan should also have 0 crosstalk

motion.cpp:
In function homeaxis, changed ANY(MORGAN_SCARA, MP_SCARA) to ENABLED(MORGAN_SCARA)
In function do_homing_move, changed ANY(MORGAN_SCARA, MPSCARA) to ENABLED(MORGAN_SCARA)
In function set_axis_is_at_home, changed ANY(MORGAN_SCARA, AXEL_TPARA) to IS_SCARA

scara.cpp:
Copy-pasted my scara_set_axis_is_at_home, inverse_kinematics, and forward_kinematics

G28.cpp:
Added my DISABLE_AXIS_Y code bit, as before