UCCNC Constant Velocity settings

[ngwagwa]

Having just moved to UCCNC from Mach3 can anyone suggest the settings for Constant Velocity that will make UCCNC create a path similar to Mach3?

Until I started using UCCNC I was ignorant of the Exact Stop and CV function so it is all black magic at the moment.

The parts I machine (injection moulds) are all complex 3D surfaces with lots of small steps and although most of the parts are curved surfaces it is important that any sharp edges are maintained.

[Muzzer]

Not sure that trying to set constant velocity within the controller is the only or best way to do this. Modern toolpaths and post processors can achieve complete control over speeds and (more importantly) accelerations, as well as include smoothing functions either within the post processor or the controller itself, if that is best.

Not sure how you create your toolpaths but the likes of Fusion 360 are very much up to date and there is the added benefit of an active and responsive forum where you could ask about this in the CAM area.

[ngwagwa]

Not sure that trying to set constant velocity within the controller is the only or best way to do this. Modern toolpaths and post processors can achieve complete control over speeds and (more importantly) accelerations, as well as include smoothing functions either within the post processor or the controller itself, if that is best.

Not sure how you create your toolpaths but the likes of Fusion 360 are very much up to date and there is the added benefit of an active and responsive forum where you could ask about this in the CAM area.

When I ran my first programme using UCCNC I had it set to Exact Stop and it took about 5 hours to finish compared to less than an hour when I was using Mach3. I found out the reason was with so many tiny movements there wasn't the time for the machine to accelerate. Looking back at my Mach3 settings I found it was set to constant velocity.

From my understanding constant velocity reads ahead and optimises the toolpath to try and achieve the set feedrate but in doing so it changes the toolpath, the allowable deviation in the toolpath is controlled by the CV settings. According to the UCCNC manual: There is always a trade off between machining speed and precision. The higher the allowed machining errors are set the faster the job will be finished, because the motion planner has more space for optimising the motion, however the less the workpiece precision might be. The only way to force UCCNC to follow the exact path is to either use Exact Stop mode (which is unacceptable due to the slow feedrates achieved) or set the CV allowable deviations as close as possible to zero.

As I was happy (in my ignorance) with the work produced by Mach3 I was looking for the CV settings to use in UCCNC to give a comparable product.

[Doddy]

Just one suggestion - and I can't help answer your question, sorry, but as this is very much a UCCNC query you might get a good response on their forums (the author is highly active/reactive on there). Of course there are people here with good experience of UCCNC, but might be worth casting your net farther (if you've not already done so).

[JAZZCNC]

CV is heavily influenced by acceleration and not just velocity. As the manual says it's always a trade-off between speed and accuracy so you can't have both but there are things you can do to increase it.

CV works by looking ahead and then determining the path it must take to make the corner and maintain the velocity, It does this by complex maths using velocity, acceleration, and corner angles, etc. It will also turn Off CV for a brief period for really abrupt angles which is why you can adjust the corner angle cut off point in general settings.

So the faster it can accelerate the quicker it can change direction, so with faster acceleration, it can wait longer before changing from the original path. Combine this with lowering the velocity and CV corner angle cut-off setting you can keep to the original path while still keeping a reasonable velocity.

Often you can actually lower the cycle times by lowering velocity and increasing acceleration. Esp, on work with lots of small tiny moves like 3D work.

As you have seen when you were in G61 exact stop mode you never actually reached the commanded velocity before the next move started at which point the process starts all over again because with exact stop the machine as to accelerate and then de-accelerate down again before the next move starts, this is why the whole machine shakes when in the exact stop. However, if you had turned up the acceleration then it would have cut faster as it can reach a higher velocity in less time, but the machine would have shaken more because it would be like hitting the brakes hard before the next move started.

This works exactly the same when in CV mode but it doesn't come to an exact stop at the end of each move, it just blends them into each other. However, the velocity is still lowered from the commanded velocity because it can only reach a set speed in the time before the next move comes along which it blends into it, so again the process starts all over again with the result being much lower velocity than what as been commanded.

This is why turning up acceleration and lowering velocity in motor tuning can actually lower cycle times. However it doesn't suit all types of work, so Here's a tip that I use all the time.
Setup several profiles with different motor tuning settings that suit the type of work your doing. So, for instance, I have a 3D profile where my velocity is tuned low and acceleration high. Then when doing 3D type work just load that profile.

To give you an example of the kind of time savings that can be had then create G-code for the Aztec calendar with a normal setup and simulate by cutting air, then do same again with high acceleration and see the difference in cycle time.!! . . . . You will get a shock.!

Also just in case you are not aware then you can put the machine into CV or Exact stop by typing G64 or G61 into the MDI before running the code, or by inserting it into your G-code files initialization line which is usually the first line in the code.