[wonderemporium]

I am running into seemingly random catastrophic errors in 4 axis toolpaths. I'm not sure if it's the toopath as generated or if the post processor is messing with it but I've attached two pictures of the latest example. At first, I thought it was failing to go to safe z between toolpaths but this one happened in the middle of a revolution roughing pass. It was set for pocketing and it looks ok in the simulator. In the simulator it ends at about A=540 degrees. In the G Code it does a rogue roll near the end of the toolpath to -140 degrees without raising the bit so it rips right through the piece as shown in the picture. I paused it, raised the bit and continued and the rest of the toolpath finished properly. Naturally this is a show-stopper so I'm hoping someone has a clue what could cause this. I have the rhino file and the full GCode I could send but it's pretty big so I would probably need to email it.

My post processor is configured as follows...

//MadCAM_POST_PROCESSOR
*VERSION*
4.2_100101
*FILE_NAME*
MachBot_4_axis
*FILE_EXTENSION*
tap
*FILE_DEST*
c:\postfiles\
*FILTER*
0.001
*OUTPUT_WIDTH*
4
*OUTPUT_DECIMALS*
3
*SCALE_1*
1
*SCALE_2*
1
*SCALE_3*
1
*SCALE_4*
1
*SCALE_5*
1
*AXIS_1_CHAR*
X
*AXIS_2_CHAR*
Y
*AXIS_3_CHAR*
Z
*AXIS_4_CHAR*
A
*AXIS_5_CHAR*
B
*CUTTER_REFERENCE*
TIP
*RAPID_FEED*
90
*END_SECTION*
*TOOLCHANGE_TIME*
0.5
*END_SECTION*
*TOOLPATH_OUTPUT*
TRANSFORM
*RAPID*
G01"x""y""z""a" F90
*END_SECTION*
*RAPID_APPROACH*
G01"x""y""z""a" F90
*END_SECTION*
*RAPID_RETRACT*
G01"x""y""z""a" F90
*END_SECTION*
*APPROACH*
G01"x""y""z""a" F"feedz"
*END_SECTION*
*FIRST_CUT*
G01"x""y""z""a" F"feed"
*END_SECTION*
*CUT*
G01"x""y""z""a"
*END_SECTION*
*TOOL_CHANGE*
(Change to Tool "toolname")
G01"zhome"
M6 T0"toolnr" G43 H"toolnr"
M03 S"speed"
*END_SECTION*
*TOOLPATH_CHANGE*
(New Toolpath)
G01"zhome"
*END_SECTION*
*TOOL_STOP*
M5 M9
*END_SECTION*
*PROGRAM_START*
(MachBot_4_Axis Post)
(Rhino Document - "documentname")
(Output Date - "datetime")
*END_SECTION*
*PROGRAM_END*
M06 T00 G49
M30
*END_SECTION*
*LINE_START_NUMBER*
1

[Dan B]

Was this one single path, or did you post multiple layers? (looking at the picture of your controller, I noticed the X exactly at 0) Also, I don't see a *FIRST_MOVE* section in your post. That has me wondering if this was the transition to another path in your concatenated code. That could explain why you didn't see it in the simulation.

If the answer to the above is "single path", I'll need to see the file. You can e-mail it to [email protected]

If the answer is "multiple", than we'll tweak that post a bit but I'll still need the file to test.

Thanks,

Dan

[wonderemporium]

Dan,

This was multiple paths and tools but the error is happening in the revolution rough which uses a 0.500 endmill. The next path is a z level finish using a 0.250 ball mill. The error happens near the end of the revolution rough but not the very end. I do see it doing the bad move as a rapid along with a couple of other rapids before doing the last few regular cuts so I wonder if the lack of a first move section could still be causing the trouble? Any chance first move is used for some other repositioning inside a single tool path?

When I get back to my shop I'll update the post and run it again. I'll also email you the files.

Thanks for your help.

[Dan B]

I wouldn't expect that FIRST_MOVE section would be causing this. That section defines what happens after the toolchange but before the first approach.

Can you repeat it? If you re-program just the roughing and post it individually, will you still get that errant A rotation? I think I would try that (even just to see the code).

If it's happening mid-stream, I think Joakim may need to take a look.

Send me the files still. I want to take a look.

Thanks,

Dan

[wonderemporium]

Dan,

I will send the files shortly but I did a couple of quick tests and came up with something very interesting. I posted again with just the roughing path and the results had the same error. I then added a FIRST_MOVE section to the post and inserted a comment in the GCode "(FIRST_MOVE)" and output again. It turns out that just before the bad move, it does use the first move section...

G01Y3.731A584.998
G01Y3.730A583.391
G01Y3.730A581.784
G01Y3.730A580.177
G01Y3.731A578.570
G01Y3.731A576.963
G01Y3.732A575.356
G01Y3.733A573.749
(FIRST_MOVE)
G01X0.000Y3.734Z0.767A-146.251 F60
G01Z1.192F90
G01Y3.734A-147.827 F90
G01Y3.734A-149.403 F90
G01Y3.734A-150.980 F90
G01Y3.734A-152.556 F90
G01Y3.734A-154.132 F90
G01Y3.735A-155.708 F90


The only other place that comment appeared in the code was where it would be expected at the top of the file before the real first move. This means that I should be able to make a rather dirty fix by adding a move to zhome before the actual move. I'll give that a try and see what happens.

[Dan B]

So it looks like the FIRST_MOVE might be more useful than I thought. Just as a side note, I always like to add a comment in the post so I can see where one path ends and another starts. Here is an example:

*TOOL_CHANGE*
"lnbr" M129 ;TCPM OFF
"lnbr" L C+0 A+0 R0 FMAX M126
"lnbr" TOOL CALL "toolnr" Z S"speed" ;TOOL CHANGE ("toolname")
*END_SECTION*
*TOOLPATH_CHANGE*
"lnbr" M129 ;TCPM OFF
"lnbr" L Z1. FMAX M92
"lnbr" L X324.Y-595. FMAX M92
"lnbr" ;TOOL #"toolnr" CONTINUES
*END_SECTION*

What you don't see in the above sample is that I leave some space so the comments "jump out" at you. Like this:



Dan

[turmite]

Dan, I am about to finally start carving again, after a long and tedious retrofit of my machine. I carve 4 axis and now I am worried after reading two post close together about 4 axis problems and you solving them with a first move. So.....what is a first move section? What does it do, where should it be placed in the post, etc and etc?

Mike

[wonderemporium]

Here is my temporary post processor (Mach 3 - 4 Axis) workaround to get the bit up and out of the way before the random A axis roll that seems to be preceeded by a FIRST_MOVE...

*FIRST_MOVE*
(FIRST_MOVE - modified for MadCAM 5 bug workaround)
G01"zhome"
G01"x""y""a" F"feed"
G01"z" F"feedz"
*END_SECTION*

It's dirty but it seems to be working so far. I'm raising the Z axis to a safe height "zhome" and then moving to the requested X,Y and A, then dropping to the requested Z. This so far has "hopped" over my model before the bad moves I'm getting. I'm just praying that this bug doesn't appear in some other flavor that isn't preceeded by a FIRST_MOVE.

[Dan B]

If I'm understanding correctly, (that is, that the "bug" appeared at the end of one path and the start of another) the FIRST_MOVE section is a permanent solution. Please check your inbox for more information on this.

I'll see if I can explain it a bit better here:

The FIRST_MOVE section was added at my request a couple of years ago to control the tool on our 5-axis Hermle machines. These machines are trunnion style 5-axis machines. What was happening is that the tool had potential to crash with the workpiece after a toolchange, as the workpiece rotated for the first cut. I needed a way in madCAM to replicate what I do in WorkNC which is to move the tool to a safe corner so that the table can rotate without hitting the tool. This is also an issue between paths. Without the FIRST_MOVE section, the path would complete, the tool would sit at the last point, and the table would position for the next cut. The risk of rotating into the waiting tool was too high to take. So Joakim added the FIRST_MOVE section as a permanent solution to these scenarios. I believe that this should be used in every post, especially 4 and 5-axis. I've added it to all of mine and it's been working well.

Mike, I would definitely add it to your post. In Patrick's example above, he has the right idea. I would only suggest, for the sake of efficiency, that these moves be made as rapids, and that the rotation be separated from the positioning. That way you won't get caught approaching the first point in XY while the part is still rotating. Something like this:

*FIRST_MOVE*
G00"zhome" <<<rapid up to your Z home height
G00"a" <<<rotate your workpiece while the tool is in the Z home position
G00"x""y" <<< position to the first point while still at the Z home position
G00"z" <<<rapid down to the clearance height
*END_SECTION*

Don't worry that I rapid to the Z position. The APPROACH section will use the FeedZ value to do the final approach to the first cut. Also, you could position to XY at the home Z height then do the A rotation. That part doesn't really matter which order you use as the tool is clear of the workpiece (if you have defined your Z home value correctly).

Where you place it in the post shouldn't matter. I'll attach a couple of my posts as an example. Unfortunately I don't have a 4-axis proven post as we don't do 4-axis work. I'll attach a 3-axis and a 5-axis post to use as an example. Both of these are proven posts.

Just remember, proceed with caution. Keep in mind that all of the above discussion of 4-axis machining is based off theory. It's not something I do, but I believe the principles from the 5-axis posts should be the same.

Dan

[mcphill]

Both the angles are the same "value" - they are 720 degrees off each other (2 revolutions):

573.749 - 720 = -146.251

There is an option in Mach to reset the A axis every 360 degrees or move continuously. I imagine there would be an option in your post processor to continue from ~574 instead of going to -146 since they are in reality the "exact same spot". Likewise, maybe there is a setting in Mach that can let it know that they values are equal, and not to "unwind" 2 revolutions - just keep on chucking.

Sorry I don't have a precise answer, but that they are EXACTLY 2 revolutions off has to be the root of the problem...

[wonderemporium]

That's a good catch, I didn't notice that. For other reasons, I had been toying with the idea of constraining the system to not go past 360 degrees anyway. If I changed my machine settings to stop it from going past 360, that should stop this although it may be a little less effecient depending on the toolpath.