Hello everybody, I've built myself a workbee, and got it sort of working with a MKS board and some 2209 drivers. I have to be careful not to overpower the drivers. So, i got some closedloop steppers with drivers. And i figured out the wiring. But. testing the motors and drivers, when i run fast - that is when i run more than 10.000mm/min i sometimes experience the motor stops. sometimes GRBL throws an Alarm:46 Sometimes the motor just stops and i can jog it again and it runs and sometimes the arduino crashes and needs a restart before i can do anything. Given the external controllers would like 1600 pulses/rpm, and I have 8mm/rpm, i guess it goes like this: 10.000 / 8 = 1250 revolutions/min 1250 * 1600 = 2.000.000 pulses/min = 33.333 pulses/sec Am i banging against some sort of limit here? and would i be better off with 800pulses/rpm? Or should i just go settle for slower? Hope to benefit from better brains ;-) /Kristoffer
Yes, you are banging a limit. putting your numbers into GRBL settings calculator using the 'Z' section 8mm per rev 200 steps per rev motor *8x microsteps = 1600 steps per rev gives Code: $102 Z (micro)steps per mm: 200.000000 0.005mm per step Z max steps/s: 33333.333333 Greater than 30kHz! GRBL on the UNO is limited to 30khz step rate, it will try to work above that, but as you have seen it will fail in weird ways. so, yes, you have to reduce to 800 steps per rev, which will give you 100 steps per mm and 0.01mm per step. (which is about 0.4 of a thou per step). If you really need more precision than that you will need to look at grblHAL on a 32bit board. terjeio/grblHAL
You won't get more precision than that without mapping the screws with 1um glass scales anyway. I'd be surprised if they were accurate to more than 0.05-0.1mm per 300mm, and I couldn't find any meaningful precision specifications for cheap hobby leadscrew anywhere, so they may not even be that good.
Insert pitch for grblHAL which pushes the step frequency limit well beyond 8-bit Grbl. My breakout will do 160K.
Aha! brilliant. Now at least i know what's going on. So GrblHal, any experience running that off a particular board?
That's a fair point. And even if i dream about upgrading to ballscrews and linear bearings, i doubt it would get that much more precise/stiff in it's current form. so fair enough, if i get to 0.01mm resolution, i still have many more improvements to make before that starts being the limiting factor
cool. looks like quite an upgrade from my little arduino. Is it still compatible with openbuildsControl ?
I haven't tried it. Probably ok in compatibility mode. You might want to check out ioSender - really well done and unlocks the advanced features of grblHAL. Supports ethernet connectivity. [edit] I did a quick look at OBC (v1.0.252) on my test setup and it seems to work OK with grblHAL. Jogging seems to send out the right motor signals. Ran a couple of CNC test files I have and the visualization showed what appeared to be correct behavior. There is a fair amount of experience using that board. The first two and last one on this list are based on that board. Full disclosure, I am the designer of it.
I dont know, I have yet to fire up grblHAL on 'something'.... however, the next version of the Blackbox might be a 32bit processor running grblHAL, or at least should be since it really is time to move on from the 328 processor. in which case, CONTROL will certainly begin to fully support grblHAL. what do you think @Peter van der Walt
@phil from seattle Is there a good open source 32 bit processor to pull reference designs from? I think the inherent advantage of the 328p is that you can just duplicate an Arduino Uno wholesale, and put your effort into the integration and power side of it, and it’s super simple to remote-diagnose and support. And of course, then you end up with multiple types and generations of products to support, which I bet OB are trying to avoid as much as possible. Especially when, for the 3-axis hobby routers that OpenBuilds sells, you really don’t need/can’t use more than 8 bits of precision anyway. It’s ok, I think there should be a FPGA-based BlackBox Advanced running HostMot2-compatible bitfiles connected to an OpenBuilds version of PathPilot (ie. preconfigured, skinned LinuxCNC), because it would be awesome and drastically extend the ecosystem for intermediate-advanced users and consumers wanting drop-in conversion options, but there’s like a 0.00001% chance of it happening.
Well, there is my Teensy 4.1 based design. It's in my github repository. eagle files and all. Several people have forked it so there may be a few variants of that coming. The core processor area is pretty easy to pull out and replace. I've got a "pro" version about done. There is at least one other design coming based on the STM32 nucleo dev board. I'm happy to work with anyone looking to build grblHAL boards.
I hadn't actually looked into the Teensy 4.1 before. That's an impressive piece of hardware, especially for the size, and I'm assuming all the HAL files are done for it. Just realized when I finally [have space to] build a CO2 laser, it would be good for that too for really high step rates (maybe you could even use SFU1620 balllscrews or something for like, pick'n'place style speeds). Whatever the next iteration of the BlackBox holds, its logic IO needs to be 5-24V capable. I have unshielded lamp wire on my mill home switches (for the time being, at least) and even at only 12V, zero noise issues. It would eliminate 40% of the support requests out of the gate.
LMAO. Yes. But until machine coords magically vanish, I still say you should try an experiment where you have the option to turn on G53 coordinate visibility via settings and see whether it helps or hinders people's understanding. My suspicion is that seeing both, maybe even with the true offset in another window like LinuxCNC's AXIS default, would help distinguish between the two. It definitely helped me in bCNC. The "offset only, no dual-coords" thing in LinuxCNC was pretty confusing at first, but if you could see both- G53 location, WCS location, WCS offset- then seeing that the two are consistently different by the size of the offset anywhere on the machine might help some learning processes. At least until they run into negative numbers...
Yeah the iMXRT1062 is a truly amazing processor, at least until the 1170 comes out... Unshielded lamp wires... Running NO switches I presume! My Pro board will support 12V on the switches. Trying to decide if I just go for 12V only or support 5V and 12V.
BlackBox can do 24v: docs:blackbox:jumper-limitswitchvoltage [OpenBuilds Documentation] Input is protected against high voltages too
Pretty sure I have the spades on the NC terminals of the switches, actually. It's trivial with Mesa hardware to switch between the two in the control- in HAL, instead of connecting x-axis-home to the hm2_5i25.0.7i76.0.0.input-01 or whatever the specifics are, you just use hm2_5i25.0.7i76.0.0.input-01-not. The HostMot driver pulls differential states out of all of the IO pins simultaneously, it's super easy. I'd see if there's a way to cover the full 5-24V range. Anyone wanting to use it with industrial hardware will need a 24V-compatible option because it's the low-voltage standard. And I'd hope anyone using a forked 32-bit motion controller would know to stick a 2k resistor on any 5V components! Oh, sweet. So why is everyone always running at 5V and hitting noise issues?!
It was a joke based on your use of the worst case wires! Should have put a smiley in. I have a huge pile of crappy speaker wire that I keep looking at and willing myself to resist the urge to use it... I put my box of shielded wire in front of it to help.
Oh I did laugh when I read it, just didn't carry over to my response for some reason. Seems like, at 12-24V you have a LOT more leeway than you do with ~3.5-5V signals. I'll replace it when I get some 24/2 shielded wire, but for now it's pretty reliable- and I don't have hard limits, so it can't cause problems that way anyway. Ironically, I went completely the opposite direction on the spindle cable for M4 and forked out for Igus Chainflex.
