Jackpot 3 changes?

In this case, it’ll work the same as it currently does, assuming there’s not already a pull-up on it. It may be that in that case you want something else connected, too, that might be powered from +24V or +12V like a set of strip lights or something, in which case that will pull the output up above 3.3V.

This was more just an example of ‘other ways someone might use this’.

Yes, as long as you’re ok with people using 5V or below inputs then this will work fine.

I have a handful of leftover inductive sensors from an automated XYZ gantry that we used at work for testing. They can be powered from 10V to 30V and have a high-side switched output, so you either get open circuit or Vsupply as the output. In this case I would not be able to use one of those.

I’m not sure why you’d say ‘yikes’ here? I think you might be confusing yourself by thinking of this as ‘logic level’. At the end of the day it’s just different ways of using voltages/currents to accomplish things. RS232 used to be +/- 12V signals for ‘logic’. Plenty of sensors use +24V output, like my ones above, because you can use that to do things directly like power a light, operate a contactor, operate a motor or electronic brake, etc. Or you can use that same +24V output to control the input to a microcontroller to signal things. Hell, lots of industry uses 230V signalling. The E-stops we have in our lab at work are 230V fed, so that they can control a 230V coil contactor directly. You could do the same thing with a safety relay and running at 12V, but the 230V option is the simplest for what we need at the moment.

Ultimately it’s your call, I would just suggest bearing in mind that you don’t get a summary from everyone who buys one of these things explaining how they’ve used it. If you take a design that has 6x 0-24V inputs and quietly swap that with a design that has 6x 0-5V inputs, you may well end up hearing from a number of those people when they replace hardware and it immediately fails!

This is one of the things that makes this situation tricky, as I’ve alluded to before. You’re not really making a product, you’re making a component. As a result of that, I would suggest that it may pay to be as open minded as possible and not make assumptions about how you think people are actually using your designs because if you’re wrong it’s going to cause you legitimate problems.

Reliability issues have killed properly big companies before. I know you’re focused on keeping costs low, but that inherently also keeps margins low which means you’ve got less buffer for dealing with 5% of people killing their boards and clogging your inbox with e-mails saying ‘it arrived broken’ because they didn’t read some fine print about input voltages etc.

I should not be assuming anything…little joke.

This I completely understand. I just don’t think there is much of a use case for any high-powered logic stuff on a board of this size. I am okay with a 5v input cap, I actually kind of prefer it. Keep inexperienced users from playing with that stuff and possibly really messing up the board and experienced users will know how to knock it down to 5V if needed. I will change the docs now to specify because I have not already. The JP1 implied 5V because it had the 5V optional rail) but never specified.


With 100k in there it never gets pulled up high enough.

Here is the 49.9 we currently have, I can go back to that.

Ok, all good. As long as it’s clearly called out then that’s probably fine. In future if you’re only doing 5V inputs then it’s probably better to avoid doing them via the diode altogether.

The good thing about having that diode in series is that your input can be pretty much any voltage that the diodes can survive. The bad thing is that it’s a lot more ‘brittle’ to things like ESD, EMC miswiring etc.

The other option is to use a voltage divider on the input or to just have the input bypass to 3.3V via a diode. If it were me, I’d have done something more like this:


The nice thing there is that it keeps the resistor/capacitor filter connected at all times, so you don’t have the equivalent of an open-circuit when the diode is reverse biased. That can help with things like noise coupling into other parts of the circuit etc.

If it were actually me, I’d probably also have an individual resistor in the +3V3 connection, too, with a capacitor across it on the output, or a common mode choke, but then as previously stated, I’m paranoid…

Edit: Never mind, I see you’ve changed the 100K back to a 10K as well. Try speeding the simulation time up. The pull-up just takes 10x as long now, which should still be quick enough.

Edit 2: It’s a 23ms step response now, instead of 2.3ms, so if you’re moving at 10mm/s it’s a delay of ~0.2mm instead of 0.02mm. That’s only for the delay on switch opening. I can’t remember if the logic for FluidNC is on switch open or on switch re-close.

It’s a cute/fun tool, but I’d be VERY wary of using it for actual design.

If you want an actual circuit design, invest the time into learning LTSpice or QSpice.

Back to the way it was then, 10k and the 49.9? That gave a 0.5usecond if I am not mistaken, the 1k brought that up to a 0.1ms.

I started learning but it takes a long time to see changes and the extra parameters means I get myself into mistakes a lot easier. LTspice is like fusion360 cam, circuitjs is like estlcam. I will keep trying with lt spice though.

So you have input-> current limiting resistor-> TVS-> filter resistor and cap-> pull up-> bat54s as a 3.3v clipper->another limiting resistor.

Bear in mind that because you’ve got 2 different conduction paths, you’ve got 2 different time constants. The switch closing and pulling it down will be via the 1K resistor, the switch opening and pulling it up will be via the 100K resistor. So one is a time constant of 1K * 100n = 0.1ms and the other is a time constant of 100K * 100n = 10ms. I usually assume 2 time constants to make a logic level transition, so 0.2ms and 20ms, respectively.

I think that might be giving circuitjs far, far too much credit. I would say estlcam is usable in a real sense. Circuitjs has already just convinced you of something that doesn’t follow the laws of physics.

Yeah, basically. Each component is a piece of the puzzle and has a role. I wouldn’t get too caught up in calling them things like ‘limiting resistors’ etc.

Working back from the input, the first resistor forms part of an RC filter and acts to limit current through the TVS. Larger values provide more filtering but smaller values will be more robust to ESD.

Then the TVS which limits over-voltage in a surge/ESD/incorrect connection condition. With the resistor before it, this should happily survive being connected to much higher voltages long term, maybe 100-200V ish.

The next resistor is part of the RC filter and also serves to limit the current through the later parts of the circuit as the TVS clamps.

The pull-up keeps the circuit in a defined condition if the input is disconnected or if it’s connected to a microswitch or open-drain output. This gets sized such that it’s low enough impedance to swamp any bias/leakage current out of the ESP32 pin and the diodes etc. but high enough impedance that the impedance of the RC filter doesn’t form a voltage divider that will cause issues with the input.

The diode array serves to act as a secondary clamp, keeping the voltage within the ESP32 limits. This is a second ESD stage but also helps with long-term connection to higher voltages like 5V or something that won’t be limited by the TVS.

The last resistor is just there to limit current into the pin in the case that the diode array isn’t limiting the voltage enough. If the diode array was connected directly, it’d be all the current through the diode array or the ESP32 without any sharing. With the extra resistor there, if the diode array is 0.1V higher than the forward bias voltage on the ESP32s input diodes then most of the current will still be going through the diode array with only 100uA through the ESP32s input diodes.

If this were an ADC input, I’d also have a capacitor directly on the pin to provide a stable voltage while the sample-and-hold circuit draws brief current pulses.

Depending on level of paranoia, I’d add a common mode choke on the input and more filtering, etc. etc.

There’s never really a ‘stop’ point, more just a ‘good enough to meet my needs’ point.

If you’re making a $3 widget, you might just have completely open pins like the ESP32 devkits do. If you’re making a multi-thousand dollar widget that is being sold into aerospace, automotive or industrial etc. then you’d do what I’ve described above or even more, etc. etc. It’s really just a case of figuring out the best way to achieve a given goal which, as I’ve said before, should really start with a clear goal! Just ‘make it more robust to ESD’ is a slightly tricky way to think about it.

Okay, let me see if I can fit a couple extra resistors and start shoe horning things in there. Obviously I trust your designs better than any others so I will make it work, preferably without changing the layout so I don’t have to remake a box and instructions.


That’s not meant to be a ‘change it to this’, more of a ‘have a think about how this would work and how it accomplishes similar tasks’.

I don’t think there’s anything necessarily wrong with your approach, it’s just a little ‘odd’ for a 5V input.

If it’s going to take some shoe-horning, there’s also the perspective that a non-ideal circuit laid out well may outperform a more ideal circuit that’s laid out poorly, etc.

I think adding the TVS and saying it’s 5V max should be fine, for this situation. I would still bump those filtering values, though, providing you’re ok with a ~20ms delay in triggering that input.

I don’t think that will work. 0.2mm time to trigger plus decel, we might break vbits. We would have to home at 1mm/s to be at 0.02mm. I think it has to be faster.

Why would you be breaking bits on home? I’m confused.

This should be repeatable, but either way.

Maybe just keep it as is, then, and take it as a future action item to write an actual spec for this kind of stuff.

Z probe to a metal touchplate.

1 Like

I had forgotten that we’d started with the probing. Fair point. That’s the ‘fast’ situation, though, where the input gets pulled low.

This is why the asymmetry gets confusing.

So the pin will be open-circuit as the probing starts (100K feeding into 100nF, fully up at 3.3V). Then as the probe comes into contact, that’s the same as closing the switch/shorting the input to 0V, so that’s 1K into 100nF, discharging it down. 1K * 100nF is a time constant of 100us. ESP32 VIL(max) is 0.25*Vcc so 0.8V, so the worst case timing is 3.3V to 0.8V.

Chucking that into QSpice:

The green trace is the voltage on the probe itself, the blue trace is the ESP32 input.

The first transition of high to low is the actual probe contact event.

That’s it zoomed in with cursors set to the contact event and the point where Vin crosses 0.8V. It’s 170us later, so at 10mm/s it’s 1.7um of delay.

1 Like

yeah, the simulator is really helping me to see that. I have set all the values to what I think they should be as best I can. I added a scope to check the timing vs my math.

The other side is the endstops and they will be on the slow end of that curve…and people tend to home X and Y faster than Z so that speed is still not good.

The JP1 and JP3 v0, have a 10k and 49.9ohm set. Not much filtering there, but fast and brings the input nice and low.

Well they fit, I will see if I can get any more separation in there. None of the traces T off,


Eager to get to the driver issue.

3 Likes

I am down to two boards on hand with some sort of motion issue. I have resoldered all the chip pins, just in case. Tested voltage of a bunch of pins, just to see if they match. Flashed different config disabling different drivers. I was kinda able to get the scope on the step pins and did not see any differences.

I need to get my little USB logic analyzer on there to see what is really going on. Any good tips on keeping the “probes” on the chip pins? I can solder something on, but a little lean probe holder seems way faster. Is the “step” pin the main one I should be watching on the driver, or do I go straight to the shift registers?

Is there any debugging info I can get over UARt that might help directly in Fluidnc?


The two boards I can’t figure out so far seem to have very different issues.

  • One will not initialize all the drivers if all 5 steppers are plugged in, seems I can rotate which stepper is unplugged and the rest seems okay. Need to test more.

  • one actually seems to work fine but all 5 steppers and drivers went full current and never seemed to overheat?? If that is possible, I guess I need to test that more. Was kinda cool to see 6 extremely hot steppers, and a very hot JP3 sitting on a silicone pad still going strong after 2 hours. How could we get step direction and speed data and not current data…to all 6 drivers? I need to test more obviously but this was my initial triage.


The good thing is it does not seem like there is an obvious fundamental flaw since the issues are different.

Two things that I would look at for that- the ESP32 power rail (on a scope), and the UART at the ESP-32 on a scope. Look for dropouts of the ESP supply rail and on the UART side let’s see what you see.

Okay, well Uart always looks high. Need to try some speed changes…but I popped my benchtop power supply being dumb. I plugged in some steppers while the board was energized. No fuses in my PS that I see, it works until it needs more than 0.02A.. It was a cheapie. back to the wall wart.

I did get to look at one of the step pins while in motion, solid square pulse

At boot is probably what you most want to see. The first couple of seconds.

just an idea… I always attach the alligator clip to the touch probe extender, so its circuit is always grounded when I’m not using it. Would something like that be a helpful or hurtful when trying to avoid a static strike?