Nomad 3 Initialization/ lag

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.

Thanks!

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?

Regarding your USB cable, does it have ferrite beads on it?

1 Like

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.


Additional information after trying again today.

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.

Any ideas?

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.

Is Windows 11 21H2 a problem? Bitdefender?

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.

1 Like

It’s hard to gauge how messed up the machine behavior is from written descriptions. Can you take a video of what it’s doing, and what your input is?

I think it’s a workflow/ storage thing.

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.

I’ve made a video but feeling a bit daft as I can’t see a way to attach/embed it. Does my profile need to be enabled or something?

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.