Prints stop after some unknown number of commands

Something seems to be causing my firmware to lock up while printing. If I print a gear for wade's extruder, it will print about 75% of the part. If I print the springs I designed for it, it will print about half of each spring. Both of these parts print just fine with the makerbot and replicatorG, so I do not believe this is a problem with slicing the model.

It almost seems like the buffer fills up then nothing clears it out so it just locks up when it overfills. That, or there is some type of error detected and it resets itself. I cannot get any feedback while it is printing, so aside from the last command that was sent I do not know what is happening internally on the arduino.

I was experimenting with some custom accessories, which I suppose might have broken the firmware due to custom code. Today I reloaded it with fresh firmware. I still have some custom hacks to prevent the temperature from going too high, but I see no reason that this would cause my problem. All it does is reset the PID if it goes above 230C since the initial heating seems to cause massive overshoot due to integral wind up.

I'm hoping someone here can help me hook up some debugging tools or has some insight into what is happening. At the moment, I can only guess at solutions. I don't have any error messages to offer guidance. Attempts to insert my own debugging messages have not worked. I have tried using the firmware's own communication functions to send messages to the reprap host console, but I get compiler errors every time.

I found a more up-to-date firmware that was released in october, so I started tinkering with that. I get the same results. Up to now, I have been using the latest host software, so I went back a couple of versions. I get the same results again - but it did squeak in a few more commands before locking up this time.

Fortunately I'm able to tweak my settings to work on raftless prints while trying to figure this out, so it isn't a total waste of plastic. With the exception of pits from my tape, I have a finish as smooth as glass on the bottom.

I've had the same issue with the host software, where it freezes after some number of layers for no apparent reason. I use send.py to send gcode to my repstrap, and don't have that problem now. send.py never freezes on me. Are you using the RepRap host to slice the model?

If you download skeinforge, send.py will be included. It's a simple command line program to send gcode. I still use the host software for warming up the machine and testing extrusion. You could also use something like RepSnapper to send the code.

Edited 2 time(s). Last edit at 12/07/2010 03:39PM by NewPerfection.

---

Help improve the RepRap wiki! Just click "Edit" in the top-right corner of the page and start typing. Anyone can edit the wiki!

Using repsnapper just flat out didn't work and I prefer not to work with command line tools so I am avoiding send.py for now.

When I try to print my file with repsnapper, my heated bed powers on but nothing else happens. No heat on the extruder and no motor movement. Manually moving the motors did not work either. It does seem to connect, but pretty much anything beyond that is not working.

You should be able to set Windows up so that you can double click a .gcode file and it uses send.py to send it. I will look into this because I hate the hassle of starting up reprap host selecting print gcode and navigating to the file when all I want to do is send the gcode.

send.py is command line, but all you have to do is type send.py and drag the gcode file into the command window and hit enter. This copies the file path of the gcode file. Easy as pie.

---

Help improve the RepRap wiki! Just click "Edit" in the top-right corner of the page and start typing. Anyone can edit the wiki!

It seems to have something to do with zeroing out the extruded length.

I have seen it lock up while printing multiple parts. Every time the last command that is sent is "G92 E0". I have about a dozen different prints that have aborted because of this bug, so I think this is a good place to start.

Just at a glance, I see that G92 is not a buffered command. According to the comments, it will wait until the buffer is empty before running it, which could point to a problem with clearing the buffer as I originally suspected. It doesn't seem likely that all three of the firmwares I have tried could have the same bug though.

I realized that my firmware was restarting itself whenever it encountered this unknown error. After weeks of trying to track it down, I had only gotten intermittent fixes at best. Sometimes I could only manage to delay the reset by a few layers. In a last ditch effort to get past it, I commented out a segment of code that forces everything to re-initialize. This probably isn't the safest thing, but it seems to have worked.

My best guess is that there is something different in the way that skeinforge sets feed rates and coordinates. Maybe it is adding extra control characters that don't show through in notepad or something. Whatever it is, it seems to trip a watchdog on the arduino which triggers the firmware's shutdown command.

With all the inner workings of the shutdown command commented out, it does nothing. Therefore, the host just keeps on sending more Gcodes and everything continues onward. At the end of the print, I just use Gcodes to shut down the motors and heaters instead.

Hi

I am investigating a similar problem. I believe I have narrowed it down to a firmware feature/bug. I am still testing but if I have a feed rate of F6000 for the extruder retraction rate sometimes the print stops. Do you happen to have a high feed rate for the extruder?

---

Regards

Ian

When you are looking at what the last sent command was, I think you may need to consider the four commands above and below that command. I'm not familiar with the buffering system enough to know if this is a potential issue. What I'm getting at is that you might see G1 F6000 as being the last command sent, but maybe the culprit is the next Gcode line that is just starting to flow through the Gcode parser and has yet to reach the buffer or be marked as "sent". This of course depends on the order of how things are done.

I did see a trend in which command was last sent though. Whenever the print stopped, it usually ended with the console saying that one of these three was the last command sent:
G1 F6000
G1 F1500
G92 E0

I fast reverse with a feedrate of 12000 or something like that, so I don't think the problem was that 1500 or even 6000 were too high. Furthermore, these same feed rates and commands never caused a problem when the Gcode came from the host software instead of skeinforge. They didn't always cause a crash either. Those three commands might appear five times in the Gcode before the line where it actually crashed.

I thought maybe it had something to do with negative coordinates, so I changed every negative value to a 0. Obviously this trashed the print, but my firmware still shut down just the same as it always had.

There was no consistency at all, so I really don't have a clue what causes it. I just know that removing the guts of the shutdown function seemed to defeat it (the function still exists so as not to cause compiler errors, but it is just empty - it will not do anything).

Hi

I seem to get consistent results now. Change the F6000 to F3000 and the job prints. Change it back to F6000 and the job fails. Can you corroborate this. If so I will put in a bug report with my sample files.

---

Regards

Ian

... could it be not software-issues but electric noise when driving the motors faster?

Some others had similar problems wihich were solved by shorter cables and/or proper shielding ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Hi Viktor

Stops consistently at the same place.....

---

Regards

Ian

Quote

I fast reverse with a feedrate of 12000 or something like that, so I don't think the problem was that 1500 or even 6000 were too high.

If such a command goes through this doesn't mean it's executed at that rate. The processor could well be overwhelmed and stuck in the stepper interrupt, ignoring all serial communications. As the fast reverse is only short, this might go unnoticed.

Quote

I just know that removing the guts of the shutdown function seemed to defeat it

Another sign of the processor stuck, not able to handle steps fast enough? What STEPS_REP_MM nubers have you?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

#define X_STEPS_PER_MM   78.858
#define Y_STEPS_PER_MM   79.836
#define Z_STEPS_PER_MM   6400.806

#define E0_STEPS_PER_MM   16      // NEMA 17 59/11 geared extruder 8mm diameter drive

// The speed at which to talk with the host computer; default is 57600

#define HOST_BAUD 115200 // *RO

#define FAST_XY_FEEDRATE 3000.0
#define FAST_Z_FEEDRATE  50.0

#define ACCELERATION_ON
#define SLOW_XY_FEEDRATE 1000.0 // Speed from which to start accelerating
#define SLOW_Z_FEEDRATE 20

Edit:
Come to think of it, maybe the problem is linked to my Z axis steps per mm. It uses 1/16 microstepping, so that number has to be unusually large. Maybe it is causing overflow somewhere? At present, the microstepping is hard wired so I can't really easily change it. In a week or two I will have some stepper driver breakout boards that will make it as easy as flicking a DIP switch, then I can do some testing on that theory.

Edited 1 time(s). Last edit at 12/14/2010 05:12PM by dazed.dnc.

With 6400 steps/mm you probably can't run 6000 mm/min. That's 640000 steps per second and would allow only 25 processor cycles between two steps. To the best of my knowledge, the "official FiveD" firmware doesn't feature limiting top speed.

Right now I build the assumption into "FiveD on Arduino", a maximum of 4095 steps/mm is sufficient for all purposes. What type of drive is that? A 400 steps/turn motor on a M6 threaded rod?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

1/16 microstepping driver,
9 tooth drive pulley,
not sure about the driven one - it should be a standard pulley though
M8 threaded rod

I measured the physical change in distance and set up ratios that compared the number of steps with the expected and actual distance. I then re-arranged the ratio/formula to solve for the unknown value, which gave me the above number.

I guess I'll have to toy around with larger steps when I get the new driver built up. The Z axis is painfully slow, even at these high step rates. Since the axis is already geared down so much, maybe 1/4 stepping will provide sufficient resolution?

An M8 thread has a pitch of 1.25 mm and it's perfectly fine to run this without any gearing. As you probably don't want to rebuild this axis, yes, reduce the microstepping. Having 100 steps per mm is still accurate enough for all those wobbly Rep(St)raps.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I am suffering same issue.

It just stops at random, mainboard leds doesnt feel like if it was reseted but maybe the extruder board can be doing that reset thing.

Also it stops at middle of a layer not a time when it should move on Z or even close to moving Z.

I thought it was because of power supply, so i changed it to a lab style power supply and now I have very good power supply but still it stops at random.

It feels like full buffer is the most logical explanation for this issue, but i m a no expert about softwares...


dazed.dnc have you been able solve issue? Or can someone help me on this?

I never did isolate for sure if it was a feedrate or huge step count problem. Sometimes it appeared to lock up when taking long moves. Other times it seemed to be related to the z axis motion. I just got past it by changing my microstep settings. Back when I used 1/16 on everything, either my feedrates were too high or the number of steps caused an integer overflow or something to that effect.

I now use 1/4 on z, 1/8 on x and y, and 1/16 on my extruder. This works well enough for me at 32 mm/s. My extruder hasn't extruded reliably enough to really search for an "optimal" configuration though. I like how quiet the machine is while running like this, but other arrangements might yield better performance.

There are other things that can cause a firmware lockup too. I don't know if it has been fixed in the newer firmware, but I know at one point comments that were in parentheses form also locked up my printer. I had to configure skeinforge to filter out all comments.

Hi guys,

I've been suffering this problem when I've just started trying to calibrate my Prusa Mendel (mega 1280 + ramps 1.4). I've gone through a sequence of steps and now I think I've identified the problem I am suffering. Maybe some of you may have a similar one.

1. Prints were interrupted after a while, not clear cause nor a fixed command in the print
2. First guess it was en EMI problem, but then I run my prusa with the power off (no real motion just the Mega processing the gcode). It still got stuck randomly.
3. It was happening on 64 bit 10.4 Ubuntu. Maybe it was a problem with this version of Linux. I was not sure as sometimes the arduino IDE upload was failing to upload Sprinter firmware midway (it id not finish successfully sometimes).
4. As I was using Pronterface I assumed it might be a problem with that software, but I was unsure too.
5. I created my own software to feed g-code commands to my Mega and I could reproduce the random lockups (no Ok answer for a command and they you are waiting forever). So no Pronterface to blame.
6. I moved to a laptop with Windows 7, still using Pronterface I was having random lockups to, where the laptop froze to reset. I thought it was the same problem, but once I disabled the USB root device power management I was able to finish successfully my first print. So maybe the problem with the Windwos laptop was no the same as with Linux.
7. Back to the Linux host I added a small delay to my g-code transmitting program so next command is only fed to the Mega after some delay. This allowed me to stay uploading much longer or virtually foerever to the Mega. That signals, IMHO that the firmware cannot cope with a fast PC after certain commands, specially if you, like me, have 16 microstepping in the four axis.

Someone mentioned that when using send.py the frozes do no happen. I am going to check whether this program adds some delay after each Ok response before sending the next command. This is what seemed to help in my tests. But I am not still 100% sure this is the problem.

I'm having the same problems, ie random prints stops. Fast moves does seem to be the issue, but can be avoided as you have suggested.

Using SFACT for gcode generation
Using Kliment sprinter firmware
Using Repsnapper host software on windows XP

In SFACT > Craft > speed > travel feed rate (mm/s) reduced from 100.0 to 50.0

This generates F3000 instead of F6000 in gcode and seems to cure the problem. Thanks guys.

Quote

In SFACT > Craft > speed > travel feed rate (mm/s) reduced from 100.0 to 50.0

If this is the whole problem, this is unrelated to the host software and instead of limiting travel speed in sfact you can also limit it in the (Teacup) Firmware. With a proper limit in the firmware, you're set once and for all. Not sure wether Sprinter/Marlin/SJFW limit speed properly.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Yes I think you are correct the problem seems to be with the firmware and lowering the feed rate is just a "Fig Leaf" covering the actual problem.

I have just done a quick rewrite of the sprinter firmware , removing all the SD card support, cleared all the extra configuration stuff I dont need such as alternative lookup tables, and pin declarations. I have just uploaded it and rerun the troublesome Gcode file on my Prusa. I have left everything else the same, including host software. The print completed without issue.

Its probably something to do with memory leaks, variables going out of range or the arduino running out of stack space or something. I remember using the HydraMMM code for a project of my own about a year ago and it was developed with imperial units in mind, when I ran it in metric the variables went out of range causing similar issues. Added to this there is the complexity of some users microstepping and others not it might explain why only some users are having problems.

Has anyone had a look at how full we are in an Arduinomega1280 ?

I was still getting a few stops during printing and have noticed that the Repsnapper "time to complete" bar does go to the end just before the print stops even though there is still lots of gcode yet to send. It also sends a M110 code to the machine at this point. Is the firmware thinking its the last line of code and stopping?

As suggested by others here I switched to Pronterface Printrun on windows and this seems to work OK. So I am now using

Using SFACT for gcode generation
Using My own "Helium Frog firmware" (A simplified Kliment sprinter firmware)
Using Pronterface Printrun host software on windows XP

I had simular issues when I was using FiveD firmware with my RAMPS 1.4.
Switching to sprinter solved the issue for me.

having issues with commands and using ftdi driver?

The buffering of the ftdi chip and the latency time out causes some issues. do this in windows xp

control panel -> system > device manager-> click on comm port that uses ftdi


then look for advanced tab. you can then change latency options. i set mine to 1ms latency , and 400ms usb timeout. (something like that anyway.)

that fixed many issues for me and allowed me to run at 1mhz baud rate with ftdi on board my mega. ftdi cable max speed is still 115200