Legacy Export for Heidenhain TNC150

[prensel]

Hi there,

I have a Bridgeport Interact CNC mill with Heidenhain TNC150 controller.
I'm trying to work with QCAM export and the only option is for TNC145 which should work (I guess..)
I noticed that not everything is included in the nc file, for example the tool definitions.

How can I add the TOOL DEF and TOOL CALL at the beginning of the exported file ?
Can I create an new export possibility / format for my TNC150 using the TNC145 as a starting point ?

Thanks,

Paul

[andrew]

The "Heidenhain TNC145" post processor should output a "TOOL DEF" and "TOOL CALL" when the tool changes. Tools that are not used are not exported.

If that's not the case, please attach your DXF and NC files.

Can I create an new export possibility / format for my TNC150 using the TNC145 as a starting point ?

Yes, you can create your own post processor based on that file postprocessors/Tnc145.js of your QCAD/CAM installation.

[prensel]

Ok, I just got a little bit further. I used the 'CAM Legacy Export' at first and that did not export the TOOL DEF.

Anyway I'm now using the CAM Export option.

I have now copied Tnc145MM.js to Tnc150MM.js and modified all references from Tnc145 to Tnc150.
Selected the now appearing Tnc150MM option in Application Preferences.

I have also added the [TR] variable to the TOOL DEF part but that doesn not populate the tool diameter/radius, it stays on R+0.000

"[N#] TOOL DEF [T#] L+0,000 R+ [TR]",

[prensel]

Also when using two tools with two toolpaths it doesnt add the 'tool change' lines into the final nc file.
From what other postprocessor can I check how this is done ?

[andrew]

Please attach your current modified post processor file, so we're on the same page, thanks.

[prensel]

Here's my current js file.

It is on Apple Mac, latest QCAD version.

Regarding the tool diameter: I see it is solved in the toolpath by adding the offset in the toolpath and not using the tool diameter as a variable for the mill. The Heidenhain has tool compensation builtin but I understand you do not use it like it is now.

I also noticed that sometimes QCAD is messing up this file and only wants to read the filename and not the declared displayname and does not use the declared values from this file.

I have added the toolpath header with defining and calling the new tool for this path.
Also added the footer to force a toolchange.

It would be better if the tooldeclaration of all the used tools is done once in toolheader and not with every toolchange.
Then in every toolpath header the tool can be called and changed.

[CVH]

I also noticed that sometimes QCAD is messing up this file and only wants to read the filename and not the declared displayname and does not use the declared values from this file.

It is the order of things ... Move line 9-10 to the bottom.
function Tnc150MM overwrites those.

Regards,
CVH

[prensel]

I also noticed that sometimes QCAD is messing up this file and only wants to read the filename and not the declared displayname and does not use the declared values from this file.

It is the order of things ... Move line 9-10 to the bottom.
function Tnc150MM overwrites those.

Regards,
CVH

I had this first but it didn't made a difference.

I also noted then when adding a mill toolpath and a drill toolpath it does strange things.
Look at this snippet of generated nc code on line 18 ?? :

16 CC X+69,860 Y+10,000
17 C X+74,446 Y+8,008 DR+
18 CC X+108,460 X-6,767
19 C X+142,474 DR-
20 CC X+147,060 Y+10,000

[andrew]

Regarding the tool diameter: I see it is solved in the toolpath by adding the offset in the toolpath and not using the tool diameter as a variable for the mill. The Heidenhain has tool compensation builtin but I understand you do not use it like it is now.

Correct. It's possible to use built in tool radius compensation by setting

Code: Select all

this.outputOffsetPath = false;

in the constructor.

However, this is usually more involved and I'd recommend to get started with the built in compensation of QCAD/CAM.

I also noticed that sometimes QCAD is messing up this file and only wants to read the filename and not the declared displayname

This is caused by moving the display name to the top of the file (see attached corrected file).

It would be better if the tooldeclaration of all the used tools is done once in toolheader and not with every toolchange.

You can output a custom header by overwriting the writeHeader function, for example as follows:

Code: Select all

Tnc150MM.prototype.writeHeader = function() {
    // write regular header as defined in this.header variable:
    this.writeBlock("header");

    // backup member variables:
    var tool = this.tool;
    var toolDiameter = this.toolDiameter;
    var toolRadius = this.toolRadius;

    // write list of tools with tool radius
    var toolNames = Cam.getToolNames(this.cadDocument);
    toolNames.sort(Array.alphaNumericalSorter);
    for (var i=0; i<toolNames.length; i++) {
        var toolName = toolNames[i];

        // temporarily overwrite member variables:
        this.tool = toolName;
        this.toolDiameter = Cam.getToolDiameter(this.cadDocument, toolName, 0.0);
        this.toolRadius = this.toolDiameter/2;

        // write tool definition to output file:
        this.writeBlockFromString("[N#] TOOL DEF [T#] L+0,000 R+0,000");
    }

    // restore member variables:
    this.tool = tool;
    this.toolDiameter = toolDiameter;
    this.toolRadius = toolRadius;
};

[prensel]

Okay thanks I have modified the Tnc150MM.js file (attached).

I have created (attached) a simple drawing with an outline mill, inline mill and 4 drill holes as a reference.
I also have created (attached) a list of tools that I can use.
The 3 generated toolpaths:
- first it mills the center hole
- then it drills the 4 corner holes
- and finaly it mills the outer edge.

When exporting nc code (test_nc.nc) suddenly from line 33 it starts littering it with G1 codes while the G1 option is NOT selected ?

[prensel]

Updated Tnc150.js with toolchange location

[CVH]

When exporting nc code (test_nc.nc) suddenly from line 33 it starts littering it with G1 codes while the G1 option is NOT selected ?

Code is exported as text Blocks and none in Tnc150MM.js seem to have standard G-Code ...
... Again it is the order of things.

You based Tnc150MM.js on GCodeBase.js

First GCodeBase.js defines

Code: Select all

    // point moves for drilling:
    this.firstPointMoveZ =           this.firstLinearMoveZ;
    this.pointMoveZ =                this.linearMoveZ;

At that point these linear Z moves where still standard G-Code:

Code: Select all

    // linear Z moves:
    this.firstLinearMoveZ =          "[N] G1 [Z] [F]";
    this.linearMoveZ =               "[N] [Z] [F]";

Later on you overwrite the linear Z moves in Tnc150MM.js:

Code: Select all

    this.linearMoveZ = [
        // move and start spinde in CW rotation, no cooling
        "[N#] L [Z] R0 F[FP#] M03"
    ];

Code: Select all

    this.firstLinearMoveZ = this.linearMoveZ;

You simply have to include specific Z motions for drilling.

Regards,
CVH

[CVH]

Unsure about your trajectory for milling the center hole (Profile 3).
I question the exterior lead in/out ...

Further I detect 6 Toolpaths:
In the above described order that would be:
- Profile 3
- Drill 2
- Profile 4
The other paths don't reflect source entities.

I don't think that 'Normal' Lead In/Out is a good choice for contouring the edge (Profile 4).
You get a motion reversal probably already in contact with the stock material.
And another abrupt motion reversal at the end.

- - - - - -

I usually add short small arc style motions to gradually come in contact with the material.
But then I discovered the QCAD/CAM doesn't allow for entry/exit motions with less than the cutter diameter ... ?

Further I don't understand how that such cutter trajectories (dashed) can have the same start position as the contoured edge (continuously).
I know this trajectory and edge as a spiraling down conical engraving point trajectory where radius increases with depth.
But here both the cutter trajectory and the edge are in a flat plane, where these connect the radius of the cutter should be zero ...
Also see here: https://www.qcad.org/rsforum/viewtopic. ... 724#p44206

Regards,
CVH

[prensel]

You simply have to include specific Z motions for drilling.

Regards,
CVH

Okay I see what you mean.
I didnt think of these 'old' declarations in GCodeBase at first but noticed that when not having a drillpath the G-codes are not there.

So I just added these into Tnc150MM.js and now it seems to work

Code: Select all

 this.firstPointMoveZ =           this.firstLinearMoveZ;
 this.pointMoveZ =                this.linearMoveZ;

I had to adjust these lines also because just using [F] and [FP] did not output the feed and drillfeed values.

Code: Select all

 this.linearMove = [
        // move and start spinde in CW rotation, no cooling
        "[N#] L [X] [Y] R0 F[F#] M03"
    ];
    this.linearMoveZ = [
        // move and start spinde in CW rotation, no cooling
        "[N#] L [Z] R0 F[FP#] M03"
    ];
        
    this.arcCWMove = [
        "[N#] CC X[IA#] Y[JA#]",
        "[N#] C [X] [Y] DR- R0 F[F#] M03"
    ];

[prensel]

Unsure about your trajectory for milling the center hole (Profile 3).
I question the exterior lead in/out ...

Further I detect 6 Toolpaths:
In the above described order that would be:
- Profile 3
- Drill 2
- Profile 4
The other paths don't reflect source entities.

I don't think that 'Normal' Lead In/Out is a good choice for contouring the edge (Profile 4).
You get a motion reversal probably already in contact with the stock material.
And another abrupt motion reversal at the end.

- - - - - -

I usually add short small arc style motions to gradually come in contact with the material.
But then I discovered the QCAD/CAM doesn't allow for entry/exit motions with less than the cutter diameter ... ?

Further I don't understand how that such cutter trajectories (dashed) can have the same start position as the contoured edge (continuously).
I know this trajectory and edge as a spiraling down conical engraving point trajectory where radius increases with depth.
But here both the cutter trajectory and the edge are in a flat plane, where these connect the radius of the cutter should be zero ...
Also see here: https://www.qcad.org/rsforum/viewtopic. ... 724#p44206

Regards,
CVH

I'm just learning how this all (should) work and for now I actually have a working setup, so great success
I can now draw a part in QCAD, export the nc code, import the nc file straight into the Bridgeport and it delivers a physical product

This is a plug for a part I want to cast.

plug01.jpeg (122.36 KiB) Viewed 586 times

The only challenge I have now is how to (easily) draw and build a 3D model from milled flat 18mm MDF plate...