Oh god I remember exactly what is going on there. That’s a bug.
Both stepper drivers share a single enable pin because we want to enable them at the same time. The problem is that for some reason FluidNC requires that each stepper driver have a unique enable pin so I assigned that one to 38 just because it was a pin that wasn’t connected to anything. To use it for something else we’ll need to figure out how to get FluidNC to be happy with that enable pin being the same between both drivers. Maybe we can set the second driver to not use an enable pin?
I have noticed that the Z motor which is opposite the dust collection area (see photo) is hotter than the one that is surrounded by the dust collection 3d printed port. I think that with all the air leakage between the 3d printed part and the sled, enough air is getting pulled past the motor to cool it a bit (I have felt the air with my hand when the machine is not running). The motor is not so hot that you can’t touch it but it is very warm. For the longevity of the motor maybe there is a way to redesign the dust collection to pull air around both motors to cool them.
I noticed this because, after a few operations, I realized that one of the motors was cool to the touch and the other was hot. I have not tried swapping the motors to see if it is that specific motor that runs hot or if it is because of the placement.
I’ve been playing around with settings and reading up on what I can, but this is definitely not an area that I know much about, so mostly I’ve been walking around like a blind person, occasionally hitting a wall and redirecting myself from there. With that being said, I may have stumbled upon something that works (or at least appears to work based on my limited perceptions).
I used the GPIO dump command in the GRBL command prompt and received the following info:
With that list, I started testing various pins in the list that didn’t appear to have anything associated with them (I backed up and made a test version of the yaml file before making changes). I tried changing the “motor1” direction pin to various pins that on the list that do not have anything in the list following the pin number. I then loaded the changed yaml and checked for errors. From that, I did not have any errors show up when setting the direction pin to gpio 40, 43, or 44. I’m not sure what those pins are already being used for, but, at very least, the machine booted fine without throwing any unusual errors. It’s definitely possible that errors could show up later during actual use though.
That’s quite interesting. I was worried that it would be the other way around when I was designing it and almost added and extra air hole so that the dust collector could pull air from around the lower stepper motor to keep it cool. I thought it would be the hotter one since it’s more enclosed. I’ll keep an eye on that!
Unfortunately I think that all of these have drawbacks (although they might not be obvious at first) 40 is connected to the fault pin on the motor drivers which lets us detect if they over heat, 43 and 44 are used for USB communication so when using the machine over WiFi they wouldn’t have an effect, but the USB port wouldn’t work
No I did that with a jigsaw and an anglegrinder and besides, the maslow was broken at that time
I think aluminium cutting needs active cooling or lubricating of the bit. so i think its going to be a mess.
I wanted to echo the observations on the top stepper motor heating up. I also experience this and just bought a spare motor while ordering the new cable type gear to see if this was motor specific or not. The airflow theory make sense though.
I have no idea how to go about it but I would really love a better way to zero out the z-axis after bit changes. It is super challenging making sure that z-axis is consistent when utilizing multiple bits for a project. Seems like a very common request I have seen in the forums.
Incorporating a way to hang the sled would be nice as well.
I have no idea how to go about it but I would really love a better way to zero out the z-axis after bit changes. It is super challenging making sure that z-axis is consistent when utilizing multiple bits for a project. Seems like a very common request I have seen in the forums.
one of the things on the to-do list is to figure out how to configure a GPIO as
a touch sensor, one wire to a clip on the router, a second wire to a flat metal
thing (a ruler or L shaped piece that you can slide under the router)
Incorporating a way to hang the sled would be nice as well.
The DC ground is also tied to the GND pin on the AC plug through the 24v brick. This means that any and all noise gets coupled to GND as well, potentially interfering with analog measurements.
The ethernet version of the mag sensors, would benefit from having the unused pins tied to GND on one side. this is pretty easy to do, and cuts down on capacitively coupled wire right next to signal lines.
The board would benefit from dielectric grease on plugged connectors, to keep dust and dirt out of the ports. Could also use water tight connectors or other connectors that have a gland.
Because of the proximity of the control board to dust and debris, a conformal coating to protect the board from particulate buildup would help keep conductive and static electricty carrying material from accumulating on the board. In particular HDPE, aluminum, and composit wood products are all of concern.
If no one suggested this, Z motors with encoders would be nice as open loop Z control does not seem sufficient. Mine have gone out of sync and smashed a few bits due to the machine losing its z as one stalls thanks to uneven belt tension.
I know there is talk of maths updates and the like, but nothing stays calibrated forever.
If no one suggested this, Z motors with encoders would be nice as open loop Z control does not seem sufficient. Mine have gone out of sync and smashed a few bits due to the machine losing its z as one stalls thanks to uneven belt tension.
Encoders don’t report positions across power cycles, so you still need to home
them periodically. Witht he older maslow, we were begging for Z stepper support
as it’s pretty low swpeed and motor/encoders are much less available for lead
screws than steppers.
I think it’s far more important to bottom out the Z periodically than it is to
retract the belts (the Z is more likely to get turned manually)
I believe that the stepper drivers we are using do have the theoretical ability
to detect missed steps (don’t know how well that will work in practice with a EM
noisy router right next to it)
@dlang I guess you mean current sensing for stall detection? That is already used for the belts so worth a try. I was a bit lazy to check but I guess the Z drivers just use PWM pins on the ESP32. I would say if EMF is a concern then encoders are a more robust way of detecting missed steps since you just use another digital pin, depends if it is cheaper to integrate new motor drivers for current sensing or upgrade the motors.
@bar, based on what @dlang mentioned on EMF, has a metal PCB shield plate / box been proposed? Again did not check the ground plane of the PCB but even if its great shield plates are pretty common for micro electronics placed close to magnets or RF sources like the games consoles that used to sit next to old tube TVs and VHS players.
Also if it has not been proposed, maybe it is worth actually doing EMF testing of the PCB at one of those facilities? Then there could be some certainty on the topic.
@dlang I guess you mean current sensing for stall detection? That is already
used for the belts so worth a try. I was a bit lazy to check but I guess the Z
drivers just use PWM pins on the ESP32. I would say if EMF is a concern then
encoders are a more robust way of detecting missed steps since you just use
another digital pin, depends if it is cheaper to integrate new motor drivers
for current sensing or upgrade the motors.
steppers don’t work with just PWM drivers, they need a couple of H bridges at
the very least.
the maslow.yaml file specifies tmc_2209 drivers for the Z
Those drivers have a stall detect and load measurement capability, so, is it that we dont have software drivers taking advantage of this or is the sensitivity just not enough for motor sync? I guess the first since if we were detecting stalls then the lead screws wouldn’t continue trying to drive the sled down at actual z bottom / z bottom could be auto measured. This could also be used to detect z errors.
I don’t know if the board is wired in a way that will allow it to work ( see TMC2209 Pen Laser V2 | Wiki.js where they
talk about needing to connect a couple of pins to make it work)
but in any case, the current maslow.yaml file has them configured for
StealthChop which is quieter, but less powerful than CoolStep and does not have
the ability to detect stalls.
@bar, can you comment on if the wiring is setup to allow this?
One thing is that I only see one uart configured, and I thought that was exposed
to the outside world, not connected to the stepper drivers
@dlang hmm, that note is pretty helpful in that it says its not recommended for Z stall detection (and I suppose motor sync) due to it being not effective at slow speeds. However, it might be nice to use anyway since z does stall quite readily in the current mode. If the PCB is wired to support it, than it might be interesting to experiment with using the brass lead screws if the additional power of CoolStep would mince the POM ones on a stall.
