Is it really necessary to fiddle with ramps from job to job?

[gerald_d]

Why are acceleration and deceleration ramps such an issue with ShopBot software, and need adjustment for various types of jobs? I have not seen this being an issue with other machines or software. I can appreciate that the different weights of routers/spindles that SB-owners install will affect ramps, but this should be a once-only setting - in fact, SB should be able to publish a table of ramp settings versus tool weight.

Apparently there is also a setting for Slow Corner Speed : a tool tip that pops up when mousing over that setting states this "Percentage to slow from full speed on gentle corners". The range is 20% to 99%. This is another thing that other producers don't give to their clients to fiddle with.

Is it nice to have the ability to fiddle with these settings, or would we prefer that they are "invisible" to us? My choice is for the latter.

[richards]

I vote for the ability to fiddle with the settings on condition that each parameter is fully documented. To me, there is nothing more frustrating than knowing that I have to change a parameter and then not having documentation explain both the purpose of the parameter and the effects of modifying its value.

Having a single ramp value based mostly on tool weight wouldn't work for me in the type of work that I often cut. When I take a light pass, the machine can accelerate much faster than when I'm really plowing deep. (I will admit, though, that I seldom change the ramp settings due to the depth of cut - extreme laziness on my part.)

[paco]

Gerald,

I believe that's a reason why the DOS version is still available...

[gerald_d]

Puts tongue in cheek....

So the v3 Windows version is for the one-man hobbyist operator, while the DOS version is for production guys with semi-skilled operators?

[mikejohn]

naughty,naughty

[elcruisr]

I'd say I want to be able to tweek. Even the big machines have problems with servo tuning issues and have to fiddle with things when switching between part types for maximum performance and quality. Most operators of big iron may not even be aware of it and live with their "averaged" settings because the factory only wants their techs playing with the settings.

[gerald_d]

Motion control is a very complex subject, as evidenced by this (http://www.nee-controls.com/machine_movement.html) little article. Good "look ahead" ability is essential for trajectory planning - I would prefer the software to do this, rather than me.

[gerald_d]

Quoting from that article:

"Therefore each individual axis may need to automatically decelerate going into the intersect and then accelerate on the other side of it. With some motion controllers they leave this function to the CNC programmer. It is by far, more desirable if this complex problem is resolved by the controller as the permissible velocity changes are a function of the machine being controlled and not the part program."

[richards]

(Those not interested in the G-Rex/Gecko controllers can skip this post.)

Gerald,
Have you visited the G-Rex forum lately? The encoder equipped steppers can/will be driven much harder than non-encoder equipped steppers. It is my understanding that the motor control algorithms will be written for maximum speed, but the feedback from the encoders will automatically slow things down when/if the encoders start to lag the step pulses, which is much more advanced than using servo motors and G3xx controllers that simply fault when the encoder lags the pulse train. In theory, that means, at least to me, that if the motors are correctly sized so that they can perform a given cut at the motor's base speed, then they can be programmed to always cut at the maximum speed for the given material and cutter being used. Multi-axis moves co-ordinate all axes so that precision is not sacrificed if a particular stepper starts to bog down. Even though that does not constitute true look-ahead, it will function as if look-ahead were active, without the complexity of pre-examining each instruction to pre-determine that instruction's effect on other instructions.

I had to write look-ahead routines for some of the more advanced photo printers to optimize the fill pattern on the rolls of photo paper being used because loosing a 4x5 section on each package could cost thousands of dollars per week per machine. The programming is non-trivial, particularly when each negative's unit/package varies greatly. In the same way, a look-ahead function for a CNC router would probably require some fairly complex code, given the mix of instructions that could occur.

(As an experiment, program several rectangles with differing corner radii and then program them to cut at the same speed. I was surprized at the effective speed difference caused by the radii. By the way, I used PartWizard to create the tool path. Your results may vary somewhat depending on the tool path program that you use, even though much of the speed difference is caused by ramping and not by the tool-path program's code.)

[gerald_d]

Mike, I think that you are off on a bit of a tangent....
The issue over there is getting more speed and sensing when true position lags commanded position. I am more concerned about the calculation of the commanded position.

Take a car having to be driven around a sharp 90 degree left bend..... One driver may position the car exactly in the center of the lane and get himself around the corner. A more experienced driver will swing slightly to the right side of the lane first, then take a gentler left hand turn (just missing the inside of the corner on the left) and will exit the turn back on the right hand side of the lane again. A much smoother/faster turn, executed within the confines of the lane, or tolerances if you want to call it that.

It is that experienced driver judgement that needs to be emulated by motion control software. And it is obviously very complex. I am sure that we wouldn't let a back-seat driver control the brakes/throttle while we pick a line and control the steering wheel. So why would a good CNC controller let the operator pick the ramps?

[richards]

Gerald, You're right about me being off on a tangent. That's often the case. In fact, I can often go for days on end going from one interesting problem to another before finally getting back to the original problem.

Now back to the subject at hand . . . As I see it, the goal is to command the machine to start at an exact point on a line segment, to move an exact distance and then to stop exactly at the desired point on that line segment. (I'm using the term 'line segment' on purpose because it's my understanding that even the smallest circles are cut by commanding the machine to move through many straight line segments, with most of the complexity needed to convert a circle or curve to line segments being handled by the tool path program or the native instruction set of the machine.)

Since a stepper motor, like a car, needs to accelerate to get to speed, a programed ramp is normally used. Trying to accerate a car too quickly either stalls the engine, if the engine doesn't have enough power to do what the driver commands, or the tires lose traction and 'burn rubber'. In either case. A stepper that is commanded to move too quickly either completely stalls or loses steps, with neither condition being acceptable. Also, a stepper motor, like a car needs to slow down gradually or a 'skid, i.e. overshoot occurs. Just like you wrote, an experienced driver knows his car and compensates with his skills to make the car do exactly what he desires. That point being conceded, let's try to figure out whether mechanical control, i.e. sensor feedback and automatic compensation, or programming would work best to control acceleration ramping and deceleration ramping on a CNC machine.

Programmed ramping to accelerate a stepper motor, if convervative ramping is used, assures that the motor with neither stall nor lose steps. It also guarantees that the motor will not be running at its peak speed because the ramp will have to be conservative enough to allow for unknown differences in the material or cutter sharpness, etc. On the other hand, a sensor based system, would sense a missed step and then automatically slow the motor down. An intelligent sensor system would compensate for missed steps to assure accuracy. In other words, a sensor based system could be commanded to ramp at an unrealisticly high rate and then compensate for all known and all unknown factors automatically.

Deceleration is another matter entirely. In my experience, if a motor is not ramped down properly, overshoot or skidding occurs. In this case a sensor based system would only know that the motor had gone too far. An intelligent sensor system could reverse the motor until the commanded stop point was reached, but the damage to the material would have already occurred.

So, in my mind, to follow the programmed tool path, sensor based acceleration would be optimum to get the motor to speed in the shortest distance, but programmed deceleration would be needed to prevent overshoot (skidding) at the end of each line segment. Whether programmed deceleration is left to the machine's operator to figure out or whether it is a function of the machine's control software is another matter entirely. I would assume that deceleration ramping should be a function of the machine's control software (which is why I suggested cutting a rectangle with various corner radii, in the post above - that test shows that Shopbot has done a very good job of incorporating ramping into the control software). Optimizing the deceleration ramping to give optimum performance, equal to sensor based acceleration, would be complex and probably require computer hardware far beyond that supplied with any moderately priced CNC controller.

[gerald_d]

I believe that sensor based deceleration is actually the easier one because the motors can be such good brakes. Much higher power/torque levels are available under braking. Cars have long had sensor based braking control (ABS), but "launch control" is still in its infancy.

[richards]

I agree that sensor based deceleration would stop a car or motor in the shortest amount of time. However, if the goal is to stop exactly at a given spot, whether it be on the road or at a given coordinate on the CNC table, a sensor based system whould have to be forewarned that a stop was required before the stop point was reached.

In the case of my Alpha, which has 1-inch pitch diameter gears on the steppers, if the axis is cutting at 6 inches per second, the motor controller is receiving a pulse train ranging between 381.97 steps per second (if the motor is using full steps) and 3,819.7 steps per second (if the motor is using 1/10 microstep). Because the gantry has mass, going from 380+ steps per second to zero steps per second requires more than just shutting off the pulse train - if the motor is expected to stop at the commanded point and not overrun that exact point. At least that's what I'm basing my response on. Since my expertise in mechanics is extremely limited, I may be making too many assumptions.

[gerald_d]

"a sensor based system whould have to be forewarned that a stop was required before the stop point was reached." That is exactly why forward-looking software is needed, and why SB software has the forward-looking capability like everyone else. (How far the programs look forward varies)

Mike, the next time you are driving, analyse what you are intuitively doing with the brake pedal when you see a stop sign and then the stop line.

Realise that constant force on the pedal is a constant ramp value.

I don't think that you stab the pedal down nor that you release it instantaneously. In other words, you gently increase the ramp value from zero, hold the force (ramp) steady for a while, and then as you approach the stop line you ease off the pedal until stopped in the right place. (This is the S-shaped ramp mentioned in the linked article).

Smoothing out the ends of the pedal force (or ramp value) eliminates "jerk". Some more light reading here (http://www.mmsonline.com/articles/100506.html).

But, yeah, if you didn't see the stop sign (by looking forward), you are going to overhoot....

[richards]

Gerald, I think we're both on the same side of the argument, i.e., that deceleration should be controlled by a program, not the program written by the CNC operator, but a program that controls the controller. I think that we both agree that that controller program must have forward-looking software. Whether that software is extremely simple and only knows how many step pulses are required to finish a line segment or whether it is more sophisticated and can look ahead at many instructions to calculate changing forces that will be caused by upcoming instructions, is not necessarily relevant to the CNC owner/operator because that parameter is probably totally controlled by the CNC manufacturer and the software people that write the code to control the controller.

By the way, I just read the article that you reference above. It's interesting reading which I probably should have read before writing my reply.

In any case, although I've been in the computer industry longer than Bill Gates, it's still amazing to me that two people separated by half a world can exchange ideas in a matter of minutes.