Hey guys here are some of my thoughts on what could be improved for the next m4 run. Feel free to add your own thoughts.
Please add bolt holes for a 3d printed handle to the M4.
Consider adding a limit switch to the z axis so we can bottom out the machine and set the zero electronically without going off the sound of the motor clicking.
I really like the idea of having a handle. It can be awkward to move around.
Would the handle be on top?
Edit: Oh I see it! 
I actually think a handle over the top would be best (at least for the uses in my head). A good place to connect could be to the top router bracket/clamp near the top and bottom support arms and going over the top of the router.
I’d be really careful of adding a handle and to where. I’m think torsional forces applied to the base of the handle would eventually crack the sled. Especially on a vertical set up.
+Signal drivers for the encoder to mainboard to make the signals less susceptible to interference and allow for long JST terminated connections so users can choose to isolate the mainboard from the M4 unit
I was looking at some of the signal driver options that are out there and they mostly seem to be good at overcoming the inductance and capacitance of a long wire (IE they can push more current) but they don’t really offer much in terms of EMI protection. Unfortunately our wires aren’t long enough for them to help (looking at the signals on the scope we’re getting nice square squrewaves)
Bar wrote:
I was looking at some of the signal driver options that are out there and they
mostly seem to be good at overcoming the inductance and capacitance of a long
wire (IE they can push more current) but they don’t really offer much in terms
of EMI protection. Unfortunately our wires aren’t long enough for them to help
(looking at the signals on the scope we’re getting nice square squrewaves)
pushing more current will make any interference smaller relative to the signal,
so it may help.
are there drivers that support differential drive signals? that helps a LOT with
interference (as the interference is the same on both wires, while the signal
isn’t)
David Lang
Yes and no. There are no differential drivers for I2C because it’s not a differential protocol, but it would be an option to switch to a CAN bus. We had a meeting with AMS (The encoder chip manufacture) to talk about that idea since a lot of their customers are auto companies. They tried to talk us out of it since the only way to do that is to add a dedicated micro controller to each encoder board to do the I2C to CAN conversion. It would be an option for sure, but they’re pretty confident that other folks are using their chips in more extreme settings without issues
@bar, has the vendor had one of their applications engineers review the design? I’ve often seen really useful feedbacks from efforts like this.
They did and they suggested lowering the pull up resistors values (which we are testing) but other than that they didn’t see any issues
Here are example of I2C Slave Device Extender Over Rugged Differential Link
LTC4431
PCA9615
nxp . com/docs/en/data-sheet/PCA9615.pdf
And spark fun got devboard
sparkfun . com/products/16988
You still use the Ethernet cable and make sure you actually use a twisted pair from the cable 
Those are pretty sweet! I hadn’t seen that one. I’d only seen the ones like this which just boost the power of the existing I2C signal.
The LTC4431 would be an option for sure although it would add like $50 to the price of each machine which would be a bummer because even at quantity they’re expensive.
I’m also 95% sure that the encoder issue that we are seeing is caused by the Ethernet cable connector being intermittent not actually EMI issues.
We do have a separate EMI issue where a lot of EMI can cause the ESP32 to crash, but that’s a known issue with ESP32s when using wifi and it’s the ESP32’s internal antenna which is the pickup so there isn’t much we can do about that one. Luckily anti static dust hoses seem to fix it, and hopefully a more robust connector on the encoder lines will fix the encoder issue
This is a great suggestion, it should help
And regarding changing the Ethernet cables with JST terminated connnectors, maybe also consider shielding the wire and maybe twisting the wires too
A pretty easy suggestions, add four arrows, notches, or something around the edges of the sled to help when lining things up and homing. E.g., you could jog the sled down to the bottom-left corner of a work piece and line up the top sled arrow with the left edge of the work piece and the right sled arrow with the bottom edge of the work piece and then home the machine quickly and accurately on the corner of the piece.
I was thinking g of suggesting the same thing, I have painted two of these marks on my sled for this purpose.
Nice! I don’t always trust my accuracy (especially centering angles on a circle), but, given the hexagons, it shouldn’t be too hard to get close enough.
I was thinking about making the sled have less friction for future. And I wonder if using PTFE plastic would help. its very slippery stuff.
Are you on a vertical frame or have it horizontal? I could definitely be wrong, but I think a certain amount of friction is intended in order to keep good cutter contact and sufficient pressure.
I’ve tried both frame orientations. While I’m not an expert, I’ve noticed a significant difference between the downward force along the Z-axis (weight/pressure) and the friction that occurs when the sled catches an edge as the X/Y axis moves. Based on this, my deductive reasoning leads me to believe that reducing friction between the sled and the workpiece could help minimize chatter and prevent sled lift.
