Sprinter (was Klimentkip/caruKlip) with acceleration

Quote
brnrd
I have converted my electronics to RAMPS 1.2 and loaded the latest sprinter from github. I am printing SF 41 generated g-code with Repsnapper on the MacOS 10.5.8 at 115200 baud and it seems to be a good working combination. Last night I printed a part that took 6.5 hours successfully. But the rounded corners came out rough and the quality didn't look as good as prints that I was getting with Gen 3.

I have the Pololus set as follows: 1/16 steps for x and y, 1/2 steps on z and 1/8 steps on E. Printing at a feed rate of 30 mm/s, I can see that it doesn't go around arcs smoothly and it goes slower than at straight segments. The filament at curves comes out wavy instead of smooth. This is a sign that the Arduino is not getting the data fast enough when it makes short moves as it goes around arcs. Is there a way to fix this bottleneck in the Repsnapper and/or firmware setting? Can be fixed with an SD-card? Is an SD card kit available somewhere?

Quote
jcabrer
You are probably using Oozebane. Turn that off. I get silky smooth rounds using Sprinter.

Oozebane is off. I never use this feature since this is for the most part obsolete with stepper motor controlled extruders. What feed rate do you use? The problem is with 90 degree arcs with a radius of 10 mm.

Note that I get this problem with either repsnapper or kliment pronterface under MacOS 10.5.8. I looked at some photo and video from Caru and they don't seem to be having this problem. So, I wonder if this is specific to the MacOS.

I just tried it on an old Dell Latitude D400 laptop running WIn XP with Kliment pronterface and it has the same problem. So, it's probably not a MacOS problem.

Here's a picture of how it looks like on the first layer at a feed rate of 40 mm/s.


Update: I just figured out one workaround to get smooth surfaces on printed parts. I set the Perimeter Feed Rate over Operating Feed Rate (ratio) and Perimeter Flow Rate.... (ratio) both to 0.25 and the Feed and Flow rates to 80. This way, the perimeter is printed at a slow 20 mm/s while the loops and fills are done at a really fast 80 mm/s. This seems to give the best of both worlds: fast print with smooth finish.

I just started a print that will take over 2 hrs and so far it looks really good up to the 3nd layer.

Edited 6 time(s). Last edit at 06/17/2011 06:38PM by brnrd.

Triffid_Hunter Wrote:
-------------------------------------------------------
> brnrd Wrote:
> --------------------------------------------------
> -----
> > Does sprinter work with the reprap host?
>
> reprap host is well known to be broken, and I've
> been finding that all the graphical hosts have
> issues. Kliment's pronsole seems to be far more
> reliable. Other command-line based hostwares seem
> effective too, such as send.py and Teacup's
> func.sh:mendel_print.
>
> I have no idea why mixing graphical hostware and
> serial communications is so difficult, but
> apparently it is.

I just tried Kliment's printrun from github and it seems to work fine. Now, I can load g-codes from SF 41 and print them using Kliment's pronterface.

I seem to be getting wavy lines all over my prints since speeding up a bit with sprinter on gen6 (from about 20mm/s to 50-60), though it appears to be worst in the Y-axis.
The prints are perfectly usable: [i55.tinypic.com] if a little kinky.

I'm using exponential acceleration and there doesn't seem to be any noticable vibration when I just move the axes around by manually sending gcode, yet the magnitude of oscillation in lines drawn is almost reaching the width of the lines themselves. Definitely not using oozebane.
Updated to the latest version of sprinter and I still have the issue, which puzzles me since I tried so hard to tighten my Y-belt. The lines are even wavy when it's drawing straight along either axis, when one of the motors should be holding stationary.

the exponential acceleration still starts and stops for each line. your better off using ramping for circles．

I think it is in the works to change this.

I get the same waviness/blobbing going around arcs like you have in your photo. I think this is because the pc is not supplying g-code fast enough to the printer. When it goes around the arc, your printer is probably stopping and starting like mine so it doesn't move smoothly. I don't know why others like Caru is not getting it.

The resulting vibrations might be persisting through the straight segments. Your frame might be vibrating. You might need to brace it since you probably don't have the motherboard plate mounted. I have braced mine so I don't see this as much.

I slowed down the perimeter feed rate to 1/4 of the operational feed rate and it made the arcs better for me.

I get these blobs too. It seems to be less with Sprinter, but it's still. If I slow the perimeter to 30 mm/s or so, the blobs are mostly eliminated, but still there.

Blobs are in my observation solved by kliments Printrun.

Is there an intention to have LCD support on sprinter?

Not for me. To eliminate blobs when going around arcs or circles, I had to go down to a feed rate of 20 mm/s on the perimeter. To speed up the print, I print the rest at 80 mm/s. Since the loops still have blobs, still shows a little in the outer layer but it's so bad.

What feed rates are you using and what OS and computer? Mine is a Mac Pro with MacOS 10.5.8.

I was working with 60mm/sec (Ultimaker) and a perimeter ratio of 0.7 iirc. We have our own Segment pausing discussion, although mostly for the 5G firmware

[groups.google.com]
[groups.google.com]
[groups.google.com]

I did a lot of imaging

I tried to configure the Ultimaker for Teacup yesterday, with partial success, but we currently discuss if sprinter would be more sustainable. The buffer could be increased quite a lot, as we have arduino 2560 as main controllers.


if you are curious about some ultimaker stuff, feel free to checkout my soup.

So I did quite some work today, I have added some lcd implementation to sprinter. It also contains some configuration for ultimakers, but it is not working completly yet.

If I make a loop after setup, and do_*_steps, the axis move. But if I try to set a feedrate and and make a linear move, it does nothing worth mentioning.

Any ideas where I could search for the problem?

jamesdanielv Wrote:
-------------------------------------------------------
> hey sprinter firmware would crash on my when
> gcode was generated by repsnapper and would work
> when skeinforge generated it.
>
> i found this line of gcode odd G1 E0 Fxxx (xxx
> being whatever feed rate you set)
>
> I spent 4 hrs troubleshooting tonight to find out
> what was going on. i disabled steps for e axis and
> it continued to work without crashing, so it was
> in the e axis. I think e axis is doing a division
> by zero.
>

I don't know about master, but updating to the experimental branch will fix this.

Thanks. Also have noticed that line moves shorter than 5mm like circles actually run better without acceleration. If distance of move is less than 5mm/ disable acceleration for that move, and set max speed to feed rate or max feed rate without stalling. This smoothes out jitters in circles, especially with exp acceleration.

edit:i have not tested this with sd card yet.

Edited 1 time(s). Last edit at 06/28/2011 04:30AM by jamesdanielv.

Nevermind on thinking this was a Sprinter bug

For future users, if you use send.py from Skeinforge with Sprinter you will have problems. send.py strips out the white space before sending the gcode to the firmware. So commands like G1 E1.12 fail to work because the firmware sees G1E1.12 and makes 1E1 into 10 when looking for the G code to do. The solution is to edit RepRapArduinoSerialSender.py and comment out block=block.replace(' ','')

Jeremy

Edited 3 time(s). Last edit at 06/29/2011 08:06PM by jv4779.

Oh seriously, what the fuck?

What a Terrible Failure!

Why the hell would send.py do that? It explains a shitload of weird behaviour I've seen in the past.

If you want a simple command-line sender, use printcore.py by itself.

printcore.py filename.gcode will send the file over, with checksumming and error correction and all.

Kliment

jagged arounded corners? how does it perform when acceleration is turned off?

Quote

send.py strips out the white space

If Sprinter can't deal with that, it's clearly a Sprinter bug.

Quote

Why the hell would send.py do that?

To save bandwidth? Stripping non-essential characters gives the serial line some 20% more speed.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

perhaps replace strtod() with sscanf("%f", ...) ?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

The gcode "spec" does say that white space around codes and values is not signifigant and shouldn't change the meaning of a line. It also says that G90 G21 on the same line is valid. Firmwares shouldn't throw stones. The spec for float arguments is not the same as what strtod or %f mean because they both have E exponent while gcode does not.

My big issue was that send.py displayed the line as read from the input file, but sent something different.

Jeremy

I thought exponent was only %g and %e, but not %f?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> I thought exponent was only %g and %e, but not %f?


avr-libc vfscanf says they are all the same....

f Matches an optionally signed floating-point number; the next pointer must be a pointer to float.
e, g, F, E, G Equivalent to f.

jv4779 Wrote:
-------------------------------------------------------
> My big issue was that send.py displayed the line
> as read from the input file, but sent something
> different.
>
> Jeremy

Yes, that would be an unexpected behavior, now wouldn't it?

I expect the original intention there was to make the displayed information more human-friendly while still getting the 20% speed boost mentioned.

Not worth the disconnect between sent and displayed lines though. This should be fixed, I ought to send a pull request...

---

--
I'm building it with Baling Wire