So this community came onto my radar because I was gifted a minirambo/LR2.
I retired the minirambo due to its lack of stepper outputs, and got a Jackpot V1 ( which feels like the better model to get due to the ability to pull the controller and program it in a separate room).
When swapping the wiring from the Rambo to the Jackpot the first thing that I noticed was that the IO pins used by the endstops were so close together that I could not wire up my machine.
LUCKILY the pins matched up perfectly to a 8x2 ribbon cable I had laying around. (Ribbon Cable breakouts for PLC controllers is something that I first saw 25 years ago. )
I ended up having to put together a quick breakout board so I could have my endstops wire up properly but this has me wanting to build a real IO board.
Following up on this hack I put together a design with some nicely spaced pairs of headers AND screw terminals, Really just to future proof the design ( and keep it generic enough so it could be used with almost any device. )
There’s already filtering on the JP1 for those inputs, so I wouldn’t worry about it.
Personally I don’t really like debouncing in hardware. It’s easy to do in software (and I’m sure FluidNC does it) and you don’t lose any response time/trigger speed that way.
It’s also an application where bounce isn’t going to be an issue. For things that can re-trigger like a button or something driving a counter it matters. For and endstop, once it triggers, it triggers.
There is no firmware debouncing at this time. Controllers should have circuits to mitigate noise on all inputs. A simple R/C filter usually does it, but adding Schmitt triggers or optos can help as well.
If you use switches that close to ground in a normally closed (N.C.) arrangement that can be more robust to noise. The connection to ground will have a much lower impedance than a pull up and the noise will have a harder time affecting the signal. A normally closed limit switch is also fail safe. A break in the circuit will immediately be noticed with hard limits or before a homing attempt.
Huh, interesting. They may still not need to, though.
There are 2 separate issues there, one being noise, one being contact bounce. Noise would be something causing triggering of the input unexpectedly, which there are filters to prevent. Bounce would be the contacts closing briefly, re-opening and then closing again, sometimes even repeating that multiple times. That only matters if the software does anything differently based on whether a contact bounces or not. If they’re using edge-triggered logic to progress through a state machine, for instance, the bounce wouldn’t matter.
Yeah, it really shouldn’t have an effect on their end stop handling. It triggers, the axis backs off a distance (which requires some time), and then they check again for the normal(ly closed) state.
How they handle other types of inputs, I don’t know. I haven’t gotten around to building something that would be affected by it yet. I just happened to come across the topic in the documentation a while back.
Actually, I have run into an input related issue… I couldn’t get the reset_pin feature to work (the 1000ms delay on boot to release the pin signal doesn’t work).
I haven’t looked at it since starting this thread.
I’d have to say that input handling isn’t quite there yet, although either I have clean switches or there’s adequate debouncing for feed hold and resume inputs.
For situations like ‘feed hold’ and ‘resume’, presumably those are pressed once and then the state of the software changes? Like press ‘feed hold’ and it stops until ‘resume’ is pressed?
For situations like that, debounce isn’t necessary because the first edge triggers the behaviour.
What it’s needed for are things like keypad inputs where a bounce might cause a double-input, so pressing 5 gets you 55 or 555. Or things where it’s a start/stop button where pressing the button and having it bounce may cause the correct behaviour then immediately cancel it.
Yeah, that’s true. Last second edit above… I was thinking it was a single input for hold and resume as I had wired up a single switch for it. Forgot that I had a flip flop toggling which input the switch hit.
Boards from this thread arrived from china, I both have 4 spares and a second design already planned out.
I was considering adding some debounce resistors in parallel to the inputs which could be added / removed via pin headers, but based on the comments I feel like that may be over-engineering.
Everything fits pretty perfectly in terms of electronic wiring and the ribbon cable means I can move the (messy) endstop wiring away from the rest of the board and could create
In a few weeks I should have about 8-9 boards of various revisions laying around with no machine to plug them into, I wonder if:
these boards would be useful in other peoples builds.
I could send some up north to ryan to sell in the store on consignment so I could recover some cost ?
Next Revision ( Still under design ) allows for 4-6 GPIO to be transmitted via RJ-11 cables to peripherals ( i.e. 110vac relay spindle control box, E-Stop mushroom button box, RTD Temp. Sensor ), the lack of electronic protection on the RJ12 ports is to increase their versatility.
