I have a lowrider V4 I’m building. Everything is hooked up and connected. However, I’m having trouble with figuring out how to connect the case fan to the jackpot controller. Right now. I have it connected to gpio16, but it does not power on. Is there some place in the fluid NC interface I’m supposed to set up to enable the those pins?
Just to add to this, make sure never to cross any wires over your wifi antenna, all your wires should be routed around or under your board, never over the top.
@vicious1 - this should be a note in the documentation. It happens periodically that people try to use GPIOs to run a fan, and those buffered outputs are completely unusable for that. (Too low a current source capability)
We should tell people to wire the fan to inlet power so that it runs if the machine is on.
They are low-side-switched FETs, but to get them to work you’d need to command them on.
MUCH better to just wire the fan always-on from inlet power in my opinion.
If a user wants to run them with gcode or UI control that’s fine on a user-by-user basis but I don’t think it should be what we recommend as a baseline.
Edit: we’ve also seen attempts to use GPIO 26/27 with 5V fans; that’s what I meant by GPIO current source capabilites.
Yes, bad assumption on my part, I refer to those as the FET switches and not GPIO out per se, which is wrong of course because all are GPIO controlled. 26/27 are buffered low current drive capabilities and 2/16 are FET switched.
Because 2/16 are low side switched, the high side is directly tied to incoming VMOT so it’s a potential way to short VMOT power if not thinking about the fact that the only thing being switched there is the return side.
GPIO 16 will only supply 5v, so if you are trying to power a 24v fan it won’t work. I use gpio 16 to switch a 5v relay, and use this to switch power for other devices, but have my fan connected across my jackpot board power connectors.
There is no real reason to switch the case fan. FluidNC boots with the drivers engaged. If you have the hole plugged with a fan, it should be running at any time the board has power.
I wouldn’t say wrong, just different to how it’s being approached here. In my professional context I would fight tooth-and-nail to say that these are very clearly NOT GPIO, they’re high current open-drain outputs. They’re labelled on the PCB with the GPIO numbers that control them for user-friendliness, but they’re definitely not actually GPIO.
Whether that matters is entirely down to the context of discussion, but I certainly wouldn’t say that your approach is wrong. Perhaps ‘the open-drain outputs on GPIO 16 and GPIO 2’ would be the more technically correct but irritatingly wordy nomenclature.
The open-drain FET that’s connected to GPIO 16 is on a header with Vmot, so it would be a 24V output in this case. In reality it’s bypassed to Vmot with a flyback diode which means that any voltage between 0V and Vmot can be used. It does not supply any voltage, nor is it only 5V.
I’m not going to pretend to grasp all of the intricacies of what you said and how it applies in the general case… but maybe you can clarify, in the case of the Jackpot, if and why it matters given our use cases and the following information
The Jackpot documentation describes those outputs as:
Which leads me to believe they are intended as general purpose outputs
The default config has them mapped to flood and mist coolant pins, which in the CNC world seems to be either used as
Mist control
Some other general purpose output controlled by M7, M8, and M9
So that also points to a “general purpose output”
So while, in this case, for the case fan, I absolutely agree that just wiring to the input power makes the most sense, I’m not understanding why there is such an aversion to using these as a general purpose output?
It seems like that’s exactly why they were put there.
I’m not currently using mine, but have thought in the past about ways they could be used.
Did I misunderstand, or are you saying that should be avoided?
My bad! I really do appreciate people asking follow-up questions when I’ve gone off the deep end a little so please feel free to point out the bits where I can help with understanding things further.
Apologies if this is going too far the other way, this is more just a stream of consciousness ramble:
GPIO (general purpose input/output pins) is a term used usually with microcontrollers pins to provide distinction vs special purpose pins. In older microcontrollers it was common to have quite a few pins that were specific purpose such as ADC inputs only, DAC only, address and data lines for a parallel data bus, UART/SPI/I2C hardware, that kind of thing. In those cases the purposes of those pins are specific and defined entirely by the hardware that’s behind them. With the address/data lines you couldn’t tell the firmware ‘make A3 high’, or ‘pull D7 low’, that was all just done by the hardware controlling accessing external RAM. The GPIO pins on the other hand are general purpose in that they entirely rely on firmware to provide their functionality, not any kind of underlying hardware. The only way to change their state is have the firmware change a bit in a register somewhere.
As silicon has gotten cheaper and more complex, we’ve ended up with micros where every pin that isn’t a power pin is fed into a multiplexer such that we can switch the function of each pin between various bits of hardware peripheral or just keep it controlled via GPIO. In that example, if we leave the pin set to GPIO then its state is controlled by firmware via bits in the registers the same as before, but we can also reconfigure the multiplexer to instead say that this pin is being controlled by a hardware UART. We can then no longer just set that pin high or low but instead control it via the UART hardware. We put a byte into the UART input register and it then clocks it out the pin bit-by-bit at the correct rate etc.
So while the pin functionality can be exactly the same (capable of digital inputs between 0V and Vcc, capable of digital outputs between 0V and Vcc while both sourcing/sinking current), the GPIO label vs whatever its special purpose would denote how it’s being controlled. In a schematic, I typically label things at the microcontroller according to how the MUX is set. Something that’s GPIO will get a note saying GPIO27 or whatever then the netlabel describing the function. Something that’s using specific hardware will get a note saying EPWM8B or whatever then the netlabel describing the function. This is an example from a design I’ve been working on recently:
The nFault signals are all just GPIO with their states being read by software. Separately there is a global fault signal that isn’t GPIO controls the PWM hardware and triggers an interrupt. The I2C and SPI pins aren’t GPIO because they’re being controlled by that specific hardware. As you can see from the truly appalling pin names, the multiplexer in this case can connect the pin to a LOT of different peripherals, sometimes even connecting to things like a cross-bar (OUTPUTXBARx) which is basically just another multiplexer…
There are a few cases where this exact situation occurs on the chip itself. Some TI microcontrollers have pins that aren’t true GPIO, instead having an output that is open-drain and rated to a higher current than other pins. I can’t remember offhand what they’re called but it’s something like ODIO so rather than being general purpose IO it’s open-drain IO, signifying that it can’t be used the same way as GPIO because it’s an open-drain output. That open-drain nature means that it doesn’t have a switch to pull the pin high, only one to pull it low. Both GPIO and ODIO have the same inputs but in terms of output states the GPIO can be high impedance, low impedance Vcc or low impedance 0V. The ODIO can only be high impedance or low impedance Vcc, the lack of a high side switch means it can’t output a high voltage directly and needs an external pull-up. The advantage there being that for a 3.3V chip, that output can be used up to 5.5V because there’s no high-side switch with its corresponding body diode.
So typically I’d only use GPIO as a term when it comes to the chip itself and maybe to buffered/filtered GPIO that I was routing out to the wider world. If I were doing something like changing them to be an open-drain output, as above, I would no longer consider them GPIO because they’re not inputs anymore, so GPO at best, and they’re not general purpose because that could be misleading. They’re open-drain outputs.
In terms of that specific documentation, I don’t like ‘line level’ as a terminology. It’s not really well defined and would be confusing. I would call out a specific voltage range instead.
Fundamentally some of this is just an argument about nomenclature and whether ‘common usage’ trumps ‘literal meaning’. I generally try to not to be a purist about this and think about the goal of the language we use. The goal is to convey a certain meaning and sometimes the most literal approach doesn’t do that without adding ambiguity. Calling it GPIO isn’t fine under any circumstances because it’s factually incorrect, there is no input capability. Calling it a GPO is fine in the literal sense in that it’s an output that is intended to be general purpose in the CNC machine context, but I would say that’s not correct in the microcontroller/electronic context in that it’s not general purpose, it’s specific purpose (high current, open drain) compared to other situations where we would call something general purpose (low to moderate current, tri-state).
For sure, that’s what I’d do, but I dove in here more as ‘terminology pedant’ rather than ‘fan wiring advice giver’
I think this is a matter of terminology. There’s zero issue with using this output for whatever purpose it suits, it’s calling it GPIO that’s incorrect and calling it a GPO that’s potentially misleading.
Not at all, use them for whatever you want! But it just needs to be clear that they can’t output a voltage so you couldn’t use one by itself to drive a digital comms line or control something that needs an unswitched 0V reference etc. without adding a pull-up or whatever.
Edit: Good grief, I’ve really gotta aim for more brevity in these responses
Edit2: And to be clear, I’m not really ‘that’ bothered by the gpio labels on the PCB or I’d have called them out during review. I think of it more as a label of which gpio pin is controlling the output rather than what the output actually is.
I appreciate the sentiment! Usually I hit post, look back over it for obvious typos and go ‘oh… oh no…’. It’s nice to hear that it’s appreciated, even if I should probably be able to say the same thing in 10% as many words.
Let me see if I can explain this better. The MOSFET schematic is shown below.
The key is that these are FETs that are low side switching. The GPIO causes the FET to close to VMOT return.
The VMOT voltage that is adjacent in the connector is only there for convenience. You could use any source you want, provided that it’s return is tied to the Jackpot VMOT return.
Another way of saying this simply is that these can be thought of as a set of switches to ground.
Think of them not as outputs but rather as commandable ways to tie pin 1 or pin 3 of the header to ground.