I just picked up a Nomad 3 “locally” that appears to have very few hours (if any). Build date is 2/2023.
I was careful to warm up the spindle, and jog all axes through their full range of travel, but initialization is giving me communications errors and occasional GRBL “hard limit” errors.
First question: I’m running a Zbook with 32GB of memory - any reason it should take several seconds for commands to send, and limit switch changes to show in Carbide Motion (build 640)?
Second: is anyone else concerned about the proximity between the left-right stepper cables and prox switch? It looks like they’re just begging to be crushed every time I try to home it.
Third: it loses connection to the machine OFTEN. I tried a different USB cable, and a different port on my laptop. Is this a hardware thing, or a software thing?
Big question: Is build 640 mature and stable, or should I try to run an older build? Are there still builds available that I could run off a tablet so I’m not bringing my nice PC into the shop?
I dislike that I’ve had better luck with an Amazon CNC so far, and I’m wondering if I go back to Fusion/ GRBL instead of using CM, or if it’s worth using CM once I get some stuff figured out.
The Zbook should be plenty powerful for that — are you keeping a log window open? If so, close it.
Post a photo of the switch?
EMI is pretty unusual for Nomads — check in at support@carbide3d.com and we should be able to sort this out — be sure to point out you have a Nomad (send a photo of the machine in).
Grbl is the firmware on the machine, so I guess you mean you were using some Grbl communication/control program such as Universal G-code Sender?
One of the two USB cables has ferrites on it - they both behave similarly.
My earlier comment, I meant Candle/Grblcontrol with Fusion, but I’d like to use CM if possible.
For a Nomad 3 with CM board version 3.0 and MG version 5.2, do I need to do any firmware updates to use CM build 640? It’s literally been in a box for over a year.
My concern with the prox switch isn’t an EMI thing, it’s a concern over physical occlusion/ pinching the cables. It looks really tight and I’m wondering if a cable got in the way of the homing process during one of the attempts.
Booted up, “initialized”, machine went to “north center” position. I did a “Quick action” move to machine zero, it went smoothly to more-or-less over the bitsetter probe. Then, it popped an error:
GRBL Alarm 1:
Hard limit has been triggered
I cleared the error, initialized again, same error immediately with a “stutter” in the X-axis toward the right limit.
I opened the enclosure, pulled the carriage towards center.
“Error, machine stopped responding”. When that cleared, it looked normal again.
Next, I did a “quick action - plunge to 1 inch over Z zero”. It retracted the spindle, then GRBL Alarm 1: Hard limit has been triggered, this time with the spindle at the upper limit of travel. I can’t initialize the machine without hitting those errors again, so I can’t jog back to center and try again. I have to physically move it towards the center of travel.
Today’s tests were done without the bitsetter block plugged in.
Hm. I whitelisted CM in Bitdefender, but when I went to “Setup new machine” after it all errored out, I watched my firewall logs and a svchost.exe was blocked during Machine Setup Wizard. It also would take 2-3 seconds to indicate the status of any home switches on the page prior to initializing, then another 3-5 seconds to register that the steel sheet was no longer near the switch.
Now, though, it’s behaving “correctly” in CM - probing works, it’s setting zero, it all seems good.
CM is still slow, but hey, if the machine works, all good.
Don’t use the quick moves in jog, it often (but not always) goes the wrong amount and loses track of where it is and then goes on to hit the limit switch. My N3 does this quire often. It didn’t used to so I am guessing a bug crept in on Carbide Motion. Using standard jog seems to be OK.
I am glad someone else has reported this as I thought I was alone.
Today, I started using manual jogs - not quick moves - and it just behaved better. Initialization was a hair unreliable (a few more hard limits), but once initialized, it zeroed well and ran a modified tool tray tutorial perfectly, including a bit change and some engraving. I can’t tell if it’s just the lubricant working back into the bearings and nuts after a year stationary, or the Bitdefender mods, or fewer sun spots aimed at my house, or me subconsciously learning to avoid what led to errors.
I’ll avoid the quick moves, be patient as it initializes, and be pleased going forward, from the looks of it. Inside the work envelope, it was super reliable and intuitive.
Thanks for the early advice/ leading questions, everyone.
A video would need to be posted to Youtube and made public and the link pasted in here, or uploaded to Google Drive or some other network site and then posted as a link.
Hi @wmoy , video linked so you can see the sort of thing that happens.
It is possible to goof around pressing stop and re-initialize and get fast moves to work and once they are working they seem to be reliable.
It’s only fast moves, it will cut all day without missing a step so it’s definitiely a software thing and not a hardware glitch / EMI thing.
My first instinct says there might be a faulty wire or bad driver/motor. The angle it moves when when you rapid to NE looks correct, like the machine truly believed it was starting from the SW corner. Which means during the move to the SW, the stepper motor was misbehaving. (You can double check the position readout in CM to be sure. The X-coordinate should be decreasing during the move to SW…)
If you jog slowly left and right, and can apply light pressure to the Z-axis to cause a skip/reverse, that might be another indicator. That would mean you push/pulled the motor in such a way that the windings got out of phase. That could only happen if one of the phases was a bit flaky to begin with.
Can’t be 100% sure, but I think it’s worth reaching out to support to see if there’s any other steps you can take for a resolution.
It’s not a broken wire. I just powered on, fresh homing cycle and immedately did a “rapid positioned to current XY” which correctly took me to the previous work zero (pretty close to preset SW corner as it happens). CM correctly showed 0,0. I then immediately followed this with a rapid go to SW and it went in the wrong direction and hit limit switch.
I then hit the soft stop button, reinitialized and rapid to SW which worked. I have just spent the last 10min going to all the rapid positions in random sequence (I didn’t count but well over 100) and they were all perfect.
I then power cycled the Nomad and hit connect to cutter without restarting CM. After homing I resumed rapid positioning for another 50 ish moves. All OK.
I then closed CM (leaving the N3 switched on) and reopened CM, did homing cycle, and on very first rapid move it went in the wrong direction again. Again, without restarting CM or the N3, I hit soft stop, reconnected to cutter and after this rapid worked again.
This is clearly an initialization bug in CM, it is so repeatable.
