MEGA shutdown...Solved - Delta Segments Per Second Issue #6703
Comments
|
Try dropping your feed rates in half & see if that solves the problem. If the step rate is too high Marlin won't have enough time to finish all its tasks. Locking up is one symptom. |
|
Thanks for the suggestion, I'm pretty much open to try anything at this point....:-) I dropped the feed rates by half, the whole thing locks up at exactly the same point, but now on the first pass of the prime.
Re-Flash with 1.0.2 and, as usual, it prints the same GCODE file perfectly. There must be some GCODE oddity that pertains to delta movement that sends the code into an infinite loop. I guess. Maybe...:-) |
|
So I have a similar issue where in my G-Code, I tell it to extrude 3mm of feed stock. It starts extrusion once reaching temps and then doesn't stop. Reverted back to RC-8 and problem doesn't exist with same G-Code. It only happens in 1.1.1 when I have pidbedtemp enabled. If I disable it, it works fine. I have it enabled in RC-8 too so I guess there is a bug with pidbedtemp or something relating to it. |
|
What bed leveling system are you using? For a Delta, the position it locks up is pretty much at the 'worst case' as far as print radius goes... There is a Delta version of UBL merged now if you are brave... |
|
I level my Kossels manually every two thousand hours when I replace the PTFE tubing inside the heat break throat. Other than that, they never change. But you know, there may be something on that radius thing. I recall seeing a new item on a delta radius setting in the config, I kept the number smaller than my bed but maybe I kept it too small..although if it's the second pass, it's already inside of the first pass...just weird...LOL I'll adjust that radius setting and I'll check the pibedtemp as well...thanks for the brain nudges! |
|
I changed the value of the radius setting (made it the size of the print bed, and then larger just in the off chance; you know when desperation kicks in), the print quits at the same point as before. I have PIDTEMPBED disabled. Still goes brain dead. So, for the meantime, back to 1.02 and printing normally. Sort of feel like Edison where I know yet another way that doesn't work...LOL |
UBL works on Deltas now... At least... it appears to do the right thing... |
|
UBL would be super for those that don't want to dive in the technical aspects of the printer and thus would be welcome update for a lot of users. The part that attracted to me to the latest firmware was the DELTA_TOWER_ANGLE_TRIM, and DELTA_DIAGONAL_ROD_TRIM_TOWER. I'd already modified the 1.0.1 and 1.0.2 code myself so I could adjust each tower but having it in one place like 1.1.x made things a lot easier. Plus the planner seemed much better with SQR routines. I normally run the DELTA_SEGMENTS_PER_SECOND at 200. At that setting those 3D_Benchies at 50 micron layer heights come out fabulous. Jezz, I wonder if that many segments is giving Marlin fits. mmmmm... something else to try I guess... |
|
AH HA!!!!! Solved....owe you one Roxy for shoving me in the right direction! Thanks! DELTA_SEGMENTS_PER_SECOND.... set it to 200, nope. Off we go into the deep blue sea. Lock up. Set the segments to 160, prints the exact same GCODE just fine. So at some point north of 180, we go off to never never land. Course this means some of the "sample configurations" for deltas that have the segments set to 200 are going to crash, die and burn too... Have to do some tests now to see if 1.1.1 with 160 steps is equal to the quality of 1.0.2 with 200 steps (on curvy things)...:-) |
|
DELTA_SEGMENTS_PER_SECOND 190 works. I'm now wondering if there are curves next to the tower locations that it causes more calculations and errors than a print in the center of the bed. At any rate, least I know why the MEGA locks up. |
wabbitguy
changed the title
|
Thanks! There's probably something funky going on with that segments-per-second usage. Perhaps as it gets close to the threshold something goes towards zero or infinity. We'll keep an eye out for this one coming up again. |
It might be useful to turn on the M100 Free Memory Watcher and initialize it. And set the DELTA_SEGMENTS_PER_SECOND 225 so you know it is in the failure zone. I'm thinking if the CPU gets saturated... we have interrupts interrupting other interrupts and winding the stack up. If you set that number and just do one big move across the print area and see how much free memory is left, that would be a very good clue if we are running out of memory with a higher segments per second number. |
|
@Roxy-3D I turned on the Free Mem Watcher, set the segments to 225...sliced a single line 170mm. No prime loops, fill... so 170 x .5 x .5 Did the print (all 4 seconds worth:-), sent the M100 F: Created a circle 180 dia x .5h x .5d Did the print and used M100 F: I was kind of amazed that with 225 segments the printer even worked. Especially on the circle...but again, I was doing it at 180mm, my bed is 220mm. So I resized the circle to 210mm. And printed again. I did notice some stutters right in front the towers but it printed. After the print was done: Just off the cuff, it doesn't look like a memory issue. But I'll give it a 9 out of 10 on the head scratcher scale... |
|
Good! You have a pile of memory left! The thing is... when weird stuff starts happening... Memory over run is some times to blame with really weird behavior. That is off the table. |
|
Ah yeah, I remember stack, heap and memory issues from when I started programming in assembler in 1978 (there I dated myself)... I have the STL file, so I'm going to starting toying around with it and see if I can maybe narrow down it a little more. And I'm going set the temps in Marlin to allow dry runs for testing. If you feel that's a bad plan, let me know. |
No. It is not a bad plan. Every once in while that happens. Here is what I would do... In PronterFace, one of the options is 'Debug Communications'. Turn that on. Marlin buffers stuff. So what ever is on the PronterFace screen when it dies is actually after the bad stuff. But not that far after. That lets you chop out a huge amount of GCode and get to the stuff causing the problem very quickly. |
|
I'm on it like a fat kid on a Smartie...let you know what I find! |
|
@Roxy-3D - did a lot of testing today... Segment steps 225...same sliced design as noted in first post...I added it here... Note I edited out all the RECV: ok because they were all received ok except as noted on the last lines... Printer died in exactly same spot as always...gCode: no RECV on this line, lockup at this point - power cycle to get back online... Changed segments to 199. Rotated STL 45 degrees... no RECV on this line, lockup at this point - power cycle to get back online... Resliced, no prime loops at all, just print the design. Still 199 segments. Back to same orientation as original. no RECV here, printed the entire first layer, almost made it through the second layer. And off once again to never never land.Off to Thingiverse and downloaded this puppy design: Sliced it, fired up the printer and it printed just fine at 199 segments and I used a skirt prime on it as well. So it's something unique I think to the STL design I have.Next, I edited my original GCODE file that caused the problem so it was just long enough to get passed the point where it would lock up. Printed it, and sure enough it locked up where expected. I then edited the gcode file down to a point prior to that. Sent that to the printer, it printed to that point and stop. From that point, I had the file open in NotePad and I copied and pasted each line from Notepad to Pronterface and the printer made it past the gcode point where it would go out to lunch. Which really ticked me off... Copying and pasting line by line should cause a problem at the same point, it didn't. Granted it's a lot slower than the 250K that Pronterface can send it, but really that shouldn't cause a problem. Maybe. I think. Ah heck, I don't have a clue. |
It depends on a lot of things. First what is causing the lock up... But also it it related to using up all of the CPU. Marlin buffers up commands so it always has something to work on. By feeding the lines one at a time, we don't have the extra activity that having the command back to back will cause. I'm just saying... That changes things. But on these kind of problems, my experience is it is very helpful to know exactly which line of GCode is causing the lockup. Because then we can start adding debug information and see if we can figure out what is going wrong. Let me think about this a little bit. That last move(SENT: N88 G1 X-15.045 Y90.427 E89.76025*69) is a long one. We can get more information by making the move shorter. And maybe by sending it a different direction. If we can figure out what the lock up is dependent upon, it makes it a lot easier to find the problem. |
|
LIN_ADVANCE has never been enabled for any of my tests. It's commented out. |
|
I just reverenced to here because it seems LIN_ADVANCE creates extra trouble on deltas due to not sufficient cpu power. |
|
Yep. It was a two fold problem. First was the DELTA_SEGMENTS_PER_SECOND setting of 200. While this is fine in most cases, if you’re sending the GCODE from Octoprint or Astrobox it will cause all kinds off issues. Mainly because neither Octoprint or Astrobox can send that many short segments so you get timeouts, loss of communication and the big stall.
Even with the last 8bit Marlin 1.1.9, the same issues appear.
After a LOT of test prints, I found scant little difference between using DELTA_SEGMENTS_PER_SECOND 200 and 120. Delta segments in my tests needed to get down below 100 before you could start to visually see the difference. So my segments are set at 120 now.
Note, if you print off an SD card you’ll never seen any of these issues. Bandwidth from the SD is far higher than the USB port.
I also found that with 1.1.9, the serial (USB) is much better but Octoprint and Astrobox has speed limits. Octoprint is 48mm/s capped, Astrobox is 55mm/s. Those are for any curves, not straight lines. The only host software I found that works, and has the ability to drive two printers at the same time with 100/mms is Repetier Server. It’s what I use now and drives both of my deltas just fine.
Mel
---
… On Apr 16, 2019, at 6:42 AM, cinealfa ***@***.***> wrote:
wabbitguy, did you ever figure out what was causing this
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Both the Marlin 1.1 and 1.1.1 on my Kossel starts the printer "prime" sequence, and on the 2nd of the 3 passes, it completely shuts down the MEGA so it's completely unresponsive without a power cycle.
The GCODE is being sent via Octoprint 1.32.
The GCODE at the point of abrupt brain fry:
Kossel Delta
Non-switched power supply
In the config suggestions, I've tried the configuration files from delta: Generic, Mini, Kossel Pro. The only difference is in the Generic. With it, the point the printer shuts down at is the same, but it's on the first prime pass, not the second loop.
I tried Slic3r, 1.2.9, Slic3r 1.30 DEV, and PRUSA's Slic3r. 1.2.9 will get about 60% through the first layer and the MEGA goes into never never land.
When the MEGA heads off to 1 infinite loop with Marlin 1.1.0 or 1.1.1, I can disconnect Octoprint, and reconnect, but the MEGA does not reset and come back to life. The LCD remains frozen, the MEGA needs a power cycle to bring it back to life.
Reflash with Marlin 1.0.2, the exact same GCODE file prints perfectly.
Configuration.h.zip
I'm thinking I must be missing some timer, or setting in Marlin, but I have no clue as to what it might be.
The text was updated successfully, but these errors were encountered: