A (rare) Autoleveler Bug?

[hanryz]

Hello everybody,

first of all, my thanks to James for this great and helpful software. I've downloaded it from member's section and am now using the 0.8.7 version for leveling my source gcode files for which I have previously created a probing log file. This works fine for top side of my PCB and the result is, as usually, great.

However, when creating a leveled sourced file for the bottom from a probing bot_log file created in advance on my machine, I seem to have a major problem, as the AL shows an error in its log window (see attachment) and refers to its autoleveler.log file for additional info. I attach this log file as well. I also attach the critical bot_log probing file.

My understanding from what I see in the autoleveler.log file is that there is a problem with ranges in the probing log file. Please note, that if done in one go (probing and milling) there is no problem. However, I would have a separate probing file for later use.

James, may be there is an advice you could give me to overcome the issue?

Thank you very much in advance,
Hanry.

[hanryz]

HI again,

I did some debugging and, using the debugger, narrowed down the place in the code where the exception occurs to probe.java file. It happens in the function public static SimplePoint3DCNC[][] createProbePoints(List<SimplePoint3DCNC> listPoints).

The problem is the following loop:

for(int count = 0; count < copiedSortedList.size();)
{
for (int row = 0; row < grid.length; row++)
{
for (int col = 0; col < grid[0].length; col++)
{
grid[row][col] = copiedSortedList.get(count);
count++;
}
}
}

It is also due to my particular probing setup, which causes the the grid[][] array to be much larger than in most of the cases, due to rotation of the coordinate system by which the X and Y coordinates of the probing points are not repeating anymore and cannot thus be eliminated from the list (earlier), as is usually the case. This, in turn, requires the copiedSortedList array to be of the grid.length*grid.length[0] size, which it is, of course, not.

I do not yet get completely into the meaning of the function, but the exception can be easily prevented by resetting the counter variable outside the inner loop for cols.

My question to James would be if this is Ok? Or is rather a dysfunction of the AL to be expected?

Thanks for considering this.

[hanryz]

Hi again,

I did some further research and I came to the conclusion that this behavior (AL not able to read log file which was created with coordinate system being rotated) of the AL is not a bug, but is rather a side effect due to rotation of the coordinate system I set in my machine (G68) in order to mill my double sided PCBs. The actual problem is, that AL is not designed to take into account this rotation. So, this thread can be closed.

[daedelus]

Sorry for my lack of response on this, one of the problems with this method of reading the probe log that it tries to read the data into a very specific 2-D array. This array expects a very specific format for the log whilst having no attachment to the original probe log generator file. If this format differs in any way, such as inaccuracy of the CNC machine or rotation of axis, then errors can occur.

Hopefully I can apply a different and more robust approach to this method in the new ALAE.

[hanryz]

Hi James,

your reply is very appreciated!

When I was looking through your AL code around the place which generated the exception, I discovered exactly the same what you just said.

My problem was rather that I wrongly presumed that AL would take into account the angle about which the machine coordinate system had been rotated when probing and writing log data with the "create only probing file" check box ticked.

Cheers,
Andre