How common are missed steps?

Hey Forrest,

here you can see how different materials trigger the inductive proximity sensor Omron E2B which was available at my local CNC equipment supplier.

Source: Omron E2B Inductive Cylindrical Proximity Sensor Datasheet

Some people also use microswitches but I would always prefer using inductive proximity sensors because the contacts will not wear out or attract dust.

The problem to solve anyway is how to attach them. As far as I know, everybody I know used 3D-printed parts, as Tom @TMToronto did as shown above. Thankfully Tom published the 3D files in this thread! An alternative would be milling them out of wood using a CNC (less plastic). :slight_smile:

Further reading

1 Like

The ones I used are no longer available but were similar to these:

I specifically used a normally closed setup so if there was ever a failure of the wiring it would cause the machine to stop rather than crash into the end stops. Because they required 12-36v and the Onefinity controller operates at 3.3v I initially used a relay board I had between them but eventually moved to an optoisolator once I could get one to avoid the mechanical nature of a relay - both methods proved to be equally as accurate. Under normal operation the relay would be held closed by the normally closed proximity sensor and would open during the homing cycle which would break the circuit on the 3.3v side to the DB25 breakout board.

The basics of the mount looked like this, note the metal screw in the plate for the proximity sensor to detect. I can dig up the stl file for the mount, same one works on X and Y. I don’t have one for the Z, that was more “custom” and not something I’m proud of but it works :slight_smile:

2 Likes

Hey Festdewalkita,

The encoders found in the usual closed-loop steppers are not absolute but incremental encoders. That means, if you move them by a number of steps, their driver checks if they did that many steps. At bootup of the machine, an incremental encoder is not able to say where the axis carriage is positioned without homing.

Stall homing, at least as it is implemented in the TI DRV8711 just works by sensing the electromotive force, it is not related to the closed loop.

1 Like

When I looked at servos early on, they start to get expensive when moving from incremental to absolute encoders, and also lower to higher resolutions. The costs added up (too) quickly, so I remain happy with my steppers :smiley:

Hey Festdewalkita,

here I link you to a typical closed-loop stepper driver and its Manual (PDF). As you can see on the diagram,

Closed_Loop_Stepper_Driver

to drive such a closed-looop stepper driver, the CNC Controller needs the step, direction and enable lines to control the motor. These lines exist inside the Onefinity Controller (they go into the TI DRV8711 stepper drivers) but are not accessible from the outside. The Buildbotics Controller in its recent version now makes these lines accessible with its 15-pin auxiliary I/O port, so that you can connect closed-loop steppers.

See also here.

What I was trying to say is essentially that since they are closed-loop means they provide feedback to the controller (as in your later post# 26). As part of the stall homing, you could combine that (presumably useful) feedback to the controller in much the same way as what we do when we zero (i.e., stall current/voltage threshhold reached, commanding - x microsteps, - x microsteps performed, commanding (x-1) microsteps, stall current/voltage threshhold reached, commanding - (x-1), etc., until the controller discovers how many microsteps lead to no stall threshhold reached).

(As an aside, I know that this isn’t the way the zero (sub)routine works…but it is analagous. One gets feedback from the sensor we plug in, the other would get feedback from the motor itself.)

Compare that algorithm to what we see in our 1F BB/LinuxCNC controller’s software where it reaches a stall threshhold in a very crude way, then dials back about a 1mm without any further refinement.

That parameters 5161 and 5162 get referenced to 5211 and 5212 via the existing 1F BB/LinuxCNC homing or via the algorithm I described doesn’t matter, except that one way is inaccurate, and the other is less inaccurate.

But just because I can conceive a better way doesn’t mean it can be cleanly implemented. It’s just not my area of expertise and I can’t justify putting in the effort to discover/implement that on my own.

These days I’m less interested in trailblazing than I am in being practically efficient. I don’t have to invent the wheel, I just have to look and see a wheel to know there’s a better way.

Har.

I’ve put a lot of time into understanding this setup. It’ll be hard to just walk away from it and start over with something else.

Hey Festdewalkita,

If I understand you right, and if you are satisfied with your Onefinity Classical Series (except the points mentioned), you could wait for the Upgrade package to Elite.

There are many reasons to choose the Masso G3 Touch and the Masso closed-loop steppers. I did not run the Masso CNC Controller, but Tom @TMToronto does since a considerable amount of time and I know Tom does not choose hardware or software without deep research on their capabilities.

Think of what you will get out of the box: Infrared homing sensors with auto squaring (sensor on masso homepage), Power Loss Recovery, Jump to Line, and Feed Rate Override - Adjust feed rate during a carve. And all that with a probably straightforward retrofit time.

1 Like

I think we’ve covered the OP’s topic well.

Suffice it to say I’m interested in a now solution set that (however imperfectly) resolves (some of) the points I raised with the 1F BB J-man as well as a future “easy button” 1F Masso J-man upgrade solution that also seems to more completely resolve those concerns.

2 Likes

Hey Festdewalkita,

retrofitting inductive proximity sensors as limit switches to a Onefinity Classical machine is something that I consider as very good value to achieve position repeatibility over homing / shut down. And there are already two offers/possibilities for the necessary files for parts to be 3D-printed in this thread.

And the effort to retrofit them would not be wasted if somewhen the Upgrade package to Elite comes out since, as Tom has shown, they work very well with the Masso G3 Controller too.

We were flirting with OT from OP…now I think we’ve crossed it.

But…I think we can continue this line of thought!

For context on the question I have owned my woodworker for over 2 years now and use it in my business on a daily basis. When I first bought the machine the first few months I experience a few missed steps. After testing many scenarios I determined the main issue was EMI and so I grounded the machine and added ferrite rings to all the wires. In the last year and half It has missed step twice. Both times were from me running the machine too fast on really tiny detail in the z axis. Last year I also moved up some of my settings to run my jerk setting at 12000 up from the stock 1000 and have my z axis acceleration moved up to 4 from 3 so even with these advanced settings it has had no issues.

2 Likes

Hi Josh, I bought my X-50 Journeyman to do the same thing as you, build guitars. I am happy with the machine, but the controller is the weak link and if I had the choice to get the Masso controller on the elite series, I would do it in a heartbeat and consider it money well spent. I have had problems with the controller losing steps because it did not like helical ramp entries. It would make clunking noises on the ramp and basically the zero point would shift which would really F stuff up. It would do a helical boring move, which is basically the same move, no problem, but caused no end of problems on the helical ramp entry. I first solved this by switching to a zig zag entry, which worked, but the helical ramp is a better entry and there was really no good reason why it shouldn’t work. I then messed around with the g-code a bit and found that if I deleted one line of code (sorry, I can’t currently remember what it was) I could get it to work. This is a poor solution and I eventually found that if I reduced the ramp speed to 30 IPM it would work. My conclusion from all of this is that the problem stemmed from the controller becoming overwhelmed. Basically not enough processing power. I don’t really care about it taking a couple seconds longer to run a program. What I do care about is that I had to figure out a workaround to overcome the limits of the controller for what should be an easy move. That and a couple guitars that are not quite right… My 2c…