Question UCCNC changing zero point - error

Greetings -
I am having a problem. I have exported tool paths from VCarve and have set the project up. The tool path is loaded into UCCNC, the table is homed, and an x, y and z zero point are set. I've done this many times before, so I know that the table is properly wired, etc. From the zero point I can arrow around the tool path and all looks good, properly to scale, etc.

I start the cycle and the cutting begins at the wrong location. The cycle is stopped and when I move back to zero it turns out the y zero point has moved 40mm (or so). I re-zero the y point and cycle start and the same problem occurs. It happens every time that the zero point changes once I hit cycle start.

Any ideas what is causing this and how to fix? It is a huge problem obviously.

Thanks -

It sounds like your Y axis stucked, a mechanical problem probably.

It's not mechanical. I've done two projects after. It is in the g-code. Vcarve exported some kind of command that is changing the zero point for the "y".

On "Job Setup / XY Datum Position" is the "Use Offset" checked and non zero??

99.99% its your Y axis loosing steps due to mechanical tuning needed.

I have been working on this.

The problem is not in the offset or mechanical. I've been doing projects ever since. This particular project was now completed as well.

It turns out that the toolpaths generated by VCarve is doing something when toolpaths are grouped. When the toolpath is generated one movement at a time, the path works. When the toolpath is combined with the next toolpath, using the same tool of course, the Y zero position is moving just over 40mm. I can confirm that I have repeated this numerous times and it is definitely occurring in toolpath file.

That's all I know. My workaround was to export one toolpath at a time.

That is quite disturbing, well worth raising a query with Vectric direct.

I've concatenated toolpaths in Cut2D without problems, so I wonder where the difference lies.

Being of a suspicious nature, I must admit to always doing a dummy run of toolpaths without any tool in place - just in case!!

can you post Gcode?

Hi everyone,

I just found this topic, that happens to be similar to another where i exposed my issue (waiting for staff approval so far) :
www.stepcraft-systems.com/en/forum/operation/1967-reference-positions-shifting-during-operation#57510


i’m actually working on a SC 600 (HF spindle), UCCNC and fusion 360.

I’ve made a toolpath to perform saw cuts in brass, and the Y axe shifts during the job….

I send you pictures here attached to illustrate.

4 cuts are programmed, with same parameters, direction… at different places of the brass plaque.


The 2 first cuts are perfectly performed, but the 2 last ones shift : the spindle starts to feed in the middle of a pass.
As seen on last pic, the shift occurs after 2 good passes of the third cut, and totally messes up the last cut.

I’ve tried to split this job in two nc files : One job with 2 first passes, and after ending it, one other with the only last two passes (with same WCS, same everything)..), and the shift also occurs at the same exact point of the X axes …

As if those coordinates of the machine would always shift the tool path..

lowering the feed during the job, as recommended in the link above doesn’t change anything.

I also tried to position the workpieces at a lower x coordinate, but it was even worst : the first cut messed up : two passes and then it shifted and started to feed in the middle of the programmed pass.

those different mistake show - i suppose- that the toolpath is not the problem, as the shifting happens at different positions (by comparison between the two jobs performed).

then : can it be a UCCNC bug that reset Y axe zero point ? or maybe some mechanical issue due to some vibrations, as mentionned in the link above ?


I really need this to work fine, as I use my SC for my job (deliveries and clients waiting ....)

Thank you in advance for your help.

Vectric looked at the code (they created it with their toolpath and the proper export settings, and reported that the code was correct - without any sudden z-recalculations or adjustments. Consider that my z-error was substantial.

Stepcraft figured it was mechanical with the gear slipping or something. we did a bunch of tests and there was definitely a problem - even on very basic code we created where we would start and so a series of steps and end, and the z position would report correctly but in fact be off a few millimeters. Stepcraft figured that my gear was dirty or not properly greased. I did a full disassembly and cleaning - but it really wasn't dirty or ungreased (except for a small bit at the top and I don't know if that did anything. Visually, the unit appeared to move exactly as it was told and there was no visual signs of slippage.

My belief is that if the code was correct and the machine functioned as it was told that it is a problem with UCCNC and/or the UC-100. The UC-100 is a terrible interface, highly fragile, and completely failed shortly thereafter - although it may have been my switching USB cords - that's the problem with fragile, you don't always know why it breaks.

So this remains a mystery, except for the one fact that the USB interface - the UC-100 is a bit of a toy - and may have been the culprit. Otherwise, UCCNC bug is #2 most likely cause to me.