Aspire PP to wrap Y values around X

[greolt]

I have written an Aspire wrapping PP for those shopbots who have their rotary axis parallel with the X

It is based on the wrapping PP that is provided with Aspire that Randall wrote.

It needs to be tested. Any users with this configuration of rotary, that would be willing to test, PM me.

Greg

[waynelocke]

I would. I just posted to the Aspire forum looking for one.

[eaglesplsh]

FYI... To all using the ShopBot 4th Axis/Indexer PP included in the recent Vectric upgrades:

Yesterday, I emailed Vectric + ShopBot about what I felt was an error/omission in the 4th axis post processor. If you are using this PP or a modified version of this PP you may want to look into this... I believe that SB has an improved version of the PP now - not sure if it's available for download publicly or if you need to call/email to get it.

If you look at the initial feed settings in the Vectric post processor, they do a calculation to convert the given feed rate (used for MY) from ips to degrees per second. This calculated value is used to set the initial MB speed.

This calculation is not repeated when additional cuts are made...(which I believe is a problem)
Say you start with a roughing pass that runs at 6 ips and then you create a finishing pass at 3 ips. Their post will set MY to 6 ips and convert the 6 ips to find the roughing speed in degrees to set up the initial MB speed. When the finishing cut begins, it will set the MY rate to 3ips, __BUT__ the MB rate will still be equal to 6ips - because it was never recalculated/updated (the value from the first cut is still in place.)

This is going to be an even bigger problem if someone tries to modify their post to work with an automatic tool changer and doesn't notice the missing speed change when they switch from a 3/8" cutter to a 1/16" cutter. (I was rewriting the PP for an ATC when I found the problem.)

I'm not trying to slam the folks at Vectric by posting this publicly before they have a chance to verify/respond. I'm very happy with all the great improvements they've made and continue to recommend their products to other CNCers on a regular basis. - Just seemed like timely info to post since Greg started this thread.

[greolt]

That is interesting info Russ

I have insufficient knowledge of the shopbot code to either agree or disagree with your assessment. I use gcode.

The PP in question is one that Randall (a Vectric beta tester) wrote for his own use.

The version which I posted about is simply that same PP, modified to wrap Y values around the rotary and output direction to fit with CNC convention.

I will leave any comment about the rotary axis speed adjustments to Randall.

Greg

[eaglesplsh]

I don't know Randall - and again I'm not trying to blast anyone else or their work. This is just a simple mistake... I spent all day yesterday debugging 25 pages of my own code - PP's, spindle start/stops, tool changes, probing routines, working coordinate offsets, etc.

The PP I was referring to was written by someone named Randall. This may or may not be the same person who wrote the PP that you're using. I've copied the revision history from the PP below, so you can compare it to your own file.

| Who When What
| ====== ========== ========================================
| Tony M 22/06/2005 Written
| Brian M 08/07/2005 Modified to output feed units correctly
| Brian M 14/07/2005 Modified to output 6 d.p
| PACO 15/08/05 Added router control for SB3 Alpha and
| router/spindle RPM dislay/prompt
| Tony 27/06/2006 Added NEW_SEGMENT section
| in case new tool has different
| feedrates to first tool
| Randall 08/10/2009 Added indexer support
| Randall 10/26/2009 Added calculation for rotational feed rate
| Mark 30/10/2009 Renamed file & Post_Name
| Mark M 30/11/2009

[dana_swift]

I have looked into the same problem, and came up with my own PP based on the Vectric one.

My indexer is connected the A axis, so DONT USE THIS POST without modification. My indexer is parallel to the X axis.

For my PP to work Z0 MUST be at the CENTER of the indexer, so Z = Radius. This is an assumption used in the math.

This PP is tested, with the additional correction that as the working radius decreases the linear cut velocity around the indexer remains at the setting specified by the selected tool.

The rotational speed is limited to 720 degrees per second. Use another value if you prefer.

I have run this PP successfully on my alpha indexer, and the values appear to be correct.

I provide no warranty or support as ususal, use at your own risk. It is strongly suggested this file be adapted to your particular installation.

Here is what I am using:


Danas Indexer PP

2897 (4.8 k)

Hope that helps-

D

[eaglesplsh]

Dana wins the prize!

I was looking for a way to do constant velocity machining, like on a CNC lathe. Somehow I didn't think to include the feed rate calculations right in with the move commands. I figured you could only have 1 line of code in those sections.

Thanks for sharing - your genius makes for much better cut files.

Have you talked to SB/Vectric about this yet? I'm sure they would appreciate it.

[greolt]

By convention the rotary axis direction of rotation should follow the right hand rule.

To correct for this use this line,

ROTARY_WRAP_X = "-"

Greg


2898

PS: Would not normal motor tuning parameters take car of the max speed of the rotary? Is this line needed?

"if &AngularFeedRate > 720 then &AngularFeedRate = 720"

Again, I use gcode, so forgive me if I am barking up the wrong tree.

[dana_swift]

Greg, there is NO standard as to which end of the rotary axis gets the motor. It can be mounted either to the near X0 end or at the far end with the tailstock at X0. Either way is just fine and matter of personal preference, use the - sign in the PP to change it to work in your installation.

As the radius approaches zero the RPM attempts to go to infinity. Protection must be provided for both divide by zero and some upper limit for rotation rate. The time it is needed is when a piece is only supported by the chuck, and cutting past zero would attempt to reverse the rotation direction. My note is that is my decision to limit the rotation rate to 720 degrees/sec. Its just a judgment call, and I noted that each user may prefer some other value (or none). Any given cut file may never approach a radius of zero and the protection may be removed. I don't make that assumption. It does not slow down cutting or the time to complete cutting the file.

It doesn't matter if the motion is encoded in gcode, sbp code, or hieroglyphics the math is the same. I have no idea what you are talking about "motor tuning parameters". Is there a PID controller somewhere I could be toying with?

I commend Vectric for making the post processor documentation available so anybody can do it their way. You have seen what I have done, as I said, it is provided "as is".

D

[greolt]

You are right there is NO standard as to which end is the drive or headstock.

But there IS a standard as to the direction of rotation.

The right hand rule concisely describes this standard direction of rotation, no matter which end is the headstock.

That is why any text book that I have ever seen uses the right hand rule as the description method.

If a CNC user wants to have their direction of rotation different to convention then that is fine. They can do whatever they want.

But there IS a conventional direction for all axis travel.

Greg


2899

[greolt]

"It doesn't matter if the motion is encoded in gcode, sbp code, or hieroglyphics the math is the same"

I use gcode and Mach3 as my controller.

Mach3 has motor tuning parameters for each motor. Steps per unit, Max velocity and acceleration.

These are not set in gcode. They are pre set in the Mach program.

When ever any feedrate is called for in gcode, Mach will not allow a motor to exceed those pre set parameters.

I just assumed this was fairly standard method and Shopbot would be much the same. I guess I was wrong.


Greg

[eaglesplsh]

I updated my own PP with help from Dana's code - works great!

After a bunch of trial and error I found that you don't need to include the MB rate calculations in the "header" section, "feed move" section, or the "new segment" section. This calculation only needs to be done in the "first feed move" section - which is used to create the first M5 command after every Z height change.

Cutting out all the extra calculations could be important to the quality of your final cut and may drastically decrease your cut file size.

Arc cuts aren't implemented in the 4th axis, so anytime you're cutting along a curve you're cutting lots of short vector segments. The control software doesn't seem to like recalculating the feed rate after every 0.005" move - when I tried pocketing out a circle at 5 ips on the 4th axis I got stuttering slow speed moves - even though I have a new Alpha machine running on a 1 yr old computer.

As soon as I trimmed out all the extra calculations my curved movements went back to being smooth and ran at full speed.

[greolt]

Russ

I tried a simple file with Dana's PP and this is just a small section from it,

M5,,-0.3656,0.9500,-54.1241
if 0.9500 > 0 then &AngularFeedRate=(180*0.6)/(3.14159*0.9500)
if &AngularFeedRate > 720 then &AngularFeedRate = 720
VS,,,&AngularFeedRate
M5,,-0.3487,0.9500,-54.4919
if 0.9500 > 0 then &AngularFeedRate=(180*0.6)/(3.14159*0.9500)
if &AngularFeedRate > 720 then &AngularFeedRate = 720
VS,,,&AngularFeedRate
M5,,-0.3318,0.9500,-54.8412
if 0.9500 > 0 then &AngularFeedRate=(180*0.6)/(3.14159*0.9500)
if &AngularFeedRate > 720 then &AngularFeedRate = 720
VS,,,&AngularFeedRate
M5,,-0.3149,0.9500,-55.1719
if 0.9500 > 0 then &AngularFeedRate=(180*0.6)/(3.14159*0.9500)
if &AngularFeedRate > 720 then &AngularFeedRate = 720
VS,,,&AngularFeedRate

It continues like that for the whole code.

Can we take a peek at your new PP?

Greg

[dana_swift]

Russ thanks for the experiment, I will update my PP. I had wondered about whether the speed code was needed after every line or just some of them, and so I did what would amount to a "belt and suspenders" approach. Overkill apparently!

One of the great things about the forum is the collaboration. This PP is just getting better all the time.

Thanks Russ and Greg.

Greg- FYI, SB3 does not have tweaks on motor parameters so the test is necessary. I wish it had real acceleration limit terms in "G's" so I could limit accelerations based on the mass of the load on the table and the torque capabilities of the motors. As it is, its a meaningless "ramp value". So much for all those physics classes eh?

D

[rcnewcomb]

Russ,
Good catch about my post processor not handling subsequent speed changes. I always run my toolpaths in separate files so I didn't catch that in my testing.

[eaglesplsh]

I'm happy to share my 4th Axis PP, which now includes Dana's constant velocity machining code, etc... in case it helps others to improve their own code.

WARNING: DO NOT TRY TO USE THIS PP ON YOUR MACHINE!!!

My PP is loaded with stuff that isn't relevant to your setup. I use it to control: Auto Tool Changer, dust collector on/off, dust collector blast gate open/close, installation/removal of the dust shoe, vacuum hold down on/off, automatic changes to the working coordinate offsets, and some other fun stuff. This code will cause error messages for the rest of you and may attempt to physically run your gantry off the table. Consider yourselves warned!


Most of my custom code is in the header/footer sections of the file. The part that relates to this discussion is:

begin FIRST_FEED_MOVE

"'UPDATE FEED RATE FOR CONSTANT VELOCITY MACHINING IN B-AXIS"
"if [Z] > 0 then &AngularFeedRate=(180*[FC])/(3.14159*[Z])"
"if &AngularFeedRate > 720 then &AngularFeedRate = 720"
"MS ,,,&AngularFeedRate"
"M5 ,[Y],[Z],,[X]"

Thanks to Greg, I added the ROTARY_WRAP_X = "-" at the beginning to match my rotation direction with standard convention.

I use working offsets to temporarily setup the center of my 4th axis location at 0,0,0. You'll find a few places in the PP that include:

"JX %(1) + 4

[eaglesplsh]

Thought I'd add an update to this thread for anyone who's following along...

I tried running a 3D file that was tool pathed in PartWorks 3D and then imported into PartWorks 2D on the indexer... it doesn't look like the constant velocity machining technique discussed above will work in this case. There are many Z moves that happen without calling for "first feed move" treatment.

3D machining is so slow that it probably doesn't make a whole lot of difference, but I thought folks should be aware of the issue anyway.

[rcnewcomb]

Russ,
Can you post photos of some of your work? I'd love to see what others are doing.