[mflux_gamblej]

I managed to get a program running on the machine over DNCX at cd, 10 baud rate.

I am running trochoidal toolpaths similar to volumill, or imachining and have run into an issue where the error 'helical raduis too small' or something similar appears. In the fadal manuals it is suggested that a helix with a steep z (thanks to fadal for actually giving some numbers?) may cause this issue, or that the feed rate may be too high.

I read in one of the manuals that the fadal max cutting feed rate is 400 ipm, max rapid is 700 ipm (this can be even faster if feed override is set to 150%). I am wondering if those specs apply to the 1993 (1400-4 cpu, cnc88) machine that I have. The control will actually run at 400 ipm in the programs, but it moves seemingly faster than a normal rapid set to 100%, and when coming to a stop it does not decelerate graciously. Anyone know the specs for my 1993 machine?

I will try slowing down the max feeds. Trochoidal paths always cut, then reposition rapidly, then cut, and repeat. the machine flies fast through the program until I setup a path with small radii. The line that will cause the machine to throw the error is one like:

N288 G01 X2.1886 Y-0.7952
N290 G03 X2.192 Y-0.8039 Z-0.108 I0.0062 J-0.0026
N292 G01 X2.2063 Y-0.8103 F400.

where the previous z value was 3 thou lower (this is a helix exit, then 'rapid' movement) even tho the rapid is just force programmed rather than issuing a G00.


I'll keep working on the helical radius error message thing. The next thing that is bugging me is the fairly ugly banging caused by very fast accel / decel. There is a G51 R-1.0 code that can be used to set the accelerations. the -1.0 means x,y set to normal accel / decel. a smaller than 1 number means faster, and a larger than 1 number means slower.

I am wondering if anyone uses these codes to slow down accel/decel in trochoidal paths to try and get rid of the nasty banging. I've read some arguments about how the banging isnt really that bad on the machine, but I don't think what I've read is right. It seems very rough on the machine and I need this mill to last me as long as possible (notice I bought a 1993, in 2013).

Too bad fadal doesn't allow access to 'machine parameters' the same way a heidenhain or fanuc does (as far as I know)...


So far I am very happy with my 'new' VMC. Lots to learn still, but I definately want to solve this trochoidal paths issue since thats the kind of machining needed to stay competitive these days.

[mflux_gamblej]

I just tried with max feed set to 150 ipm and got the same error in the same place as I have been getting.

N248 G01 X2.2067 Y-0.8267 F150.
N250 G03 X2.2157 Y-0.8183 Z-0.11 I0.0006 J0.0084 F46.
N252 G01 Y-0.8131 F69.
N254 G03 X2.2133 Y-0.8028 I-0.0264 J-0.0007 F47.
N256 G01 X2.2127 Y-0.802 F51.
N258 X2.2096 Y-0.7983 F46.
N260 G03 X2.1913 Y-0.793 I-0.0143 J-0.0152
N262 X2.1897 Y-0.7938 I0.0006 J-0.0033 F58.
N264 G01 X2.1894 Y-0.7941 F89.
N266 X2.1886 Y-0.7953
N268 G02 X2.183 Y-0.8072 I-0.1378 J0.0573
N270 G03 X2.1889 Y-0.8185 Z-0.107 I0.0069 J-0.0036
N272 G01 X2.207 Y-0.8208 F150.

error happens at line 270. As far as I can caluclate, the radius is huge!

line 266 to 268

i j x y
2.1886 -0.7953 start
-0.1378 0.0573 2.1183 -0.8072 new ending pos
-0.0703 -0.0119 change

-2.2561 0.8645 x,y components of radius
2.416060318 radius of arc (distance from center to either start or end position)



line 268 to 270

i j x y
2.1183 -0.8072 start
0.0069 -0.0036 2.1889 -0.8185 new ending pos
0.0706 -0.0113 change
0.071498601 approx (linear) distance traversed


-2.182 0.8149 x,y components of radius
2.32920287 radius of arc (distance from center to either start or end position)
0.003 change in z height


so the radius is over 2", and the move is about 0.07" That seems like its plenty big. my old bridgeport with a heidenhain never blorked at me about a move like this. The feed rate is pretty high?? (i need some help from someone on that opinion) at 89 IPM during the helix?

[mflux_gamblej]

I found that decreasing the feed rate during the operation will allow the control to perform some of these small helical moves, but I tried many different feed rate maximums and no value cures the problem fully. I also went and modified my post so that any time a 0.003" helical entry is performed, the feed would be set to (max feed of my choice).

This didn't solve it either.

This is quite frustrating for me since my very old heidenhain could deal with this issue. below is the exerpt from a fadal manual:

Helical Move Too Short, N =
(See error message HELICAL RISE TOO STEEP)
Helical Radius Too Small, N =
(See error message HELICAL RISE TOO STEEP)
Helical Rise Too Steep, N =
The radius of the circle and the helical rise are radically different in length
(usually the rise is much longer in comparison to the radius).
Also, depending on the programmed feed rate, the control may or may not be
able to handle the situation. Reducing the feed rate in the program usually
helps.


This is way too vague. It seems that they only handle helical paths for things like thread milling? anything else can't be calculated? I can't feed at 2ipm to solve the issue... the control needs to do this automatically for me.

I have not tried the acceleration trick yet. Let me see if that works now.

[Mat Mexico]

acceleration and deceleration for small increment and changes in directions is called HIGH SPEED MODE.
Investigate if your machine has a G code for that (unlikely for the age of the animal).

Otherwise you have to check out how to configure you CAM to do so.
Basically it will output a maximum feed for a segment longer than the minimum set length and lower the top feed for smaller increment and direction changes so your program will have a feed data at every line and your machine will not "bang".

[mflux_gamblej]

indeed this does not exist on my old machine. I can likely get my post to output the lines right, but it is unlikely that I'll be able to model it perfectly. In other words, it may take a lot of trial and error to get a feed rate equation that works on all arcs.

this is the solution though, I've tried everything from feeds, to accel / decel (machine doesn't like it when you prog. a lot of G51's and errors out with no message), to changing helical heights, etc.

I'll work on getting the feeds to do what I want. The machine looks ahead in the incoming DNC and catches these errors before they are executed so at least there haven't been crashes

[mflux_gamblej]

I got it to finish the tool path finally by setting the feed to 20 ipm if it is doing a helical path with a Z change in a certain (small) range. I also enable G9 prior to execution of the same small Z helix, and then disable it with G8, and set the feed rate back to what it was prior after the helix is complete.

This works good, but doesn't solve the 'booming' entirely. I'll likely continue implementing some kind of post processor level HSM routine. I wonder if it can compare to a real HSM routine? Certainly it will force the control to do a lot of code processing that it would do in a more machine friendly way (like assembly / binary or something) if it were done behind the scenes in a typical HSM option that you can buy from the control mfg.

There is always something when you start up a new (to you) machine and get it to behave how you want. I guess I don't always even use trochoidal stuff, but if something doesn't work the way I want it to, I get obsessed with fixing it.

On to rigid tapping! (hopefully that won't need so much help).

[mflux_gamblej]

for now I use somewhat of a look up table where I look at the ratio of helical height change to arc length. Using that ratio I decide on a proportional feed rate multiplier. I am still using G9 / G8 a lot too. With this table the booming is pretty much gone and I can run fast feeds on looser helical paths. Also, any helix below 0.002" radius gets made into lines.

Additionally I bolted the machine to the concrete and that helps a lot with the noise and vibration.

rigid tapping works good too

[Uguessedit]

Did you ever figure out anything further per your situation? We have a similar issue and it’s happening in multi part operation with Gibbs cam. Machining 6 identical parts and the first 5 work fine but on the 6th we get the helical error. I did find it has to do with ramping down while making the hole. Works fine on our other brand machines but not Fadal. If we use plunge instead of ramp and step it down the issue is alleviated. Sadly it takes an extra 20 seconds to machine the hole by plunge method and the finish isn’t quite as nice. Difference of a mirror smooth finish and minor fracture lines. I’m sure the post processor should accommodate this but the folks who write for us don’t seem too interested in getting the feature to work and would rather we provided our own method in accommodating the circumstances. It would be interesting to hear from others. We have a 3/8 end mill doing a contour ramp down through .5 depth making a 1/2” hole. I’m sure if we used a 5/16 or 1/4 end mill the issue would resolve or we’d start breaking end mills.