Hi, I am having same issues as CookieMonster with Tutorial #2. I have attached the image, can you guys please suggest how to fix this issue?
Thanks
Hi all,
For what it is worth, I think I may have narrowed the X-axis drift down to a problem with the Mac OS-X version of Carbide Motion.
I have been battling this X-axis drift, going through a number of failed attempts using different feed rates etc. In one instance I even eyeballed the drift happen while cutting air, after restarting an interrupted cut.
In one case, cutting a raised relief map, I noticed that the accumulated drift during the roughing pass appeared to be zeroed when the finish pass started - resulting in a canyon being cut through all mountains 
Here comes the clincher, I was driving the Nomad using Carbide Motion Version 2.0.314, Build Date 2015-04-9 on an Apple Macbook Pro running OS-X Yosemite.
Last weekend I switched to a Windows Computer running Carbide Modion Version 2.0.314, Build Date 2015-04-10. Since then I have already done 3 cuts, none of which has had these X-axis problems. To reconfirm, last night I reverted back to the Macbook, just to see the same problem happen again.
Hence a question, are any of you guys experiencing the X-axis drift using a Windows machine to drive the Nomad? If not, then the culprit may be a bug in the Mac OS-X version of Carbide Motion.
Thank you loftur for your diligence in investigating this 
that’s a good question. I’m a Windows-only person, and haven’t seen the issue.
Unfortunately I am indeed on windows (Windows 7).
There is an interesting thing, though; I had glitches solely in the +X direction when hooked to my desktop computer in the computer room. I tried moving it to another room and used my laptop (both Windows 7), and the glitches changed so that they were occurring only in the -X direction (and much more frequently). I wonder if there is some electrical interference/noise/grounding thing happening around that usb cable or something.
Using also the Mac OS version on Yosemite and also had the X axis drift. It doesnt always do it but especially for longer carvings. Especially my 8-10h map relief carvings. I can’t reproduce it thought, the very same file sometimes works, sometimes drifts slightly. Tried on 2 different Macs, 5k retina and 2008 Mac Mini.
Today I successfully disproved my theory - two failed cuts due to X-axis drift, although using a PC to drive the works.
I have a new hypothesis though 
All the problem cuts were using millimetres as unit of measurement in the “Toolpath Parameters” setup window in Meshcam.
I have now just finished two cuts where I used inches as unit of measurement in the Meshcam “Toolpath Parameters” setup. No X-axis drift whatsoever. 
So the new hypothesis is: Is the X-axis drift caused by a rounding error somewhere, when converting units of measurement???
As a test, I removed the Arduino board, and controlled the stepper board directly from my lathe’s PC parallel port using Mach3 (with settings modified for the Nomad stepper board). The glitches persisted, leading me to conclude that the problem is an electrical problem with the stepper board itself. Possibly a few boards have a component or two that is out of tolerance, leading to increased noise susceptibility on the step input line. I’ve been in contact with Rob and Jorge about my testing.
I also recently exchanged the fan since the fan was very loud and potentially could have caused overheating at longer carving sessions (which is when i usually found the X drift). Thanks for the quick replacement part Jorge by the way!
Just started my first 7+ hour carving after the fan change. If its drifting again, the fan was not the cause. Since it doesn’t drift all the time though (even with the very same NC file and same wood and same cutter etc), i’m curious to see how it goes.
I had a look at the stepper board. It uses 3x DRV8818. Here is a link to the data sheet:
http://www.ti.com/lit/ds/symlink/drv8818.pdf
Comparing the layout with the data sheet layout guidelines, pages 20 and 21, it looks like there may be two potential problems. There is no bypass capacitor close to the DRV8818 VMB pin. Also, the path to the VMA pin is a bit long.
I have added 3 x 0.1uF bypass caps near VMB and one 1000uF cap near VMA. See red circles.
It will be interesting to see if this will cure the drift problem - only time and lots of cuts will tell 
Loftur, good idea. Tried it yesterday on the X axis. The datasheet wants low-ESR ceramic bypass caps on both VMA and VMB pins to ground as close to the chip as possible so I used good ones. Took about 30 seconds using the dial indicator to determine it didn’t help. 
(The bulk caps it also wants seem to be already present below the stepper headers).
The other feature that I see on the reference PCB layout but not implemented here (or as far as I can see on the similar gshield board) is the low-impedence ground ring around the chip. That is a feature I’ve seen on things like a very low noise, high gain photodiode amplifier I worked on many years ago. I wonder if that could be a significant factor here also?
I hope your results are better. On my machine the X axis is the “bad boy” but the Z axis shows occasional missed steps, so it seems to be a very individual problem.
I just tried two external power supplies. The first is 24V, 8.5A switching supply that is in a case shaped like an old AT PC power supply. The second was a nice Lambda 24V, 10A switching supply.
Neither helped the step glitching problem, either frame-grounded to the Nomad frame or isolated from the Nomad frame.
Well - it is confirmed, the added caps did not fix the problem.
Just did a test letting the Nomad jog back and forth without the spindle running. You can hear the glitches, they are quite frequent. You can actually feel them too if you have your hand on the spindle. For whatever reason these glitches only happen during leftward movement (negative direction).
Even more weird is that the glitches must be added steps, not missed, the X axis is drifting slowly but surely to the left. I will pull the thing apart again during the week and do some scoping. Let’s hope it is something simple like noise on the Vcc.
OK, from the sublime to the ridiculous. In my last disassembling and reassembling of the stepper board, I noticed that one ear of the heatsink was bearing on the 3.3V regulator chip. Even though the chip surface is plastic, I was wondering if some kind of frequency could be transmitted to the heatsink itself. Real Elvis/UFO stuff, but at this point I’m not going to ignore any possibilities.
So I took off the heatsink one more time and filed down the bottom edge of the ear so it wasn’t touching the chip. No improvement in the glitching problem.
But I feel better for checking anyway. 
Problem identified and fixed - no more glitces 
When probing around with an oscilloscope I noticed that there were very substantial spikes, up to +/- 1V at the USM0 and USM1 microstep input pins of the X-axis DRV8818. As the stepper motor controllers are not being used in micro stepping mode, these pins are clamped to logic 1, at 3.3V (Vcc) through 4.7kohm resistors (R1 - R6).
I also noticed that the 5V logic for “step” and “direction” is fed directly from the Arduino board to the stepper controllers. This is somewhat unusual, but the data sheet appears to indicate that it is OK to use logic “1” voltages higher than Vcc, or up to 7V. Reason I mention this is that it may contribute to the spikes seen at other logic inputs.
In any case, the resistors R1 through R6 are unnecessary and shorting those reduces the spikes present at the USM0 and USM1 inputs to near zero. This has totally eliminated the glitch issues.
R1 to R6 are just below the three connectors, two beneath each connector. All now shorted.
(OK the board is upside down ),
If I were to redesign that stepper board, I would probably eliminate R1 to R6 altogether as they don’t seem to serve a clear purpose other than maybe protect the 3.3V regulator a little bit if the stepper drivers get fried for some reason. If keeping them, then those resistors should not be larger than 470 ohm. On the other hand, I would add 470 ohm resistors on the step and direction inputs, to compensate somewhat for the transition between 5V and 3.3V logic, however - according to the datasheet this seems not to be necessary.
OK - to the caveat: I happen to be an EE and an active electronics tinkererer in my spare time as well, so I was not particularly stressed about voiding the warranty on that board. However, play at your own risk - if you are experiencing the glitch issue, then it is probably better to contact Appolo, Jorge and Rob.
Anyways - having torn the machine apart two times in as many days, I am very impressed with the build quality - good job guys.
1 Like
You know how if you can’t find your sunglasses, you don’t buy a new pair because you hope it’ll just turn up eventually? Finally after a few weeks you decide they’re lost for good, so you give up and buy a new pair, and 5 minutes after you get back from the store you find your old sunglasses? Well, I just sent my old, glitchy Nomad back to Carbide just this afternoon so your fix is 4 hours too late for me . Given the laws of the perversity of the universe, I conclude that this fix is therefore probably legit 
and would be interested to hear if it works for @Randy as well…
Testing here is commencing - jogging back and forth for hours with the spindle off. So far so good. Not a single glitch heard or measured.
In my previous post I inaccurately stated that microsteps are not used. Correct is, with USM0 and USM1 clamped at logic “1” the steppers are fixed at 8 microsteps. This also explains the strange behaviour that the glitches are instances of faster movement - a changed state on either of those pins means quarter or half step, full step if both see a negative voltage spike at the same time.
That’s some great troubleshooting @loftur, You rock
I received @Randy’s board yesterday and was setting aside time to hook it up to a scope and begin the detective work, but glad you beat me to it. I’m going to make the change and send it back to Randy for further testing. Randy, Rob and I talked about a potential perfect storm of component tolerances, coil winding, power supply noise, trace width, etc that might have caused the glitch. And yeah, if one of the lines gets a negative spike it’ll change the microstep from 1/8 to something bigger for a brief moment. Funny thing is, the Shapeoko 3 controller board is largely based on this design, and we decided to remove those pull-up resistors from USM0 and USM1.
OK, I’m down to the garage/workshop and will report back in about 20 minutes.
This is why I don’t do schedules… 
I verify @loftur’s solution (EDIT: To the extent of my 100 out-and-back 50mm rapids performed without glitch).
Thank you so much, loftur! And thank you for waiting until I posted my whack-job theory first. 
@Jorge, please send the reworked board to @kjl instead. My board is functional, though not pretty after my rework. My SMD training was over 10 years ago and I’m way out of practice.
Now to re-hook-up the spindle and reinstall the electronics cover and fan and skins and make some parts! 
No, don’t send the board to me; I already sent my nomad to you (carbide3d)! Feel free to send me back my original machine and I can fix it, or fix it for me and send it back, or send me a new one; I’m happy in any case.