Don’t know where to start with this… GC or firmware?
Here is one of my large gcode files. It’s dither pattern drilled with a v-bit at varying depths. The first image is GroundContol’s render of the file, as it should be. Second image is what it produced at the cutter (stopped about 25% through).
It starts at the upper right and works its way up and down the diagonals.
Then for some reason it randomly jumps down some distance in the middle of some lines creating the voids you see between sets of lines. There was no binding in the linkage or chain link skips… motors just sent it down randomly.
I’ve checked the Gcode where the jumps occur and rendered it in several different tools, but I don’t find any issue with the gcode itself.
I am using GC .99 and the matching firmware Using triangular linkage kit. Seems to calibrated well enough on the holes it drilled correctly. It just seems to lose its mind very once in a while.
chain skips can be very fast (need to view in slow motion to see them), but that you are seeing sure looks like a chain skip problem on your right motor
Thanks for the super fast reply gents. I’ll make some adjustments in the way the slack links hang and see if I can get it all a little more in parallel. In truth I think I’ll make chain guide out of delrin, over the holidays to help things stay straight.
Yes, I was tiring of cutting squares, so I set up something that would test the limits a bit. (Apparently a lot… as getting the gcode to load into GC at the right home position is a bit of a chore.)
Appreciate the insight.
Incidentally, I don’t recommend the dither thing unless you have lots of time. That whole thing is about ~5500 plunges. About 25% of the way through took 5 hours. Z axis speed is a killer. I have the retract set to .125 inches to minimize wait time but still takes forever. Maybe I’ll chance it and go .07 and hope my wood is not warped at all.
Thanks for the super fast reply gents. I’ll make some adjustments in the way the slack links hang and see if I can get it all a little more in parallel. In truth I think I’ll make chain guide out of delrin, over the holidays to help things stay straight.
look at the plywood chain guides that were posted here recently.
Yes, I was tiring of cutting squares, so I set up something that would test the limits a bit. (Apparently a lot… as getting the gcode to load into GC at the right home position is a bit of a chore.)
what were the problems you had?
Incidentally, I don’t recommend the dither thing unless you have lots of time. That whole thing is about ~5500 plunges. About 25% of the way through took 5 hours. Z axis speed is a killer. I have the retract set to .125 inches to minimize wait time but still takes forever. Maybe I’ll chance it and go .07 and hope my wood is not warped at all.
We should be able to just swap out the motor for a faster one to improve this.
There was a link posted a couple days ago to a whole set of options.
look at the plywood chain guides that were posted here recently.
I made some modifications with a couple of carabiners and swivels to get the slack side and load side of the chains almost in parallel. Will take a look at the chain guide you suggest.
what were the problems you had?
The large gcode file just crashes GroundControl without any useful error. I am now running from source with 64-bit Python 2.7.14 and it loads now,but I can’t redefine home without a similar crash. So my workflow is to load up some small junk gcode, redefine home, and then load the large file. This too sometimes crashes, but restarting GC after this, has the new home and large file loaded.
We should be able to just swap out the motor for a faster one to improve this.
I saw that thread and didn’t think much of it until I tried the dither project. Now I understand.
A very interesting project.
Would you be willing to share the .nc?
Similar issues, with the sled teleporting, skipping parts of the code have been seen, caused by
buffer overflow
no blanks in the code
to many blanks in the code
lines with single X or Y moves
All of above is solved as far as I know. You might have found something new.
it occuresto me that since you did not finish the cut, we haven’t looked at how
the g-code is laying things out.
when it’s pecking at things, does it start in one corner and work diaginally? or
does it move horizontally (skipping some spaces)
it could be that the g-code will come back and finish these sections. Did you
try loading it into a g-code simulator to see what it’s doing? something like: https://nraynaud.github.io/webgcode/
I like @dlang’s guess that it is planning to come back and fill in those spots. Depending on what program is used to generate gcode the algorithms that decide the order that things are cut in can result in some strange behavior where the code will cut something part way, then go cut something else and come back.
This is an easy possibility to rule out by running the gcode through a simulator to see what the order will be…although on re-reading your original post it sounds like you have probably already done that and ruled out that possibility?
it could be that the g-code will come back and finish these sections
That was my thought as well… which is why I let it run 5 hours, but I can clearly tell that each ‘section’ fits in the previous one, like a puzzle piece, plus the overall location of the sled (as seen in GC) wasn’t jiving with where it was on the workpiece. So then I ran the gcode through several different simulators to verify.
It starts at upper right and and moves back and forth line by line toward the lower left.
Last night late, I started making a few modifications to the chain slack tension setup to try to keep things a bit more in line, but I may just end up, this evening, cutting out one of the chain guides that has already been shared herein, to eliminate that as a possibility.
To get around the issues with the large file in Ground Control I’m currently running from source with 64-bit Python 2.7.14. Still slow, but no crashes unless I redefine home. I also tried packaging with Pyinstaller but it seems that the .exe. that it delivers is really more about packaging up the python binaries and not really compiling the script. i.e. the script is still being interpreted at runtime and thus has no performance improvements over running from source (at least that I can see). If you know differently then please share.
I started messing around with Cython which does compile the python script. I got a build compiled. The exe starts like the portable one (loading SDL and such) but it does not recognize the ‘import’ modules… more to understand there.
Thanks for everyone’s input. Truly great contributors on this forum!!!
nevermind… it lost its mind again. This time it started trying to raise the bit into the heavens. I caught it and got it stopped before breaking anything. After I reset the z axis to zero, I thought I could pick up where it left off, but now the directions are all kacked up again. Up command goes up right, down command just whines and doesn’t move. I’ve restarted, rebooted, reloaded and cleared eeprom. nothing. ‘Test motors’ seems to work but nothing else.
I think I’m done on this project. too much time invested with nothing but frustration to show for it.
Thanks for sharing the gcode. My GroundControl crashed right at trying to load the file.
Konsole: radeon: mmap failed, errno: 12 Fatal Python error: Couldn’t create autoTLSkey mapping
Will dig deeper into this.
It is a new stress test for firmware and GroundControl.
It’s people like you sharing their trials, that make this project better day and weekly.
Thank You!
I thought better of abandoning the project, after taking some time to reset myself. I still don’t know why I couldn’t recover control of the unit after all the resets, reloading firmware, etc. So what I ended up doing:
Using a spare arduino that I had (thanks to bar), I loaded the .99 firmware on it.
Then used the portable release of GC from the site to test control of the sled (eliminating my 64-bit as a source of issues). That worked.
Recalibrated chain length\position.
Went to the 64-bit version of GC (needed to load the large file). Everything working at this point.
Found the spot in the gcode to restart where it left off. (position was off a mm or so, but I can live with it).
Restarted late last night
Slept in my truck so I wasn’t far away
Still running well so far this morning
Barring any more issues, it appears it will be done around 7:00 PM tonight. 20-something hour run. (May need to change out the brushes on the router if it makes it through this).
This is definitely a stress test, of both the software, the machine and me.
Curious what you find Gero. Thanks for looking into it.
Looks like I am hitting hitting a memory limit (in Python I guess).
10000 lines render well. Wondering if I keep adding lines until it crashes would match with where your drills start skipping.
Edit1: I could push it up to 15225 line of code. There it will render, but if I click on ‘Actions’ it crashes.
So do we have a limit at rendering max 30000 red and green circles? The error mentions my Radon, so could this be a hardware limit? Definitely memory running out somewhere.
…something to do with a memory limit was my guess as well.(hence trying 64-bit) However I don’t think it is strictly an “amount of memory available” issue. I tested it on my PC at work using the portable version of GC (.99) which is 32-bit (Python 2.7.11) and it opens just fine! No 64 bit or source needed. It is a windows 7 machine vs the Windows 10 machine I have at home. (Also, nothing is cut off at the top in windowed mode) Confused…
Can only test with Ubuntu 64bit and Python 2.7.13 right now.
Interesting enough for me, as I want to drill full sheet pegboards for my workshop and might run into the same issue. Wonder if @bar finds it interesting too
We would need some more testers to dial in, if hardware or OS is giving different results.
As a workaround, a switch to turn of rendering of Z would help short term to get rid of the crash.
More interesting is, if it is a different issue from skipping cuts or are they related.
My hunch on what’s going on is that GC is just running out of memory and doing something really weird like dropping the serial connection. The way we made GC use much less memory was to make it so that many lines in a row are now rendered as a single continuous line. Each line object which gets rendered takes some memory, so making many small lines into one large line saves a lot of memory. A line can have up to 62,000 points so we render the gcode as all one line until we get to a z-axis change at which point we switch to a circle to mark the location. Because this gcode is super complex AND has a TON of z-axis changes it looks like it might be the perfect storm for not doing well in our memory conservation system.
