I’m building a Encoder Wheel MPG Unit based on the FluidNC Dial with the CYD.
If anyone is interested i will upload the STL Files on Printables when it’s done.
Also did one for the M5 dial, but i will not use this as the clicky clicky on the encoder is much more satisfying 
Oh I like that! Cool design choice for the wheel as well.
Is that screen and wheel roughly the same price as the M5 dial?
Screen is around 10-15$ and the wheel also 10-15$. Actually way cheaper than the m5 dial.
FUN! Share more details when you get the chance. I used one of those clicky wheels before and it was pretty nice.
XLR is a pretty cool idea as well, cheap cables and made to take a beating.
I built a less smart jog wheel using a Arduino to simulate a keyboard for my Mill CNC running bCNC on a PI4 with a PiCNC hat and external DM242 drivers. Not my design but I totally agree that the click is nicer than the M5 (which is now sitting on my desk to make that pendant).
Now that is what I’m looking for. The cost of the M5 dial is really off-putting to me. It seems wrong to pay more for the display than the controller.
$30ish for the wheel and screen is still a bit on in the high side, but for a good pendant, still acceptable.
Wonder how much they cost in bulk.
That screen includes an ESP32. I’m not sure how you do much cheaper.
On alibaba you can get the display down to 2$ handwheel about 4$
That makes the project much cheaper! I’ll look forward to this!
Can anyone with electronic knowlege help me. I want to integrate the protection circuit like on the buyable PCBs for the m5 dial. Did i chose the right components as i want to this on a throug hole pcb. and is the wiring right?
Looks close. The VMOT Schottkey preferably would be at the pendant end.
For comparison, Bart’s module uses:
For RX/TX definition, it depends on what you put into your config.yaml. Yours looks fine to me.
You’re not using an RJ12 there, so I can’t verify that you would be pin-compatible with Bart’s pendant RJ12 wiring.
Short version:
Those are the wrong TVSs, they’re 33V parts and will do basically nothing. Better to leave them off entirely.
If you really want to have a TVS on there for ESD protection, you’ll need to use a surface mount part which isn’t as scary as it sounds, they should solder down to strip-board reasonably well.
Personally I wouldn’t bother. The M5 dial likely already has some level of ESD protection (edit: not really, straight to the ESP32 which is disappointing but the ESP32 at least does have its own basic ESD protection), the 120R resistors will help and if you wanted you could instead add 1nF capacitors where the diodes are which will help with transients/noise a bit.
Long version:
I think you have the wrong TVSs there. I would also strongly recommend against using those big TVSs on the RX and TX lines. Big TVSs like that typically have extremely high leakage current and capacitance along with relatively inaccurate breakdown voltage tolerance. Those ones are 33V units that are intended to be used with a 28.2V maximum and in the worst case begin conducting 1mA at ~35V, so likely won’t protect against anything significant without the rvoltage rising to more like 38-40V.
They also have a bit over 1nF of capacitance so that 120R resistor and 1nF capacitor is effectively a 1.6MHz filter which shouldn’t be too much of a problem but if there’s some other series resistance around or existing capacitors for filtering and you’re trying to run a higher baud rate then you’ll start seeing some rolling off of the edges.
I don’t really like Bart’s approach here of just using TVSs, that’s a bit ugly and doesn’t perform very well in reality but it’s the only realistic option if you need to protect 3.3V lines and don’t have access to the 3.3V rail. I’m also not sure why he’s using bidirectional ones there. Hopefully that’s a symbol error.
If the inputs are 5V tolerant then a better approach would be to use small-signal diodes and half-bridge them to the voltage rails then put a single big TVS on the 5V rail.
I also wouldn’t bother with PTCs generally. They’re too hard to get right and they never work the way that people think they do. Instead, go for a low value fuse with the fastest blow time you can find and make peace with the fact that you’ll be replacing them if you muck something up, but that it’ll never be an issue once the thing is working properly.
I can’t find any through-hole TVSs with a 3.3V standoff voltage so I would either get a surface mount one and try mount that or I’d omit them entirely. Surface mount stuff actually isn’t too hard to solder on strip-board so that could be worth a try.
Another option is just to put some capacitance there, that itself can go a LONG way to reducing ESD related issues. There are a lot of other ways to protect against ESD, too, mostly being shielding such as shielded cables/connectors/enclosures etc. but there’s a solid chance that the M5 dial is already somewhat ESD protected so I wouldn’t worry too much.
Edit: After looking at the schematic I’m way less impressed with that M5 dial thing. It’s truly garbage design to have GPIO pins exposed to the world without any filtering or protection. Doubly so when it’s intended to be connected to a long cable. Very disappointing.
Bart and Mitch have repeatedly stated on their discord that they are seeing ESP-32s blown on both sides of the system by ESD associated with pendant connect/disconnect. I wouldn’t leave these off. (In fact, I’ve noted to @vicious1 that future Jackpot boards should add the ESD protection to the jackpot for all expansion headers)
Fluiddial uses a 1Mbps bit rate.
The symbol is correct.
My apologies, I wasn’t familiar with that part, and didn’t look it up. As @jono035 notes those aren’t 3.3V parts (Which I ASSUMED in my ignorance of the part number). Completely wrong for this applicaiton.
That may be easier to solve with choosing a better connector system that uses a make before make ground. But yeah, I edited the original comment when I found out the dial didn’t implement anything. I’d definitely think it worth adding something, even if it wasn’t a TVS.
This is a very clear example that I can point to when someone questions why I’m so derisive towards most open and DIY electronic designs. It’s the difference between designing something and engineering something.
Then likely the reason they’re blowing shit up is negative transients. That TVS won’t do anything at all in the reverse direction because they on-chip parasitic diodes will already be conducting and stuff will be getting smoked. That is a BAD design choice.
Well, that makes life a bit more difficult. You really need good edges for reliable UART based comms so probably around ~10MHz bandwidth on that channel. Personally I’d rather see it be an RS485 link or something more robust at that speed but oh well. That’s not insanely high bandwidth but it’s definitely heading to where I’d use a monolithic ESD protection setup that consists of a bridge rectifier to the Vcc rail and then a TVS across that. Far lower parasitic capacitance which means that more protection can be provided in terms of series impedance before affecting edge rates negatively.
Edit: I’m not at work so I can’t check but I think we’ve used the Diodes Inc D1213A on USB lines before. The one in the SC-70-5 package that allows an external connection to a decoupling cap to help absorb energy and bypass to the rail.
Without that, you can DIY the same thing by still doing the bridge rectifier approach and then put a cap+gruntier TVS there, but care is needed to avoid too much parasitic inductance which will increase the let-through voltage. The alternative to that is to put the ESD protection directly on the terminals and then filter as much as possible afterwards so the relatively slow step response of the ESD protection doesn’t mean as much because the high edge rate section is filtered.
I’ve been thinking about this for most of the morning here and I don’t think there’s a way to actually do this while sticking to a through-hole design.
This is the best I can come up with:
To solder the ESD array I would cut the 2 traces in the strip board, tin both the right hand sides lightly, press the diode array into the tinned section and re-heat one of the tinned parts, checking that the diode is stuck in place. I’d then reheat the other tinned part and add some solder, then go back and add solder to the first tinned part. Then add solder to the left lead that’s in the middle and solder it to both adjacent lines.
The extra gold trace to the left is where I’d add a wire or solder blobs to connect those ground stubs back to the main ground strip.
Ignore the connectors, that’s just there instead of screw terminals because I didn’t have a 2.54mm pitch screw terminal model in Altium.
Edit: Actually, further inspection shows that those diode arrays are intended for 3.3V and 5V usage, so their let through is a little higher than it could be. It’s still a hell of a lot better than nothing, but something like a Bourns CD143A-SR3.3 mounted in a similar fashion would provide a closer connection. You could just clip the Vdd pin off entirely and ignore it.
So true.
Can you point to an open source reference design?
I’m considering laying out a combined FluidDial pendant and isolated RS-485 board to use with Jackpot.
I’ll look into the data sheet for that. Thank you.
I’ve thought about this prior to today as well. I did my first few FluidDial builds with RJ45s, but hated the idea. It was cheap and easy.
No other connector family seems both affordable and suitable, while not implying something else (e.g. a USB-C style connector).
Is there a suitable connector out there (Open question to the forum…)
Not that I’m aware of but I’m happy to tell you what I’d do if you’ve got a goal for how bomb proof you want it.
I don’t think I’d bother with an isolated RS485 design unless you’re trying to achieve something specific with the isolation? The pendant is effectively floating anyway under normal usage so isolation will only realistically give you a little extra common-mode impedance/rejection at a LOT of extra cost/complexity.
If you want to go full hardcore mode, I’d use an RS422 driver chip. Anything works but I’m partial to the TI parts, something like a SN65HVD1474. Those are neat because you can power them from 3.3V or 5V and their inputs are 3.3V compatible on 5V supply but there will be cheaper options. I’m a big fan of slew-rate limited drivers as well, but that’s a ‘nice to have’. Using it with an RJ style jack in 6P6C (RJ11 but with all 3 pairs) or 8P8C (ethernet) and 3/4 pairs works. 1 pair each direction and 1 pair for power. 120R terminations at each the receive end of each pair, I like doing those as 2x 60R resistors and a 100nF cap in the middle to 0V, but for 422 it doesn’t matter. Also 422 doesn’t ever turn off its drivers under a valid operating condition (unlike HD RS485) so no defined state termination is needed. If doing half-duplex I make one termination defined state (so something like a 220R terminator with something like 680R to +V on one side and 680R to 0V on the other such that the entire network still maintains 120R impedance but when open-circuit idles with just enough voltage to keep the transceiver in a valid mark or space condition, whatever the normal ‘idle’ for the line is).
You’ll need 3.3V or 5V power on both sides for the driver ICs but that could easily be an appropriate LDO off the full voltage. Just keep an eye on current draw as driving ~3-4V into the termination resistors is a notable amount of current, 30-40mA potentially.
If using multiple pairs for power, I put Vcc/0V on each pair, rather than Vcc on one pair and 0V on the other as that gives you the lowest inductance and highest capacitance per unit length.
I don’t usually bother with external ESD protection on those drivers as they’re already pretty meaty both in terms of ESD capability and input voltage range on the pins, but then I’m usually designing for fixed installs or I try to use scoop-proof connectors that have make-before-make grounds like the Harting industrial series.
If you don’t want to go that hardcore then for short runs I don’t see anything too bad about using the GPIO directly, but I’d definitely want a bit more protection/filtering on it.
Regardless of 422, GPIO, whatever, I’d add a ferrite bead to every signal (even 0V) near the connector and then either a direct to ground connection or an appropriate cap (100nF for power, 100pF maybe for signal) to a ground plane, well attached, 2 vias per pad etc. Sizing the FB and the cap depends on the signals you’re trying to let through, but at 10MHz anything in the 100R @ 100MHz range is probably golden. Having equal FBs for every pin helps with avoiding a common-mode to differential-mode transform caused by different impedances on each pin.
Then an ESD suppressor like the CD143A-SR3.3 I mentioned above.
Then potentially extra signal filtering if you wanted to have better control over the lower frequency parts of the signal set with an f(-3dB) frequency around a decade above the highest preserved content, although the FB and cap is probably more than enough for this at 10Mhz for a 1Mbd signal.
If I were using RS422, I’d probably stick with an 8P8C ethernet socket for my own use, I know not to plug it into an ethernet socket. For wider use I’m not as much of a fan of them because a 422 driver plugged into an ethernet socket will happily smoke the isolation magnetics by stuffing 5V DC down it. You can avoid that by changing the pinout but then that means you can’t use OTS patch cables. If you use shielded sockets then you can use shielded cables, too. The shielding on them is actually pretty crap due to the limited way the socket interfaces to the plug but that’s likely to get you a make-before-make ground connection and provide good passive ESD protection.
As for connectors, the venerable DB9 works pretty well here. They’re uncommon enough now that cross-mating isn’t a huge issue and they’re all shielded (somewhat poorly) but in a way that makes it all but impossible for the shields to not have at least briefly connected before a contact is made. Not scoop-proof, though. Same situation with the good old DIN connector, too. That’s what I used on my MPCNC. In both cases you can also get pre-made cables relatively cheaply that use shielded/screened cable, although none of it’s all ‘that’ great.
Lemo make some pretty good small signal connectors but they’re spendy.
Harting modular, Bulgin Buccaneer, an M12 automation connector, any mil-spec style connector if you want to be hilarious. Actually, I intended that to be a joke but a lot of those have cheap compatibles available via Aliexpress too, I noticed the other day. I found the SP16 and similar connectors on Aliexpress that look like a knock-off version of the Amphenol C16s or Bulgin Buccaneer series that I used to use and love when I was doing port automation equipment. Same thing for the Lemo connectors, automation connectors, all sorts.
So probably not as much help as I might have thought with the connector but perhaps looking at affordable pre-made cable assemblies and working backwards could be a good idea. The automation connectors are probably the best bet there, actually, as they’re pretty compact and commonly have right-angle molded versions available. Technically it’d be best to have twisted pairs for RS422 but in the range of 1-10m it really isn’t going to matter absent some REALLY gnarly noise issues.
Thank you for a quite refreshing brain dump!
There’s plenty here for me to think about and see if I can come up with simple requirements to drive some implementation ideas. I also have plenty to chew over with respect to connectors and whether / how to pick something good but also affordable.
I’m not intending anything commercial, just a simple board to help out the V1 machine builders who want pendants and/or spindles.
The knock-off mil-spec connectors appeal to me (but then I work with the real thing all day.).
[off topic rambling… ]
I had a surplus pair of 38999 connectors in one of my cars for a while with a GPS and Ham radio hanging off of a homebrew cable. Mostly because it was hilarious to tell people the connectors were literally worth more that the old beater Firebird they installed in.
[/rambling]
The COTS spindles use RS-485, and though the differential signalling of RS-422 is nice, it’s not what those devices have.
I’ve worked with RS-422 extensively in aerospace applications but it doesn’t seem at all common in low-to mid priced spindles. Those spindles aren’t things I work with outside of the DIY CNC application and even then are new to me.
I’m no fan of RS-485, to be clear, but trying to use RS-422 on the FluidNC side and then convert to RS-485 at the VFD doesn’t seem particularly sane to me.
Bart’s reference designs include two RS-485 implementations for spindle control.
The non-isolated reference design uses three GPIOs (Txd/Rxd/RTS).
The isolated version uses only two GPIOs, and doesn’t need RTS for duplex toggling.
This matters in the Jackpot ecosystem because there are only 4 available GPIOs on a Jackpot.
If you use an RS-485 spindle and a FluidDial pendant, you need all four of those GPIOs- so not needing the RTS signal to manage duplex is important.
I fiddled around on a breadboard to sort through the way the half-duplex turnaround using RTS was working and then decided the isolation was possibly worthwhile on a hobby CNC and never went any further because I needed all four of the available GPIO anyway.
I also made a little proto board with a stacking header so I could break 2 of the Jackpot GPIOs out to send to a FluidDial pendant and then pass all the rest of the IO up to a stock copy of Bart’s isolated RS-485 module. It seemed workable- except I can’t currently test it.
(I don’t have a spindle to test with at the moment, so deferred next steps until I have a chance to work with a couple of interested forum members on thier own builds.)
I don’t want users blowing up Jackpot ESP-32s with pendants or VFD spindles, which seems rather commonplace. I also don’t want the M5Dials or other similar pendants easily blown up.
I hadn’t thought through the implications of Bart’s ESD diode pick and see clearly now how it’s a terrible pick.
Your discussion about signal conditioning on the output side is very well recieved- thank you for pointing that out.
Yeah that’s generally my practice.
That’s a hilariously instantaneous shadow-requirement you’ve uncovered there 
You originally only mentioned the M5 dial so that’s the only context I was working with.
RS422 would allow a passive connection to the dial without needing anything different on either end. Using a slightly more complex IC that allows driver shutdown means you can get RS422 or RS485 HD with nothing more than a wiring change. RS422 mode would use driver and receiver wired separately and always on, RS485 HD mode would connect driver and receiver output terminals and use the DE/nRE pins to control transmit direction.
Oh, ewwwwww. I don’t think that’s inherent to the isolated design, that’s just using the driver input to enable/disable the receiver, so basically treating it as actively driven marks with passive spaces from the extremely weak defined-state termination. That’s pretty ugly. Using the passive state for comms will lead to very different signal margins and noise floors between mark and space as well as some edges being fast and some being slow, leading to pulses being well outside 50%. If it works, it works, but it seems like it adds a LOT of potential unreliability.
In this case, I think he’s doing that with the isolated one so that he can use a dual-channel isolator and save either a 2nd isolator IC, shifting to a quad channel with one unused or using a tri-channel and limiting the range of available options.
I can see how the isolation would be useful when connecting to the VSD but there’s a solid chance the inputs are isolated from the power stage in the VFD anyway.
I’d personally try to scavenge another GPIO from something or do something trickier before I’d resort to enabling/disabling the driver during transmission.
