UCCNC Turn Problems

[andrej]

Yea, that makes two of us. I installed Mach3 demo, and yes I can see the arcs are all wrong there no matter if I use Mach3 or LinuxCNC postprocessor... not sure what else to try.

What CAM and postprocessor did you use to test UCCNC Lathe functionality?

[andrej]

OK, so another update. I changed the Linux CNC PP to output X axis coordinates in G8 Radius mode rather than G7 Diameter mode. Changed a line at the beginning of the file which tells the software to change to G7 so that UCCNC remains in G8 mode.

If anyone wants to try it is line 227 in the current version of the PP, look for

Code: Select all

var xFormat = createFormat({decimals:(unit == MM ? 3 : 4), forceDecimal:true, scale:1}); // 1 - Radius mode, 2 - diameter mode

I was playing with gcode generated by grbl turn postprocessor. There I found out that if I opened the file in G7 mode it was all broken, but with G8 it loaded correctly. So I tried it with Linux CNC and it worked, atleast in software. Need to try it on actual lathe later but so far it looks promising.

Now the toolpath looks OK!!!

Any insight into this @uccnc please? Do you maybe have a sample gcode toolpath which uses G7?

[andrej]

Seems to work fine on lathe too now.

On the left G8 good looking toolpath (and part). On the right the toolpath with bad arc.

[cncdrive]

I think (just figuring) that UCCNC starts in G8 mode and LinuxCNC lathe mode probably starts in G7 mode.
Then if the generated g-code movements are calculated in G7, but if the post does not put a G7 at the beginning of the g-code file then the file opens and reads in G8, so then the toolpath will be wrong.

The solution is to force the post processor to put G7 or G8 (depending on which one the CAM program is using) in the beginning of the g-code files.

[andrej]

The postprocessor puts G7 at the beginning of the code by default. But it opens damaged. Even when UCCNC is set to G7 after start via MDI.
After changing postprocessor output to G8 and replacing beginning of code with G8 it opens fine.
I tried all possible combinations I think... UCCNC in G7 or G8 mode, open file with G7 or G8 or nothing at all. Only the above combination seems to work fine.

If you want you can download my modified PP for F360 from https://github.com/raenji-sk/LinuxCNC_PP_UCCNC_Turn and compare the result with the one in Autodesk F360 official library.

[cncdrive]

Hmm, can you post the G7 and also the G8 version of the same job?
Then I will check to see what's wrong.

[andrej]

I added the files to my github account so you can get them from there https://github.com/raenji-sk/LinuxCNC_PP_UCCNC_Turn/tree/main/CNCDriveTest
https://github.com/raenji-sk/LinuxCNC_PP_UCCNC_Turn/blob/main/CNCDriveTest/LudoFigure_Lathe_G7.ngc
https://github.com/raenji-sk/LinuxCNC_PP_UCCNC_Turn/blob/main/CNCDriveTest/LudoFigure_Lathe_G8.ngc

[Joachim]

Hello guys,

Funny I was also working on HSM post pro, you could try mine
I modified G7,G8,G28,G53,G76 radius mode and diameter mode, options have to be set before post.
G7 is buggy with G2/G3

Most of the code is from Linuxcnc Lathe PP.

Let me know bugs, I'm only in demo mode in UCCNC

https://github.com/JoachimF/UCCNC-Lathe-HSM-PP

[Joachim]

Messages are moderated ?

[cncdrive]

OK, I figured the problem. And no, G7 is not "buggy" with G2/3 in UCCNC.
In UCCNC G7 I parameter is also required in radius mode and your post processor outputs I in diameter mode.
This can be clearly seen from your example codes because the I parameter is the same in both of your G7 and G8 codes of the same job.
Can you change your post processor to output the I parameter in radius mode if G7 is active?
This means that the I parameter has to be multiplied by 2 all the time when G7 is active.