complex 3d milling

[ppsi]

I am trying to machine molds with complex 3d surfaces (generated in Solidworks). Dolphin 3d generates some nice looking toolpaths, they load into Mach3 without a hitch, and I can scroll through the g-code and watch the toolpath (which appears to be correct) on the Mach display. The part cuts beautifully for 10,000+ lines until it randomly makes a catastrophic z move and eats itself. I can't find the problem line in the code or by scrolling through the toolpath in mach, but it is wrecking the part before I can e-stop. Any ideas what I should look for? Is anyone using Dolphin 3d to produce complex geometry? HELP!!!

[Khalid]

check on any other simulation program

[metalworkz]

Hi,
Can you do a search of the Z's in notepad and check the depth of each Z? If you are aware of the approximate depth when the tool crashes you might be able to look for dimensions that are deeper than the known problem depth? Is it possible that the X and-or Y made an incorrect move and caused the tool to cut into the part in the wrong direction? I think the suggestion from Khalid about running the program in another simulator may be a good way to find the problem. Do you have a simulator to run it on? Maybe you can step through the program in Mach near the part where you are having a problem and you will be able to see the problem line of code? Sorry, I hope someone with better ideas gives you a reply.
Regards,

[S4 Monster]

Can you repeat the fault or is it a random fault?
If it's a random fault then I would suspect a machine / controller fault.
If you can repeat the fault, then I would suggest running the program (without the component loaded) and press feed hold (cycle stop?) when the fault occurs, this should give you an idea of where to start looking in the G-code program, it's going to be before the line that you have stopped on.
If it's difficult to stop it at the right position, then try turning the feedrate down as it gets closer to the problem position.
Alternatively, if you can get some soft material (e.g. Tancast), run the program cutting this material, you can then rerun the program and you will have a visual indication of when the problem is going to occur.

Failing that, as the previous posters have suggested, try some simulation software to track down the fault.

[ppsi]

Thanks for the responses - I have a pretty good idea where in the code the problem comes from - I ran through it yesterday cutting air one line at a time and didn't see a rogue z move that would have caused the hole in the part. This would support the machine / controller fault. The strange thing is that I had run variations of this program in wood to get the settings right and had a similar fault in the same spot. I changed a bunch of settings after the first fault (speeds, feeds, strategy) and still see a fault in the same area of the part. I am now wondering if the source iges file is causing the problem (the iges file is about the only thing I didn't change between iterations).

My family tells me there is a holiday this week, and won't let me near the cellar for the next few days - I guess I'm not going to be allowed to resolve this until next week....

[HuFlungDung]

It sounds like a DNC error, except that you're probably not running this in DNC mode.

I've seen instances myself, where large gcode programs are written to disk with an incorrect character, specifically a carriage return character is substituted for a line feed character. You cannot see these characters in an ordinary text editor, but they exist at the end of every line of text.

The result of this is two lines of code written together as one long command line.

Normally, the machine halts with an error because it cannot interpret such a line correctly, but I don't know if Mach reacts that way, or whether it does something else and keeps on going.

Anyways, some text editors will show you this condition, in that, as you scroll through the code, you will suddenly see two lines run together. Other editors 'autofix' this when the file is sent to the display for you, making the error impossible to see.

I use a hex editor to scan for this type of error, yes the very first one that comes up on Google Its a dandy little tool: Freeware Hex editor XVI32

The search method is to use 'find' to look for a string written in hex as this:
0D 0D

That string is the illegal string, and should never exist because it consists of two carriage returns. All the legitimate lines of text will end with:
0D 0A
which is carriage return and line feed.

So try searching your gcode file using the hex editor for the 0D 0D combination. If you find a few instances, don't be surprised. You can heal them all with search and replace in the hex editor.

BTW, this same error often occurs on large files transferred to a floppy disk. I'd hardly call this a random error, because of the precision of the mistake (it could be any of 255 other characters if it were actually random) so I think it is something to do with Windows interacting with certain hardware.

[S4 Monster]

Hu, that's very interesting........I remember a few years ago trying to track down a spurious error which was occurring for a customer using a well know CNC control (no names mentioned), the machine would bomb out when it got to a particular line of the code.
I checked the code in a windows based text editor and everything looked fine. Every time we ran it on the machine (DOS based control), we got the same problem. I deleted and rewrote the line in the same text editor, sent that to the machine and it ran perfectly.......
The only thing that I could put it down to was something to do with the windows text formatting........weird. Do you think that your hex editor idea could have been used to solve that?

Anyway, ppsi, have you tried taking a very close look at the cutter path in Dolphin 3D? Try zooming in on the 'problem' area, and turn off the model and workpiece visibility (only the toolpath remains), and see if you can spot something.......

[HuFlungDung]

S4,
I wouldn't doubt that the double carriage return error has existed for a long time. I've never seen it happen in a smaller file, I have no idea where the cutoff point is in file size.

At the time I discovered it, I was running DNC using a cnc editor from Millwrite, and lo and behold, when the machine stopped, I ran over and looked at the line it had stopped on, had a WTF moment, and then did some research

Then, some time after I upgraded to a Haas, I noticed this problem again with file transfers from a floppy. The graphics check on the Haas would stop at the bad line, and would also show the error exactly as it was, two lines on one line. Incredible as it might seem, examining the file on the hard drive showed no errors, but the mere copying of the file to a floppy disk introduced the error. I was only too glad to switch to RS232 for file transfers, as this totally bypassed this spurious error on floppies.