Hello Guest it is March 19, 2024, 07:03:21 AM

Author Topic: Just when you think you are finally getting there....  (Read 9692 times)

0 Members and 1 Guest are viewing this topic.

Offline Davek0974

*
  •  2,606 2,606
    • View Profile
Re: Just when you think you are finally getting there....
« Reply #10 on: November 27, 2016, 08:00:30 AM »
Its set at 3500mm/min and 350mm/s/s on X&Y with 2000mm/min and 750mm/s/s on Z
Re: Just when you think you are finally getting there....
« Reply #11 on: November 27, 2016, 08:21:35 AM »
linear distance travelled during accel or deceleration -  0.5 x V^2 / a = 0.5 x (1000/60)^2 / 350 = 0.4mm

centripetal acceleration radius = V^2 / acc = (1000 / 60)^2 / 350 = 0.79mm

hence at a feedrate of 1000mm/min and with an accel (+decel) of 250mm/s/s, you are likley to end up with a 0.8mm radius on inside and outside corners ..... without consideration of tool offset which may affect this  given a 2mm dia tool is nt going to end up with a 0.8mm insider radius in the corners .... you may be looking at 1mm + 0.8 etc

then again all of the above could be bull!   (just something I'm reading up on at the moment.... I've not been under the hood with mach3 to figure out the tradectory planner following error )
Rob

Albert Einstein ― “If you can't explain it to a six year old, you don't understand it yourself.”

Offline Davek0974

*
  •  2,606 2,606
    • View Profile
Re: Just when you think you are finally getting there....
« Reply #12 on: November 27, 2016, 08:31:50 AM »
Bull or not, it's above my math grade ;)

But what does it all mean?

Surely if the mathematical rounding is 0.8mm and my physical rad is 1mm i should be good to go as machine rad < cutter rad ? If i had a machine rad of say 5mm and a cutter rad of 1mm then i would expect to see a 5mm radius regardless of tool dia??

Clearly i have something not set right?

I doubt the servo tuning has any input here as the following errors are lower now than before.
« Last Edit: November 27, 2016, 08:34:52 AM by Davek0974 »
Re: Just when you think you are finally getting there....
« Reply #13 on: November 27, 2016, 09:07:17 AM »
https://www.khanacademy.org/science/physics/centripetal-force-and-gravitation/centripetal-acceleration-tutoria/a/what-is-centripetal-acceleration

If you had a 5mm tool, with tool compensation, at those feed and accel rates, I'd still expect a 0.8mm error as one axis must slow down and the other speed up to maintain velocity
Rob

Albert Einstein ― “If you can't explain it to a six year old, you don't understand it yourself.”

Offline Davek0974

*
  •  2,606 2,606
    • View Profile
Re: Just when you think you are finally getting there....
« Reply #14 on: November 27, 2016, 09:32:12 AM »
Ok, thats complex. But what does it mean to my issue?

Do I just need to whack the acceleration up, retune the servos and test?

What sort of figure would I need to aim for?
Re: Just when you think you are finally getting there....
« Reply #15 on: November 27, 2016, 10:41:29 AM »
Given acceleration is generally fixed as high as it can be, I would suggest lowering the feedrate in the corners using your post processor (sheetcam can do it, no idea about vectric).

Basically lowering your feedrate 1mm before and after the corner to 60% will probably sort it ....

Sorry out and about at present, no pc access
Rob

Albert Einstein ― “If you can't explain it to a six year old, you don't understand it yourself.”

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Just when you think you are finally getting there....
« Reply #16 on: November 27, 2016, 11:07:36 AM »
Could well be a CV issue but I am also wondering if you have backlash comp enabled and maybe that is also a factor.

Offline Davek0974

*
  •  2,606 2,606
    • View Profile
Re: Just when you think you are finally getting there....
« Reply #17 on: November 27, 2016, 12:33:01 PM »
No, BC is turned off on this setup.

I don't think Vectric can do the trickery sheet cam can.

Offline Davek0974

*
  •  2,606 2,606
    • View Profile
Re: Just when you think you are finally getting there....
« Reply #18 on: November 27, 2016, 05:05:29 PM »
What settings should the mill have for CV distance and stop cv on angle boxes??

At present CV distance is turned off in my screen set and there is no cv angle box at all (2010 screen set) but i guess it still has a value set somewhere?

Offline Davek0974

*
  •  2,606 2,606
    • View Profile
Re: Just when you think you are finally getting there....
« Reply #19 on: November 28, 2016, 07:54:41 AM »
I stumbled upon this little gem from Art this morning, excellent analogy of CV, explains a lot....


::Why doesnt CV run at commanded feedrate, or why is it code dependent.?

CV ( constant Velocity ) is an ideal, not a reality. The laws of physics show it cannot be done. I mean just jump in your car and try to drive a square path around the block at a constant speed. You cannot do it under any circumstances without tearing off your tires, or rounding the corner when you spin the wheel. ( or stopping at the corners and having someone pick up the car and turn it. :) )

CV is really the name of an option that ATTEMPTS to do a constant velocity of the path the Gcode calls for. In truth its name should be "Best-Speed Optimization" There are many methods of trying to do it, some better than others. It depends not only on the code itself, but on the lookahead. It depends on so many things in a planner that each type of planner has its own issues with it and its own variation of how the feedrate reacts to Gcode.

Mach3 is a bang-bang accelerative trapezoidal velocity planner, and a very good one for almost all code types. Its CV is created by the simple rule of beginning the acceleration of the next motion when the acceleration of the current move goes negative. ( deceleration phase). This means you are literally adding one move to the next , allowing for the speed to increase. Im sure many have read this before and can picture it in the context of two motions where the second is added to the first , thus making the deceleration phase virtually invisable ( thus constant velocity ), but what I , or Brian, rarely mention is that it operates in full lookahead, this means that in tiny segment code, the code of a line may be passed over by the time sequence of the planner as it progresses, but that motions speed must still be added in to the total of the motions distance.

This means its an iterative process, where up to 100 lines or more may be actively added together in terms of their deceleration phases being added to the next motions acceleration phase. This can be hard to wrap the head around. Each Gcode line has to be considered fully in the iterative calculations involved. Imagine tiny segment code where the angle of the next motion is constantly shifting ( typical 3d work ), and the processor is trying to keep track of the real speed thats possible. Since the consistancy of the speed is a function of the additive properties of each motions deceleration phase, it means the max speed an individual motion can do is important in the functions total speed accumulation.

I know, still hard to wrap your head around. So back to the car analogy, you hop in your car and try to CV your way at 30 MPH around the block ( 4 lines of Gcode), you can probably do it, but the corners will be rounded and slower than the straights and the faster you go, the more rounded the corners, but the speed will be fairly constant.. bit slower at the corners...

OK so far, but in 3d GCode, that 4 line trip around the block is replaced with 1,000 small 1 foot motions around the block,AND you dont know your actually driving around the block. With 20 line lookahead, and 1 foot moves, you get to know only that you need to drive 20 feet ahead at a time. SO naturally, you will be light on the gas pedal, and will drive much slower because for all you know, the wife may yell STOP!! after any 20 foot section. You wont get up to the speed you did when the block was 4 lines of Gcode..
Now after 10 feet, your wife deigns to tell you that your going at least 20 more feet.. you still wont stomp the gas, after all you MAY need to stop soon.. this situation repeats till your all the way around the block.

This is the crux of 3d slowdowns and feedrate limitations in CV modes. Even if we increase the efficiency of your wifes glasses so she can see 100 feet ahead ( 100 lines of lookahead ), youll still need to drive slowly.. though a bit faster than with the old glasses. And thats with straight lines. Now if the wife is constantly saying " Move an inch to the left..now right..now left..", youll slow down even more. A computer is nowhere near as smart as you are.. ( well, most of you. :) ) , so it too will drive pretty slow, the sole advantage in fact is the computer has endless patience and wont end up smacking the wife about the head and ears for the back seat driving..

Yes, ( I can smell the oil burning. :) ), it IS possible to look further ahead, recalculate current motion speed based on upcoming traffic and conditions, and then recalculate all motion based on the future events, but this has ramifications in other more basic calculations the planners need to do in their uSecond to uSecond activities. Work is being done in that area, but we're still a ways off from finally cracking that nut to allow CV to operate in a more mathmatically pure way. For one thing, the actual mass effects need to be taken into account to let planners know the true maximum speed that should be allowed for any motion to motion joining process, properly taken into account that would be the basis for the next generation of planners to start the CV process. Conformity plays an import part as well, Mach3 is famous for driving almost any machine, so next generation planners have to take into account that not all systems are created equal, this means that they must be more systematic in how they apply calculations and must base them on physics engines that better reflect the actual world they live in.

Hopefully, this explains a bit about the challenges of CV modes ( or better yet "Best Speed Optimizers" ). Its hard to convey whats really going on under the hood and the limitations each planner type has, but Ive been deeply dipped in the theory of planners, and I can tell you from an inside view that you assist your CV by two methods, first, never raise the feedrate commanded thinking this will help you go faster, youll find best speed is obtained by commanding a speed the code can actually do. What I typically do is run the code in the air for a few minutes, see what it does, and then change the F-Word to match what you actually get. For example if you command F1000 and get 62.5 , I then reset the system F70. This actually helps the system go a bit faster. ( due to some peculiarities in the way such algorithms work.), and second, set the lookahead (LA) as large as you dare for that code. 200 lines LA will work much faster than 20 line LA, just like buying your wife better glasses.

For those that dream of a system that takes corners at the commanded speed, forget it, aint gonna happen, never will, and if someone offers you such a system...back slowly away.. :-) , their breaking the laws of physics, and Hawking has a mean left hook.

It IS possible for some manufacturures to have software that does CV much better, but they do suffer from other ailments as a result, and quite often will drive only the machine or drive mechanisms they were written for, this makes those solutions bad for the general case. Its all a matter of the tradeoffs one selects in their planner design and operations, and how the machines vary in the general population. Like backlash, its a theoretical way of approaching a perfection that is provable to be impossible. Its my hope that some day tiny code will CV exactly as large code does, but like the world we live in , things get annoyingly hard as you go smaller and smaller.. just ask Einstein...

Thanks,
Art


So, it seems the solution to ALL CV rounding issues is simply more acceleration - make it so the change in one axis slowing as the next is accelerating is so small that it's pretty much invisible. Of course slowing the code down has the same effect but this can damage the work and/or cutter to some degree so not really an option in many cases - plasma will burn a hole if too slow, routers will burn the wood and mills will eat cutters due to rubbing instead of cutting unless spindle speed is lowered to match.

I will revisit my setup and tune the servos after setting a far higher acceleration, see what that does.