ideally we would want to support both the standalone and the spi mode (the spi
mode allows for the detection that the stepper has run into the end of it’s
travel without needing limit switches), as that would let us use any stepstick
module, but since we are using spi for the encoders, if we only supported that
it wouldn’t be the end of the world.
That still requires 2 parts to mate though if I am looking at the right part. I was thinking something more like this 1824460000 Weidmüller | Connectors, Interconnects | DigiKey through hole, but for good reason, they are robust. Wires do not accidentally pull out. I’ll keep looking for SMT. You just push down the tab and stick the stripped wire in the hole. Same to remove it. I work with high school kids using these all the time, pretty fool proof as long as they dont let stray strands touch.
When SPI fails due to cables it is usually due to too much capacitance in the cable limiting at high speed, not shielding. A differential driver inserts propagation delay. What kind of signal and environment did you test the encoders in?
We started using ferrules in March and like them. I tried to get other teams using them and there was a lot of pushback about unnecessary cost and labor. Their tune might change if they short the FPGA.
Is the disconnect force high enough on the Phoenix? I don’t see any locking tabs. I’ve tried some off brands that slide apart under their own weight. If someone doesn’t zip tie a motor cable and the plug disconnects while running, what is the worst that could happen? Sled runs off the workpiece, sled jams and bit starts a fire. Maybe our current sense should check for under current as well to sense disconnects and shut down safely.
Thinking further about this, if we’re talking about the Z motor, we could route the Z motor control signals to a header in parallel with the L298 for that channel. A firmware setting would choose whether the firmware sends PWM /ENable to those pins for the L298 or STEP/DIRection for a stepper daughterboard. I don’t think the L298 would interfere with the stepper signals and the header would take very little board space. The encoders specified don’t use the MOSI signal, so SPI wouldn’t be as easy to handle. The stepper control signals are almost a ‘gimme’, though.
it doesn’t make any difference to the software, layout the board to support the
on-board antenna (hanging off the end of the board the module is soldered to)
and you support both versions.
default to on-board, that will work for most people, separate antennas are one
more thing that can go wong for them but there should be a special order
option for a few bucks more to get one with an external antenna for those who’s
shop is a significant distance from their house and it’s wifi (the built-in can
still be made to work, with an extra AP involved to relay the signal or with
purely local connectivity (no Internet) but it’s far better to be able to hook
up a high-gain antenna if you really need it.
very low holding torque (so it’s not a worm drive). you would have to add
absolute mode encoders to the output shaft for this (or at the very least, an
index pulse)
Looking at the BOM for the ESP32 DEVKITC-V4 with a 16MB version of the WROOM-32D, the parts would come to around $15 when the parts are bought in single quantities. Bom_ESP32-WROOM-32D DEVKITC-V4.csv (3.1 KB)
If you want to go with a custom board with a Pi driving it take a look at the PCA9629 from NXP. It connects over I2C and handles all of the timing and driving it also has built-in ramping. https://www.mouser.com/new/NXP-Semiconductors/nxppca9629/
I didn’t say anything about leaving the machine unattended, but the machine
needs to get updates and be able to fetch g-code from the Internet (especially
with maslowcreate pending)
this controller may be something we can use as a common testbed, it’s got
h-bridge support for two motors,sd card, esp32 and a bunch of other i/o
it is too early to pick something like this and define it as ‘the’ new board,
but it may be something that people who want to work on the software, but not
the hardware could consider working on rather than waiting for hardware to be
produced
they also have these boards that may be worth experimenting with
Low data rate and slow clock makes me feel better about it. Found this reference, Extending the SPI bus for long-distance communication http://www.ti.com/lit/an/slyt441/slyt441.pdf
Holding torque is a spec for just the stepper. It says it is a worm. Up to 30:1. so multiply torque by 30 and add whatever factor being a worm drive gets you. Gearbox looks an awful lot like the current Maslow box.
Steppers do not require encoders for accurate open loop operation. Since GRBL is intended for steppers, there is no need to abandon that functionality. It makes sense to keep it as an option alongside servo drive. If it is an option, there should be a hardware reference design to test it with. That is what I was suggesting. If you think it requires higher specs, that is fine by me. What do you think of keeping the stepper drive option in the software?