[gwarble]

hey all,

i can't seem to find a parameter to affect this (i was hoping it was MDR minimum deccel ratio via param 1710 for corner override but i don't think it is)


so its an 18-mc fanuc on a Hwacheon Sirius-U VMC... below is an excerpt of the code that is causing the problem...

runs fine with or without look-ahead (G8P1) but if i enable AICC (G5.1Q1) the toolpath freezes at N9999 below...

its a small arc but its not non-existent.... and coming from a CAM system (i've encountered it on other toolpaths as well) i'd rather solve this at the machine level

i also have never had this issue with the same toolpath running on a few 18i-mb's with AICC or AI NANO... as well as on a couple 0i-mc's and 31i-ma... with AI APC and AICC I respectively...

i also ran it on old 0-mc and 0-md controls, without AICC of course, but with look-ahead (g8p1) and no issues either... just on this 18-mc and only when G5.1Q1 is active (flashing AICC in the corner)

thanks ahead of time... i know all the smart people on this forum will help me solve this before i start going back thru the parameters page by page

thanks
- gwarble

X6.9979Y-7.1331I-4.4133J3.7032
G3X6.968Y-7.2035Z-5.4499I0.0701J-0.0712
N9999X6.9967Y-7.2745Z-5.4474I0.1J-0.0008F500.0
G0Z1.

[psychomill]

AICC has certain rules that need to be followed. My first thought here is ...

You have a "G0" move on the next line and there's no command to turn off AICC. So, after the the N9999 line, try shutting off AICC mode BEFORE commanding "G0Z.1". You may even need a short lead out line first depending on the visual effect seen on the part.

[gwarble]

thanks for the advice...

that may be the case, especially with the high feedrate before the g00... but i'm hoping to solve this in the control because its obviously computing a decceleration of 0 feedrate under these circumstances... and the code is otherwise working fine (without aicc) so i don't want to blame the code

(the weird feed/move/rapid combo's are a result of a CAM system's rapid material removal toolpaths... ie SurfCAM Velocity toolpath, which is a constant tool engagement toolpath... with really high feed rates in between cutting moves for high speed machining)


after playing with some parameters... i'm pretty sure its related to the feedrate differences... if i change the F500. in that line to a F50., it doesn't stall... and if i mess with parameters 1770 and 1771 (which compute the maximum acceleration) i can get it to run that line but the machine movements end up jerky

maybe fine tuning of 1770 and 71 is all thats necessary... but i'm not sure

- gwarble

[psychomill]

You're not reading what I wrote.....

You need to shut off G5 before going into a rapid. This is "code thing"... You're switching modes between feed and rapid and AICC don't like it....

You even said it yourself...

and the code is otherwise working fine (without aicc)

[gwarble]

i did read what you wrote... but sorry, you're wrong

while you're right, there ARE some limitations... going from a feed move to a rapid move is definitely NOT one of them

this is AICC not HPCC (they have different limitations, and AI is with G5.1 not G5)

the code also works on other machines with AICC, and on this machine with a different feedrate value

the real issue is a decceleration "after interpolation"... the behavior is affected by accel/deccel parameters, and the arc in question is processed, and interpolated (leaving .0001 distance to go in X and Y) before freezing...

and using a feed rate of 50.0 instead of 500.0 removes the problem...

my guess is an "auto corner override" or "block overlap" setting...

- gwarble

[psychomill]

I may very well be off... however,...

You need to clarify which mode HPCC you're running then... or if it's AICC. HPCC has a G5 format as well as a G5.1 format... basically it's RISC or without RISC. But leaving who's wrong or who's right aside...

It could be corner override but I'm not sold on that. But you say if you're running AICC and going 50IPM... all is good huh? Hmmm....


Another thought... are you running cutter comp in this mode? (but since you know the rules... probably good here as well eh'...)

I usually have all this dealt with by some of my friends at FANUC... I leave it to them quite a bit as I have a ton of other machines to deal with. As long as when their done it's doing what I want... I run with it. I'll dig around and see if I got some docs on what you're seeing but you just may be on the right path...

[gwarble]

i thought i did in the first post... but no worries, thanks for helping me narrow it down...


in my experience and in what i've read in the yellow books... AICC (or AI NANO, which is basically the same in practice) works fine in almost all cases if called after a tool change and a G49, before a G43 tool length offset... cutter comp (radius) can be applied and canceled inside AICC... although in this case it's not being used

my typical code has AICC running in almost all cases except at toolchanges and tapping, where the M29 macro turns it off...

- gwarble

[MysticMonkey]

3403#0 ?

[gwarble]

thanks for the help and info...

on this machine, 3403#0 is already set to 1, which is what all my other machines are set to as well... do you have a description of what this bit does? its not in my manual for 18-mc but i'll check the 18i manual tomorrow

thanks again
- gwarble

[MysticMonkey]

The only reference I have found to this parameter is in the 21i operations manual B-63614EN and the 0i-MC Connections manual (function) GFZ_64113EN

According to these manuals It deals with the precision of radius error in circular interpolation when in AICC mode.

[samu]

i also ran it on old 0-mc and 0-md controls, without AICC of course, but with look-ahead (g8p1) and no issues either...

How does work look-ahead on 0-md. Do you need extra hardware and/or activate an option bit??

[gwarble]

to be honest i'm not sure whats up with that... seems like G8P1 is totally undocumented on the 0-mc and 0-md... i've had the service reps (not fanuc but its vendor) tell me that's not an option on the 0-m, but it does work...

its not like AICC... its just preview control (not contour control) i call it look ahead and the chinese text i translated via google translate to find out info about it called it "First control"

- gwarble

[samu]

i run this program to see effect of G08 P1 but there was no deceleration and i didn't see any difference with or without G08 P1.

G08 P1
G91 G1X200.0 F3000
Y-200.0
X-200.0
Y200.0
M30

[gwarble]

while i'm no expert, i think if you want to deccelerate at the corners of a square like this you want "automatic corner decceleration" and its associated params... look-ahead is different, and its benefit is to deccelerate around a SPLINE toolpath, or planar, when reading segments of code that are too small...

hopefully someone that really knows can chime in, but i think what its doing is reading ahead X number of blocks, and determining when small code segments are causing necessary decceleration to maintain a precise contour...

- gwarble

[gwarble]

so i took your example, in inches being roughly a 7.875" square at 118ipm... and did a test like so...

ran a 7.875" square with four corners
ran a 7.875" circle (g2 or g3)
ran a fake circle of the same diameter made up of small line segments, making up around 480 lines of XY values

in one cycle, with G8P1, first two paths maintained 118ipm, SPLINE path maintained only 78ipm, timed at 53sec

in one cycle, with G8P0, maintained 118ipm for all three paths, corners in the square sounded a little harder, timed at 46sec

so i need to reiterate that i don't know exactly whats happening because of poor documentation or whatever, and the above data says that the G8 is hurting cycle times... but in reality it gives me a better shape and finish on my part...

your questions have made me want to do some more quantative tests including making actual parts and CMM'ing them... but as of yest i've just been trying to learn what i can while still being productive making parts :)

attached is the code i ran... DO NOT RUN IT ON YOUR MACHINE, its set up to use the macros i have on my machine already and is not universally safe... i hope everyone knows that but this is the first time i'm posting actual code so i figured i should disclaimer it


- gwarble

[gwarble]

i figured i'd bump this thread as i still run into this problem from time to time and have not found a resolution

i still believe this is accel/deccel and/or auto corner override related but i'm unable to get consistent results...

since my original post, i've also seen similar behavior to this on 0-MC and 0-MD controls... while using G8P1 and basically "TrueMill" style toolpaths (lots of code, splines and segments, arcs and helixes, designed to minimize tool load)

which makes me wonder if its buffer related... hmm

anyway, just wanted to revisit in case anyone knows what direction i should look

thanks
- gwarble