Heidenhain question

Off and on for half a year I have been running a new milling machine (2006) with the Heidenhain 320 controller.
Sometimes via CAM (Edgecam) , most of the time using the controller itself.
So far so good.

Recently I started trying some more complicated , large CAM programs.
Problem is the machine `dwells` independant of feedrate , just like it can`t keep up.
Resulting in poor surface finish.
Adjusting the feedpot doesn`t do any good.

I`m guessing the programs are just too big to be running smoothly , lack of memory ?
(is has 10 MB storage and a 400 MHz Celeron processor )

Any suggestions ?

For sure it's not lack of memory or that your programs are too big.

I'm guessing that you're posting your code without radius comp (R0), so the control does a exact stop at every point.

The TNC320 doesn't have the advanced features for dealing with small contours like the TNC530.

So here are a few things to try, post the progam with radius comp (RR/RL), manually put RR/RL into the program and set tool R to 0, with RR/RL on use the M120 look ahead.

Hi

What you are suffering from sounds like the symtems of 'data starvation'
which can occur due to 2 causes

1. comm speed is not fast enough to deliver the data to the machine via a DNC link (not your problem)

Or 2

The machine cannot process the required block move in time for the move to be smooth, so calculates the move, moves the axis, then calculates the next move, of course stopping when it does the calculation.

The way to avoid it is for you to output the CNC code from edgecam as a series of straight line moves only without rad compensation, so instead of say:

CC X+65.456 Y-98.56
C X+54.56 Y-123.345 DR+ RL F2341 M3

it converts each arc into a series of straight lines, However.
This vastly increases the size of the programs.

Another trick to do is this, instead of having a block format like this for every line :

L X-98.345 Y-52.123 RL F2345 M

do this instead :

L X-98.345 Y-52.123

and only add the feedrate/compensation commands when you have to.

Boris

<<<an ex-spurt

Could this be due to settings in the machine parameters? I have a much earlier Heidenhain control, there is a parameter for continuous velocity machining which enables the look ahead. In a CAM generated program that has lots of small moves with small angles between them, this parameter needs to be set correctly or you will get a move stop at each block. Once set up properly it should cut continuously without any dwell between blocks. Even in the '80s, computers were faster than machines.

Took a closer look at the original program today which had lots of blocks like this :

L X-98.345 Y-52.123
L X-98.678 Y-52.543
L X-98.953 Y-52.....ETC

Since this was the `shakey` program I figure my post is setup for too big a step when doing a circle in straight-line increments.

Some more experimenting resulted in this :
(same basic geometry , only changing the way radii were produced and using/not using M120)

CC X+65.456 Y-98.56
C X+54.56 Y-123.345 DR+
L X-98.345 Y-52.123

- this CAM output gave the best results , lots less `shaking` but still no completly smooth movements. (when watching it)
No radiuscompensation (R0)
This program was aproximately 1/3 size of the original.


L X-98.345 Y-52.123 RL M120 LA5
L X-98.678 Y-52.543
L X-98.953 Y-52.....etc.

- I put in the RL & M120 manually , interestingly it took shorter to run
Still shakey.


L X+65.400 Y-98.00 RL M120 LA5
CC X+65.456 Y-98.56
C X+54.56 Y-123.345 DR+
L X-98.345 Y-52.123

-This was an interesting combination , resulting in quite random Z moves , fortunately no crashes.


It seems shrinking the program by letting the control interpolate circles is helpful.
Still not quite there tough.

Adding an M120 got me funny results , it seems the farther I got it to look ahead the funkier the Z moves became.
50 lines ahead got the strangest results , 5 or so still yielded Z moves , a lot less tough.
Any tips on `the` useful amount of look ahead ?

All I can think of now is getting the post edited to doing circles in smaller increments.
Or checking the parameter that Swarft_Rat mentioned.
Thoughts ?

Are you using the actual tool radius in your tool table (R) or are you using 0?

I would try running with RL, with circle path and no look ahead.

L X+65.400 Y-98.00 RL
CC X+65.456 Y-98.56
C X+54.56 Y-123.345 DR+
L X-98.345 Y-52.123

Only thing I can think is that your tool radius (R) is set to 0 and using M120 causes the control to miss calculate.

Who is the maker of your machine?

Yes , toolradius was set to 0 and combined with M120 , like you suggested.
And boy , did it miscalculate it`s pants off.

Didn`t try running with manually placed RL and no look ahead , will give it a try tomorrow.
Thanks.

The machine is a Kunzmann toolroom-type mill.
I learned a new way to make the contoller puke today : large filenames
Overall it`s a nice machine tough .
Most suited for onesey-twosey projects.

@swarf_rat
I'm having the same problem, what machine parameter are you talking about??
Im lost in parameters and all of them seem the same thing, please help

swarf_rat said:

Could this be due to settings in the machine parameters? I have a much earlier Heidenhain control, there is a parameter for continuous velocity machining which enables the look ahead. In a CAM generated program that has lots of small moves with small angles between them, this parameter needs to be set correctly or you will get a move stop at each block. Once set up properly it should cut continuously without any dwell between blocks. Even in the '80s, computers were faster than machines.

Click to expand...

What parameter are you talking about?? Please help me I think im having a problem with that parameter

Cycle 326, search your help file

5 axis Fidia guy said:

Cycle 326, search your help file

Click to expand...

What do you mean by cycle 326, are you talking about an MP parameter? i cant find that cycle anywhere, I think im misunderstanding your phrase...

There is a cycle 326 and cycle 32 to adjust machining parameters. Tolerance and acceleration etc..