Large g-code crashes linuxcnc

[Jay S]

As the title suggests.

Large (90mb+, maybe less) files crash linuxcnc.

I have a 400mm cubed build platform and have been trying take advantage of it

[andy pugh]

It might be the graphical preview getting bogged down, if you are using Axis.
If you are using axis (and only if) then you can inhibit the preview,
it might be worth seeing if that helps.
http://www.linuxcnc.org/docs/html/gui/axis.html#_axis_preview_control
(section 11.7)

(As an aside, I don't know where the Machinekit documentation is?)

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Michael Haberler]

could you a bit more specific than "crashes" and "large file"?

In terms of error reporting, please follow these guidelines: https://github.com/mhaberler/asciidoc-sandbox/wiki/Reporting-an-error-with-Machinekit

also, posting the ngc file would help - error reports which cannot be reproduced are interesting but useless

Very likely you're just exhausting memory. You could try to enable paging by adding a swap device, or shrink the file by preprocessing, for instance lines2arcs can reduce file size a lot:  http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinesToArcs

- Michael

[Alexander Rössler]

It might be the graphical preview getting bogged down, if you are using Axis.
If you are using axis (and only if) then you can inhibit the preview,
it might be worth seeing if that helps.
http://www.linuxcnc.org/docs/html/gui/axis.html#_axis_preview_control
(section 11.7)

Just to mention. I have tried the commands and they did not work (or at least they did not solve the problem). 

[Michael Haberler]

Those commands cut down on preview graphics sent to the UI. They will not reduce the size of the internal representation of the  program held within the milltask process, so no significant improvement on memory usage can be expected.

The way this is designed, the whole NGC file is parsed and held in memory, for - among other things - boundary violation detection. This will necessarily result in problems if you run huge NGC files on a machine without virtual memory backed by swap space, which is usually the case with machinekit setups on embedded systems.

The ways to deal with the issue are either at the NGC program level (eg reducing the size by optimization like through lines2arcs), or at the platform level.

At the platform level the only realistic option right now is adding swap space. There is no 'fix' for running out of memory without swap space.

If running such huge files become the norm on non-VM embedded systems, then one way to address the issue is to modify interpreter/task to limit readahead from 'total program' to say a few thousand lines. This requires a code change.

Downstream we should be able to relegate embedded systems for what they do best, realtime operations, and do stuff like parsing NGC file on larger machines like a laptop or some PC, and only send the result to the RT appliance for execution. Again, coding work required.

- Michael

[Kent A. Reed]

On 05/07/2014 08:44 AM, Michael Haberler wrote:
> If running such huge files become the norm on non-VM embedded systems,
> then one way to address the issue is to modify interpreter/task to
> limit readahead from 'total program' to say a few thousand lines. This
> requires a code change.
>

Implicit in "this requires a code change" is the need for a separate
preprocessing program which sucks in a G-code file and spits out a file
optimized for this approach, yes?

Regards,
Kent

[Michael Haberler]

no, I didnt have that in mind - rather being an alternative to preprocessing, but at the platform level

the issue right now is:

interpreter sucks in a humungeous NGC file, spits out canon commands (C structs for you geeks ;), same go on a list in-memory

list grows too large - shit happens on non-VM systems

so the idea is to limit the memory requirements of the list - one being: limit interpreter readahead and hence implicitly the size of the downstream list; that means the interpreter (or task) cant just dump canon out, it must observe a credit limit and wait if this is hit - more credit will be given as commands are executed and removed from the list

another idea I had today is - write the canon commands to a tmp file instead of a in-memory list - AFAICT they are accessed in-sequence only

but I really rather have that problem solved by moving off the interpreter from the RT platform altogether, this doesnt scale

- Michael

 

Regards,
Kent

[andy pugh]

On 8 May 2014 19:57, Michael Haberler <habe...@gmail.com> wrote:
> but I really rather have that problem solved by moving off the interpreter
> from the RT platform altogether, this doesnt scale

"Not scaling" doesn't seem like a sufficient reason to abandon the
"everything running on a single PC" option that is working perfectly
well for thousands of people.

[Eric Keller]

On Thu, May 8, 2014 at 4:23 PM, andy pugh <bodg...@gmail.com> wrote:

On 8 May 2014 19:57, Michael Haberler <habe...@gmail.com> wrote:
> but I really rather have that problem solved by moving off the interpreter
> from the RT platform altogether, this doesnt scale

"Not scaling" doesn't seem like a sufficient reason to abandon the
"everything running on a single PC" option that is working perfectly
well for thousands of people.

I had the same thought, and there are tons of people that are going to want to run the software on a BBB that also drives the interface just because it can be done.  These things aren't mutually exclusive, you can always use a network topology over localhost.

[Michael Haberler]

On Thursday, May 8, 2014 10:23:38 PM UTC+2, andy pugh wrote:

On 8 May 2014 19:57, Michael Haberler wrote:
> but I really rather have that problem solved by moving off the interpreter
> from the RT platform altogether, this doesnt scale

"Not scaling" doesn't seem like a sufficient reason to abandon the
"everything running on a single PC" option that is working perfectly
well for thousands of people.

Not sure where you get the "abandon" from - this is all about adding an option which is not there, not about taking one away

but maybe we can agree on that not every task rammed onto an embedded system with no VM actually makes sense to run  there

as for the perfection of the single PC option: yes it runs fine, given the right percentile of motherboards and assorted esotera

But then, good luck to those who think this - as a single option - is a reliable path into the future, and for the past I wonder why it hasnt become a mainstream package - it might just be the integration problems are so pathetic this has no chance whatsoever becoming a technological choice outside the current determined circle willing to fight uphill until the last motherboard has been recycled

- Michael

[tylor abel]

I just got hit with this today also, i am trying to print a 17Meg file, i added a swap space and i watch it fill up.  when the axis progress bar gets to about 80% the axis window shuts down and when i do dmesg the last entry says system ran out of memory.  i was typing free in the background while the file was being opened and although i added 256Meg of space into the swap it wouldent fill past 70Meg.  Ill look more into this lines2arcs thing unless someone else has any ideas/workarounds.

[Kent A. Reed]

Tyler, Jay.

Full disclosure: I haven't created G-code files big enough to trigger the roadblock you've run into so this is hypothetical.

The memory allocation scheme in Linux has long since gotten so complicated I don't really understand it. Doing a little digging this morning, I found this article on the Linux Out-Of-Memory issue which gives me some ideas about what one would need to do experimentally to understand what's happening when LCNC/MK is processing large G-code files like yours. Two points in this article which catch my eye are items 2 and 3 (especially the concluding line in 3) on the list of "important things to remember." Swap space is not all it used to seem to me.

You may be able to see your way through the details faster than I can.

http://www.linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html

Regards,
Kent

[Justin Edwards]

Replacing axis with tkemc (in the ini display section)  will get you past 17mb file crashes.  The interface isn't very intuitive for people with delta printers though.  You'll have to switch modes a few times each session for homing and Z moves.    

[andy pugh]

On 5 October 2014 12:57, Justin Edwards <justinl...@gmail.com> wrote:
> Replacing axis with tkemc (in the ini display section) will get you past
> 17mb file crashes.

That suggests that the problem is actually in the Axis preview. It
would be interesting to see if
(AXIS, STOP)
Near the top of the file also prevents the crash.

[Schooner]

It will, ( at least partially ), the problem does seem to be the preview
in Axis

See later entries https://github.com/machinekit/machinekit/issues/193

[Kent A. Reed]

I absolutely agree that Axis and especially its preview function is
problematic, not just for memory-usage but also for performance reasons.
I measured and posted some data about its behavior vs alternative UIs in
both local and remote display conditions when we were first
experimenting with Beaglebones.

Still, I would love to have more data in hand to support making our
real-time control system more capable of dealing with memory-usage
problems than crashing unceremoniously. Imagine a purpose-crafted Linux
OOM Killer (you can look it up) which does a better job shedding
less-critical processes in an attempt to keep the mission-critical
process(es) going. Pie-in-the sky for sure, but the goal seems worthy.

Regards,
Kent

[Schooner]

A programmatic alternative to the (AXIS, stop)

If you comment out lines 1114 to 1127 in Axis (open_file_guts() )
that will completely disable the preview on file open, without affecting
anything else except that you will only get error
advice when you run the code as opposed to when you load it, if for
instance a move exceeds the soft limits

You will still get a plot which follows the cut in real time

I don't have a big enough file to test this with properly, as I don't
use reprap and CAM etc

regards

[Charles Steinkuehler]

On 10/5/2014 8:29 AM, Schooner wrote:
> A programmatic alternative to the (AXIS, stop)
>
> If you comment out lines 1114 to 1127 in Axis (open_file_guts() )
> that will completely disable the preview on file open, without affecting
> anything else except that you will only get error
> advice when you run the code as opposed to when you load it, if for
> instance a move exceeds the soft limits
>
> You will still get a plot which follows the cut in real time
>
> I don't have a big enough file to test this with properly, as I don't
> use reprap and CAM etc

Very cool!

Anyone with enough GUI programming savvy to make this a configuration or
ini file option? I'd love to be able to run this way on my 'Bone
powered 3D printer, but I don't think this should be forced onto everyone.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Bas de Bruijn]

On 05 Oct 2014, at 13:57, Justin Edwards <justinl...@gmail.com> wrote:

Replacing axis with tkemc (in the ini display section)  will get you past 17mb file crashes.  The interface isn't very intuitive for people with delta printers though.  You'll have to switch modes a few times each session for homing and Z moves.

I tried Gscreen, even Keystick (which crashed a few times), and I don’t understand why I havent tried tkemc. I Just did so and my file of 17MB loads and prints without problems. Normally I would try to not make files bigger than 5 or 6 MB.

Thanks for sharing

Bas

[John Morris]

http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html

See the part about `/proc/PID/oom_adj`.

John

[Justin Edwards]

I was trying some large prints to test out my new delta and gcode files would easily go over 30mb.   I printed one print successfully starting last night @ 38mb (about an 11 hour print)  and it did fine with tkemc.    It isn't uncommon for me to have very large gcode files.  

Here's a couple videos from earlier with a small print.  https://www.youtube.com/watch?v=C8SRLnpdM8E  https://www.youtube.com/watch?v=PK2ubfZ8SDY    

[tylor abel]

So i changed "display = tkemc"

i got it up and running, towers x,y,z and extruder A homed.  i hit run and it moves down really fast, then i get joint following errors.  i turn machine power on again from the pull down and i extrude a much of plastic... weird.  can you list your steps from 1 to print with the tkemc display so i can follow in the steps of greatness.

Thanks

Tylor

[Justin Edwards]

Before running again go back to MDI and do g92 A . 

After homing I do g1 Z30 F2000 to get it into position. Then switch to auto then run

[tylor abel]

I found out where this speed joint error was coming from.  using kisslicer the x/y speed was set to 500mm/sec, at 60mm/s print speed it was taking the 500x60 and giving me a F30000 travel speeds.  i have toned this down and now dont have joint issues.

[Kevin Bragg]

Hello again all.  I'm having trouble with LinuxCNC crashing on the "large" files.  I'm attempting to accomplish this step:  "If you comment out lines 1114 to 1127 in Axis" ... what exactly does this mean?  If I can just be pointed to the file which I need to modify, I can go from there!

Thanks as always for the help.

[schoo...@btinternet.com]

That is an old post

I made a commit quite some while back that enables the complete disabling of preview, along with many other feature changes in Axis
https://github.com/machinekit/machinekit/commit/286e4a4089f260ca298c01ea5f9c87be59ea7e7a

The docs were amended too
https://github.com/machinekit/machinekit-docs/blob/master/src/config/ini_config.asciidoc

regards

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at http://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[schoo...@btinternet.com]

Basically it means that the ability to disable preview in the ini file is now part of machinekit.

You would need to upgrade to fairly recent build or do a fresh pull of the repo.

Be aware however of Michaels recent warning of changes involving tp and kins loading syntax in hal files,which break backward compatibility.
The change to the files takes 20 secs if you familiar with them, but be aware.

regards

On 06/03/2015 04:31, Kevin Bragg wrote:

Wow.  Thank you!  I don't know what all this means.  I'll digest it this weekend!

Kevin