True, doesn’t necessarily need to be switchable, given the difference in current/wire size etc.
Oh, I didn’t get a chance to mention this before, as well, but beware some of those cheap switches. It’s a bad idea to use a multi-amp rated switch at uA of current and the switches that are intended to be used at uA likely aren’t rated high enough for load. Mechanical contacts are tricky like that.
I’ve gotta bail out for a few hours, but hopefully that’s a starting point to work from.
1 Like
Good point. All switches including relays, specify a minimum switching current. (“Cleaning current”, or “Wiping current”.)
I have intesnse misery in my past life from someone else that designed a system that used a double pole double throw relay to switch power on one side and measure state on the other. Every single one went intermittent within about 6 months of operation.
1 Like
Sadly, I wish that were remotely close to true. In my experience very few do, but all SHOULD.
That’s what I should have said. They all have the limitation, but many (Most?) don’t put it in the data sheet.
1 Like
Yeah, which then makes it a wonderful thing to try to design around and a great point to argue with people about.
There’s a reason why relays with gold plated bifurcated self-cleaning contacts exist, otherwise we’d be using big cheap tin-oxide button contact power relays for everything.
Edit: Admittedly this is more of a problem with relays than switches themselves due to lifespan/contact styles etc. but it still matters. Power switches for logic signals can go bad remarkably quickly and give you some funky results.
1 Like
Thank you as always.
What is to gain from this vs just using the jp1 mosfet for the 5v pwm/ttl?
1 Like
A post was split to a new topic: Jackpot config changes
Can we just select the pull-up value we need and feed it into the buffer, 5v or vmot? then is still needs to be able to handle more amps right?
Best to start a new topic for your specific board. We can more easily help you there. with your specific file.
I am not understanding the difference? Edit the YAML and save a copy for future use.
A post was merged into an existing topic: Jackpot config changes
TTL= 5V logic output, limited current drive capability.
But having a buffer in front of the existing V2 circuit would let you have all three outputs be laser capable, at the cost of an additional IC and three more terminal blocks (or pin headers)
1 Like
We can get rid of the first mosfet and drive the other one directly? The first one is just there to level shift if I remember that right. That should gain the speed back. What would the extra headers be for?
Or, are you saying have each output split into both 5v and vmot, each with it’s own terminal. Not deal with the switch at all. Not sure.
Seems like we have options if it has to get redone. Might be time for a jackpot3 thread.
Oh, more just for logic stuff I don’t like doing open-drain unless I have to, I prefer driven high/low, etc. It does depend a lot on what you want to do with the output, if it’s just something like PWM control then it probably doesn’t matter as long as it can be kept relatively fast but you can run into issue if you’re trying to use it for data like controlling a WS2812 or whatever. With open drain you need to balance the same stuff we’re talking about now, either low resistance pull up for speed, high resistance pull up for efficiency, can’t have much capacitance, there are some weird EMC issues that can crop up, all purely for the limited (in my eyes) benefit of voltage flexibility. Most of those are less of a concern when you’ve got a load you’re driving but just for a data line it’s just kinda a bit crap. Perfectly fine for single kHz level PWM etc.
With an open drain output you’d just add a pull-up to whatever source and it’d be fine. With a buffer you’d have a chip where you’re either changing the entire Vcc for that chip or leaving it fixed and then handling it in other ways.
My usual ‘recipe’ for outputs is to have them at 5V with a decently robust buffer/level translator IC. That way they work well for 5V logic and converting to 3.3V logic is just a divider away for slower signals or a level translator for faster stuff. If I know everything will always be 3.3V because I’m designing the entire ecosystem then I’ll stick with that but buffered. If it’s all within the same board or a ‘close’ board, such as within the same enclosure, or if it can be filtered to be very slow then I’ll just connect directly via GPIO in that case.
If you’re doing the high-side switch you absolutely need the first MOSFET for the level shift because P-channel FETs are referenced to +V rather than 0V.
The approach I’m suggesting above would be to treat it as 2 separate circuits, both of which are somewhat simpler so closer to your ability to design and understand a bit more fully. You could either do it with the same switch approach but configured such that the switch is just choosing one of two circuits driven by the same output, one circuit which is the 5V one and has a buffer IC to give you a 0-5V fast signal, or the other circuit which is the 24V open-drain high side switch which gives you high impedance or +24V at a couple of amps, potentially. I would suggest that in that case a potentially better option would be to just not have the switch at all and just have a 2nd header, so you’ve got one header with 3x high current high-side switched outputs and a different smaller header with 3x low current 0-5V TTL outputs.
The circuit you’ve come up with here is a great learning experience, but it’s clear from what we’re discussing that there are a lot of decisions you’ve made there without coming remotely close to understanding them. I don’t mean that to be critical or negative and definitely not in a discouraging way, I mean that what you’re doing would be like me trying to design a new core for the LR4 rather than just a tool mount. I could do it, I could copy the existing one to a degree, but fundamentally without the deep understanding of the topic I’d be more likely to fall down rabbit holes and create problems for myself. It’d be a great way to learn some thing ‘in the deep end’, but I’m very concerned that you’re a bit too quick to get 100 made and then something that needs a minor tweak becomes an issue that you need to solve to dig yourself out of a several thousand $ hole.
This doesn’t seem like a JP2 ending issue, to me, more just something that probably should have been part of a prototype test. Either way, it’s something else to add to your list of specifications/testing.
2 Likes
So, I don’t know if this is the place but this is the design process I try to follow, roughly speaking:
User stories - This is the first step and can be a valuable tool when dealing with clients who don’t have a lot of domain-specific knowledge but can also help when mulling things over yourself. I would write a bunch of things like:
‘Bog standard LR4 user: This user will build a YBR compatible LR4 with no modification, built from a V1E.com kit and should be able to use the JP2 without needing to modify wiring or dive deep into documentation.’ Then attached to that you’ll have requirements such as: Must have enough stepper drivers to drive an entire LR4. Must have enough inputs to handle enough end stops. Must have an easily printed case that fits the LR4 ecosystem. Must have stepper connectors compatible with the wiring from the kits. etc.
Or it could be:
‘Power LR4 user: This user will have a LR4 with some modifications and will want additional quality of life or aesthetic features. They may have lighting on their gantry, a variable speed spindle, an added laser module, remote controlled dust extraction and a pendant etc.’. Requirements for that may be: All the requirements of a bog standard LR4 user. Ability to control a WS2812 based LED array or similar (maybe with a note saying todo: ‘poll the community to find the most common options for this’ or ‘decide on a single YBR+ compatible option to encourage people towards’). Ability to control the most common spindle types. Ability to easily attach a pendant without extra hardware, etc.
And having stuff like this is also useful:
‘Power user of a highly modified 3rd party platform: This user may have an unknown platform with unknown steppers/servos/external drivers, unknown amount of endstops, rotary axis, tool changer and others. This user is not supported by the product.’
From there you’ve got a set of requirements that you can condense into a second sheet. Usually there would be some kind of scheme for relating them together, such that a requirement such as '5 stepper drivers can be linked back to user stories 1 and 2.
From there you’d start to develop actual specifications such as input voltage ranges, stepper drive currents, connector specifications, input current limits, operating temperature limits, whatever else is needed to make the design as definitive as possible. Some of those won’t be able to be defined in the ‘top down’ approach like this so can be left open to later be back-filled from a bottom-up perspective (such as current draw etc.). Some of those specifications will be simple to define, some will be more complex and may break out into other specifications such as a nominal input voltage range, an absolute maximum input voltage, a short term overload/withstand voltage, a maximum isolation voltage between user and device, etc. These just get added as you realize a single requirement line can’t be met by a single specification line etc. Some requirements will have multiple specifications, some specifications will need to meet multiple different requirements, etc.
THEN from there you can finally come up with a test plan. Ideally every single specification will have some kind of test in place to make sure it actually works as intended. You’d design it and then once you’ve got a prototype back you’d go through DVT, design validation testing, where you test everything to make sure it does what you expect. That it will handle 30V on the input without anything burning up, that the stepper drivers don’t overheat at 1.5A out and 50 degrees C ambient, that the output PWM signals are acceptably clean, that the outputs will drive a 2A load without damage, that protection mechanisms act as expected, etc.
Obviously that’s all overkill for a solo dev and is more geared towards a method for generating consensus amongst anywhere between 5 and 500 or more people who are involved in the process, but there are still useful parts of it in there and it’s well worth considering which are the most important bits. I still use the user stories, even when it’s just me and the user may be a single client on a single machine. It’s a good ‘plain language’ way to say ‘it must do X, must not do Y and doesn’t need to do Z but it might be nice…’, which can help avoid feature creep or missing the forest for the trees, etc. For the specifications, you also don’t need to have an 800 line spec doc that’s all nested and cross referenced, but for bits where you know they’re critical, it’s a good way to note it down and then, most importantly, attach a test to it! Thinking about how you’ll test something before you design it is super helpful, both in software and in hardware.
4 Likes
So barTs module couldn’t even make it work? Isn’t that odd? Or not? If that did not work, is there a problem further up the chain?
I hear you. Clearly defining all the constraints would be amazing but nearly impossible. Anything we add pushes the boundaries for the board to be used for other things. Each new use case outside the MPCNC and LR increases the amount of unknowns. Each new use case drives sales, sales lower cost from larger batches.
For the must-haves, full MPCNC and LR compatibility on the yellow brick road at the best possible price, we have that, 5 drivers, 6 inputs, stable control at the best price possible.
From there, I want to make the best use of the rest of the available IO. The more universal that I can make the board, the more the board will be used for things other than the MPCNC and LR. This drives sales, sales means buying in larger quantities, larger quantities means lower prices for our core users. So as I see it, how do we make the best use of the 3 (or 4(gpio.0)) available output pins.
So for those outputs I am not sure the best use cases. FluidNC supports analog up to 20mhz( I tested it to 100khz), or digital. The closer we get to that the better but 5000hz is a minimum. I would much rather the firmware be the limitation, not the board. From what I see most of the laser “5v TTL” seem to also be fine with 3.3v. Not sure if that helps. We have 4 output pins (or more) we can always go back to 2 of each power level. Since I do not fully understand why our current outputs are so slow that might be best, or make completely separate circuits that are selectable.
I am not a huge fan of adding more of the giant wago blocks though. If it is a selectable thing I rather the user move two jumpers, that add a second set of terminal blocks.
1 Like
As to why move to JP3, I will be selling the boards I have. They are fully functional if you are not using a laser, they would make great Zen boards if nothing else. Calling the next one something makes the bookkeeping and instructions easier.
1 Like
https://www.tindie.com/products/33366583/5v-output-module/, this one handles lasers just fine. The other board does not specify the lower end of the input voltage and suffers from the same issues as the circuit we made at 5V.
1 Like
Would these come with only 2 drivers?
No but they are inexpensive.
1 Like