What's new
What's new

Arc programming causing Z to nose dive. cannot find the issue here.

huleo

Hot Rolled
Joined
Feb 12, 2014
Location
UT
I know everyone will ask for specifics and code, which I don't have at the moment, but bringing a late 90s aquajet online right now. They all like to use their own friggin proprietary control. the program manual is VERY vague to say the least and just says "for arcs use, I, J, K".....uh, ok.

Program it just like everything else, and it will start in an arc as it should, then plunge in Z to some unknown value WITHOUT ANY Z axis code at all. Nothing. We have removed the K, put it back, ran a K0.0, you name it.


I am just curious at this point is someone had had a mysterious Z plunge in an arc and what the cause was? I can be certain if we take this code to any Fanuc, it will be just fine. Has to be something with max arc length before another segment or something odd.

We ran this several different ways and different code in single block. It will do it at a different time, depending on the code, but will ONLY do this on an arc. If we program just lines, no problems. This has nothing to do with the machine losing position or something, the control is doing this.
 
Are you talking about Aquajet waterjet? I had never heard of it so i looked them up to get control specs. Uh, well, their website is a bit lacking but what concerns me is when I clicked on the control its a Siemens 808D turning control. Is this what is on your machine?
Capture.jpg
 
Ah shit, I just mean water! I think it is JetEdge. The damn thing just royally pisses me off because it is designed for idiots so you do shit like tell it what material, orifice, and it decides your feed rate and such..... We found a way to bypass that shit, but this programming glitch has cost us a job so far. I can tell you for certain it is not a mainstream CNC. If it was, we would not have these issues.
 
I looked through my cam systems to see if any had a post for that DI pc based controller but nothing even close. Had a peak at their website and i'm more dizzy headed than I was with Aquajet using a lathe control on a waterjet. Jetedge is claiming 36,000 hours trouble free? I don't think iv'e ever seen a pump last a month without a rebuild. And why in the hell would anyone need 150 HP motor to drive a 60k psi waterjet?
 
Try reversing the arc direction in your dxf file before import. Unblock/ungroup everything before import, best to have lines and arcs in continuous direction. does it accept dstv files? does it only happen on arcs that go thru the xy quadrant?
 
Greetings,

Try checking your program axis. Some machines, especially multi-axes lathes like Swisses, have an axis call, (G17, G18, G19, for mine.) that sets up which axis things move in. So a G03 in G17 arcs between X&Y, but the same code, with a prior G18 call will arc between X&Z, with no Z call that you can see. Fanucs will do it too for mill controls, so it's not *just* lathe controls.
I doubt it's the same G numbers for your controller, but check to see if your controller has some sort of logic like that, and check to see which axes it's set to use. Bet you one of them is Z.

Hope this helps.
Regards,
Brian
 
The DXF did come into question because we typically would import 3D models. I cannot imagine how the geometry would cause this as the tool path generated fine, without errors.

On the G17-19, all of this was combed over pretty carefully and though X/Y motion WAS invoked and moved fine through some of the arc, it then just decides it needs to plunge Z but certainly does it while interpolating with another axis. I cannot recall but that is something to test for sure, to see if it moves with a certain axis every time.

We will also generate clean geometry right in CAM to see what it might decide to do. What is super odd is per the code (and I say that because at the end of the day, that is all that matters to the machine), there is nothing to invoke Z motion. No G19, no nothing, just more IJK code that it started the arc with. But throw it some lines, it is just fine with that.


I am more curious about a dirty DXF and what I can check for? We don't play with them much and this might be a hard lesson.
 
If the dxf came from 3d model I can almost assume a bad file... I see it often with parts we need to cut. Fortunately our plasma ignores things outside z=0, and just spits all sorts of warnings about file being incomplete (actually it says illegal).
I will recommend viacad 3d as the simplest program to check your files. There is a free trial off their website which will at least get you started in spots that have errors. highlight all, right click and show direction: you will see geometry direction for everything. Finding the arcs with (center almost always) off z plane is harder, but checking all is simple by just highlighting all and doing a 2 pt extrusion. It gives an error if there is overlap/double line or incomplete chain in a plane. Last, highlight all and do a verify-object count. If it contains anything other than line or arc then the 'dumb' cut software will throw junk code at your machine. Our burn table is made by Controlled Automation - opposite of homer table, yet still has some quirks that took me a while to figure out. We have a voortman profiler, and it is the fancy name - and it is far worse on any imperfection of imported file. That one you can not have an arc over 90 unless it is complete hole. I am subbed out to other shops when they get wonked files--and I just gave 3/4 of my secrets to you.
It takes a while of using whatever nest/machine software they use to understand how to lie to get the machine dance. How is head height controlled? (sensor or just set at z=part + gap)
If it takes dstv, the steel industry standard nc file, then 97% of your problems vanish.
 
I should mention that we are NOT feeding a DXF to the control and letting it generate paths. All geometry is brought into mastercam and toolpaths generates from that. We have never had a case where the paths were good in MC, yet no good on machine unless the post out is bad. However, those things are typically verified in vericut. This one is so simple we can just look at the code.
 
use machines nest/import software, I can finger cam for our machines and that is it, gcode files from clients using solid works or catia do not work. I swear the robots know if gcode was made outside their mothership. In fact voortman will intentionally mess up a dstv shape file if made on software outside theirs or Tekla (you strip header lines and paste in a generic machine generated one and the same file is perfect. You would think 2-d files would be simplest of all... No macro, no subroutines?
 
i have seen program where G19 called and somehow CAM software stuck another G17 in and that caused big problems. also reset defaults. if you press reset button and G17 is active then if you need G18 or G19 it needs to be restated.
.
some cnc use G55 workoffset and reset press if it defaults to G54 that can cause immediate problems. seen it where cnc doesnt want to start operator presses reset, machine starts but the defaults cause of reset press can cause big problems. same with loosing tool comp.
if G0 G43 H1 Z2. and H1 is 10.0" and reset press so G49 active if it see a G0 Z2. it will normally crash tool cause tool offset not active to keep it 10.0" higher
 








 
Back
Top