[jeanyes]

I just added a 4th Axis to my Shop Sabre CNC machine. I need some help getting MadCAM/post processor setup up correctly. I was able to get MadCam set up so that it would generate what looks like a good toolpath as well as the simulator looks like it's doing what it should. The problem is that when I generate the G-Code it is not rotating the 4th axis. It puts a value of "W0.0000" on every line. The value should be somewhere between 0 and 360. Here's a sample of the first few lines of output:

G80 G90
M3
G0 X0.0000 Y7.7832 W0.0000
G0Z3.0825
G0Z3.0625
G1 Z3.0000 F" "a" feed"
Y7.7883 Z2.9954 F W0.0000 200
Y7.7936 Z2.9899 W0.0000
Y7.7981 Z2.9844 W0.0000
Y7.8018 Z2.9789 W0.0000
Y7.8046 Z2.9735 W0.0000
Y7.8067 Z2.9681 W0.0000
Y7.8078 Z2.9627 W0.0000

I have it set up for simultaneous 4-axis output, I have not tried indexed output to see if that works instead. Any ideas?

[Dan B]

Please attach your post-processor. I can see right away from the posted code that you have errors. Look at the line starting with G1.

Do you have any samples of good code (from a manual perhaps?) Is your 4th axis really W axis?

Thanks,

Dan

[jeanyes]

Dan,

I did notice the error in the line starting with G1. What I posted is the default 4axis file that comes with Madcam. Here's the post-processor with the error fixed that I have been trying since I last posted. I do not have a sample of good code but my 4th axis really is W. If I type W180 into WinCNC (which controls my Shop Sabre) then my 4th axis rotates 180 degrees. Here's the file:

//MadCAM_POST_2003-12-10
*VERSION*
1.0_031210
*FILE_NAME*
Shop Sabre 4-axis
*FILE_EXTENSION*
tap
*FILE_DEST*
c:\postfiles\
*FILTER*
0.005
*OUTPUT_WIDTH*
4
*OUTPUT_DECIMALS*
4
*SCALE_X*
1
*SCALE_Y*
1
*SCALE_Z*
1
*AXIS_1_CHAR*
X
*AXIS_2_CHAR*
Y
*AXIS_3_CHAR*
Z
*AXIS_4_CHAR*
W
*CUTTER_REFERENCE*
TIP
*TOOLPATH_OUTPUT*
TRANSFORM
*RAPID_FEED*
800
*TOOLCHANGE_TIME*
0.3
*RAPID*
G0 "x" "y" "z" "a"
*END_SECTION*
*RAPID_APPROACH*
G0"x" "y" "z" "a"
*END_SECTION*
*RAPID_RETRACT*
G0 "x" "y" "z" "a"
*END_SECTION*
*APPROACH*
G1 "x" "y" "z" "a" F"feed"
*END_SECTION*
*FIRST_CUT*
"x" "y" "z" "a" F"feed"
*END_SECTION*
*CUT*
"x" "y" "z" "a"
*END_SECTION*
*TOOL_CHANGE*
M3
G4X14
*END_SECTION*
*TOOL_STOP*
M5
*END_SECTION*
*PROGRAM_START*
G80 G90
*END_SECTION*
*PROGRAM_END*
*END_SECTION*
*LINE_START_NUMBER*
0

[Dan B]

madCAM 5.0, correct?

What is your syntax for spindle speed? That's not in your post.

Can you give me a sample of your old (3-axis) code? The beginning and end is all I need.

Also, do you want control of the coolant?

Dan

[jeanyes]

Yeah, MadCAM 5.0

I'm not sure on the syntax for spindle speed. Unfortunately Shop Sabre is closed today. I do not use coolant. Here's the beginning and end of some 3-axis code:

G80 G90
M3
G4X14
G1 X25.4376 Y77.1840 F800
G1Z0.5000 F800
G1 Z0.0147 F200
X25.4708 Y77.1559 Z-0.0288 F200
X25.4739 Y77.4710 Z-0.0300
......
......
Y82.1606
X4.3485 Y82.2110 Z-1.5201
X4.3514 Y82.2583 Z-1.5300
G0 Z-0.5150
G0 Z0.5000
M5

[jeanyes]

I don't know if this will help, but these are the lines I had to add to my Wincnc.ini file:

[W Axis]
axisspec=p0 s3 d7 r500 a400 k3
axisvel=r300 f300 s50 m200 h300.

[Dan B]

I don't know anything about this machine, so the wincnc.ini file is Greek to me. I would guess it's a configuration file, and that it is controlling the spindle speed.

Take a look at the attached post. It should work for you. I approached the first move with an X and Y move, then positioned the W then bring the spindle down. This is a shot in the dark, but I think that's a safe way to do it. If not, you can adjust the *FIRST_MOVE* section to suit your needs.

Be careful the first time. Writing a post without access to samples of good code and/or access to the machine can be risky.

Let me know how it works,

Dan

[jeanyes]

Dan,

Thank you! This does generate values for W! I'm going to put your post file next to the original to see exactly what you did. I owe you!

This leads me to the next obstacle which is more of a pure madCAM question. For this particular job I am at the absolute maximum diameter that my machine can handle. I simply don't have any more z-height room. I thought by setting the "Traverse-Safe Clearance" to .0625" would keep the bit from ever traveling more than .0625" above my piece height. But when I generate the toolpaths there are traverses that do go well above this .0625" which would cause me to hit my soft limits during a cut. Is there another setting somewhere I'm not aware of? Here's a screen shot of a the roughing toolpath so that you can clearly see traverses greater than .0625"

Attachment 191088

[Dan B]

What happens if you put the clearance value really small, say .010"? Would your .7992" value change?

[jeanyes]

It lowered the highest traverse from .7992" to .6417" - still too high for my machine. I really need it to not move more than .125" above the surface. To get the .6417" to work for me I would need to lower my 4-axis setup by removing the plenum for my vacuum table and bolt the 4-axis chuck directly to my frame. Not impossible, but certainly a lot more work than I would like. Or I could manually edit the traverse curves in rhino which again would just be too much work.

[Dan B]

Unfortunately I can't think of any other setting that could help. I'll keep digging though. Any chance of posting the file to play with?

Dan

[jeanyes]

Dan,

The design in the file I'm working on does not belong to me. I've created a very simple example with the same diameter of final product along with a stock model of the same diameter as what I'm using. This sample file exhibits the exact same issue. I've left the roughing toolpath in the file for you to see but of course you can generate it yourself. Below is a link to the sample file:

http://www.onestop3dshop.com/share/4...se_problem.3dm

[jeanyes]

Update: I've been experimenting and realized that the problem does not happen with FLAT end mills. Ball mills are where the problem occurs. Not sure about the other types of mills. This is actually good news for me because I can make a flat end mill work if I have to. The Z-level finishing won't be ideal but still workable.

[jeanyes]

Update2: Actually, it does happen with flat end mills as well. What type of tool path you are generating is a factor. Roughing leads to the worst case of traverse heights going higher than they should. Zlevels did not go higher than it should. Planar went higher than it should have but not near as bad as roughing. Pencil tracing is about like planar.

If I can't get this worked out within a day or two I'm thinking I may just have to find an editor that will go in and take all z values greater than 3.125" and replace them with exactly 3.125" Or something like that...

Or if indexed 4-axis works for more than 90degree increments I may be able to try that. 90degree won't work for me because I don't have enough carving depth. but if I go only 45degrees and limit how deep I go it may be able to hit everything. I guess even if it doesn't support that I could just generate a series of 3axis tool paths and manually rotate between each tool path...

edit: Even Zlevels will traverse too high. I'm not sure what is changing but when I went back to generate a zlevels path again it had same issue as others. I did not change any zlevel settings, I had just been generating other types of toolpaths trying different settings.

[Dan B]

Are you posting code and seeing these values above 3.125" or are you basing it only on what you see in the simulator?

The reason I ask that is to determine where the problem may lie. If your toolpaths in the simulator are using a ballnose cutter, your measurement that you provided is from the center of the tool radius, but it will post from the tip. Depending on the radius you used, it may appear to be a problem. Take a look at this illustration. It's not exactly the same, but the principle of displayed vs posted is the same. The post will provide values calculated from the tangent points of the ballnose tip:



I'm more or less just thinking out loud. I have your file now so I will experiment when I get a chance.

Dan

[jeanyes]

Yes, I am posting code and seeing the values above 3.125"

Yeah, it always bugs me that Ball nose cutters always show the lines above the actual cut depth. Is there a way to change this?

I have a programmer friend that was able to write a simple expression that goes into my g-code files and sets all z values above 3.125" to exactly 3.125" so I at least have a work around. It would be nice to get this figured out though. I have a feeling it's out of our hands... going to be something Joakim has to look into.

[Dan B]

We experimented with showing the toolpaths at the tool tip for all tools about 4 years ago but this lead to other issues. For example, it's very easy to use the wrong style tool and not notice it because all tools display from the tip. That's what we found when we worked with an early beta. Maybe other's experience differs, but there hasn't been much discussion about changing it. Some programs have an option to let the user select their preference, so maybe that could be something to think about for a future release.

I've looked at your sample file for a while now, and I don't have a solution. I'll leave this one for the bigger brains to figure out!

Dan

[jeanyes]

Dan,

I really appreciate your help with this. Getting the post processor fixed for me was a great help. Joakim should replace the current one with this.

Should I send an email directly to Joakim for this or should I assume he'll see this here?

Thanks again,
Jean

[Dan B]

I would expect that a lot of posts that ship with madCAM could benefit from the *FIRST_MOVE* section. It was a later addition which is probably missing from any older posts. However you could probably say the same thing about coolant, fixture offsets, tool length offset, box top clearance etc. I think it's important that madCAM users read the section on post-processor configuration to see if there are any sections that they aren't using but should be.

I don't mind helping people with their posts. If someone took a look at the help file, found a feature they want hooked up, and attached their current post, I would be happy to make the change. It only takes a few minutes when you understand how the post works.

What might work well is if there was a repository for madCAM posts on the madCAM website. Then users with good quality posts could upload them for others. Of course there would need to be a disclaimer in case of malicious intent (posts that don't work). It would be up to the user to test (air cuts) until they know the posts are good. It also could be a valuable resource just as a reference for people creating their own posts.

Just thinking out loud again. In the meantime, if you want to drop Joakim a note referencing this discussion, I'm sure at the very least he will replace the old post with my new version.

Dan