Machine stopping.

[slipshine]

Tried the new version 1.0.5. Still stopping made it 25% threw a 3 hr print.

As a note after I disconnected and re connected I was able to control the fans and the Axis Movement. But Unable to get any responce from either
temp settings. I can post the code that it stopped on but its just like the others.

I uninstalled 1.0.4 and 1.0.5 and just reinstalled 1.0.5 and will don some more testing over the weekend. Right now having to print from SD Card.

[Simplify3D]

Ok, so a few more questions as we continue to dig into this.

1) I looks like everyone who is having issues is using Win7 64-bit. Has anyone has this issue on another OS or does it appear to be isolated there?
2) Pretty sure I've already seen this from the log, but the position and the exact command where the build stops is not consistent, correct? So it isn't stopping at the same line every time?
3) Have you tried slicing with 1.0.5 and printing with 1.0.5? Some of the changes affect the actual G-Code file so I want to make sure we aren't still printing a 1.0.4 .gcode file through the 1.0.5 GUI.
4) Has anyone had this issue pop up with temperature monitoring turned off in 1.0.5?

This has been a tough one for us to fix since we haven't been able to reproduce it on our Win7 x64 machines despite numerous multi-hour prints. We can attempt to make fixes, but if we can't reproduce the error it's hard to verify if the fix actually worked, that's why we need you guys!

To give you an update on what we're thinking right now, the problem is definitely caused by the fact that the software does not receive a response back from the firmware. It sends a command and doesn't get an "ok" back so it assumes the firmware is still processing one of the commands in its buffer. It is typically not a good idea to send without receiving the confirmation since that can create buffer overflows or lost data. I have done some investigating into the methods used by other programs and several of them just use tons of sleep() commands, which seems like a bad avenue to pursue. In essence, a lot of them send a command and wait for a specified time (say 500ms) and then send the next command. That doesn't give you any assurance that the individual command you just sent is not a 5.0 second slow move and thus you can end up sending commands before the firmware is ready. We have a few other ideas we are going to test that seem like a better approach.

Can one of you guys post an example .gcode file that keeps pausing on your M2? Ideally one that isn't too big so we can test is repeatedly without wasting too much time.

And if you're seeing this issue, I would suggest printing through the SD card while we work out a fix.

[slipshine]

It doesnt seem to just be mulit hour printing. i would say its closer to around the 45 minute mark but occasionally sooner.

I am attaching a part that doesnt use much fillament that generally fails 1 out of 3.

Let me know if there is anything else I can do.

gift-clip.zip

g-code 1.0.4

(208.94 KiB) Downloaded 629 times

gift-clip-2.zip

g-code 1.0.5

(204.26 KiB) Downloaded 588 times

[Karl_Williams]

On my Gen6 board running marlin, it freezes after the last line of g-code has been run. This happens every time with 1.0.4 and 1.0.5 (I hadn't tried printing before that). After running the last line it just sits there indefinitely. I ran a job last night and it sat in that state for 6 hours until I clicked the stop button. Here are the last few lines in the com window before I click the stop button:

SENT: G0 Z10 F150
RECEIVED: ok
SENT: G90
RECEIVED: ok
SENT: M104 S0
RECEIVED: ok
SENT: M140 S0
RECEIVED: ok
SENT:

When I click the stop button I get manual control of the axis back but now the temperature polling has stopped. Here's the com window after clicking the stop button:

Total build time: 79.62 minutes

Enabling and disabling the temperature monitor doesn't do anything and the clear temperature plot doesn't work either. I also tried enabling and disabling the verbose logging and that doesn't work either. If I manually send an M 105 then it returns the temperature and updates the temperature displays.

SENT: M 105
RECEIVED: ok T:27.63 B:30.00 @:0

Note that I've never had a freeze happen during a print, just after the last line of g-code.

P.S. I'm getting some seriously nice prints now that I've fine tuned it for my mendel. Better than anything I've done with Skeinforge and Repetier host.

[Karl_Williams]

In my last post I mentioned enabling and disabling the verbose logging and what I meant was that it doesn't restart the temperature polling. Everything else is logging in verbose.

[Simplify3D]

It looks like it's sending an empty line to the firmware and expecting a response. Can you look through your G-Code file for blank lines? If it's happening at the end, I would start there. Version 1.0.5 shouldn't send any empty commands, so I'm a little surprised to see that in your comm output. Try deleting the last few lines in the file so the last line is M140 S0 and let us know if that fixes things.

And you should post some pictures of your prints! Maybe we should start a thread for showing off recent prints with Creator... I just printed an octopus that I'm particularly proud of

[Karl_Williams]

Yep, that fixed it! I deleted everything after the M140 S0 line and it finished properly. The temperature polling is still working as well.

[Sparky]

Thanks for the tip! It appears (finally) that blank lines in gcode were the cause of serial halts when I tried USB streaming in 1.0.4. Oddly though in 1.0.5, sample file bracelet.g (containing a couple of blank lines) will USB stream OK from the SD in the PC, but when copied to the HD it will not stream from the HD. Yet if the blank lines are edited out, it will then stream from the HD.

I'm impressed with the performance and appearance of 1.0.5. Nicely done! A couple of trivial feature requests: monitor ticked ON by default, and color digital temp display i.e. bright red digits on dark red or black background, or bright green digits on dark green background to simulate an LED readout and enhance visibility.

[slipshine]

After a weekend of printing after uninstalling 1.0.4 and 1.0.5 and reinstalling 1.0.5 there appears to be no change in my problem.
I am using and windows 7 64bit (AMD Quadcore Processor) and a Makergear M2 Factory built In Nov. 2012 unmodified.

While printing it will just stop at various places. Sometise in 5 minuted 90% within an hour.

When it stops the build platform and extruder stay on. If I hit the E-Stop and reconnect I will have contorl of the axis
but the monitors (Graph & Digital) will not show change. I must exit the software and go back in.

There are 2 ways I can print. I can either Copy the files to the sd card and print without error. Or if I use Pronterface to run the g-code there are no issues so that is what I am doing. I know that is not what you want to hear but hopefully this will lead you to a possible solution.

I do like the software I am working on some .1 profiles. all that I ask is dont give up.

Let me know if you need anything else from me?

[Simplify3D]

We definitely didn't stop working on this! We've been printing parts pretty much non-stop for the last 5 days with our test machines to see if we could get this to pop up. Lots of long multi-hour prints. We thought we saw it once, but then we realized it was just because one of the computers went to sleep.

Until we get this completely nailed down, here's what we've already done for the next version (1.0.6) to help. We added uploading to the SD card via USB to make your job a little easier if you don't want to unplug the card each time. We're also adding in a "Force Continue" button that basically allows you to force a print to continue if it stalled (better option than pressing the E-Stop button and it won't reset the build). We're also going to take another stab at solving the root cause, but you guys will have to let us know if it's successful.

slipshine - Do you have another machine besides Win7 64-bit that you could test on? Is anyone out there still seeing this error on any OS besides Win7 64-bit? It will help a lot if we can figure out if it's OS specific. And I'm guessing you're using the stock M2 firmware from 2012, right?

If no one else is seeing this on another setup, I'm starting to think it might be a x64 driver or maybe something specific to your hardware...