Just built a Pro XXL with HDZ moving from my SO3 XL with HDZ. I’ve either discovered a bug or I’m doing something strange. I don’t ever recall having my Z crash after a probing cycling with the bitsetter if I had initialize in CM. The Z starts to retract and the gantry begins homing but it seems the z limit switch is either not triggered or totally ignored. I slam on the power switch to stop it, disconnect from CM and reconnect and everything goes back to normal if I initialize. I’ve checked the limit switch and it seems to trigger fine. I can reproduce this everytime by probing and then trying to reinitialize. Also has anyone had issues tramming and squaring the Pro? I suffered trying to get good belt tension the on the Y axis and can’t seem to reliably get the front to back tram right using shims. My next step is to try and loosen the shoulder bolts on the gantry and see if I can twist it into tram.
The switches are for homing only, they don’t function as limit switches.
Please check in w/ support@carbide3d.com — let us know step-by-step:
- what you did
- what you expected
- what actually happened
and we’ll do our best to work through this with you.
But if you hit initialize shouldn’t that home the machine therefor triggering the limit switches? Its unclear why initialize would cause a z crash
Yes, but they’re triggering as homing switches, not limit switches.
Possible causes:
- switch placement needs to be adjusted
- trigger post is missing
- mislabeled wiring
- faulty wiring/connector
@RocketSurgeon just to be clear what you are describing is occurring when initially powering up the machine and connecting to the machine in Carbide Motion and hitting the initialize machine button correct?
- Open Carbide Motion
- Power on you Shapeoko Pro
- Press the “Connect to Machine” button in the GUI
- Press the “Initialize Machine” button in the GUI
- … the machine crashes on the Z axis
You also mention probing do you mean you set Zero (XYZ) either manually or using a bit zero and afterwards reinitialize the machine (triggering the homing sequence) and your issues occur?
I’ve observed similar things and put in a very lengthy email to support documenting what I’ve observed with videos attached not long ago. Not sure what version you are running but I’ll assume it’s version 542 (or earlier) which is the one I documented my problem on. I’ve noticed in the Beta version notes under version 545 the following change log
545
- (NEW) Better handling of GRBL restarts
Maybe this addresses the issue but have not had time to confirm it.
The link to the beta software is here if you want to look at it ( https://carbide3d.com/carbidemotion/beta )
So to clarify. I discovered this by accident and then could repeat it. I bring up carbide motion, connect to the XXL, then initialize the machine. Everything works as expect, all homing switches are operating as normal life is good. Then I place a bit in the router, and I run a tool probe. The machine acts as expected, the system jogs to the stored position, probes the bit and sits waiting above the bitsetter. For some reason I decided to hit initialize after I did that last night deciding it would return to home. Well it did sort of but the hdz homing sensor was not triggered during the initialize cycle and was just grinding on its way to the back right corner. I hit the power but, disconnected carbide motion. Repowered the machine, reconnected to it. I took a wrench and tested the homing sensor on the Z to see if it had failed…all of them were working and registering as expected. I hit initialize and everything homed as expected. Decided to try it again just to see if it was a fluke. Probed the tool, then hit initialize. Exact same thing home sensors on Z didn’t respond and z axis was grinding. I can’t come up with a good reason why running initialize disables the homing sensors after a probing cycle. I’m running the latest official version of carbide motion.
Like @WillAdams mentioned send this into support if not done already and maybe this has already been sorted out in the beta (change covered under 545) but if not they need to know especially if it’s repeatable.
Yeah I’m going to reach out to them. I was going to take some video to include so they understand what the issue looks like. I was more or less seeing if anyone else had run into it.
Unless I’m missing something, something seems out out of sequence.
My machine never stops and waits above the bitsetter, it probes the bit length and immediately moves left to where it asks for a bit to be installed. There it waits and the Job Info screen comes up. there is no Initialization Button on that screen. I’m using CM 542.
This confused me too.
One possibility is that the machine is disconnecting after touching off the probe, which is why its sitting above the Bitsetter and the “Initialize” button is showing.
Simplest thing to check would be for a wobbly or loose USB connector.
The more I thought about it it almost seems as if the software and machine are restarting.
Doesn’t sound like a Z issue. Are you sure it’s not the X?
Unless I missed it, I haven’t read where you’ve actually performed an XYZ zero operation after the BitSetter operation.
Spend some more time and write a numbered list of steps that you actually perform when the problem occurs. Support personnel will want this, too.
I switched to the beta and disabled the bitsetter and the problem went away. With the bitsetter enabled the probe on the z axis seems to inactive and isn’t triggered at all. Disconnecting and reconnect resolves it. Still trying to diagnose the issue.
When you initialize, the Z moves up first.
If the gantry moves at all, that means the Z switch worked.
You said it was moving to the back corner. If that’s true, the Z is not the issue. I’d check your X switch. If it only happens when you initialize from the bitsetter, maybe there’s a loose wire?
With the BitSetter disabled, you say it works. If you jog to the bitsetter location and try to initialize, does everything still work?
Let me simplify it. I think there is something funky going on with the homing sensor on the z axis. I’m not sure if its the sensor or something going on with the board itself. I ran a homing cycle tonight after jogging around the board and there is a very strange delay going on with the Z. I’m fulling expecting to destroy the new HDZ with how often the HDZ is driving the stepper to the top and hitting the metal plate before the homing sensor is detected. I’ve tried adjust the position of the sensor itself, but that didn’t help. No matter what I do when I test the sensor manual it seems to pick up fine.
Please send photos showing how the Z-axis homing switch is mounted, and of the wiring and connectors (all the way to the controller) w/ close-ups of any logos on the connector housings in to support@carbide3d.com and we’ll do our best to get this sorted out.
Hopefully got this sorted. The issue became intermittent and then it would just magically crash again. It stopped for a few milling sessions and then when I started up the machine it crashed again on init. When it crashed I did see the homing sensor light up which was odd on the Z. I had been trying to catch it on video to send in. But just my luck I check the sensor just after it crashed and it was not detecting anything. I gave the sensor wire a little wiggle and like magic it was back alive. C3D is sending a new sensor and cable so hoping that sort this out.
Tramming sucks unfortunately. You can chase your tail since each adjustment requires you to loosen bolts and add shims. It’s unfortunate it was not addressed in the new HDZ.
Yeah tramming on the pro HDZ for some reason seems more tedious than on the SO3. Every little adjustment seems to throw everything out of wack and I have to start over. I haven’t been able to dial out the front to back tram yet. Couldn’t really get there by shimming so I loosened all of the shoulder bolts and tried my best to twist the gantry to take some of it out. Some eccentric bolts on the HDZ would have been nice for tramming.