PRT 96 speeds

[bill_flesher]

What are the speeds of the PRT96.

[tuck]

I clocked one doing 80 in a 65 last Monday....

I cut no faster than 2.50ips, jog about the same. Unless I've been misinformed, the Alpha can cut much faster but only for straight line cuts. I'm told that if you're cutting/routing shapes (letters,circles,etc...), the Alpha is good for about 2.50ips as well but will always be able to jog much faster. I was told this by an Alpha owner.

[bill_flesher]

Thanks will it cut cabinet parts and make shelf pin holes. Cant afford the alpha yet but can upgrade later if need to.

[tuck]

Bill, I believe it will do anything the alpha can do, just not as fast for some applications...

[bill_flesher]

Thanks for the input I think I am going to get one. Been looking at them for some time and this forum is a great place to get info.

[gerald_d]

I understand that for straight line cut cabinet parts the Alpha can be a LOT faster than a standard.

[richards]

My Alpha cuts 8-ips straight line, about 2-ips on small circles (2 inch dia.) and jogs at 30-ips.

Others push straight line cuts even faster.

[steve4460]

Hi Guys

I have an alpha and I am working on cutting out a bunch of cabinet parts for a local shop out of 0.500 maple plywood with shelf peg holes and datos . I am using a 025 down spiral cutter and 0.25 stepdown and I am cutting at 6"sec and jogging at 14" sec without any problems . With a PC router and a 6.5 HP shopvac for the vacumme hold down .Only on smaler parts do I need to slow down quit a bit.
Just my two cents.

[mikejohn]

Try this test.
Take a complicated file, say a V-carve with smallish letters, and check the time taken to cut the file in simulation, first at 2" (50mm) cutting speed,4"(100mm) jog speed, then at 4 times these speeds.
The results may well surprise you!
Anything with a lot of ramping and little jogging is not going to benefit much with an Alpha over a PRT.
On the other hand, cut out a rectangle the size of the table top, with 50 holes drilled in it, and the result is going to be a lot different.
So once again its horses for courses.
Depending what you are doing the purchase of an Alpha can be a great advantage, or simply a waste of money, compared to the PRT.

...............Mike

[tuck]

Most well said, Mike. And Bill, you MIGHT consider shopping around for a used PRT. Mine is a 1996 model with a wooden table built to ShopBot specs. I purchased it 4-5 years ago for about $4,500, Porter Cable router and computer included. I did upgrade the control box a couple of years ago ($800.00, +,-), and spent $$$'s on CAD programs, but my old PRT has paid for itself many times over.

Like Mike says, it's all "horses for courses". If you are certain that you will end up in, say, a high-production cabinet business, cutting dozens of sheets of stock every day with mostly straight line cuts, drilled holes for standards and the like, you're probably gonna be better off right away with an Alpha and a spindle router. Now you're looking at about 15 grand. On the other hand, if you just wanna get your feet wet with CNC, you might look for a used old war horse like mine. It ain't pretty, but it gets the job done that I need it to do.

I know of a local "ShopBotter" who has a new Alpha, 48 x96, steel table, 5hp Colombo spindle, all the bells and whistles. I guess he's had it for about 6 months and has cut a couple of things on it as it gathers dust in his garage. Moral of the story? Be careful what you wish for...you just might get it!

Good luck! ;-)

[gerald_d]

Why is an Alpha faster on the straights?.....

I have a theory that was triggered by an experience of once trying to tighten a bolt on an Alpha (with the motors switched on) and was surprised to feel that the motors on the gantry "gave way" probably at around 40lbs of force. It was a weird sensation because the whole thing just moved back into position again when I released the pressure. All very smoothly and without fuss, but the system was way out of position for a period of time.

My theory is that the "muscle" of the PRT and Alpha motors are similar. They give similar torques and speeds. However, when the motors are overloaded they behave quite differently....

- The standard PRT motor "jumps a tooth". It physically loses a step (with audible noise and a jerk) which also means that it has now "forgotten" where it was. There is no mechanical damage. It is like bringing 2 magnets together and they push apart because the poles were mismatched. To be safe with a brainless PRT motor one has to work way below this "loose a step" possibility to have a safety margin.

- the Alpha motor has some intelligence built into it. It knows when it is getting close to the point of losing a step and it just calmly and quietly lets this step slide with the intention of catching back up to it later. It is physically impossible for the brain in the Alpha to make the muscle give more power (law of nature), but it can make the motor work smarter. The Alpha brain says to the motor muscle: "You can push yourself harder because I will remember how many steps you lose if the load gets to be too much - we will catch them up later".
On long straight cuts, it really doesn't matter that the motor is lagging behind the position where it should be. The brain can memorise the lost steps. But, at the end of the cut, where you want to change direction, all those lost steps must be caught up. Going through a series of tight turns, the brain can't really tolerate lost steps and it has to work conservatively (slower).

It is often said that an Alpha motor cannot loose a step because it has an encoder. But maybe we should be saying that an Alpha cannot permanently loose a step, or that it cannot forget a step. I contend that the Alpha motor does temporarily slip steps without telling the SB controller about it - it is just very good at playing catch up.

[hespj]

Gerald, stepper motors and how they work are a closed book to me. Are you saying (re Alpha) that the available torque to resist being moved out of position is the same as the available torque for positioning whilst cutting? Also, is the available torque for resisting being misplaced the same when idling (staionary) and when moving/cutting?

[gerald_d]

A stepper generates less torque (and uses less current) the faster it turns.

When a stepper is stationary, it generates the most torque, called the holding torque, consumes the most current, and gets the hottest.

However, typical control systems limit the current to a stationary stepper, to reduce the heat, but the net result is also that the holding torque is reduced at standstill. It depends on the controller's detection/limitation logic on exactly how much torque you have near the standstill speed.

So, to answer your question, it depends on:
- at which speed the controller thinks the system is standing still
- by what percentage it cuts the current (torque) below the designated speed. (a 70% reduction is common)

I was really surprised at the very low force needed to move the Alpha out of position - I'd love to try that again and see if the display shows the changed position. My guess is that the display does not change even when the motors are 2" from where the SB controller thinks it is. I mean, if the controller did know that the motors are 2" off then it should have kicked in the full current (if applicable), or have flashed a warning?

[joe]

Thanks Gerald for the best description I've heard so far about the difference in the two systems.

I've asked several manufacturers about the advantages of steppers, verses servo motors. It seems to boil down to the cheaper cost for steppers. If servo power was less expensive, I'm sure they would be installed on our PRT's.

Do you think there is any relationship with the smoothness of radius cuts and the motors used. I've seldom been pleased.

Thanks again for your very cogent description.

J

[hespj]

Thanks Gerald, that's enlightening.

"I was really surprised at the very low force needed to move the Alpha out of position"

I guess the router isn't likely to be subject to a 40lb force when it's stationary, it's the forces when cutting that are important. But it looks like your saying that at very low speeds the Alpha might be subject to losing position.

" I'd love to try that again and see if the display shows the changed position"

I'll give it a go.

"Do you think there is any relationship with the smoothness of radius cuts and the motors used"...Joe

The varying holding torque as speed varies?

[gerald_d]

Joe, remember that I said it was my theory - maybe wait for a second opinion on whether my theory is the truth. I would really appreciate someone who really knows the difference to come in here and explain it in layman's terms.

As for smoothness of stepper vs servo on radius cuts, there are many opinions on that. I don't know of anyone who has done a straight stepper->servo conversion of a standard ShopBot. My gut feel is that servo's alone won't smooth the cuts. I have suspicions about our pinion gears being forced into the racks and having a rough ride there - but that is a whole other thread by itself. "Servo" prices are coming down.....

Cross-posted with John, edited to add.."But it looks like your saying that at very low speeds the Alpha might be subject to losing position. I don't mean to imply that the Alpha has a problem area at very low speeds - I am saying one can demonstrate that the Alpha has a mind of its own under certain conditions. The non-Alpha also has the current reduction at standstill. Pushing an Alpha out of position is said to be a risky move for the "drivers" - I am not trying to encourage it, but I am very curious what the screen says if it happens accidently.

[hespj]

Just ran the Alpha in a 1m (39.5") dia circle, it took 26 seconds at max speed, which seems to be about 4.75 inch/sec.

Gave the carriage an "accidental" shove whilst it was idle and the readout didn't change. I would say it took more than 40lbs to move it. I had to put my weight behind it. I guess some of us have more weight than others............

[mikejohn]

I still feel that complicated shapes, more complicated than a circle, are never going to reach much above ramp speed.

............Mike

[gerald_d]

John, I don't know how you stay so thin when your wife bakes those divine cakes


I am surprised that such a gentle circle would knock the speed down by 50%? How long does it take to "cut" a 1m square? (should be about 15 secs for the max speed of 10 ips)

Aha, so the readout doesn't change - that confirms that the SB controller is not getting any feedback as to where the tool is really positioned. The only way that the SB controller can have some confidence as to where the tool really is, is to slow it down. But I didn't think that it would have to slow down that much on such a big circle.

[richards]

Shopbot has an excellent section on ramping in the Command Reference page 21. Quoting from the page, "Ramp Speed also defines the speed of the slowest moves your tool makes. For example, if your tool is moving through a series of very short back and forth cut segments, the look-ahead-ramping feature of the software will have determined that there is not enough length in the moves to accelerate to speed and will execute the move at a continuous slow speed rather than wavering up and down. The reduced speed will be the Ramp Speed. The Ramp Speed also comes into play for very small arc segments or circles. If a circle or arc has a radius smaller than the “Small circle size” set in [VU] then it will be executed at Ramp Speed. The look-ahead function is described in more detail below. But in general you can think in terms of Ramp Speed defining the lowest operational speed for intricate moves." To me, that explains why non-linear moves execute more slowly. The ramp values can be changed with the VR command.

I don't know whether the Shopbot controller tracks the actual position of the Oriental Alpha stepper motors. The Oriental Alpha controller outputs encoder signals, which if used, would show any deviation between the desired position and the actual position. (A concise manual is available on the Oriental Motor web site. Click on stepper motors and then do a search for the Part Number AS911AA."

While you're on the Oriental Motor web site, take a look at the torque/speed chart for the AS911AA motor. If I've done the math correctly, when the Shopbot is moving at 10-ips (600-ipm), the stepper motor is loafing along at a little less than 200 RPM (assuming a spur gear pitch diameter of about 1-inch). The torque chart shows that, at that slow of a speed, the motor is still producing maximum torque, or about 550 oz-in. Even while jogging at 30-ips (1800-ipm), the motor is still producing about 500 oz-in torque while turning about 500 RPM.

The non-geared standard stepper (PK299 series) produces about 200 oz-in of torque at 200 RPM. Be aware, however, that the choice of motor driver and configuration greatly influences to amount available torque with the PK299 series. For instance, the PK299-F4.5B motor can produce over 800 oz-in of torque when properly wired with a decent motor driver.

Of course price plays a big part in determining which motor to use. The Alpha series lists for about $1,200 each. The PK299-F4.5B with Gecko driver and 1/4 of a power supply (assuming four motors per machine), costs about $500 each - but, that motor is blind. If it misses a step, you wouldn't know until you measure the part and see that it's too small.

The other option is to use a servo motor rather than a stepper. The servo motors that I've looked at all require an encoder, so absolute positioning is a given. However, the low cost brushed servos, which cost almost exactly the same as the PK-299 series stepper motors, only allow a very small out-of-position error before the driver shuts down. Depending on the encoder used and where the encoder is mounted, the movement to cause a fault condition is very small compared to the Alpha stepper motor. The higher priced AC type servos that more closely compare to the Alpha stepper, cost about $1,000, depending on where you buy them. There is another problem in using a servo on the Shopbot. Servos need gearing or belts to reduce their speed to usable levels. Personally, I prefer toothed belts because they have zero backlash if tensioned properly, but whether you use belts or gears, you have to figure in the additional cost of the speed reducer.

So, unless you're someone like me who really gets a kick out of spinning steppers and servos on a test bench, let the folks at Shopbot worry about which motor is best and then select either the PRT if your speed requirements are modest or the Alpha if your speed requirements are higher.

[gerald_d]

John, from what Mike quoted above....... "The Ramp Speed also comes into play for very small arc segments or circles. If a circle or arc has a radius smaller than the “Small circle size” set in [VU] then it will be executed at Ramp Speed."
.....what is your "small circle size" setting? Maybe your 1m circle is being considered as a small circle?

[Brady Watson]

SB3 does not monitor the motor's position. It is all done within the Alpha driver. All SB3 does is tell the Alpha driver where to go. The Alpha driver does all of the rest, including monitoring position and position correction calculations in Alpha-mode if necessary. SB3 is still open loop in a sense and receives no data back from the Alpha driver as far as I know.

-B

[gerald_d]

So Brady, what makes the Alpha go slower around curves - is it the SB3 controller, or is it within the Alpha driver?

(I think it is the SB3 controller, because each driver does not know what the others are doing. ie. a driver doesn't know if it is alone cutting a straight, or if there are others working with it to cut a curve)

[bill.young]

Hey John,

Are you running the newest Control software, 3.4.20? One of the fixes listed in the readme file for 3.4.20. is " -Fixes ramping threshold in metric" which I believe was keeping some types of moves from ever getting out of ramp speed.

Bill

[paco]

Since curves (arcs too) are interpolate into segments by SB3, I believe that the last VR setting (Slow Corner Speed; Percentage to slow form full speed on gentle corners; default is 60%) come into play in the speed of the tool.

From what I've read about the Alpha motor driver and motor kit, like Brady, I believe that SB3 is not monitoring position with the driver/encoder... but it do monitor alerts (overheat, cannot get back into position after a moment, collisions {majors}) from the drivers.

From the default (factory) VR settings, the tool will accelerate 2"/sec. (2 units) every 0.4" and will start the speed at 0.4"/sec. Same for decelaration... so it should reach say 10"/sec. in about 5" (4.8") or so.

[Brady Watson]

Gerald,
The flow of data to the motors is similar to:

CAM-->Output SBP-->SB3 (process ramps etc according to your settings) = step & direction signals -->
Alpha/PRT driver converts step/dir to waveform data motor understands --> Motors

Driver(s) Send(s) alerts back to SB3 only if necessary (as Paco pointed out)

-B

[gerald_d]

Okay, let's get back to the basic issue here...

Why, and how much, can a Alpha move faster, particularly on straight line cuts, than a PRT (both having similar power motors)?

[hespj]

Bill, I'm running an older version of control software, I shall look forward to trying the new version tomorrow. Mike John's comment:
"I still feel that complicated shapes, more complicated than a circle, are never going to reach much above ramp speed."
is typical British understatement. I've had the SB take 3hrs + roughing out irregular 3D shapes. That experience was boring enough to get me tweaking VR and the toolpath software (RhinoCam), both of which speeded things up somewhat. Tomorrow with 3.4.20 I fully expect to move from second gear into overdrive.

Gerald, I havn't looked or changed the Small Circle Def on the SB computer, so I guess it's the same default setting as I have on this computer which is 6.35, which I assume is dia in mm (equal to 1/4")

[richards]

Gerald,
When the motors are turning at the same RPM with a 48 VDC driver for the PK299 motor and the factory Alpha driver for the AS911AA alpha motor, the Alpha AS911AA motor has 2-1/2 times more torque than a PK299-02A motor, which is probably similar to the motors used on a PRT (500+ oz-in vs 200 oz-in). (I don't have a part number for the PRT motors.)

If you wanted the motors to run at 200 RPM (about 10-ips) and if the combined force (gantry movement + cutting force) requires no more than 200 oz-in, then both motors could move the axis at the same speed. However, if the move required 550 oz-in, the Alpha could move at about 10-ips and the PRT could move at about 6.5-ips. This is according to the charts on the Oriental Motor web site. In both cases, the motor would be directly connected to the spur gear, without a reduction gear.

The "Why" question is beyond my understanding, except that the Alpha motor runs at a much higher voltage than the PK motor. My testing of a PK299-02A motor combined with a Gecko G212 drive running from a 70VDC power supply shows that the PK motor can hold its own against the Alpha's AS911AA motor. HOWEVER, to truly equal the alpha motor, the PK motor would have to be equipped with an encoder and an intelligent controller, such as the not-yet-ready-for-showtime Gecko G100.

---

MONITORING the Encoder
It should be a trivial matter to show the following-error (discrepancy) of an axis. Every step pulse sent to the motor could be held in a step counter variable. Every 4th encoder pulse (if the alpha uses a quadrature counter) could be held in an encoder counter variable. At any time, the encoder counter could be subtracted from the step counter, and the following-error would be known. Comparing the following-error value to a maximum-error value could trip an emergency stop.

[bill.young]

Hey John,

I'll keep my fingers crossed!

[richards]

MOVE SPEED
Is it possible that move speed is being slowed by a low setting in the Z-axis move speed? Before I started ramping into cuts, which allowed the Z-axis to move at 6-ips instead of 0.5-ips, the M3 commands killed productivity.

CAUTION: Spindle users be aware that a standard Z-axis plunge speed should be about 1/10th the speed of a 20-degree ramped plunge.

[dirk]

Differences between Alpha and PRT controller:
PRT and PR Controller (Blue Earth) max usable step frequency 7K, Alpha controller same board, replaced with faster processer and crystal - 20K with standard USB adapter, max 30K with special high speed serial board in computer. The Alpha board will drive Geckos with a compariable square frame stepper at close to the same performance.

[richards]

I just ran two sets of circles on my Alpha, seven circles per run, starting at 1-inch diameter and finishing with 7-inch diameter, using the CP command.

The first set had MS, 1.5, 1.5. The second set had MS, 5.0, 5.0. The results are:

Last Complete |Cut Mode| Elapsed: 00:02:40 Reps: 1 16:17:38 04-07-2006
File Max: 18.50, 18.50, 1.00 Min:- 18.00, 0.00,- 0.09 Offset:no Brks=0
Last Complete |Cut Mode| Elapsed: 00:01:20 Reps: 1 16:23:35 04-07-2006
File Max: 18.50, 18.50, 1.00 Min:- 18.00, 0.00,- 0.09 Offset:no Brks=0

Note that the second set of circles cut in exactly 1/2 the time required by the first set of circles.

[Brady Watson]

Mike,
Post your VR Sheet so that we can compare ramping values to ramp speeds and your cut time. Are you using default values or did you change them?

-B

[paco]

Circle Resolution (mostly) and Small Circle Def might be relevant to consider too... if modified from the default values that is... maybe the tolerance settings used in the CAD/CAM package can "interfere" with all this... and I really wonder how accurate is the timer of SB3 (not that I'm assuming something specific)...?!

[Brady Watson]

Good point, Paco. A low value (.0001) Tolerance DOES slow down a Bot. I would imaigine that the post processor when cutting circles specifically, would also affect speed. One does it in arc moves, the other in segmented moves.

-B

[paco]

Aren't arcs made into segments (straight lines) in SB3? I'm refering to the Circle Resolution of the VU command; keep the mousse pointer at it (the parameter title) for a moment, it display a definition of what it's about... Circle Resolution - "Sets the size for each segment in a circle/arc"

[richards]

Paco and Brady,

I used all default settings for the VR and VU parameters. Also, I ran the test using version 3.4.20 software.

The SBP file was hand coded with simple jogs, moves, and the CP command for cutting the circles.

[gerald_d]

Joe, if you havn't given up on this thread yet, I am more confident about my layman's theory now.


I would still love to see a True Speed Indicator on the screen as the system cuts. As John Hesp has shown, we might believe that the system will follow a certain speed, while the true speed is 50% less. This situation makes it impossible to do chipload calcs, for example. Absolutely everything that has been said on this Forum about a speed giving a result is now again been shown to be dubious.

[joe]

I'm still hanging in there. Where are the interositers?

I like your theory. It makes sence. Even if it's wrong, I still like best.

[richards]

From my experiences with both the Shopbot and a test bench running Mach 3 and Mach IV software, the curve/arc/circle/ramping slowdown is common. Using the automobile example, an automobile can travel much faster on a straight section of road that it can on a curved road, at least if the driver wants to stay on the road. A CNC machine is made of mass. Although I'm a poor student of science, I do recall that heavy things have inertia and that heavy things like to retain their current state, whether they're moving or standing still. The ramps and slow down through curves seems to be necessary for the machine to work.

Gerald points out a very valid point, though, about chip loads. A file that contains cuts for curves and for long straight cuts is going to force the operator to either favor the slow parts of the cuts or the fast part of the cuts when he's deciding on chip load.

[Brady Watson]

Unless you had a spindle that would speed up and slow down RPM proportional to the move speed of the CNC, chipload will never be consistent.

-B

[gerald_d]

But, if we had a CNC router that actually obeyed the dialled-in speed, the move speed and thus the chipload would be consistent. Our DOS ShopBot does give us a steady move speed except for the very sharp corners. It might be slow compared to an Alpha, but it is steady. Our Gecko/Mach machine also holds steady speeds for most profiles. I think it is only the "stepper-with-encoder" application, where the speed boundary is pushed much higher, that has the wide range of speeds.

If there was a True Speed Calculator, it would be feasible to feed that signal to the spindle so that it does do a constant chipload. Folk doing CNC turning on metal lathes do that - when they turn a ball shape with changing diameter, the spindle speed is changed to maintain an ideal load on the cutting tool.

[joe]

How significant would that be to function. Perhaps there would be longer bit life, due to less heat, but what else. Could there be a smoother cut?

Most of us novice type are looking for a cleaner cut. There's a real time loss when the sandpaper com out. At my shop, it's allways being used. No matter how fast the thing runs, it's all for naught in the end it has to be messed with. The verry worse is PVC. It shows every error and is difficult to sand.

[hespj]

Well that was a revelation. I was pulling Bill's leg when I said I expected my SB to be in overdrive after installing the new software, but that's what happened.

If you remember I cut a 1m (39.5") dia circle and couldn't get it to do it any faster than 26 seconds - 4.75"/sec.

Loaded control software 3.4.20 and the same circle takes 14 sec - 8.8"/sec. I am very pleased with this, I wasn't expecting such a big improvement in performance a year after I bought the machine.

Cutting irregular 3D shapes also improved, but not as dramatically. A test 3D cut with the old software took 2min 24sec. The same test cut with 3.4.20 took 1min 49sec. This looks like it will reduce cutting time by a very worthwhile 25%.

[Brady Watson]

Joe,
I cut a lot of Komatex PVC here at the shop and it boils down to a few factors. One thing that not many people mention when complaining about edge quality is how well the part is being held down. If you are not using vacuum or carpet tape to hold down PVC or other plastics, you are going to spend some time sanding.

Besides hold-down, the next thing that will greatly influence edge quality is how much you are asking of the tool per pass. To me, chipload is a good guildeline, but here in the real world even the perfect chipload calculation doesn't address the fact that some people ask too much from let's say a 1/4" bit. You may be able to run ideal chipload, but bit deflection plays a role here in some cases. I have found that going down 90% of the way with .02 allowance and then a full depth pass gives the cleanest cuts in PVC. If you are SURE that you have good clean vectors when you cut, then I won't mention that as a potential issue.

I think that this is a great thread for dialogue, but let's keep in mind that speed and chipload are not what we are after, which is clean cuts as efficiently as possible. Sometimes this means spending some more time thinking about holding the material down effectively and doing test cuts with allowance to see what yields the best edge. The allowance trick is definately the ticket for PVC and other plastics where you have to keep moving to extract hot chips, but don't want to put up with ridges from a small tool that shows signs of deflection in the edge.

Efficiency of the ShopBot is only part of the equation...If you spend a little more time on the tool cutting, in many case you will save more than that time on the back end, rather than doing post finishing/sanding.

-B

[richards]

Let me plug the 3.4.20 software in this thread also. I don't know what they've done, but the old 'chatter ' problem is almost non-existant. It's almost unbelieveable. Although I never keep the 'standard' tests from version to version, ALL previous versions left an edge that needed sanding, usually heavy sanding, particularly in the ramping area. With version 3.4.20, the cuts were smooth at all speeds tested, ranging from 1 to 6-ips. The tests were straight x-axis cuts, straight y-axis cuts, 45-degree x/y-axes cuts, and circles. (The 3-ips 45-degree cut showed a VERY MODEST amount of 'chatter'. I had to look really hard and then run my finger several times along the cut to verify that there was just a little bit of 'chatter'. The other cuts were as clean and smooth as I've ever seen. By the way, having just a little roughness at certain speeds on a stepper motor should be expected - but I am talking about a very small amount of 'chatter'. (This test was run just after emailing Ted about other things, when I basically wrote that everything about the Alpha was excellent except the 'chatter' problem. Sorry, Ted, you had that fixed. If I had installed the software that you had already posted in the download section of the Shopbot site, I would have known that the Alpha is now able to do anything that I have the skill to ask of it.)

[gerald_d]

Mike, what version did you have before 3.4.20? Do you see anything in the release notes (http://www.shopbottools.com/SBCSupdatenotes.htm) that will give this order of improvement. Bill, if you will, do you know why 3.4.20 works so much better for Mike?

[richards]

Gerald, I skipped version 3.4.19, so the last version must have been 3.4.18. There is nothing in the release notes that seems to directly address the 'chatter' problem or even ramping, except threshold ramping in metric, which I don't use. That's why I was so surprised to see clean, sharp cuts. I hadn't expected the results that I got.

Other than changing to version 3.4.20, the only mechanical things that I did to the Alpha was to clean the spur gears, but I've done that before, so I would rule that out. Also, I dropped the motors away from the rails so that I could check for binding, but I re-tensioned the springs to my standard settings. Again, I've done that several times in the past. Reducing the electrical noise generated by the VFD should not have been a factor, or I would have been one of the few who had a 'chatter' problem.

To make sure that the test wasn't a fluke, I just ran it again using a different piece of MDF and a different cutter and got the same impressive results.

[joe]

Thanks Brady,

I don't have a very effecient hold down system so I'll just screw down each letter and do some test. Although I trust you judgement, I'm skeptical since I've previously attempted allignment tests, speed changes, bit tollerence, etc. I've kind of given up, but am willing to give it another try.

I appreciate your assistance.

[Brady Watson]

No problem Joe...I struggled with it at one point and it took a 40 sheet order to get me on the right track! Don't worry if you don't have a vacuum system. High-traffic indoor/outdoor carpet tape works very well. Screws do not work well on any plastic material. If you were cutting 3/4" PVC, I would cut 2 passes @ .02" allowance and .35" stepdown and then come back with 0 allowance and do a full depth cut in one pass.

The other thing worth mentioning is the length of the tool. I typically use end mills for most cutting and the XL 1/4" cutters for example have a 1.125" CL and scream and chatter in dense material where an identical grind .75" CL end mill does not. That vibration goes right to the edge...and sends you looking for asprin and ear protection.

-B

[mikejohn]

There is something bothering me about this Forum, used by many as their introduction to, and education of the Shopbot and CNC routing in general.

It is the making of definitive statements which in fact only apply to a certain part of the overall operation and techniques of the machine.
Brady says above "but let's keep in mind that speed and chipload are not what we are after, which is clean cuts as efficiently as possible. "
In my case, when cutting 'blanks' for rocking horses, I don't give a jot about quality of the edge, because the whole thing is shaped after the blanks are assembled, and the finished product is millimeters under the part cut by the 'bot. Speed and chipload is everything.
I have other issues I will take up in other threads.
My concern is that people will either be put off by what they read, when in fact they are quite capable of operating or using the Shopbot for their needs, or take an unnecessarily expensive path, or believe that the highest technical system is the only way to go, or sometimes be given downright bad, or even dangerous advice.
This forum is lauded as being a great help to many people (certainly including me). Posters should try not to make their advice dogmatic, unless they are certain the advice they are offering is either the only choice, or the best possible choice for the circumstances in question.

.............Mike

[tuck]

Haha, Mike John,...I beg to differ. I will continue to come in here and argue, even if I don't know what I'm talking about, which is most (if not ALL) of the time.

You can't stop me, because I ALREADY KNOW that I AM an IDIOT!!!

I am PROUD to be an IDIOT! I am such an idiot, that I am too proud to learn from veterans that are trying to help me out. I am such an idiot, that I don't need anyone but myself. I am such an idiot, that I think I know everything I need to know. I am such an idiot, that no one can be of benefit to me."

I'm sorry I rambled on. All I meant to say was "A good router is better than a spindle in most cases."

[joe]

Thanks Brady,

Although I don't cut very much Acrylic, we have a continual need to reverse cut PVC. These are letters that are used in the cast stone, concrete, sign business. I am using special bits, which are double fluted, 2" cutters that have a 12degree and 15 degree draft to them. When cutting 1/2" Centra there has been considerable chatter. I look forward to making that extra pass, which if it works, will save lots of time.

I don't believe theres' much chatter from the bits as they are 1/2" shank and about 1 thick at their base and very heavy.

For some time I only condisered this problem to be some kind of carriage weakness, viberation or harmonic distortion. I guess it doesn't make any difference if this solves the problem.

J

[mikejohn]

You see Mark, you understand completely.

You say "A good router is better than a spindle in most cases."
It is the in most cases which makes all the difference.
Mind you, most could be changed to many.


I feel all opinions are welcome here, and should be encouraged, but they should be shown as opinion not as fact unless they are indisputably fact, (my shopbot table is painted blue, for instance)

.............Mike

[tuck]

"(my shopbot table is painted blue, for instance)"

Ewww.... you got one of them blue steel tables? Ewwww! Mine is made out of pine wood and looks like a forrest! It's enviormently friendly.

Your's ain't.

EWWWWWW!!!

[mikejohn]

Now how do you know, from what was written above, that my table was steel?
Supposition Mark!
It could be a painted wooden table, but it's not!
You are making my point for me more and more. Thanks


..............Mike

[hespj]

Mike, I think most forum readers accept that they are reading opinions, however those opinions might be phrased. One might as well complain that a bloke down the pub said that Man Utd was the best team in the world.

[tuck]

Mike John, yo don't fool me. You got one of them icky steel tables. Admit it, man, and good be good with it. OK?

LOL!

[mikejohn]

John
I agree that most forum readers recognise the difference between fact and opinion, but I clearly remember when I first found this forum, I was not one of the "most".
Then I knew nothing about CNC routing (don't know a lot now!) so when I read a statement I had to take it at face value. A few times others stepped in to correct inaccuracies, saving me grief and heartache.
I have strong opinions on which software, tools, bits, hold down, works for me, and I will voice my opinion when I feel it helpful (or even to be contentious) but I will never suggest that my way is right for all or any other person or circumstance.
I would simply like others to also make this clear.

Do Manchester United still play in the Premier league?


.............Mike

[mikejohn]

Brady
Does this mean that you feel the arrogant stand of making emphatic but untrue statements is somehow justified in your case?

Why be insulting to any Forum member with an opinion that differs from yours. The First Amendment is one of the corner stones of civilised living, do you feel it applies to yourself but not to others?

Keep things civil.

.............Mike

[Brady Watson]

I'm too busy to get hooked into this drama. If you don't like what I say, then don't read it & move on.

Have a nice day

[mikejohn]

Ignore my post two above.
Brady felt he wished to delete his prior post, and I am pleased to see the remark withdrawn.

I am pleased to see no personal animosity anywhere on this Forum.

I will, however, continue to give opposing views to others opinions, politely I hope, if I feel it may be constructive or help clarify points of interest. I recognise of course that my views are not always correct, in fact are often incorrect, but others correcting my errors may also provide useful information, not only for myself but also for others.
I will have a nice night


................Mike

[bob_lofthouse]

Tomorrow might be interesting...

At the moment I cut and run my machine at set speeds which I know are pushing it to its limits.

With the new version of control software and a apparant reported increase in speed, will this mean that I will have to adjust all my part files (reduce speed)?

[hespj]

Robert, until somebody more knowledgable comes along, and in my humble opinion, you probably won't have to adjust. If you have a part file that has set the speed to, say 200mm per second, then that will still be the max speed the router/spindle will reach.

(You might have a problem if the router/spindle was never reaching the 200mm/s because of the complicated shapes you're cutting, but any straight lines of any length would allow the spindle to reach the 200mm/s).

All IMHO.

[bob_lofthouse]

Hi John,

Thats what I've been thinking.... Have I been cutting wood at what I thought was 6ipm but was really 4ipm.

John... If you see a carriage flying overhead tomorrow you know the answer....

[jhicks]

Long post but good stuff. Can I ask if this "new version" and its seemingly positive impact on an ALPHA edge chatter is useful to us PRT guys?
I agree that those edge cuts are essentially "the sum of their parts" in that hold down, bit deflection, sharpness, ramping, etc, etc. etc, all add up so please don't feel the need to elaborte on those points.
Does the new download help improve this and can it be used on a PRT?
Thanks
And try to play nice out there boys!

[bill.young]

Hey Jerry,

All I can tell you is to give it a shot. The PRT and Alpha executables are functionally the same...just select the PRT version from the download page.

Oh yeah, there is a new version up 3.4.21 with a couple of small fixes. The chipload calculator wouldn't start correctly because of a typo in the Virtual Tools ini file and there was a formatting problem with labels in a file. No big changes in this one I'm afraid but it's still good to stay current.

Bill

[richards]

I'm glad you caught the labeling problem. I scratched my head for about 1/2 hour on that. Finally I changed my file's logic so that I only had one conditional branch per subroutine. Version 3.4.20 worked fine after that - and, as a bonus, the subroutines were more concise.

[jhicks]

Thanks Bill, we'll get it loaded and see what happens

[ted]

There are a number of different issues being dealt with simultaneously in this thread (not including the non-technical ones) and I think that without separating them it’s going to be a little confusing to sort it all out. So I'll take them one at a time. I apologize for the space required. You can skim down to your issue.

PRTalpha vs PRT Power.

Power, measured as holding torque at standstill, is about the same for both PRTalpha and PRT. It takes 60-70#s force to push either tool out of position (you can measure this by pulling with a fish scale). The PRTalpha motors are almost twice as powerful as the motors on geared PRT tools, but after gearing is taken into account, the standard PRT actually generates a little more force at the tool. Keep in mind, that so far we are talking about the force when the motors are not moving. [In the case of both type tools, power is actually reduced to 75% when at rest to keep the drivers cooler -- at slow speeds they will actually have a little more power than mentioned above, but you get the general idea.]

Stepper Speed vs Power.

Steppers lose power as they go faster. This happens because this type motor is driven by rapidly switching the polarity of the power to the motor coils to produce each ‘step’ move in the rotation of the motor shaft. It takes time for the coils to fully reload and power up at each of these changes in polarity. This means that as the motor is driven/switched faster, the coils will get to the point where they don't have time to fully load and produce full power. At this speed of stepping, the motor starts losing power. With most steppers the loss is not linear. Power typically decreases slowly to a point, then falls off more rapidly.

The way to improve things for a stepper motor is to feed it higher voltage. The higher the voltage, the more quickly a coil loads. This is what a stepper driver is all about -- it initially loads the coil on each polarity change with a high voltage, and then cuts the power back as the coil loads up, preventing the current draw from going too high. So a standard PRT runs at 40 volts. At this voltage, the power stays pretty good until 1.5 and 2.0 inches/second (typical cutting speed) and then starts falling off more quickly. On a standard PRT, above 3.5 to 4.0 inches /second, the power becomes too low to be reliable.

PRTalpha Speed & Power.

Now, if you were to double the voltage, you would load the coils faster and would about double the speed before the power drop-off happens. Double it again and the speed attainable before the power drops increases again. The speed difference between the PRTalpha and PRTstandard tools is primarily the due to the PRTalpha motors being fed with about 160volts. This higher voltage, in addition to a couple of other factors, means that the PRTalphas carry their full power to much higher speeds. Indeed, they are still at just about full power at 30 inches/second.

The PRTalpha Closed-Loop Feedback System.

Making a stepper motor ‘closed-loop’ deals with the problem that they can potentially ‘lose steps’ or ‘lose sync’ in relation to the control system. If a standardPRT motor is pushed beyond the speed that is has adequate power to move the tool, it may lose steps and its position will no longer be accurate. This is the downside of stepper motors. The upside, is that until this point of failure, they are nearly perfectly accurate and any slight error that might occur in positioning on an individual step is not cumulative. Each step is itself accurate and independent of any previous steps. Steppers offer a very simple and robust way to produce motion. When not pushed beyond their capability, they are inherently accurate, digital, and easily managed by computers. In contrast, for a servo, any point of position depends on the feedback system bringing the motor into adjustment and this requires a relatively complex positioning system. There’s certainly nothing wrong with a good servo, but they are expensive – and we would like to find a good, high-performance system that is affordable. The inexpensive servos seen on some of the low-end CNC tools are slow in comparison to a PRTalpha. The advantage of the PRTalpha approach is that it combines the natural accuracy and quick-motion advantages of a stepper, with the closed-loop control of a servo. It works to avoid losing a step, corrects if it should happen, and if it can’t recover, shuts down and alerts the operator within a few seconds. Yes, put the 60+#’s of force on the carriage that it takes to pull it out of position, and it snaps right back!

Need More Power in a PRTalpha?

So, PRTalphas do not have any more power and only slightly higher step resolution than standard PRTs, but they do retain full power at any speed they move at. Cutting at 10 inches a second (600 inches/min) they are still at full power. For those who would like even more power and resolution, we expect shortly to start shipping PRTalphas with optional 7.2:1 tapered-hob, gear-heads. We initially resisted the gear-head approach because we liked the simplicity of the straight-drive motors – having virtually nothing to wear out. But there are applications where more power and resolution are can be useful.

Why Ramp (acceleration and deceleration)?

Imagine taking a gantry that weighs several hundred pounds, getting it moving at speed in one direction, and then trying to instantaneously reverse its direction without slowing down. The force on the motor would be intense – potentially much more than the force that the motor has (see above) to produce motion and hold position. Abrupt changes in direction also place strains on the gantries that can result in deflection and vibration. To maintain accurate position and smooth cutting motion, when a CNC tool comes to a corner, it slows and stops, and then accelerates back up to speed in the new direction.

The decelerations and accelerations into and out of corners provide tools with a smooth and controlled method to change direction. These speed changes are often referred to as ‘velocity ramps’, or just ramping (as distinguished from cutter ramping by which a bit is progressively moved lower into the material at the beginning of a cut). The software ‘looks ahead’ at upcoming moves, and depending of the severity of an approaching corner, programs in the ramps. During these brief periods at the beginning and end of a cut, the feed-rate will not be optimized. Thus, the idea is to make the ramp as short and brief as possible. That is why, using the [VR] function, you can adjust the settings that define the occurrence of ramping in order to make ramps shorter or longer and begin and end at higher or lower speeds. That is to say, you can make ramping more or less aggressive in order to best optimize cutting for your tool and for a particular project. In fact, ramps can be shortened to be fractions of a second, or in slow cutting, completely eliminated. For full details on the adjustment, and to understand the velocity profile of a ramp, have a look at the discussion on ramping in the ShopBot Command Reference. It can be accessed from HELP in the software.

Tool Movement Speed and Speed Display.

Note that when the tool is not in the ascending or descending limb of the ramp, its speed is the speed that is shown in the display. It may seem from the sound of the motors that the tool is moving at a different speed on a diagonal than when it is on a straight Y or X move, and indeed, the motors are turning at different speeds. But the motion of the cutter is vectored to be exactly the same speed in every direction (with exception of the ramps). For example, when on a 45 deg diagonal the motors turn at about 70% the speed that they do on the straight in order to produce the set/indicated constant speed in the cutter path (remember Pythagoras; two motors are contributing to the vectored motion).

Slow in Curves and Circles ? Probably Not ...

Imagine that you are coming into a corner that is tightly curved. From the tool’s point of view, if the radius is very small then the problem of changing directions is the same as if the corner were a simple angle. And, if speed did not ramp down and back up again, the cornering would be disruptively abrupt. For this reason, the look-ahead function looks at sharp corners, not just in terms of sharp individual angles, but also in terms of tight arcs and curves. If there is a lot of curvature over a short distance, the corner will be ramped. This also means that a regular circle will not be cut at full speed, unless it is of sufficient diameter to be above the ramping threshold. Using default settings on a standard PRT running at 1.5 inch/sec, circles over about 1” diameter will be cut at full speed, and those less will be cut more slowly.

Do this little experiment: Set XY move speed to 1.0. Set the duration of the warning period to 0 ([SW] to 0). Set the XY ramp speed to 1.0. Now do a 10” circle with the [CC] Command and look at the elapsed time. You’ll find it to be 31 (pi * 10), which is the exact time it should take to execute the circle at 1inch/sec. Now change the speed to 2.0, and change the ramp speed to 2.0 [*a standard PRT will probably lose steps if started with a ramp speed of 2; but the displayed time to run the circle will be accurate]. Again, run a 10” circle. You’ll find the time to be 16 (pi * 10 * .5), again the exact time it should take. On a PRTalpha you can go up to 10inch/sec with this exercise. You can’t set the ramp above 2.0 so you will lose a little time to ramping, but you’ll still see nearly exact tracking of what the elapsed time for a particular speed should be. Bottom line is that once a circle or arc is above the tight diameter that triggers ramping, circles are executed exactly and continuously at the defined speed. For a standard PRT, practically speaking, this is any circle/arc above 1” diameter.

Now, the high speeds for PRTalpha’s make the situation a little more complex. Ramping is graded with a PRTalpha. For example, if the move speed is 4inches/sec, then an 8” circle will be cut at full speed, but a 2” circle will be cut slower, a 1” circle even more slowly, and a .2” circle very slowly. If the PRTalpha speed is 8” a second, the partial ramping will cut in at a slightly larger diameter, with speeds then similarly progressing down with smaller diameters. Think of this in terms of speed. If you are going 1 inch a second, then coming to a 20 degree corner is not very significant, but if you are going 10 inches a second there is a pretty large redirection of momentum that must occur. So the faster you are going, the more likely ramping should be. The amount of slowing in the initial gradual ramps is set by the ‘Slow Corner’ parameter in [VR]. The default of 65 means 65% of the current move speed. Set it to 99 to turn this slowing off. A standard PRT does do a little of this, in that the slowing from 1” diameter down to smaller diameters is graded, but it is not as broadly dynamic as for the PRTalpha because of the PRT’s more limited speed range.

*** APOLOGIES FOR METRIC!

Somewhere after version Sb3.3.18 an error in setting the ramping thresholds in metric appears to have crept into the software. The error caused circles/arcs to be much more likely to ramp and stay slow. I’m afraid we only very recently became aware of it. This error is corrected from Sb3.4.20 on … and all the above stuff should also apply exactly the same way to metric. Sorry we didn’t catch this one sooner.

Slower in 3D ? Yes, but ...

Ramping and the related slowing happens in 3d for similar reasons to ramping in 2D: to prevent abrupt changes in momentum that would be disruptive. Things are a little different though because the action of the Z axis is an added variable to consider. The Z is like the X and Y, though not quite as heavy; still, if Z motor speed changes are too fast, they can be disruptive, causing vibration or lost steps.

The look-ahead functions in 3D work like they do in 2D, but before thresholding for angular change is evaluated, there is an evaluation to determine whether maintaining the designated vector speed will cause any axis to need to move faster than its designated speed. For example, if the Z speed were set to a relatively low speed, and the file had many steep verticals in it, there would be situations in which to maintain the constant speed vector in XY motion, the Z axis might need to travel faster than its assigned speed. But because it would violate it maximum speed, the look-ahead process reduces the speed of XY motion so that the Z does not go above its designated speed. This means that for a 3D file, you will always want the Z speed set as high as practical.

An example of this 3D limitation sometimes causes a problem when using ShopBot’s tabbing function. Ideally in with tabbing, the execution of the tab does not disrupt the smooth XY vectored motion. If you have to slow down for each tab, it can create a tooling mark in the part. However, if the Z speed is set too low, or the angle of the ascending and descending legs of the tab are too steep, then the tool will be forced to slow in order not to go above the designated Z speed in the legs of the tab.

More generally, in an intricate 3D file there will often be lots of relatively abrupt changes in direction. Changes in direction will activate protective ramping and slow the cutting of the file. So the idea with any 3D file is to make sure the ramping is optimized for the type of cutting that is being done. The nature of the types of cutting that people do can vary quite a bit, so this is something that you will tend to need to work out for yourself in order to get optimal speeds. You will want to adjust the basic ramp speed (higher will be more aggressive). You will want to adjust the move ramp rate (smaller is faster and more aggressive). The default is .4, but most 3D files will work well at a more aggressive .2. Finally, you will want to consider adjusting the 3D threshold. This is the speed change (relative to the ramp value for the axis) that must occur for a 3D ramp to be set during the look-ahead process. 100% is the default. If you raise the value to 120%, more of a speed change will be required for ramping and the action will be faster and more aggressive. See ramping discussion in Command Reference (available from HELP in the software) for more detail.

Setting these ramp values (along with getting good basic feed-rates) so they work well in your files will increase cutting efficiency. In general, we find that with a cabinet type file, a PRTalpha will cut a part about 3-6 times more quickly. With a 3D file, we find processing 2-3 times faster. It all depends a lot on the nature of the work.


Hope that I have gotten some of the questions of this thread answered. Sorry for being so long-winded about it.

-Ted

[Brady Watson]

Thanks Ted. That was a VERY informative post that answered and clarified a lot of questions that I had on ramping and how it relates to the movement of the tool.

Now to go out to the shop and test some 3D ramps...


-B

[dvanr]

Doesn't the preview mode use ramping when it simulates the cut path in x&y and z?

[gerald_d]

My experience of that particular Alpha giving way was when loosening/tightening the 1/4" bolts through the V-rollers on the Z-slide. (the y-car moved along the gantry). I didn't have my fish scale with me there, but I knew it wasn't over 40lbs. Repeating that exercise this morning, I see the force needed for that bolt is more like 20lbs. Given Ted's words above, there must have been something wrong with the y-car on that bot. (Yes, the motors were ON at the time - it was like working against a spring)

[mikejohn]

Do I understand that if you are making cuts with continuous direction changes, .5" (12.5mm) high letters for instance, then the Alpha has little or no advantage in speed?


...........Mike

[hespj]

Ted, thanks for an excellent explanation. Since my last post I looked up VR in the help file and was enlightened somewhat, but your post clarifies this further.

You say "On a PRTalpha you can go up to 10inch/sec with this exercise. You can't set the ramp above 2.0 so you will lose a little time to ramping, but you'll still see nearly exact tracking of what the elapsed time for a particular speed should be."

Firstly, why not 12"/sec?
Secondly, I'm running my SB in metric, and as I mentioned in a post further up this thread, the max speed I could get cutting a 1m (39.5") dia circle, using a variety of ramp speeds, was 8.8" (225mm/sec) with move speed set to 300mm/sec. Ramp speed had little effect if I remember rightly. If there is an upper limit for circles of 10"/sec then 8.8" is quite close, but it's not close to 12"/sec. Is this a metric anomily rearing its ugly head again? I'll try "cutting" more circles in inch and mm this afternoon, it's more fun than the job I'm supposed to be doing.

Given the variety of parameters which might need changing from one type of cut to another, is there a way of saving groups of settings? For instance with experience I might find the best speeds and ramp values for rough cutting 3D where speed is important, but finish isn't, but these wont be suitable for 3D finishing; and again, other sets might be optimum for 2D cutting rough and smooth. It would be good to select these with one or two mouse clicks.

Gerald, when I moved my carraige and thought it took more than 40lbs, I was moving X (two motors). It moved about an inch, is that what "your's" moved?

[hespj]

Mike, let's have a race to find out. Email me a file. I think there'll be little difference.

John

[gerald_d]

John, it felt like it was to the order of an inch - certainly more than 10mm, but probably less than 50.

[mikejohn]

John
You have mail.
To be more precise, an email has been sent to your email address, which I hope has arrived

[dvanr]

answered my own question last night. Preview does not include the ramping values.


7816

preview can be out by as much as 20 % too low in its time estimate on cuts involving 8 simple rectangles that fill a full sheet.

It would be great if preview simulated the actual cut a lot closer. Save a lot of time and enable accurate estimates.

[tuck]

Dang! What a thread! Started out with, "What are the speeds of a PRT96?" Ha!

[gerald_d]

Dick is a metric user - do the inch guys also get cut time estimates that are too low?

[dvanr]

Should have added that the test was done with the latest software/firmware 3.4.21

Tests were done in inch mode , we have been drawing in metric and cutting in inch and haven't had any problems so far

[gerald_d]

Why cut inch if you draw metric??

[dvanr]

I'm not the only one using the machine , and worried about some of the negative feedback on the metric option in SB controller. ( I have to keep a wary eye on my rabid SpringBotter friend when he gets near the bot)


The postprocessor in Partswizard made the metric to imperial conversions easy. It also made it easier coming to grips with feeds and speeds, as most here talk in inch/sec.

[hespj]

Mike, email recieved and file aircut in 6 min 5 sec. XY speed 300mm/sec, Z speed 100mm/sec. Jog XY 700mm/sec, Z 300mm/sec.

Hopefully Mike will tell us how long his PRT took to aircut the file. The file appears to be three rows of lettering, each row about 50mm (2") high.

[ted]

Let me see if I can answer a few of these. It's hard to keep up sometimes.

On the Cutting Time for Part Files Having Only Small Moves.

Yes, Mike, in a file with all the moves less than say .5 inches, a PRTalpha will not cut much faster. If you really want to push it, you could probably reduce the cutting time by 50% because you could very aggressively ramp in a way that you couldn't safely do with a PRT. But this would probably take some tweaking and might not produce as good a cut as you would like. With default settings, the time should be about the same. (Hey, there is nothing wrong with a PRT!)

On Estimated Cutting Times Displayed in Preview Mode

Point taken. We'll work on improving that. At the moment the estimated time is computed from the speed, and a simple correction added based on the number of ramps. It gives only an approximate result and is sensitive to number of ramps and relative length of segments.

On Top Speed for Circles

Circles/arcs are very communication intensive becasue the vectored speed is constantly changing and the speed changes as well as the motion are transmitted from the PC. The bottleneck in circle speed (on PRTs and PRTalphas) comes from reaching the maximum communication speed to the box, at which point the tool won't go any faster. There is probably 5 times more info transmitted in a circle than on a straight. The critical point is usually about 2.5 in/sec for a PRT and about 10-12 in/sec on PRTalpha. But, communication efficiency can vary with computer, so you may be a little above or a little below this point.

We're always looking to improve communication speed since this gives us faster circles and better resolution. Going to a USB bridge gave the PRTalpha about 4x the speed of a PRT, and our next controller will probably use USB directly to get beyond these limitations (why we prefer serial to parallel connections is as subject of another essay, but believe me for the moment, we have reason). Now, in the short run, for those who are really determined, you can get about a 25% boost in communication speed on a PRTalpha by changing to a Quatech USB bridge from our standard one. The Quatech turns out to be considerably more efficient, even at the same baud rates.

More importantly, if you need to cut circles or curves at 12 in/sec and are being hampered by communication speed, you could increase the segment size slightly (thus reducing the number of speed changes that need to be communicated), you will increase speed. That said, I just tried a 500mm circle on a PRTalpha at 300mm/sec. It did the circle in 6 sec which is about right, especially considering ramps. So I'm guessing that the reported 8.8 speed in the report above either results from a difference in computers or perhaps a difference in resolution of the circle (was it a PW file or a CC command, for example) ?? I don't really know, but it would be good to get it figured out.

We certainly don't intend for there to be a difference between inches and metric in anything. But the practical problem is that we hardly ever run in metric in the shop here other than for testing. So we are sometimes not as fast to pick up on a metric issue as an inch issue. I am totally amazed that no one told us until about 10 days ago that many metric circles were not getting out of ramping. We do try and monitor the forum, but had missed this.

And, On Forum Monitoring

We do try and pay attention to issues raised here. But what we hope the forum to be is a place for people to get advice on issues related to projects, cutting techniques, production techniques, concepts, philosophy, etc. For problems with the way a tool is working, or with clear bugs in the software. The best thing to do is to contact us. Even after hours and on weekends, we check phone messages and email, and we do our best to get back to people right away. We understand that support issues can come up in the evenings and on weekends and don't want to leave people stuck. We love the Forum and the broad support it provides ShopBotters, but on things that we can quickly straighten out, we want to do it. On those bugs, or whatever, just send an email to support@shopbottools.com (mailto:support@shopbottools.com); describe the issue, and send a sample of the problem file and your problem.log file (so we can re-create your specific software setup).

The Advantage of Doing it Ourselves ...

The main reason I urge you to communicate software issues to us is that in addition to wanting to help, we are able to help make things better. We design and produce the ShopBot Control software and controllers ourselves. That means we can dig in and fix it, tweak it, modify it, and improve it to make it work better. Your particular priority may not always make it to the very top of the list, but it will be there and we will probably get it implemented. We are not dependent on what an outside provider decides should be a feature of the software, we want to be able to continuously enhance the core components of the tools ourselves. And we work pretty hard at it.

I'm thinking there was something else I was also going to comment on, but can't remember it now ... later.

-Ted

[ted]

Oh, just remembered the other point ...

Saving Settings

Yes, John. You can save settings you like at any time. Just use [US] to save the current settings. You can give the file a name appropriate to whatever type of cutting you are doing. Then, anytime you want to reload these settings you can use [UR], or just go to the file with [FP] and run it. (If you saved with the .sbd extension, you'll need to switch to "Show all files types" in the file selection window; or you can save with an .sbp extension.)

ShopBot's .ini file and all the default setup files (the .sbd's) are just Part Files. They can be run anytime to change settings. Or you can set up special files to just change certain settings.

-Ted

[hespj]

"I'm guessing that the reported 8.8 speed in the report above either results from a difference in computers or perhaps a difference in resolution of the circle (was it a PW file or a CC command, for example) ?".......Ted Hall

Cut with CC command. Computer is 1.3Ghz celeron if I remember correctly. I notice that there's a couple of second pause before the router starts moving (but timer is ticking), this makes the elapsed time for my 1m dia circle 14-2 = 12 sec, giving a speed of 260mm/sec (10"/sec). Very acceptable.

"I am totally amazed that no one told us until about 10 days ago that many metric circles were not getting out of ramping."

Well it's difficult to know what's going on when a person isn't an expert in CAM. I've air-cut a lot of circles this morning in inches and metric, various diameters, various speeds and various ramp speeds. None of the 28 circles I cut was more than a second faster or slower for having ramp speed set low or high (10 or 50 in mm).

But cutting a 3D test file with low ramp speed (10) took 1min 6sec, whilst the same part took only 50sec with high ramp speed (50). Excellent.

"Yes, John. You can save settings you like at any time. Just use [US] to save the current settings."

Thanks.

[mikejohn]

John
um! where do I find the .log files?

I will air-cut that file again tomorrow.
Your speed is definitely faster than mine, but by how much I am unsure
Its a 650mm (26") x 180mm (7") sign with 3 rows, 55 letters.
Cut speed x/y 50mm(2")PS, z 25mm(1")PS, Jog x/y 100mm(4")PS, Jog z 50mm(2") PS

Thanks for doing the test.

.............Mike

[bill.young]

Mike,

If you're running the DOS software you don't get the .log files...they're just in the Windows software.

[mikejohn]

Thanks Bill.
I will re-run the file, see how long it takes.

I must get onto a Windows computer!!

...............Mike

[mikejohn]

Hi! folks

So John cut my file on an Alpha in 6 min 5 sec. XY speed 300mm/sec, Z speed 100mm/sec. Jog XY 700mm/sec, Z 300mm/sec.

I cut it on a PRT96 in 10 min 45 sec.
Cut speed x/y 50mm(2")PS, z 25mm(1")PS, Jog x/y 100mm(4")PS, Jog z 50mm(2") PS

Now, although there is no direct correlation between Johns' speeds and time, and my speed and time, it is still a significant saving.
Now, do I buy an Alpha, cut at close to twice the speed and pass on my savings to my customers and increase sales, or keep all the extra profit for myself?


............Mike

[benchmark]

Hi Mike

What version of Shopbot control are you using ?

Paul

[gerald_d]

Mike, John was air cutting. If you want to compare, you both have to cut wood and get similar cut qualities afterwards.

[hespj]

"Now, do I buy an Alpha, cut at close to twice the speed and pass on my savings to my customers and increase sales, or keep all the extra profit for myself?".......Mike J

Mike, I think if your cutting signs such as these you keep your PRT. If your carving rocking horse bodies you get an Alpha (and keep the profit of course - the value of an object is how much people are willing to pay, not how long it takes to make). Although this does depend on the times taken for each machine. Another race cutting a rocking horse body?

[mikejohn]

Paul,
The latest DOS. v.2.19, I think it is.

Gerald,
Are you suggesting the shorter time would be of a lower quality? The only problem for comparisons with this are the many other variables, like bit sharpness and overall Shopbot condition, being discussed elsewhere on this Forum at this time.

John
My comments about profits was a little tongue in cheek

Rocking Horses are in fact hand carved.
If there is any interest, I can post my methods, how the Shopbot and 'hand' methods combine, in another thread if it is of interest to anyone. The method could have uses other than making Rocking Horses.

..............Mike

[benchmark]

Mike

Perhaps you could send me a copy of the file to try on a PRT WINdozer V 3.4.22 for a comparison.



Paul

[stevem]

I'd be willing to try the "speed test" file on a Bot operating under Mach2 control. I would need the CAD file and will convert it to Gcode.

[mikejohn]

Pual, Steve
You have mail.

..........Mike

[benchmark]

Mike

So that we can arrive at an accurate comparison
perhaps I could have the 13 VR values you used on the file.

I was also interested in the font type and what programme you used to create the SBP file.


Paul

[stevem]

I ran Mike’s file to cut air. Run time was 18 minutes. The long run time is totally attributable to the very inefficient tool path generated by VisualMill5.

Total time to generate the tool path was more than 30 minutes. A chat with MecSoft support is in order.

[gerald_d]

I ran Mike's G-Code version of his sign file on our Gecko/Mach "MechMate" and got a time of 7 min 25 sec. Steve should be able to go faster because he has a lighter (shorter) gantry than ours.

[mikejohn]

I now wonder how many different variables there are in determining the speed for cutting, starting from a .dxf file?
The original design?
The machine?
The conversion (toolpath)coding?
The ramp values?
The machine operating software?
The computer running the machine operating software?

What else?

............Mike

[seana]

So if i read Ted's post on PRTalpha/Prt power correctly (posted on April 10th). If you increase the Prt power supply you can cut closer to the high end of the spec's of the PRT?
Can this be done (increase the power supply)? Is it as simple as changeing the power supply?
I have a PRt and just ran into this last week and would like to cut at a little higher speed.

[gerald_d]

Mike, this thread is getting too long (370kB) to load on my dial-up here at home, do you want start a new thread with those questions?

[richards]

Sean,
It may be more complicated than just increasing the power supply voltage. If you visit the Oriental Motor web site, you'll be able to find either the exact motors that you have on your machine, or motors similar to those that you use. Study the torque curve for the motors that you use. Most motors were not designed to have significant torque at Alpha speeds. For instance, the PK299-02 motor that I'm testing has about 800 oz-in of torque at 60 RPM, but only 200 oz-in at 200 RPM when used with a 48VDC power supply. If I changed to the PH299-F4.5B motor, and increased the voltage to 60VDC, I would have 800 oz-in at 400 RPM. To use the F4.5B motor, I would have to have a motor driver that used a parallel connection to the motor, and I would have to use a motor driver that could handle 60VDC.

I have absolutely no knowledge about the drivers Shopbot used on anything except my Alpha machine, but I would guess that you would need to use something like the Gecko G201/G202/G210/G212 series of motor drivers. So, if you added motor drives at about $150-$175 each, motors at about $215 each, a power supply at about $300, and if your controller board is able to send a pulse rate fast enough to move the steppers at a significantly higher speed, you might end up with a faster machine.

Do a search on Gecko, here in the forum. Some users have posted reports of significant speed increases.

[seana]

Thanks, Mike for you detailed response.
I figured that it was a little more complicated then just swapping power supplies.
I will look into all the upgrades that you mentioned later when i get a chance.
Thanks again to all that contrubite to this forum, it has saved my but more then once.

Sean

[dirk]

Sean:
I think the power supply voltage of 48v on the PRT is about as good as it gets. I don’t think the drivers can handle any more voltage. You can check the power supply and adjust the voltage adjustment screw up to get a few more volts. Mine was putting out 44 volts and adjusted to the minimum. I don’t think this will make much difference. When I first started using my PR it came with a 12V supply. Changing to 24V and later to the PRT control at 48 made huge differences in performance. I’ve been testing Geckos and have experimented using up to the max of 75 volts. I expected to get a lot more performance with the higher voltage, but between 50 and 75 volts you may gain 5%. I did notice a good increase in performance changing from a 600Mhz computer to a 1.5Ghz. Also you may check and see if your using ¼ step or 1/8 step on your board. I think the 1/8 step uses a lot more bandwidth and processing. Although I haven’t tested this you may get a higher speed using the ¼ step. I think the bottleneck to higher speeds on the PRT is the step frequency available from the controller. I may try and hook up an alpha controller board to the standard drivers and see what happens, I just don’t want to let the magic smoke out.
Dirk

[stevem]

Mike Gcode inch file generated a time of well over 20 minutes. The arc were being cut as line segments.

The improved VisualMill file reduced the cutting time to 11 min. 48 sec.

[mikejohn]

Steve
I have taken the liberty of reposting your message here (http://www.talkshopbot.com/forum/show.cgi?tpc=312&post=0#POST0) as I think it is also of interest to that thread as well.

.............Mike