#57 Error when loading output file into AXIS: Cannot turn cutter radius compensation when (it is) on

[Anonymous]

Originally created by: inner.bushman (code.google.com)
Originally owned by: christian.kohloeffel (code.google.com)

What steps will reproduce the problem?
1.Load file from attachment,
2.Enable cutter compensation for ANY shape,
3.Optimize & Export as usual

What is the expected output? What do you see instead?
Expected g-code for the shapes, with cutter compensation.
Get error on file open in LinuxCNC AXIS. Screenshot in attachment.

What version of the product are you using? On what operating system?
Version:
PyQt4 Beta: $Rev:: 549 $
Last change: $Date:: 2015-02-04 13:44:52#$
Changed by: $Author:: Christian Kohlöffel $

OS: Ubuntu 14.04

Please provide any additional information below.
After inspecting the output file you can see SOME of the shapes have duplicated compensation gcode for each pass after going down on Z.
The most shocking part is the gcodes are OPPOSITE!
When first pass has the intended G41 the seccond pass has G42 and third has G41 again.

Files in attachments are containing the problematic shapes only. Other shapes stripped for clarity. Please let me know if you need me to provide more information

Thanks in advance,
Wojtek

[Anonymous]

Originally posted by: christian.kohloeffel (code.google.com)

Hi Wojtek,

i just checked the ngc file but i do not find any Problem at the line 622. Where do you see the above explained issue. The attached error message may mot lead me to the correct line.

However if you have a open shape this is milled with G41, G42, G41 etc if there is more then one pass to reach the defined depth.

I think this is a Topic of LINUXCNC or the combination of lead in radius and tool Diameter. Which Parameters Did you use. Also please check the following link for more Details:

http://linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/27013-cutter-compensation-problem

regards
Christian

Owner: christian.kohloeffel
Status: Started

[Anonymous]

Originally posted by: inner.bushman (code.google.com)

Hi Christian,

indeed the error is in different spot now. Probably after i've stripped the shapes the new shapes order caused it to land somewhere else.
According to my linuxCNC the line causing the problem in the uploaded file is 1167.
It's nothing more than G41 (invoked after initial G42 and some moves).
And yes, you are right. The shapes are open. I've noticed it few days later trying to work it around somehow by offsetting the affected shapes in my CAD, that's when i've spotted gaps. I will investigate the compensation behavior on some primitives to see what else i can make of it and if i find something useful to either this project or LinuxCNC itself, i'll let you know.

Thanks again for the reply,
Wojtek

PS: i will be posting another issue about compensation on closed shapes :(

[InnerBushman]

Hi Christian,
I've solved the issue with open shapes compensation and i'd like you to add it to your code. The solution is in fact REALLY simple:

Add G40 before each new G41/42 call.

I've modified the output from DXF2GCODE by just adding those G40s before each new G41/42 call and the code works like a charm.

Thanks in advance,
Wojtek.

[chrisko]

Hi Wojtek,

I think this option is already implemented. Try the following in the Section General:
cancel_cc_for_depth = True

For more options refer to:
https://sourceforge.net/p/dxf2gcode/wiki/PostprocessorConfiguration/

please give feedback if that worked for you.

regards
Christian

[InnerBushman]

Thanks for the reply. I've tried the mentioned option and it in fact adds G40 but in a wrong (for this issue) place. Canceling it before going down on Z breaks things cause then the move on Z is treated as "exit move" and next move is treated as "new entry move" causing unexpected path to be interpolated by the interpreter.
It is vital to invoke both commands one after another without making any move, otherwise things get broken.

This gives proper results:
...
G1 X 20.000000 Y 10.000000
G1 X 10.000000 Y 10.000000
G1 Z -2.000000
G40
G42
G1 X 10.000000 Y 10.000000
...

This is the output with mentioned option set to True and it breaks things:
...
G1 X 20.000000 Y 10.000000
G1 X 10.000000 Y 10.000000
G40
G1 Z -2.000000
G42
G1 X 10.000000 Y 10.000000
...

I'm not sure of the purpose of this option. I'm sure it might be useful in other brand g-code interpreters which expect the G41/42 to be disabled during Z moves. But since you are working on integrating it with linuxCNC it would be good to follow their way of thinking (which i must add, makes sense to me).

Please let me know if you can change the existing or add another option to make it work as presented.

Cheers,
Wojtek

[chrisko]

Hi Wojtek,

is already wanted to start coding, but I think I found a faster and also working way of implementing that.

Try to change the following in the prostprocessor:
[Program]
cutter_comp_left = G40%nl G41%nl
cutter_comp_right = G40%nl G42%nl

I'm very sure this meets your needs :-) ...

[InnerBushman]

Yes, it's a dirty hack but it does work for open shapes :D
Thanks, i'll use that for now ;]

[InnerBushman]

Christian, I think there's no point in trying to fix it any other way right now.
Should we push this fix?

[J-P]

Hiya,
I thought this is a very nasty fix. So I changed it in the new 3d version to what you really want - if it's on and you switch direction simply turn it off first.

In the weekend I will start a new topic about the 3d version - in the forum. Where I also want to start the discussion if we should keep on supporting the "2d" version. If so it means I will apply all my fixes to that version as well.

[InnerBushman]

That sounds great! I'll be waiting for the forum thread about the 3D version cause i have trouble running it. It seems that Debian 8 has slightly older version of Qt5 libraries in their repositories than what you have used for the 3D version.
I hope you will be able to help me out with this.

Cheers,
Bushman