Short version: Halp! Mah Z dun wurk rite! Long version: So I've got my half-width LEAD 1010 together (Lead 0510? 1005? Eric the half a LEAD?), but I've been stuck for the past few days struggling with an intermittent problem that simultaneously won't go away, and stubbornly refuses to manifest on command. So far I've only seen it in the Z axis, which is also the only new motor on the system - the other three motors and all the electronics having been carried over from a previous build. The basic problem is that sometimes, rather than dropping a step or three here and there, it seems to drop an entire command - something like G1 Z-.5 F2 will slowly count down the Z axis DRO in Mach3, while the motor does nothing. I noticed it in the course of working on an auto tool zero script, which does a G31 probe down at around 15ipm (around .5-1"), then a G0 rapid retract (maybe .1-.3") before doing a second G31 at about 2ipm (twice the retract distance, stopping when it hits the plate). When it happens, it usually seems to be that final low-speed downward probe that it misses - and when it does, it always misses the entire movement. Sometimes it happens more than others - it might miss that last pass on 4-5 back to back tests, or might let me run the program 20-30 times without a hitch. I've pretty much ruled out the acceleration settings (it seems about as likely to happen at 10i/s^2 as at 100i/s^2), and temperature doesn't look likely either (the Gecko G540 is rated for 70°C but rarely hits 40°C in regular use, and I've gotten runs of missed commands anywhere from the mid-30s to mid-50s. the stepper has ended up occasionally pushing 50°C in the course of testing, but that doesn't seem to correlate either). I still haven't entirely ruled out step/dir pulse width, but it's not looking very likely. So... any obvious mistakes here? Any vague and unfounded guesses? Any more efficient troubleshooting programs? (I've pretty much been spamming the tool zero script on repeat, since I've been too lazy to deal with debugging anything else from scratch, and nervous about running anything that would be capable of getting itself into a nasty crash if it skipped a move or two) The motor is an Openbuilds High-Torque NEMA 23 on the Z axis of a new Lead Machine (only supporting a flimsy little Harbor Freight trim router right now, not the big heavy water cooled beast) and being driven by the aforementioned Gecko G540 (using a 3kΩ current set resistor), powered by a 36V/10A PSU, and controlled by a long outdated version of Mach3 on an even longer outdated XP box. This motor, the wiring, plug, and resistor are new (and it's even plugged into the same port/driver as the old machine's Z axis) - everything else has been in the same configuration for years. If it matters, the steppers on X, Y, and A are KL23H256-21-8Bs from Keling/Automation Technologies (datasheets downloadable from the store link) - same phase current, lower torque/inductance/resistance. They're all currently hooked up, but idle - all my testing has been with only the Z axis active. More details available on request. -Bats (less details, on the other hand, may be difficult to provide)
For testing purposes I'd probably just write a similar program to bounce it up and down at various speeds that I could run on repeat. Since the probe is already written, it seems as good as anything. Though maybe over time and enough variations you could potentially find the speed at which it "becomes reliable"? Of course you'd have to watch it, since skipping an upward move between downward moves Would Be Bad. Any time I had a motor completely and silently ignore a command, it was because the wiring was wrong (or had sprung loose within the rat's nest that constitutes my testing environment). Probably the first thing I'd do is get a scope trace on the z axis STP lead at the Gecko, though I doubt that's it if it's always the low-speed move that it skips. To ignore one G31 command and not another, and intermittently at that, is just thoroughly odd. If the current's set low or the resistor rating is inaccurate, it should just clickety-clack away without actually moving anything, you can definitely hear that it's getting power. And if the signals are dodgy, it should skip other moves here and there too. I'm stumped at the minute, I'll have to ponder on it- slash hope someone else here has somehow come across almost this exact situation. To possibly A/B test the signal quality, you could potentially just flash grbl to a $10 Uno and stick that into your Gecko to see what it does. Maybe the computer hardware itself is crapping out on you, for whatever reason, due to age or environment. Or Mach has given up on low speed moves. I dunno.
Hi Bat That first line has a definite Scottish ring to it. Next. I know enough not to comment on GCode, as it really isn't my area of expertise, if indeed I have an area of expertise. I am a practical/mechanical sort of guy, so you know I'm gonna suggest you swop over the motors.
That's exactly what's had me reluctant to toss together a test like that - especially since the Z axis doesn't have a whole lot of travel to spare - not like the longer axis, where I could set a test to run for a could hundred iterations, come back in a half hour, and see if it's an inch or five away from where it should be without that inch causing it to bury itself in the frame and fold the leadscrew in half. The probe script only last a few seconds - making it a pain in the arse for extended testing - but between a couple years of use and thousands of test runs in the past few days, I'm confident that it's got enough idiot-proofing to keep even me from destroying anything critical with it. Or, well, at least as long as I don't run it too many times without remembering to put the alligator clip on the tool and the contact plate underneath it. Funny you should mention that. I did find a somewhat-looser-than-strictly-optimal plug on that motor today... but only after a few hundred iterations without the problem manifesting anyhow, so I'm not sure if tightening it actually did anything. That's exactly what I've been wishing I could do... unfortunately my only sillyscope is basically a museum piece - army issue, probably circa WWII, mostly-repaired (probably?) but still scares me to plug in, and absolutely no use for capturing passing events. I think I still have a reasonably modern Chinese counterfeit USB logic analyzer, but even if I could dig up the almost certainly pirated software that interfaces with it, I don't know that it's really cut out for that much current. This. The fact that it's losing entire movement commands rather than individual steps, that it's losing them sometimes but not others (and sometimes with high frequency), and that it's almost always the same movement that it seems to lose... not that there are too many different movements in the script for it to choose from. Yep. And it's obviously not struggling to make the move and failing - it's just sitting there and idling quietly. One thing I'm still a little suspicious of is resonance. The Gecko drivers are supposed to be all but immune to the common midband resonance stalls, but I've found a few scattered references to steppers also facing a similarly problematic range at low frequencies - I just haven't been able to find enough information about it (and absolutely none that also references Gecko drivers) to guess whether it's a likely cause, or even whether 2IPM (~200steps/sec?) falls into whatever band is considered "low". Exactly. And this is why I'm suspicious that the vaguely-looseish connector I found wasn't the source of the problem. I can't think of any reason it would shake out of contact only with that motion, and then reliably regain contact as soon as I'd hit 'retry'. That's basically what led me to post this - hoping that either someone coincidentally ran into precisely the same strange problem, and could tell me what obviously stupid mistake I'd almost certainly made to cause it. Are they making Unos with parallel ports now? Or are you thinking of just running in the relevant lines for step, dir, and charge pump (I've got at least one Uno, and maybe still a few digisparks, but, if it's not obvious, I've never actually played with grbl). I've also still got that free xPro kicking around... but the fact that - like today - I can loop the test for hours without a blip makes me wonder whether switching out the boards would actually tell me anything other than "well, it didn't happen today". Hardware (or OS) age wouldn't surprise me at all - although I have the PC pretty well heat and dust controlled - if it weren't so regular and/or irregular about when it happened. Mach's generally fine with low speeds - I had all four motors running down at least to .25IPM when I was tweaking the tuning, and they didn't complain - but the 'Cypress Enable' VB engine it uses for button scripts is definitely a little suspect. The only reason I ruled that out is the fact that Mach's DRO - which the script has nothing to do with beyond zeroing it out at the beginning of a probe - keeps counting down during the missing movement (since, obviously, there's no encoder to tell it otherwise). -Bats ( next step: sledgehammer calibration! )
Y'know what they say: If it's not Scottish, it's c...aught and ***'d out by the filter. Would it make it any better if I told you that the main bulk of the script was VB, with just a few lines of G-code? I'm definitely considering it, but, like Rob's suggestion of testing it with an Uno & grbl, I'm bothered by not knowing whether the swap actually solved the problem, or if it's just going through a several hour period of being cooperative that coincidentally overlaps with the time the motors were swapped (as I don't think a permanent swap would be a great idea, since the only reason I have the high torque stepper on the Z in the first place is because of the impending weight of the big spindle). With either swap, the only useful or informative scenario I could hope for is that the problem would reoccur with the new configuration... which is a frankly rather depressing result to hope for after putting the effort into making the change, especially since it would tell me that the cause is probably something even more obscure. Still, it might be the only thing to try... except that today I haven't been able to get it to happen at all. Which should be a good thing, right? -Bats ( call the Journal of Irreproducible Results - I'ma gonna win me an Ig Nobel with this one! )
Mostly wild guess, I have an electronics and controls background, but no cnc experience. I have to think a loose wire, probably a stp, but I'd reseat all the z ones to be sure. If that's not it, maybe the interface cable. If neither of those fix it, then try swapping drivers, followed by motors. Feel free to add in colorful language, in whatever dialect, whenever you see the need.
CreemCheese. You've noticed the superb colourful language of Bat as well. Sometimes I've enjoyed his style of writing so much, I haven't noticed what he was talking about!! However, if the machine is going to go wrong, fine, but I know there is nothing worse, and I really hate, these intermittent faults.
I'm still Team Loose Wire as well, honestly- I dealt with it recently when putting the laser together and it really does cause some weird sh--tuff. That often appears that it would be caused by a bad driver or a program fault or something, but it's just one random wire- and then, often, a different random wire. And I mean, the only way to deal with an intermittent fault is to just tear it all down and start again. Vive la revolution! (Interesting that revolutions always have to be masculine, according to the French... Not very 2019). (Just the electrical side, though, the machine frame did nothing wrong!) Yeah! That's some sweet grbl-to-Gecko action right there! https://smile.amazon.com/dp/B074387N6B - It would be reusable as a Gecko tester any time you needed it! Or just dump the Mach altogether and use bCNC instead for more advanced features. Or even try a linuxCNC boot drive, since you already have all the parallel ports plugged up. There must be some kind of way to isolate the issue. I mean, it may literally just be a case of putting rotary encoders on the steppers and letting the thing error out if it doesn't move. But if I were you I'd be very close at this point to ripping out all the wiring and electronics, rebuild the whole thing from scratch, new cables, everything. (And +1 for Bat's humour contribution to the board, I usually respond with weirdness in kind, it's great. I feel like there should be some kind of resolution, perhaps involving a large shiny metal object, maybe even in the shape of a key...)
