Machine stopping.

[slipshine]

When printing from the usb with monitor off or on the machine will just stop.

It always makes it to a different place. And sometimes compleats the print.

Using 1.0.4 windows 7 64 bit. Makergear M2.

Have never had this before swithcing to this software.

It has never done it while I was working on the computer. I am always away when it stops.
I originally thought it could be some screensaver or power setting thing but I have them disabled now
and it still messed up last night.

1st couple of time it turned off the drives and heat. The last time it just stopped. I havent tried
to print from the sd with your software.

Is there a way to send the file you want to run to the SD card then start printing from there?

Any other Ideas welcome.

[chuck12]

I posted a question on how to export g-code to sd card where I meant export to the sd card currently plugged in to the M2 as you can in Pronterface.
I still don't see a way to do that.

[slipshine]

Thanks Chuck12- Hopefully it is a undocumented feature.

I think it would be really stable if you could checkmark and option in settings and when you go to run
a file it would automatically copy it to the sd run the part and then remove it.
That would eliminate alot of potential micro timing issues. Just a thought.

[Simplify3D]

I like the concept of copying the G-Code to the SD card and then automatically printing it, but unfortunately the SD card file system has some very odd naming conventions that can be a pain to deal with. We've had some difficulty trying to predict it in the past so it might just be easier to require one extra click to select it and print. There's no way to upload to the M2's SD card via USB right now, but I'll put it on the todo list.

Slipshine - Can you do me a favor and make sure you Machine Control Panel is set to verbose mode so it records all ingoing and outgoing communications? The only reason I can think of that a print would stop like this is if the firmware fails to send a confirmation command or some of the response gets corrupted. You should be able to see the last few communications in the serial window when the machine stops and that should help us narrow down what's happening. And printing from an SD card should bypass any communication issues you are having since that is 100% managed by the firmware alone.

[mir4k]

I am confirming the issue from my side using Win7 64bit, Creator 1.0.4 / Std.supplied M2 PLA fff profile.
Tried a print 3 times and the machine just stopped mid-print (first with, second / third without temp. monitor.
From SD the same slice printed without any issues.

Neiter was the last command the same nor was the spot where it stopped the same, nor did anything "happen" on the computer (like screensaver or similar). I did however notice that the last command was always from PC to printer with no answer received. Of course, this might not mean anything with only 3 tries and a 50/50 chance for each. I have saved the comms for two of those attemps and will upload them asap (not at my printer right now).

I think I do have a (dirty) solution to the file system and it's unpredictaility concerning filenames. Just a thought:
- read all files from the sd card and store the names.
- copy the file to SD card
- read all files from the sd card and store the names
- compare readout 1 and 2 and the delta is the file that shall be printed (no user input required:)

Another option would be to generate a new folder each time, store the file (which is then bound to be the only one in the folder) and delete the whole folder when the print is finished.

Third option would be to always use the same, predictable filename when printing - overwriting the old one but thus be sure to always use the correct file. This would mean one singel may not be used by the user (For me this would be totally acceptable if I know it beforehand "(Hint" in the print dialoge, maybe ?)

[Simplify3D]

Good ideas. We were also thinking of just using very short random 5 character names (like A7HjR.g) and then just deleting the file after the print. If the name is short enough it won't get jumbled by the SD card file system.

And back the issue of prints stopping midway, we've been printing parts pretty heavily the last few days and haven't had this come up yet. Without seeing it firsthand, it definitely sounds like the problem is the lack of a confirmation message from the firmware. The software won't send another command until it receives an "ok" from the Marlin firmware. If the reliability of these communications continues to be an issue for you guys, we will need to investigate a different method. I know Creator sends G-Code extremely fast, so maybe some artificial limiting would help. We also made a slight change in version 1.0.5 (probably coming out tomorrow), that might help with this issue. But again, we haven't been able to reproduce it, so if you notice it again with the next version, definitely update this thread with your findings.

[slipshine]

This is what the end was like

RECEIVED: ok
SENT: M105 T#
RECEIVED: ok T:220.3 /220.0 B:109.5 /110.0 @:28
SENT: G1 X126.390 Y126.326 Z60.225 E7.13883
RECEIVED: ok
SENT: G1 X126.334 Y126.418 Z60.225 E7.14292
RECEIVED: ok
SENT: G1 X126.264 Y126.499 Z60.225 E7.14701
RECEIVED: ok
SENT: G1 X126.183 Y126.569 Z60.225 E7.15110
RECEIVED: ok
SENT: G1 X126.091 Y126.625 Z60.225 E7.15519
RECEIVED: ok
SENT: G1 X125.992 Y126.666 Z60.225 E7.15928
RECEIVED: ok
SENT: G1 X125.888 Y126.691 Z60.225 E7.16337
RECEIVED: ok
SENT: M102
RECEIVED: ok
SENT: M105 T#
RECEIVED: ok T:219.9 /220.0 B:109.4 /110.0 @:30
SENT: M105 T#
RECEIVED: ok T:219.9 /220.0 B:109.4 /110.0 @:30
SENT: M105 T#
RECEIVED: ok T:219.9 /220.0 B:109.4 /110.0 @:30
SENT: G92 E0
RECEIVED: ok
SENT: G1 E-1.00000 F600.00
RECEIVED: ok
SENT: M103

[Simplify3D]

So based on the various logs I've seen, here's what I can say. In a few cases, the firmware receives a command and it never sends a response back. When this happens, the program will not proceed. This is the desired behavior as sending commands without receiving the "ok" can result in buffer overflows and other bad outcomes. I did see another log where the software sent an empty line and then was waiting for a response. That might be a bug related to 1.0.2 that we have already fixed. Your .gcode file should not have any empty lines in it with the most recent version.

We've made several changes with 1.0.5 that might fix this issue, but we have been unable to replicate it in our lab, so you guys will have to let us know if it pops up again.

[slipshine]

If you relaease it they will come.

Have a great Friday everyone.

[Karl_Williams]

I have a similar problem that occurs 100% of the time after the last line of g-code when running the file. The stop button stays enabled as if it is still waiting for more g-code so the axis controls are locked until I click on the stop button. At first I thought that the job wasn't finished so I added a Z axis lift to the finish g-code section. The Z lift happens and then it sits after the last line. I originally thought that the jobs weren't finished because my firmware settings for Max Z axis speed was set way too high so when it would try to move the z axis at the same speed as X and Y it would stall out and lose steps. So my test cubes were way too short. I'm using Gen6 electronics so this might not be related.