Initial Set Up assistance

As the title says - I have been noticing that the Openbuilds Control will randomly pause in the middle of a program. Some programs are fine, others will just randomly pause - the one I am working with currently has paused about 4 separate times now.

Is this a software bug or known issue?

How do I correct this?

I would like to be able to walk away and let the machine work on some of my longer programs. Yes, I do trust my machine with certain proven out toolpaths. ***pause #5 just as I am typing this!***. The only way I have found ***Pause #6*** is to hit the pause button and then resume the job to clear the issue. ***pause #7***.

Ok, well now this time its stopped completely and the spindle is just running at rpms sitting in one place. What is going on with this software??

I am able to control everything else just fine - start/stop spindle function, stop program, send machine to machine home, etc.

Additional info:
1. Not cutting wood, only metal
2. Not getting any alarms of any type
3. Machine works fine on some programs, pauses randomly on others
4. Using shielded cables, VFD to spindle has both foil and braided shielding

 

I think it is EMI. I just created a new tool path program to pick up where the last program stopped. I didn't change anything except for the starting surface. This new program cut a feature out that isn't part of the tool path at all.

Would the tool probe wiring be more sensitive to EMI than the stepper wiring? That would be the only thing that I added before noticing this issue ramp up in frequency.

 

And now my machine zeros to the WCS down the center of the part and not the corner.

 

Not sure what is going on here, but has anyone experienced issues with their steppers continuing to run when they shouldn't, or, not running when they should?

Thought maybe it was EMI, but this happens when the VFD is completely turned off.

I jogged the axis to set up for probing and two things happened -

The first, Openbuilds control says it stepper can't run until it finished moving (or something like that) and I could watch the corresponding axis digits move on the screen, but the motor/screw was not moving at all.

The second, I jogged the z axis by simply tapping touchpad on my computer which should have correlated to a short, brief movement of the z-axis. Instead, it just continues to run and crashed into my vise! Thankfully it was offset enough that the collet nut hit square on the edge of my material and the bit completely missed the jaw.

Why is this acting this way?

 

I can't even unlock the alarm from the abort. Again, no sources for EMI present.

 

Even more lovely surprises...

I had to re-home the machine, reset the controller to register the change.

I jogged back to set up for probing, the axis acted better after the reset. Went into the probe function and for some reason it rolled back to a bit diameter from 2 projects ago and was not showing the diameter for the last project I completed. 6.35mm not the 4.7625 (3/16") from the last project.

Ok, no big deal, I enter in 4.7625mm and carry on. I set up for probing the y-axis, confirm, run probe cycle, and watch the machine continue to run and bend the bit before stopping (when it registered the continuity).

 

What the **** is wrong with this software and blackbox? Seriously? I can't afford to blow through $100 bits because this **** hasn't had all of the bugs worked out.

Kind of pissed. ZERO EMI. NONE. Probing causes bit to bend, throws my tram completely out the window. Try to probe again and this **** box rapids my **** bit across my vise!


Rather than perform the Y-axis zero, the **** thing is trying to perform x/y/z and is rapiding to .886 / .886 on x/y. Haven't had very many issues with this thing until I tried using the probing feature. Then all of these issues start showing up.

 

I have reviewed it. The issues are present with the VFD turned off at the panel.

 

I was the source of the alarm - I have initiated aborts when its clear that the the probe cycle is not registering a touch or when it randomly decides to rapid into the z-touch cycle when I am trying to use and x-zero or y-zero by itself. This is probably the single most damaging problem that is occurring.

I stopped doing the x/y/z probe cycle because I would prefer to have the bit push against the material and still give me the chance to abort rather than including a z-zero and driving the tip into my stock and destroying it altogether. When I do the x or y zero it rapids to y=.886" x=.886" and drags my bit across the front of the stock.

Resetting for two reasons - inability to clear an alarm that I initiated with an abort, and to reset my machine home. I have had to reset for a new machine home because the steppers continued to drive past the machine home location, in one instance losing steps.

I cant be any more reactive than having my hand on the abort or e-stop. When I say that I am watching my bits being crashed into the workpiece doesn't mean I'm standing there like a dolt not doing anything about it. Of course I am going to stop it as soon as I can.

The problem with probing is that there is no way to tell if it is going to stop until the bit is already touching the workpiece. Once touching, it will either stop or continue going and when the tooling is 1/8" diameter, anything beyond simply touching the workpiece destroys the bit by shearing it off. I read from another user that they use a piece of round stock to set their x/y - which is something that I may do going forward to prevent damage to good bits. But at that point it kind of negates using the probe function for convenience and Id be better off with a spring loaded edge finder like I was using.

Bits are new or have a few runs on them, either HSS or TiN coated but not dirty, chipped, or damaged in any way. I rotate the bits so that they are touching off on the true diameter and not in the crux of the flute. I have tested continuity with the multimeter, thats not an issue. This is also happening with I clip the lead directly to the stock itself. Material is clean, no dirt, dust, or debris, nothing preventing good continuity. Stock also tested with multimeter for continuity.

I stopped probing with the x/y/z probe cycle because I don't want the tips of my bits to be pressed into and snapped off when the z-axis probing cycle fails. Because of this, I am using the individual axis probing. When I select either the x or y axis probing cycle, set diameter, and probe, the bit rapids to x=.886" and y=.886" when its down along the axis it is supposed to probe. This results in the bit being dragged across the front of the work piece.

Macbook Pro
Mojave, V10.14
Mid 2015 Retina
2.2 GHz i7
16GB DDR3

 

Is it possible that an EMI spike could scramble the EEPROM in some way? EMI as the root cause seems like the most reasonable and plausible explanation, but the fact that these issues are presenting when the "EMI generator" (aka VFD) is turned off tells me there is more to it than simply moving some wiring, adding a few chokes, or pulling stuff apart to add shielding.

The probe wire has a ground, constant voltage, and a signal wire. Is that signal wire more susceptible/sensitive to EMI than the voltage wire? Everything has gotten exponentially worse once I started using the probing feature, I am wondering if that probe signal wire is acting like an antenna for EMI?

 

Why has the title of my thread been changed to "Initial set up assistance"? This is not an initial set up problem!

 

Of the one or two times that probing did work properly, I simply rotate the spindle by hand so that it isn't touching off in the open space between the flute and the shank.

 

I don’t position over the stock for an x/y/z probe cycle. I position it over the bottom left corner, exactly like the picture. This is not the problem.

For the x-zero, y-zero, z-zero, I position the bit within about .100” from its corresponding edge. When performing an x, y, or z zero, the bit is supposed to travel in a straight line that corresponds to the axis selected. Instead, this box rapids to perform a full blown x/y/z cycle.

 

No, it doesn't appear so. I am using v1.0.311

 

A couple things to note before I can try a windows omputer-

The control version is 1.0.311 and it appears that 1.0.312 is where the Mac compatible control ends, is this correct?

Also, the MacBook that I am using isn’t loaded with software, files, or other junk. It’s very close to its original state as purchased and is only being used to operate the OB Control. The only other items on it are the arduino IDE, a scanner utility, and MS Office for Mac. I haven’t seen or experienced any performance degradation whatsoever.

 

no, I am not using the OB probe.

I am clipping the signal wire from the probe wiring to the workpiece. Since the machine is grounded and everything is either aluminum or steel, there’s no need to clip at the spindle/bit. I’ve tested this thoroughly to ensure there is no loss or break in continuity.

Attached is a pic of the location I moved the signal wire to during troubleshooting. It still gave me problems in this location as well.

 

Here’s

ok, no problem

I have only been using the signal wire, with ground and V+ not connected to anything.

How would you hook this up so as to use the machine chassis? Ultimately, it would be great if I could simply touch off on the workpiece itself and not even fool with a touch plate at all except for circumstances where its necessary.

Got it.

See previous reply. Maybe I am hooking this up wrong?

This might be the issue - the machine is on earth ground, as is the rest of the electrical. Knowing that, is this a potential culprit for erratic probing issues since I am connecting signal to an earth grounded chassis?

I don't think the grounding is related to the random toolpath stops and pauses - I think this is separate. This issue happened before and after I started using the probe function.

The only machines that I can use are

1. First is a very low quality Asus from 2018, its a base model and incredibly slow. I originally wanted to use this computer for control, but it didn't even like loading the 3D toolpaths.
2. Second is a 2012 - 2013 Dell Precision. 2.8 GHz i7, 32 GB RAM, NVIDIA Quadro, 64-bit OS

Thought it was worth mentioning that there wasn't anything consuming resources needed for the control software.

 

I also went out to simply try running it again. I started up the computer (mac), turned on power to the electrical control items - Black box, OB Power supply, VFD not on (still off at breaker). Then I plugged in the USB cable, booted OB Control, connected to port.

Using a 6mm stud I tried performing an x, y, and z zero on the workpiece. They all worked fine with no issues. The touch from the probing cycle was light and registered immediately on all 3 axis.

I also have chokes and a new USB cable arriving today - the chokes are for each of the stepper cables, I plan on putting a single ferrite bead on each end of each cable.

The new USB cable is a bit longer with ferrite beads installed like the OEM OB USB cable. This cable is 16 ft long to get the laptop a little further away from the control and VFD. In case there are EMI issues with the ports on the laptop.

I do plan to run a test with the Dell Precision and will do this before I add the chokes and USB into the mix.