Minor bug found in 0.8.5

Report problems here
Post Reply
kvnrydberg
Posts: 19
Joined: Thu Jul 17, 2014 4:46 am

Minor bug found in 0.8.5

Post by kvnrydberg » Wed Sep 24, 2014 8:20 am

I was one of the few having trouble with arcs causing infinite loops in the early 0.8.x versions. Lately, I've been converting my g-code to lines in Cambam, which has been a rather poor solution because the arcs get bastardized into a string of jagged little lines. Unsightly, and really pushing my 10 mil trace/10 mil clearance design rules. But no more of that, it seems. So far 0.8.5 has fixed these problems for me, so thanks so much for the good work.

You might remember I do most of my drawings in illustrator and export them as a .dxf file. This works ok, but the dimensions in the .dxf file never precisely match the dimensions in the original .ai file. For example, an object I place at (0,0) in illustrator may be at (.0001, 0) when I load the .dxf file in Cambam. No big deal as far as I'm concerned, but this led me to find a bug. Using a .125" endmill, I was profiling a rectangle, the left side of which was designed to be at X = .0625". This means of course that the spindle should be at X = 0. In Cambam, however, the left side of the rectangle was at .0624" or some such number, which forced the spindle to be at X = -.0001. So when I made the g-code file, fed it into AL, and loaded the output into Mach3, it gave me an error message. "Radius to end of arc different from radius to start", I think. But when I moved the rectangle in Cambam to X = .0625", and did the same, all was well. Strange. Looking at the AL file, you can see where some wanky numbers start to show up in your interpolation routines just as the spindle moves past X = 0. I did try moving the left side of the rectangle to X = 0, just to see whether it was the negative position that was causing the problem, but it was not.

Anyway, have a look if you want. Three files are attached. Obvious which is which.
Attachments
ControlTestGOOD.nc
(660 Bytes) Downloaded 58 times
ControlTestBAD.nc
(674 Bytes) Downloaded 63 times
ALControlTestBAD.nc
(146.82 KiB) Downloaded 58 times

daedelus
Site Admin
Posts: 363
Joined: Tue Oct 01, 2013 1:41 pm
Location: London, UK
Contact:

Re: Minor bug found in 0.8.5

Post by daedelus » Wed Sep 24, 2014 4:37 pm

I do remember :D and am glad that the latest version helps fix things mostly. :)

I use CamBam myself but only so far as to load a gcode file into it so that I can briefly inspect it visually. CamBam is great for this because it nicely color codes arcs and lines separately. I did try to convert arcs to straight lines directly within AutoLeveller but this meant you would need many small lines to create an acceptable curve, as well as the other issues you have mentioned. Breaking arcs down into smaller arcs rather than linear lines is a much more elegant solution as you say but can have problems with the centre offset, represented by the I and J values.

The error you see is often caused by this I and J value not being accurate enough, and CamBam seems a lot more tolerant of this than Mach3 or LinuxCNC. I am wondering if using millimeter instead of inches might give you the necessary resolution to workaround the issue.

Anyway, I will have to leave the files till the weekend to look at, but thanks for providing them though. The more information I have on an issue the better.
http://www.autoleveller.co.uk/. Software to probe and adjust a GCode file for PCB's or any probe-able surface.

http://www.autoleveller.co.uk/cnc-probe-guide/. A short guide to setting up the probe.

-James

kvnrydberg
Posts: 19
Joined: Thu Jul 17, 2014 4:46 am

Re: Minor bug found in 0.8.5

Post by kvnrydberg » Thu Oct 02, 2014 9:15 am

I ran into another problem with the latest AL release. I leveled some code with an already-made probe log and, while running the output file, the bit dug nearly 1/8" into the workpiece at one point. This has never happened to me while using any of the AL releases. And heretofore, aside from the weirdness I wrote about in my last post, I have been using 0.8.5 extensively in the past couple of weeks with flawless results. At first I thought it must be some spurious data in the probe log. But the log is fine. And so is the original G-code. It's just that at one isolated move in the leveled code, shit happens. I'll upload the offenders. The error is at X2.5578 Y0.3999.
Attachments
AL.G-Code.txt
(62.22 KiB) Downloaded 71 times
Probe File.txt
(1.63 KiB) Downloaded 62 times
G-Code.txt
(38.78 KiB) Downloaded 73 times

daedelus
Site Admin
Posts: 363
Joined: Tue Oct 01, 2013 1:41 pm
Location: London, UK
Contact:

Re: Minor bug found in 0.8.5

Post by daedelus » Sat Oct 04, 2014 2:13 pm

Sorry for the late reply, I have been quite busy of late with work related stuff. My new job is OK with me but it does mean I have less time to work on AutoLeveller nowadays.

Anyway, I have received some emails from another AutoLeveller user, who has the exact same problem, i.e. the occasional spikes in Z height. Not sure why yet but I will get to the bottom of it. At first I had the same thoughts as you, i.e maybe the raw probe file contains some erroneous data in it, causing the spikes. But no, the probe file looks fine there too. Will continue to investigate.

PS. I have read and made note of the suggestions in your other post too. Good ideas. Thanks.
http://www.autoleveller.co.uk/. Software to probe and adjust a GCode file for PCB's or any probe-able surface.

http://www.autoleveller.co.uk/cnc-probe-guide/. A short guide to setting up the probe.

-James

Post Reply