What s wierd is that it works for some time and then stutter.
Been following this thread, though I’d comment on this anyway. If I’m following this correctly…
Anyone who has dealt with these controllers knows they are pretty dumb. @dean448 stated that they appear to be made for ‘low cost diy’ applications. Although with my Ruida, I don’t think qualifies for the ‘low cost diy’ market.
If you think about how this generally works, a computer sends step signals to another device that switches the current in the fields to move the stepper. If they reside on the same board or not, it makes no difference. None of the boards I own, including the Ruida knows if ANYTHING is powered up downstream of the controller. Therefore can know nothing about what happens after it’s signals leaves the controller. Like did it move or how far…
With no feedback to determine if the command was executed or if it executed properly the controller has no way to know anything about what the machine is actually doing, physically.
To engineer something that ‘crashes’ into the frame as part of the startup (or home) is questionable, to me. There must be other hardware on it for it to determine it’s home position, rather than crashing.
Switches are ‘cheap’ compared to ‘engineered’ encoders, current monitors and other types of hardware along with associated software that must be ‘engineered’ to support it.
Plus if it ‘knows’ it’s having a problem, it could probably ‘heal thyself’ and not have to reset, since it would really know where it was anyway. Or at least ‘halt’ with some type of error message.
As you can tell, we are trying to help, but @berainlb pointed out, all of what ‘you use’ is ‘alien’ to most of us.
For what it’s worth, when controllers randomly reset, it’s commonly power fluctuations being the issue.
Good luck
Maybe I interpreted this video incorrectly? Buildbotics homing without limit switches on the Onefinity CNC machine. - YouTube
There is a concept of “Sensorless Homing” I’ve seen on 3d Printers and now apparently CNC machines. It relies on detection of lost steps by the stepper driver through back EMF . This isn’t the same as a true closed loop solution.
I’ve never really liked this solution and feels a bit like a hack but here we are.
An excerpt from Klipper firmware documentation describing this:
Sensorless Homing
Sensorless homing allows to home an axis without the need for a physical limit switch. Instead, the carriage on the axis is moved into the mechanical limit making the stepper motor lose steps. The stepper driver senses the lost steps and indicates this to the controlling MCU (Klipper) by toggling a pin. This information can be used by Klipper as end stop for the axis.
It is still feedback from the driver circuit to the controller.
I would view this as a poor mans ‘hack’.
Does it just ‘run’ into the frame?
How does there controller know ‘exactly’ where/when the missed step actually occurred?
I think the accuracy would be less, even if you backed off the frame and re-engaged it. There may not be an absolute step there.
I agree, doesn’t sound like a very good solution to save a wire and switch.
Thanks for the information berainlb. Of all the machines I use the only home that I really use is Z axis of the printer. Bed height never changes.
In all other machines your basically zeroing the DRO. Digital read out. Which is like pressing origin on the laser.
I think we know why it’s shuttering and resetting, the question is what on the machine is causing it to do that? Low speed which is poor design or drag on the axis?
I agree with Jack on one point, contact them and ask.
Look at the video Jack. And when you guys use the word hack that makes me think low cost.
Essentially, yes, at least in certain configurations. Might not be true in this case as I’m guessing they’re using the lugging at slow speeds to provide a similar back EMF. But purely speculating.
This is definitely considered a less accurate process. For example, on 3D printers this wouldn’t be considered accurate enough to handle Z-axis homing as it’s likely far enough off that you’d have bed adhesion problems with the first layer.
You still have to add components and modify the software to check ‘back emf’. Don’t even know what that is exactly since any magnetic field collapsing around a coil will produce ‘back emf’ no matter if it’s a moving or stopped coil.
Is there something unique in the waveform you would have to detect to tell if it’s a ‘good’ step or ‘bad’…?
If it knows it missed a step, it should be able to correct it without a reset operation.
Can’t make it ‘cheaper’ adding hardware and software to it.
This is helpful…
https://forum.buildbotics.com/viewtopic.php?t=199
If I’m reading that article correctly basically it relies on a situation where no voltage is expected. If voltage is detected it is assumed to be from back emf. This explains why the process is so finicky about motor speed, step size, etc.
Still a hack… but maybe a useful hack when other options are not immediately available.
I had a stuttering issue on my Thunderlaser. It turned out there was a hairline break in the axis sensor cable. The sensor cable was constantly flexing on the gantry due to the gantry movement. This eventually created a break in the wire, so every now and then the machine thought the sensor stop had been activated. If the head was going fast enough it would stutter past the break. Not sure If this is your problem.
Small companies who develop new stuff (in this case controllers) have to come out with something new and different. May not make sense to us but less experienced folks don’t know better. Could also be that machines don’t come with limits? Not sure and doesn’t really matter.
Pretty sure that this topic doesn’t answer why it’s resetting in the first place.
Can’t remember when this wasn’t some type of power issue.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.