Regular sheet steel would be fine. Just before I found out about your revised Maslow I bought a Makermade M2, and that has a steel sled which could probably be a decent source of inspiration given that they borrowed your design to begin with.
Steel is real, toughness and tensile strength is beyond compare from the standpoint of injection molded ABS.
I could take some pictures of the steel sled parts tomorrow if you like. Everything is still in the box it was delivered in.
I would be curious to see that. The photos on their website look like it’s CNC cut wood.
I was wrong, the sled is indeed made from plywood, but it does have extruded aluminium rails for mounting stuff, and all the brackets and the Z axis assembly is very solid metal.
Overall I would say that this has a higher build quality than my assembled yet untested M4, but the M4 seems capable of much higher precision.
All the parts are either steel or aluminium except for the actual sled. The router clamp is very solid aluminium.
Also throwing in some pictures of the rock solid corners my friend made for me.
I was wondering the same thing! I’m still getting familiar with the firmware source, but I don’t think GPIO 39 can be put to work without a corresponding firmware change. The issue I see is code that randomly blinks the Ethernet LEDs/GPIO 39 - I guess it serves as a hardware-based visual cue that the machine is alive/running through the main event loop?
Well if that did get reassigned in the firmware as a direction pin for the Z Motor it would possibly serve as an indication of when the z motor is going up. Based on what I was seeing when I was monitoring gpio 38.
It’s 38 and 48 which are the Aux pins.
We do have the option to do something cooler with the ethernet LEDs though if anyone has a suggestion for when they should turn on or change brightness or anything.
Our MakerMade sled is made from 3/4” plywood. Rosewood to be exact, since it’s a hardwood that falls around ~1500 on the Janka Hardwood Scale and it’s native to SE Asia, where we source the plywood sheets from. More expensive than other woods, but it’s a solid build.
I’ve been using both the M2 and the Maslow 4. I have my accuracy dialed down to a little less than 1mm on the M2. The far corners can still cause problems depending on what frame you build. All our kits now come with 15-foot chains that will accommodate our XL frame. You can cut the chains down for various frame sizes.
When I use my Maslow 4 horizontally, the accuracy is about 0.5mm. The few times I used the Maslow 4 vertically, it was difficult to connect and reconnect each time I had to cycle the power. But my vertical cuts were about the same as the M2 (slightly less than 1mm).
—t.j. Weber
tj@makermade.com
Maker Made & Sourcery
For the mama mia sets?
Bar wrote:
It’s 38 and 48 which are the Aux pins.
The problem was tht 38 was used as a placeholder to satisfy fluidnc about having
a unique enable pin per stepper, so now that placeholder can be reallocated as
one of the LED pins, and 38 can be used for a relay or touch sensor
David Lang
Right! I think that GPIO 43/44 could also be good contenders. They are used to run the USB OTG port on the ESP32S3 dev boards so I had them listed as “do not use”, but since we don’t have that connector I think we could move it over to one of those and be safe.
Edit: On our ESP32S3 module those pins aren’t even exposed, but we can probably still drive them safely.
I think that there is probably a way to make FluidNC happy with the same EN pin being used for both motors which is really the right way to solve it
I am curious, after looking at the board schematics and the yaml file, why are two z motors defined in the yaml file when it looks like the two motors share all the same pins from the esp and there is no independent feedback from them to the esp. Can we get away with only listing a single z motor in the yaml? Again I could be reading the schematic completely wrong.
The trinamic drivers are smart so we can talk to them over I2C (or something similar) which is a neat feature because we can say turn up the power if we want the motors to hold harder (at the cost of more heat), the problem is that we have to talk to them independently (they each have their own address). They do share an Enable line though which for some reason FluidNC isn’t happy about. I bet that there is a way to make it happy…editing the FluidNC code directly is always an option
Been wondering if the M4 would get slightly higher accuracy if the belt drives and sensors could be mounted on each corner, and the pins had fixed positions on the sled.
All with a specified distance to surface so there is less variance in belt length per distance traveled.
Do not see any reason to why the circuit boards should be on the sled this way.
This would also probably have the side effect of increasing reliability because of reduced exposure to vibrations and dust.
When/if you need to remove the sled there could be a function to give the belts a fixed amount of slack.
The issue then is that if the system rotates or gets torqued at all the router bit will move leading to inaccuracy.
Check out the Cubio X, I think that it’s basically what you are thinking, right? So it is totally possible to do it that way.
https://www.kickstarter.com/projects/cubiio/cubiio-x-portable-cnc-robot-for-makers
They don’t have automatic calibration, I’m not sure it’s possible with that setup, but I could be totally wrong about that
Bar wrote:
Right! I think that GPIO 43/44 could also be good contenders. They are used to run the USB OTG port on the ESP32S3 dev boards so I had them listed as “do not use”, but since we don’t have that connector I think we could move it over to one of those and be safe.
Edit: On our ESP32S3 module those pins aren’t even exposed, but we can probably still drive them safely.
I think that there is probably a way to make FluidNC happy with the same EN pin being used for both motors which is really the right way to solve it
That would be ideal, but if not, having a LED light up when the steppers are
enabled is not a bad thing.
David Lang
Isn’t that the same as this other project I saw some years ago where they used a thin steel wire to measure distance, and the router was positioning itself using rubber screw drives?
Or am I mixing it up with the one that used a specific fluorising tape for positioning?
Oh! And there was that one design you had to move yourself but the router moved itself in the sled to make the cuts as programmed?
So hard to find those things again, at least you have a name that stands out.
KaffiMann wrote:
Isn’t that the same as this other project I saw some years ago where they used a thin steel wire to measure distance, and the router was positioning itself using rubber screw drives?
Or am I mixing it up with the one that used a specific fluorising tape for positioning?Oh! And there was that one design you had to move yourself but the router moved itself in the sled to make the cuts as programmed?
So hard to find those things again, at least you have a name that stands out.
you are thinking of the shaper, that has a router that can move a small distance
and knows where the main body is via cameras and dot patterns, then moves the
router wihtin the main body to cut accurately as long as you move the main body
‘close enough’ to the right line.
The one Bar is referring to has 4 spools in the sled, one at each corner.
I would like to experiment with the maslow 4 electronics adapted to such a
system, but we need to first focus on the fixes that we know we need now before
we complicate things more.
As bar says, trying to do a calibration where sled rotation changes the belt
lengths is FAR more complicated, and I’m not confident that we are doing it
right for the simple case we have where the arms all point to the center of the
sled.
David Lang
I understand, pretty sure those are just for referencing the position and it is using some sort of wheels for propulsion, like another design I saw previously that used thin steel wires for referencing the position and rubberized screw drives to move.
I think the problem you are talking about in terms of reference position relative to physical centre of sled could be solved using 2 pins, one above and one below with 2 belt connection points for each pin, another sensor should be added to ensure proper orientation. Motorised drums placed at suitable locations and the belt is going through a fixed pulley close to the belt sensor.
Behold my MS paint skillz! 
Fairly certain this should be possible using 1 extra sensor to ensure proper rotation, and the 2 pins will always have a fixed distance to the router bit.
Not sure if this is a good idea or not, brainstorming can generate a lot of noise sometimes.
KaffiMann wrote:
I understand, pretty sure those are just for referencing the position and it
is using some sort of wheels for propulsion, like another design I saw
previously that used thin steel wires for referencing the position and
rubberized screw drives to move.
Nope, I dug into it and it’s 4 gt2 belts with motors and encoders (very similar
to the maslow)
There is probably another one out there that works as you are thinking, but
that’s not what Bar pointed at.
I think the problem you are talking about in terms of reference position
relative to physical centre of sled could be solved using 2 pins, one above
and one below with 2 belt connection points for each pin, another sensor
should be added to ensure proper orientation. Motorised drums placed at
suitable locations and the belt is going through a fixed pulley close to the
belt sensor.
how sensitive is you orientation sensor? will it work when vertical, tilted, and
flat?
If it’s off by 1 degree on a 16" sled, that translates to the pins being out of
alignment by ~3.5mm. Is the sensor affected by the magnets, wires, etc on the
sled?
by putting the spools on the frame rather than the sled, you now have a lot of
additional wireing to handle (since you have sensors on the sled, at least one
wire needs to go to it)
There’s also a lot of complexity eliminated by keeping everything active on the
sled with the frame/anchors being passive devices
not saying your approach can’t work, but explaining why the maslow 4 was
designed the way it is.
David Lang
