Blobbing due to small pauses. [help me]

You need to cap the maximum speed so that the timer interrupt period is always slightly more than the time to service the timer interrupt. That way there will always be a little bit of time left over to service the UART interrupt, which shouldn't take long. Mind you, neither should the timer interrupt if it was written sensibly.

---

[www.hydraraptor.blogspot.com]

i'm watching my log in repsnapper right now as well, and seeing the same thing as you jim. seems like the errors are only coming on mine on a retract.

Hi Nophead.

I haven't played with the Atmega tool chain that much, so I'm not sure if they have a useful profiler that would allow me to determine how long the ISR takes. I'd probably need to get their proper debugger for that too.

I could always try twiddling PIO lines and use a scope to measure the duty cycle. Although I don't have a scope or logic analyser at home, I'd have to take it into work.

The Z-axis moves were originally being done at 4mm/s when I first saw the error messages. If I slowed it down to 0.5mm/s the errors went away.

For the retraction, my retraction happens at 30mm/s, the same as my print speed, which is odd. It doesn't have any comms problems when the X & Y and extruder are moving, but retract the extruder on its own and it has issues. Not entirely sure why, but probably because the extruder needs more steps per mm due to the gear ratio and during a move it isn't the dominant axis.

James

If your retraction is 30mm/s I assume that is in terms of feed stock, so yes the motor has to turn much faster than the axis would for 30mm/s of travel.

---

[www.hydraraptor.blogspot.com]

@jim: What is your retract speed? I think this is with Gen 6 but what firmware? I think the way to solve it is to lower your retract speed until you don't get communication errors anymore. In the TZ gen 3 remix, I found that with 1/2 step set on Pololu, I can only go up to 12 or 15 mm/s.

Has anyone seen this on RAMPS? It would be very informative to collect the speed limits on all the axes (X, Y, Z and E) for each electronics/firmware combination.

I'm running the default build of firmware that comes with the Gen6. Not entirely sure which RepRap version it is based on. I've just had to add the M117 GCode to my version for my bed mapping program since it wasn't supported in the Gen6 version, so I suspect it is pretty old. A lot of the MCode listed on the RepRap page are not supported in this version.

James

---

--
Check out my blog: AdventuresIn3-DPrinting

@brnrd

i just tried lowering my retract speeds (original was 30)

i tried 15, 10, 5, 4, and 2

i was still getting the errors till i hit 2mm/s retract speed.. while i was happy to see the error disappear, that is an unacceptably slow retract speed and actually makes things worse, because there is a bit of ooze as it's trying to retract

Edited 1 time(s). Last edit at 05/16/2011 12:17PM by cgjeff.

I'm beginning to wonder if the Gen6 has problems with retraction (& possibly Z-Axis moves) due to ISR duration. Thinking about it, if I vary the retraction speed all the way up to 120mm/s (extreme I know), the actual speed of retraction doesn't really change. I suspect that the timer is firing before the previous ISR has completed, or the ISR execution time is longer than the timer duration at speeds of 30mm/s+ (depending on how the FW is configured). As a result the retraction always takes the same amount of time regardless of the retraction speed, unless it is really slow.

The same may go for the z-axis if you crank the speed to high. However for printing purposes, it never really moves that far, so it probably isn't that noticeable.

I need to dig a bit more into what is actually going on during these retraction and z-axis moves. It shouldn't be much.

James

---

--
Check out my blog: AdventuresIn3-DPrinting

Can you change the microstepping mode in the Gen 6 electronics? I understand that it can go to as little as 1/8 steps. Can this be changed to 1/2 for instance?

Not without a soldering iron and cutting some traces. The stepper drivers a configured in micro-stepping mode via PIO pins on the driver IC's.

The Atmega is being clocked at 16MHz, I wonder if I could switch out the crystal and clock it faster (and change all the timer settings in the firmware). The datasheet implies it can run up to 20MHz.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

I have this problem with gen 6.

You guys know far more about the problems here than be but as I have doubled the steps per mm for my X and Y I can report that mine still runs fine at feed rate of 35mm/s. I have the travel feed at 50mm/s and it all seems fine. It only really pauses with the react.

Does setting react to 0 diable the command? I will test it once I have finished fixing some things on my printer.

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

Setting retract to 0 (and the additional restart value to 0) will disable retract. It will be interesting to see if your longer belt-mod has helped this out.

I've been distracted by skinning tests and the associated Skeinforge plug-in, plus a two-week business trip, so haven't had much time to look at this. However, while I was in China I stopped by the Seed Studio office and picked up their open-source logic analyzer board, so now I can really test my theory that the ISR's are over-running by adapting the Blink() function in the ISR to fire at the entry and exit point and monitor it on the my new toy.

I'm also going to try switching over to Teacup firmware and see if that fixes the problem. I think all the floating point math is to blame for the length of the ISR.

Once I get back and get over the jet-lag, I'll let you know how I got on. Only a few hours left before my flight home

Regards,

James

---

--
Check out my blog: AdventuresIn3-DPrinting

Have you tried running teacup firmware on the gen6?

I never get any pauses (except the rare comms error) using 16th micro-stepping on all motors, and printing up to 60mm/s. Mind you i'm using my own electronics, but all that stuff is basically the same...

I can report that the belt mod makes no difference on the pausing despite needing twice the number of steps.

It pauses exactly the same. So the x and y don't seem to affect it at all!

I am out of my element with this kind of stuff. I will try setting it to 0 and see what happens. From what has been reported I'm thinking it will not pause.

I know that the parts from Mendel parts are printed without react as it slows down the prints. But you get lots of strings.

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

Well that's interesting.

I just tried setting the reaction settings to 0 and the extruder simply rocked back and forth and wouldn't turn to extrude!

I have no idea whats going on there.

Does gen6 even work properly with the dimension settings? Would I be better off switching them off completely and using the other settings?

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

Found why it was not extruding. I had accidentally changes a setting.

Anyway now it is it still pauses with it set to 0.

?????????

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

I have been observing and my machine seems to pause a lot when trying to do small circles or small parts where the movements take a short time to complete.

This is only generally true though as I have made large circular objects that have infilled with rapid movements side to side traveling round the ring and it has not paused at all.

It is suggested to increase the connection speed to 38400 in the firmware and program so I will try that tomorrow.

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

You could try increasing the baud rate, however I don't think that is the source of the problem. There is a 4-command buffer on the hardware, so it shouldn't be running out of commands so quickly, even at 19200. A 25-byte command will be sent in 13ms.

The problem is caused by the UART ISR not getting serviced when making fast (or short) moves as the main move ISR consumes all the processor resource. This causes the command buffer to get flushed and the print head to pause while it waits for fresh commands.

Increasing the baud rate will speed up the time taken to resend the flushed buffered commands, so shorten the pause, but not eliminate it.

I did try installing both Teacup and Sprinter firmware this weekend. Neither exhibited the pausing problems. However they did have problems of their own (to a lesser or greater degree).

Teacup doesn't work reliably with RepSnapper (temperature readings don't work and it keeps stalling during the print), but it will work with RepRap host or Send.py.

Sprinter does work with RepSnapper (temp readings are stable and it doesn't stall) but it isn't as feature complete as Teacup. E.g. The heater controller appears to be simpler in design. Setting my extruder for 218C, it regularly wound up at 234C.

I'm going to stick with Teacup and spend some time dialing it in for my machine. This looks like the way to go.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

Thanks for the info.

I may try sprinter in that case.

If I can get my head round it all!

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

so if teacup can't communicate with repsnapper, what are you using to send commands to the board then jim?

edit: sorry i reread your post and answered my own question

Edited 1 time(s). Last edit at 06/06/2011 04:58PM by cgjeff.

Jim I would also love to get my hands on your files for the teacup firmware setup for the gen-6 board.. i'm having some trouble getting mine to upload to the board, get a different error every time just about..

OK, I have been playing with Teacup this evening. After some tweaking of settings I have nearly as good prints as I was getting with the original firmware on the Gen6 without any of the little blobs. With a little more tweaking I'm sure it will be even better than before.

Interestingly, the printer runs faster than before (which does point towards the old firmware running out of MIPS) and the extruder settings for E_STEPS_PER_MM are nearly half of what I needed before, which also suggests that there were some bottlenecks in the original firmware.

To get high quality prints on my single test cube print I had to slow things down to 25mm/s (which still looks faster than 30mm/s with the old firmware). If I print more things on a bed I could probably print faster.

I've attached my Config.h and ThermistorTable.h files, these should work for any stock Mendel-Parts Mendels with Gen6 Electronics. You may need to tweak your steps per mm settings as I have real XL pulleys on my motors, rather than printed pulleys.

Regards,

James

---

--
Check out my blog: AdventuresIn3-DPrinting

thanks jim, I'll give this a shot today. Though I can't test any actual extrusion till i get a new hot end, as mine is kaput.

But I can get the firmware on my board and test out movements, and do dry runs of some g-code in the host software

Tested Sprinter today and it works great.

But now my extruder has packed up. So rebuilding that.

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

Thought I should give some notes on using Sprinter with gen6.

Firstly use the 100k (or 200k if that's what you have.) files for the thermistor not the Mendel parts one. That ones hopeless. And turn on smoothing for the temperature readings as it seems a bit over sensitive to fluctuations.

The second, and very important thing. There is an option to turn on STEP_DELAY_RATIO. You have to turn off STEP_DELAY_MICROS. Until I did this it kept missing steps in a catastrophic fashion sometimes after a long time printing. You may wish to make the acceleration settings slightly more conservative too. I knew it was a firmware issue as I never missed steps before.

Otherwise its just a matter of inputting the steps you used in the old firmware for all the motors and loading.

Oh and selecting the option for the gen6 board which is number 5.

After all that my prints are now looking awesome and my accurate is down to .002"in or .05"mm as measured properly with calipers now the blobbing is out of the way.

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

Good info Madkite, and sprinter has no problems communicating with repsnapper?

Not as yet. It seems to all work perfectly. I will be attempting a full print bed tomorrow so it will get a good test. That's if that all works properly.

The prints all go faster for the mm/s so 25 is more like what 35 is with the old firmware. Best to turn that down and make a gcode before running it. You should have seen it go when I first tired it. Shaking like crazy.

And the extruder put out way too much plastic to begin with too so that needs resetting but you should know how to tweak it all to print nice if you have got to the stage of being annoyed by blobs.

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

Hey Madkite,

would you mind posting your configuration.h file for sprinter. I want to compare it to mine. I got everything to upload to the board, but when I try to connect to it in repsnapper it just times out, and I'm trying to figure out why.

Did you set the baud rate? I think it is near the bottom of that file. I set mine to 19200.

I can post it tomorrow as I have to catch a train to London very shortly.

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

Have a look at this from the Mendel-parts forum regarding temperature fluctuations:
[www.mendel-parts.com]