[randyrhine]

Hi,

I'm getting a KmotionCNC abort about 90% into a long (4+hour) job. A C++ runtime window comes up with the message " The Application has requested the runtime to terminate it in an unusual way". I restarted from the beginning and the same thing happened at the same point. The system is Windows 8.1 and KmotionCNC is 4.32. Is there any other information I could supply? I'd be happy to share the g-code file if need be. The g-code is from Aspire.

Thanks,

randy

[TomKerekes]

Hi Randy,

Sorry to hear this. I haven't heard of this before. Please do send us the GCode and your configuration settings (GCodeConfigCNC.txt and your Initialization C Program) and we will see if we can duplicate the problem.

You might try our latest Test Version 4.33k to see if it works better. Although I can't think of anything specifically why it would other than some general optimizations.

Regards

[randyrhine]

Thanks for the reply, Tom.

I'm rerunning the job as I type. I think it might be a memory problem. With the initial; gcode file loaded, the task manager showed KmotionCNC using about 68,000k of memory. With the job about 1/3 through, it's up to 420,000K and growing. I suspect a memory leak. The system is Win8.1 64bit with 8G of memory.

Still want the files or is their something else I can check/do to narrow it down?

thanks.

randy

[TomKerekes]

Hi Randy,

You might be right. I don't think a memory "leak" but rather requiring an extra ordinary amount of it for the backplotter. Please send the files so we look into it. Our program is 32-bit so it is basically limited to ~2GB of virtual memory regardless of the amount of physical memory.

If you push "Clear" on the GViewer Screen does the memory use reduce?

Regards
TK

[randyrhine]

Hi Tom,

I think that's it.....the G viewer. I was running it today without the Gviewer screen...and it ran to completion, but the memory usage at the end was about 1.6g. So...I started it up again in "air cut" mode with the GView screen on...memory usage started to creep up....hit clear...and it dropped back down. Turned off the GV screen...memory continued to creep up....turned on the GV screen (memory took a bit of a jump with that) and hit "clear" and memory dropped down.

So....even with the GV off...memory usage still creeps up. But clearing it drops it down. So...the work-around is to keep an eye on the memory...and/or hit "clear" every hour or so. .

Still want the files?

thanks,

randy

[TomKerekes]

Hi Randy,

Thanks for the GCode file. But I'm not able to duplicate the Memory problem. Are you sure those are really your settings?

Break Angle 10deg
Look Ahead 2 sec
Collinear Tol 0.0001 inch
Corner Tolerance 0.003 inch
Facet Angle 4 deg

The most memory I can see being used is 156MBytes (156,000KB).

The file size isn't that huge ~236,000 lines. There must be something strange going on.

I'm testing with a W7 32bit system. I wonder if it is a graphics card issue?

How much memory is used if you just simulate and plot by pushing the Simulate "run" button?

I noticed the GCode seems quite "noisy" and you have a Break Angle setting of only 10 degrees. The noisy data has a lot of angles greater than 10 degrees which results in lots of stops. Changing the Break Angle to 90 degrees runs a lot smoother and faster (~55% faster) with very little change in the trajectory path. See the Animated gif file where I tried to show the slight difference in the path. I isolated 2 typical paths to show the difference. I also actually ran the whole job with your settings except for a 90 deg Break Angle and it only took 1.81hrs. Rounding the corners should actually make more segments and use more memory, but it never used more than 156MBytes.

Attachment 265766

Regards

[randyrhine]

Hi Tom,

I think this may come down to a "dumb user" error.

The trajectory planner settings on the file I sent were, like you thought, incorrect. They were from a backup folder I keep on my office PC . I forgot I had made some changes a couple of months ago to the actual ones out in the shop.

The actual settings are:

Break: 10
lookahead: 6
colin tol: .0001
corner tol: .001
Facet: .05

I think it's the facet angle that is causing the high memory usage. Back when I was messing with the params, there was a problem with a pattern that had a lot of sharp corners at various angles that were being curved...and the pattern also had a lot of very short segments and the machine was stuttering and I was trying to eliminate the curved corners, as well as the stuttering. Based on various posts on the forums, those params seemed to work. Except, from looking at the posts again...I think the facet angle should have been .5 and not .05. Setting it to .5 I see a lot less memory being used than when it's at .05. And even less memory being used when it's at 4. It does seem to run smoother when the break angle is set to 90 (with the facet angle at either .5 or 4). But I may need to change those back when i do the engraving patterns that caused me to fiddle with them in the first place.

The lookahead is so high because I was getting some type of buffer under run error that suggested increasing it. That may also have been because of the extremely low "facet angle". So,,,probably that can be set lower as well....which I'd like so that feed override settings take effect faster.

I was just doing short tests this afternoon...and will run the full job either tomorrow or Monday. I'm sure I'll see similar results to what you saw.

Thank you very much for digging into this.

randy

[TomKerekes]

Hi Randy,

Thanks for posting back. Yes Facet Angle of 0.05 deg would put 200 segments into a single 10 degree angle change which would use large amounts of memory and USB bandwidth.

Good luck
Regards