AutolevellerAE 0.8.5 creates GCode with trailing periods

[justinwol]

Hello,

I just purchased AutolevellerAE 0.8.5 and gave it my first trial run. The end result turned out great (I attached a picture), but it took quite some work to get it there. The main problem was that the autolevelled gcode had trailing periods on many lines like:

Code: Select all

X48.292Z-0.22770.

And in the middle of the line:

Code: Select all

X48.312. Y7.991Z-0.22739

To correct this, I used Notepad++ with some regex to find and replace the patterns where the extra periods where. It ended up taking numerous attempts at loading the autolevelled gcode into Mach3 until no more errors were found. Quite tedious.

Another issue was that the starting point generated when I loaded an OGF was way off to the side of the stock. As a result, I ended up just manually inputting the starting point and the size of the stock and generated a PFG that way - which worked great.

Is this a bug, a result of manually setting up the mesh, or something else?

Thanks, love the software, I just need to iron out the workflow.

[Country_Bubba]

Hi,
Nor sure what happened. I just tried generating a file with the latest version and it appears normal.
Could you please let us know what your post settings and units are? Also any custom options that you may have included?

Thanks in advance.
Regards

[daedelus]

I, like Art, am not sure why this is happening. I cant see how these issues are arising, but they do so it needs fixing. Do you have any custom controller option? Please, email me your OGF if the issues persist so I can run it through my debugger and report back to this thread.

[justinwol]

I've been away on holidays, but when I get the time I will upload the gcode and give some more details on the problems I posted.

On a different note, I'm having a different, more pressing problem. Is there a maximum file size or stock size to Autoleveller? Autoleveller will not seem to load the attached gcode file - it simply does nothing, in both 0.8.5 or 0.9.

Thanks.

EDIT: It looks like my 687kb file is too large to attach. It has ~54,000 lines of code.

[Country_Bubba]

Hi,
I cannot answer your questions from a programmers standpoint, but I just loaded a rather large sized file I found on my hard drive. Its 1.67 MB and it opened it just fine and shows the trace pattern just fine (AE .0.9.0)

In my experience, I have not run into a size problem, but then again my stuff is usually quite small.

[justinwol]

Here is the file in question: https://drive.google.com/file/d/0B1Ytrs ... sp=sharing

It is generated with Fusion 360 using the stock mach3 post configuration.

[Country_Bubba]

Wow, this gets more curious each posting!
I downloaded your file and attempted to open it in the latest version and like you, nothing, nada, not even an error message.
So I attempted to run it through Camotics simulator and once again it bombed! But it did give me a lot of errors including "ERROR:std::exception: bad allocation" whatever the heck that means.
along with "ERROR:unknown exception" several more times!
Looking at the Gcode file, the only thing that appears odd to me is that any position that does not contain any digits past the decimal point ends with the decimal point itself eg X512. as an example. I am used to seeing digits beyond the decimal point even if they are 0.
Next just for grins and giggles, I opened the file in Sheetcam and was very surprised to see a bunch of extraneous circles! (see attached jpg)
They all appear in Sheetcam on a layer noted as Tool 3 0.150000 deep. I then attempted to do a simulation on the file and immediately got the following error: "Post processing...
Warning: WARNING: Feed rate is zero
Post processing completed with 1 warnings"
This makes no sense as there are several F1000 and F700 commands through out the file! But is is a mystery to me why this will not simulate in two different programs!
Also, AE may be getting upset by the use of the G17 codes, but James will have to answer that one.

And as I am not a user of Mach, I cannot do any sort of debugging there.

Sorry, but maybe some of my ramblings will give James an idea as I am hoping a solution can be found and would like to know why it won't work!

[Country_Bubba]

OK, we have now had some success! Went to bed last night and thought about it and this morning started eliminating sections until we got down to a working solution.
To make a long story short, the (2D CONTOUR1 2) routine is the culprit! As you can see from the screenshot in Sheetcam, by eliminating these routines, it eliminated the extraneous circles!

When I tried to load just (2D CONTOUR1 2) it bombed and I haven't gone through that line by line to see the problem, but based on my experience, I would bet those circles are not wanted anyhow??? One thing I have found, is that eliminating this section also eliminates all references to G18 so there may be something to that also??? I don't know. I will leave it up to you to figure that one out.

[daedelus]

Loading the file in AE, I too see no activity at all. There are a lot of lines with trailing periods though as Art said. I assumed that was causing AE to choke, so I removed all the trailing periods from the file using my text editor and a regular expression. Loaded the file back into AE and still nothing. Something else must be causing the problems in addition to the trailing periods.

If I run the file in my debugger, the first line it chokes on is

Code: Select all

G18 G3 X98.971 Z-0.15 I0 K0.1

The G18, G17 and G19 codes are plane selection lines where G17 is the XY plane and G18 is XZ. It is best to stick with G17 for AE as anything else seems to cause issues. AE may be confused by the constant swapping of planes. It could also be the "K0.1" bit as this changes the centre point in the Z axis where AE is expecting an "I" or "J" or both as these correspond to the X and Y axis, not completely sure of the exact cause of the issue.

I think the main problem here is Fusion 360 because it is designed for 3D modelling I think, and inserts lot of GCode swapping planes and changing Z's. The viking head turned out well so Fusion 360 obviously works sometimes when the trailing periods are removed from the gcode. I dont know fusion 360 but is it possible to design in a way which does not cause the problems, now that we sort of know the issue?

To remove the trailing periods, you can load the file in notepad++ and press ctrl+h for find and replace. Then select regular expression and enter "(.+\d)\.(\D.*)" in the find box. "$1$2" in the replace box. Click "replace all" and it should remove the offending periods. Do this twice or more to remove the remnants where lines contain more than 1 trailing period.

findnrep.jpg (49.64 KiB) Viewed 8925 times

If anyone is curious about the regex, "(.+\d)\.(\D.*)", in English it says "match any line with any 1 or many characters followed by a digit, followed by a period, followed by anything which isnt a digit, followed by any number of any characters". The parentheses group the parts of the line so that we can refer to the groups in the replacement. So "$1$2" just says replace each match with the contents of group 1 followed by the contents of group 2, i.e. the same line without the offending period.

hope this helps a bit

[daedelus]

I was too slow Art pipped me.

A great workaround Art. Essentially agrees with me that the arc lines (G2 and G3) combined with G18's are the issue here.