I’ve used my S4 Standard for about 3 weeks now. It’s been idle for a week but I was anxious to keep using. Today I had one of those Murphy’s Law days… and this is the latest problem. I had the probing failed issue which other’s had reported. After reading the forums that corrected by reloading the configuration. The first time it would actually push the button then the probing failed. But cycling the power on the S4 again. It seemed to probe.
I wanted to test some engraving depths but I usually zero with bitzero using an endmill then switch to a Vbit. After going through the bit changes and bitsetter probing. I started the spindle and it started to carve air. Seems the height didn’t reset. Later I just zeroed the Z with the vbit. It did start carving, but much deeper than I expected. When I jogged over I saw the Z had been reset to a deeper than the surface even with the same bit. I went through the process several times monitoring where the Z zero is with Carbide motion and seems that bitsetter is not properly measuring tool length.
The bit setter was working correctly last week.
This is a long list of things that seemed to be not right today. I don’t know they are relevant but at some point when the configuration was messed up the Z wouldn’t stop going up despite the limit switch so I don’t know if the Z motor or screw got damaged (though they seem to function fine).
This is fine but it has to be done in a particular way. So, be sure you are doing things in the right way.
If you are using the BitSetter, then you can never arbitrarily change the tool in the collet.
As in, when you are replacing the endmill with the VBit, only do that when there is a prompt in carbide motion telling you to do it.
Do not, ever, zero using the BitZero with an endmill, then reach for the wrenches, and change the endmill to something else. Always wait until you are told to do that.
Please let us know about this at support@carbide3d.com — include a photo of your Z-axis motor wiring and connectors, including those of the wiring extensions and at the controller and we will do our best to assist.
I sent am email to support, but I may have found the answer.
Due to the original bitsetter probing issue I reloaded the configuration to the machine. But in reviewing the instructions later, I realized I didn’t load the defaults after. It is possible maybe the machine had the wrong Z-Travel. I loaded with the leadscrew (is that correct for S4 standard?). Repeated changing bits with the load new tool in carbide motion and jogged to check the Z. Seems to be correct now.
Though it fixed the problem, I won’t feel comfortable about the depth of cut until someone can confirm this could cause the problem.
For what its worth, that wasn’t the problem. It’s doing it again. For now, I’m just going to have to disable bit setter. It’s just not functioning correctly. Hopefully support will have a clue.
Thanks, but I’m not changing bits when not prompted. I’ve even had the situation where I’ve zeroed, verified the zero in jog mode. Then run the job, it cuts to deep, stop the job, measure the zero in jog mode and find it’s been reset. In theory since I didn’t change bits. Bitsetter should not have changed anything.
As an update: bitsetter now seems to be ok, but until the cause is found whether machine or user error it’s going to be a while before I trust it again. I’ve been running it without sweepy for the moment so I can see the initial cut and running different gcode between tools so it is easy to verify the z.
Hopefully you are getting close to a resolution given your latest post.
With respect to the question you asked here, the answer is “yes”. The different types of Z-Axis all have different parameters that essentially say how many pulses it takes to move a millimetre. So if the wrong axis is selected and the configuration sent to the machine, the axis will move the wrong distance (linearly).
More problems. I’ve emailed support, but I get that issue where the spindle moves down and stops after 10mm when trying to measure the tool length during initialization, which is what happened the last time. However, this time bitzero also fails to probe. It doesn’t move at all before the failure. I know if the probe doesn’t make contact in a short distance it will fail, but it just doesn’t move.
(I thought maybe something was wrong with the bitzero so I unplugged it. But the bitsetter still doesn’t work.)
I can still use the S4 but have to zero everything manually.
The BitSetter code has a maximum search distance of 10mm, after which it aborts to avoid excessive travel. It’s a safety-cum-convenience thing. The tip of the cutter has to be within 10mm of the probe before you start
Can you power-cycle and connect to the machine, but NOT initialize, then go to the Settings tab in CM, and check whether you see “PROBE” displayed under “GRBL Active input pins” ?
The odd thing about this is when I started having problems both the first time bitsetter malfunctioned and this time. The S4 had been powered off for a few days. Yesterday when this latest issue happened, frustrated I went out for a walk for about an hour, when I came back I was going to do some manual zeroing, but thought what the heck, I’ll try bitsetter again, It worked as well as bitzero. If I didn’t know better it feels like the S4 needs to “warm up” for a while which I’m sure should not be the case.
To add to what Will is mentioning, when you are not using your bitzero make sure it lays somewhere such that it is not in contact with the machine frame, which may ground it (and therefore falsely trigger the PROBE signal, which then gives all these problems you have been seeing)
The PROBE signal under GRBL Active input pins should only ever be displayed when:
the bitsetter is triggered (manually or with an endmill)
the bitzero is triggered (which should be visible on its LED)
I had same problem
I was zeroing and when finished I sat the clip on top of the zero block
When my router went to bit setter it would travel down a little then stop
Took me a short while to figure it out but still felt daft
Last night it had started behaving correctly. I went down this morning to switch USB cables to address my other problem I’ve been having. Went through the initialization cycle and sure enough bit setter is exhibiting the problem again. So I cycled the power, disabled the bit setter, initialized the machine. Then I tried to probe using the bit zero. Carbide motion momentarily said busy then I got a probe cycle message. There was no movement of the spindle whatsoever.
Obviously when probing the lead is attached to the spindle and the so the probe and lead are not touching.
Extrapolating from Julien’s thinking, when you see this problem you probably should check the settings page to make sure no PROBE signal is active.
The BitZero and BitSetter both use the same wires. You should not have a PROBE signal active unless the button of the BitSetter is pushed, or the BitZero’s light is on.
If the PROBE signal is there when neither of these is true, you have a loose or crossed wire somewhere.
I think you may have an intermittent short of the PROBE signal to GND somewhere in the wiring. Could be at the controller side, or somewhere down the cabling to either the BitZero and/or BitSetter. The way to confirm is checking that “PROBE” message under GRBL Active inputs before initializing / before probing
(replying in parallel to @Gerry, so…what he said!)