Frage UCCNC versus GCode Settings

Could someone please explain: "who's in charge (and when), the loaded GCode, or UCCNC"? I always attempt to set the feed rate, spindle speed, etc. correctly for the type of material and end mill size, then use those same settings when designing with Vectric's VCarve Pro, being careful with all of the toolpath settings. So, does the (VCarve created) GCode take precedence at run time, or do other settings in UCCNC come into play that may conflict with the GCode? This is the only reason, I'm guessing, for perfectly good GCode to be ignored and the spindle to go off on a weird path, ruining the material being milled (my earlier post "Mind of It's Own?) shows I am not clear whether the problem is a defective UC-100 USB controller, some other hardware component (ALL test very smoothly running), or the software. Before anyone suggests checking all connections, that has been done over and over. Lastly, could someone clarify setting the LED number on the SC-100 control box? I usually set it to about 16 when manually jogging or homing, but thought that number has no effect when the running code takes over (am I wrong?)

SFDeeJay schrieb: So, does the (VCarve created) GCode take precedence at run time, or do other settings in UCCNC come into play that may conflict with the GCode?

The g-code will take precedence, and should override any settings in UCCNC, provided those setting are actually in the g-code.
Most g-codes are modal, and once used, remain in affect until another g-code changes them, or you change them when the g-code is not running.

This is the only reason, I'm guessing, for perfectly good GCode to be ignored and the spindle to go off on a weird path, ruining the material being milled (my earlier post "Mind of It's Own?)

This should not happen. If you see this happen, Feedhold the machine, or just try to watch, the DRO positions, and see if the DRO shows the machine where it's supposed to be according to the g-code, or somewhere else.

If the DRO's are showing the actual position, then the problem is with your g-code. If the machine is somewhere other then where the DRO's say it is, then the machine has lost position for some reason.

I am not clear whether the problem is a defective UC-100 USB controller,

I doubt that the UC100 is the issue, but I could be wrong. If the UC100 were defective, it most likely wouldn't work at all. I've never heard of any motion controller, for any software, cause the machine to move in ways other than the g-code is telling it.

Does the toolpath look correct when you load it into UCCNC?

Gerry, Can't think of a reason it would NOT be reliable, but because I suspected the GCode being faulty, ran it through a good visual test program, "CAMotics". It showed the tool and toolpaths running perfectly, all the way to completion. So, even though all x, y, and z movements go smoothly in jog mode, I like to blame someone/something other than myself, so I'm going to say it's the extreme sensitivity of the machine while running GCode. If I learn differently (being like a dog unwilling to give up a bone) I'll post new findings.