G-Code Load Time

[SCzEngrgGroup]

I recently started doing true 3D toolpaths, which means a huge increase in G-code file sizes. I'm finding load times to be really, really slow. One of the smaller files is about 12 Mbytes, and takes almost 30 minutes to load. Is that normal?

Regards,
Ray L.

Similar Threads:

• Need Help!- Which code fits to load aluminum
• Need Help!- VB code for G-Code Cycle time estimation
• Mach3 Doesn't load all the G-Code
• Won't load G Code?
• How do I load an edited G code program

[SCzEngrgGroup]

Yikes! Up to 90 minutes to load a 24Mbyte file, and it's still not done! It using 55% of the CPU, and memory is constantly changing over a range of 180 to 800+ Mbytes. I have no clue how much longer this will take, but this is a problem, as the load time it getting close to the program run time...

Regards,
Ray L.

[SCzEngrgGroup]

Finally finished loading after 2 hours 15 minutes...

Regards,
Ray L.

[SCzEngrgGroup]

Had another annoying problem while the program was running - during one looooong part of the program, it was doing a large spiral path with a small step-over. Throughout this hour-plus long part of the program, the KFlop stopped every ~2 minutes of run-time, flagging a Coordinated Motion Buffer Underflow. I assume the lookahead I need to increase means a change in my CNCController program initialization of the KFlop? Where exactly is that parameter located?

Regards,
Ray L.

[TomKerekes]

Hi Ray,

Yikes those are some big files. Are you running KMotionCNC or your VB Program? When you say "Loading" what do you mean? Just opening the file in the editor without running it?

I just checked KMotionCNC with a ~12MByte 641,000 line GCode file (40 consecutive copies of ear.ngc) only takes < 1 second to load and 4 seconds to simulate/plot.

I suspect your code might be adding one line at a time with Windows re-drawing the Control every line? KMotionCNC uses a Scintilla Control for the GCode Editor.

Regarding Underflows you might also investigate the settings in your CAD system to see if you can reduce the data. It might be generating unnecessarily short vectors. KFLOP can handle a sustained rate of ~2000 segments/sec. If the data is more complex than that a Buffer Underflow would be expected. More buffering time can help with peak data rates but not for sustained rates. Most systems are incapable of changing direction by a significant amount more than 2000 times per second so this is not normally a problem. The Trajectory Planner Co-linear Tolerance can help reduce the segments sent to KFLOP while still preserving reasonable accuracy. See:

Tool Setup Trajectory Planner



From .NET the related parameters would be KM_MotionParams - CollinearTol and TPLookahead

HTH
Regards

[SCzEngrgGroup]

Tom,

I'm running my c# application. Guess I'll have to dig into it and see where all the time is going. I haven't touched that code in years, and don't recall anything about what the g-code file load sequence looks like. I think you're right that it's loading the file into the editor that is really taking up the time. I also use Scintilla, but I think I may load the file a line at a time.

On the underflows, the code is nowhere close to 2000 segments/second, but the code does contain a lot of g-code parameters. Could that be slowing things down significantly? The code in question is about 250K lines like the following:

X3.1563 Y6.2083 F[90.00*[#100/400.0]*[#102/100.0]*[#104/100.0]] (F90.00)
X3.1270 Y6.2230 F[90.00*[#100/400.0]*[#102/100.0]*[#104/100.0]] (F90.00)
X3.0668 Y6.2529 F[90.00*[#100/400.0]*[#102/100.0]*[#104/100.0]] (F90.00)

Regards,
Ray L.

[RCaffin]

Ray

Part of your load time might be all the maths evaluation.
For a start, why don't you use another parameter, so
X3.1563 Y6.2083 F[90.00*[#100/400.0]*[#102/100.0]*[#104/100.0]] (F90.00)
becomes
#1=[90.00*[#100/400.0]*[#102/100.0]*[#104/100.0]]
X3.1563 Y6.2083 F#1 (F90.00)

But then, WHY on earth do you redefine the feed rate in every line????
Change to
#1=[90.00*[#100/400.0]*[#102/100.0]*[#104/100.0]]
F#1
X3.1563 Y6.2083
X3.1270 Y6.2230
X3.0668 Y6.2529

You may find a huge speed-up

Cheers
Roger

[SCzEngrgGroup]

Ray

Part of your load time might be all the maths evaluation.
For a start, why don't you use another parameter, so
X3.1563 Y6.2083 F[90.00*[#100/400.0]*[#102/100.0]*[#104/100.0]] (F90.00)
becomes
#1=[90.00*[#100/400.0]*[#102/100.0]*[#104/100.0]]
X3.1563 Y6.2083 F#1 (F90.00)

But then, WHY on earth do you redefine the feed rate in every line????
Change to
#1=[90.00*[#100/400.0]*[#102/100.0]*[#104/100.0]]
F#1
X3.1563 Y6.2083
X3.1270 Y6.2230
X3.0668 Y6.2529

You may find a huge speed-up

Cheers
Roger

What gets output is determined by HSMWorks. I basically only get to control how it's formatted, unless I do a whole lot of work on the POST.

I'm pretty sure that, as Tom suggested, my problem is in how I am loading the G-code into the editor in my application.

Regards,
Ray L.

[SCzEngrgGroup]

Pretty sure I've found the major problem. After loading the file into the Scintilla control, I parse it, in c# code, to do syntax highlighting. I suspect that is quite time-consuming on such a large file. First thing I'll do is add a test that will disable the highlighting on large files. I remember when I wrote that code it was intended to be temporary, so was rather brute-force, and not at all efficient. But, it's worked well all these years.

Regards,
Ray L.

[SCzEngrgGroup]

Surprisingly, it appears that Scintilla is doing this to me. My syntax highlighting no doubt takes some time, but it is manageable. But loading the text into Scintilla is the primary offender.

Here's what I'm doing:

I have a GCodeFile object, which reads the file, and puts all the text into List<String> FileLines; as individual lines. I then call the GCodeFile.ReadAllText method, which simply appends NewLines to each line, concatenates the whole file into a single string, which is then passed to the .Text property of the GCodeDisplay object, which is the Scintilla control. It is setting the Text property that is eating all that time - all the other operations, including the syntax highlighting, are reasonably quick.


public LoadFile()
{
...
GCodeDisplay.Text = gcodefile.ReadAllText();
...
}

public String ReadAllText()
{
String lines = "";

foreach (String line in FileLines)
{
lines += line + "\n"; ;
}
return lines;
}


Anyone have a clue what I can do to speed this up? Is there a better format in which to pass the text to the control?

Regards,
Ray L.

[SCzEngrgGroup]

Looks like I have, once again, lucked out, and found a trivial solution to the problem. Turns out directly setting the Scintilla Text property is, for unknown reasons, appallingly slow. But, calling the AppendText() method is quite fast. With that one line change, my 24MByte G-code file loads in just 1 minute, 5 seconds, even with my brute-force syntax highlighting enabled!

I'm a happy camper again!

Regards,
Ray L.

[SCzEngrgGroup]

Tom,

I do still some guidance on the buffer underflow problem:

1) Could all those parameters be part of the problem?

2) What parameter do I need to change (through the dotNet interface) to increase the lookahead? How much should I increase it?

Thanks!

Regards,
Ray L.

[RCaffin]

Hi Ray

Aaarrgghh! 99% of the time is spent doing nothing of value at all!

When you declare a string buffer like that and put a line of text in it, the memory allocated is enough for that string, and nothing more. When you append to the string buffer, it has to create a new and longer one. So what is happening is that every time you add a line to the buffer, a whole new string buffer just a little bigger is created and ALL the old stuff is copied from the old buffer to the new buffer, and then the new line is added at the end. Your machine is absolutely thrashing itself just moving data around! A good work-out for the memory chips I guess.

Now, you CAN speed this up very easily. Declare a huge STATIC string buffer at the start of the program and use it. Since we are using modern PCs these days, with Gigabytes of memory, you could afford to give the buffer ... oh, say 50 MBytes? This would have been inconceivable in the days of 16-bit computers, but today ... trivial.

Cheers
Roger

[SCzEngrgGroup]

Roger,

I think you missed, or mis-read, my last post. My code, where I read the file line-by-line, and concatenate it into either a List<String>, or a single long String, executes within a second or two. It's actually adding the text to the Scintilla control that is horribly slow, for reasons I don't understand. But, since switching to using the Scintilla AppendText() method instead of simply setting the Text property, performance is now quite good. With Debug turned off, it loads the 24MByte file, and does the syntax highlighting, in under a minute, which is more than acceptable.

Oddly, today I got no buffer underflows, despite running virtually identical code for a much longer time (over two hours). I'd still like to increase the lookahead, just for protection. But, I can't find the parameter....

Regards,
Ray L.

[RCaffin]

Hi Ray
Missed it.
Eh - maybe Scintilla was doing something similar? Who knows?
But now it works.
Cheers
Roger

[TomKerekes]

Hi Ray,

1) Could all those parameters be part of the problem?

I think it is unlikely. The PC is pretty fast at calculations so those should take a few microseconds at most.. You might Simulate the code to see how much time it takes to prove the point.

2) What parameter do I need to change (through the dotNet interface) to increase the lookahead? How much should I increase it?

From .NET the related parameters would be KM_MotionParams - CollinearTol and TPLookahead

Regards