Sprinter (was Klimentkip/caruKlip) with acceleration

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jgilmore — Mon, 11 Jul 2011 21:10:23 -0400

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...

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jv4779 — Thu, 30 Jun 2011 13:30:50 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

Triffid_Hunter — Thu, 30 Jun 2011 12:07:02 -0400

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

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jv4779 — Thu, 30 Jun 2011 11:56:39 -0400

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

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

Triffid_Hunter — Thu, 30 Jun 2011 04:09:58 -0400

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

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

Traumflug — Thu, 30 Jun 2011 03:28:00 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jamesdanielv — Thu, 30 Jun 2011 03:27:16 -0400

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

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

Kliment — Wed, 29 Jun 2011 23:15:58 -0400

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

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jv4779 — Wed, 29 Jun 2011 12:56:27 -0400

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

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jamesdanielv — Mon, 27 Jun 2011 21:44:21 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

caru — Tue, 21 Jun 2011 19:40:14 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

bkubicek — Tue, 21 Jun 2011 16:07:38 -0400

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?

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

bkubicek — Tue, 21 Jun 2011 05:56:11 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

brnrd — Tue, 21 Jun 2011 05:44:31 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

bkubicek — Tue, 21 Jun 2011 02:45:26 -0400

Blobs are in my observation solved by kliments Printrun.

Is there an intention to have LCD support on sprinter?

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

Dale Dunn — Sun, 19 Jun 2011 21:04:12 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

brnrd — Sun, 19 Jun 2011 07:47:56 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jamesdanielv — Sun, 19 Jun 2011 07:41:15 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

4ndy — Sun, 19 Jun 2011 05:58:58 -0400

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. :S

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

brnrd — Fri, 17 Jun 2011 13:35:24 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

brnrd — Fri, 17 Jun 2011 11:58:35 -0400

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.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jcabrer — Fri, 17 Jun 2011 11:23:22 -0400

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

Maybe post your settings, and we can compare.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

brnrd — Fri, 17 Jun 2011 10:35:57 -0400

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?

Thanks.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jamesdanielv — Wed, 15 Jun 2011 07:29:01 -0400

well i checked into it tonight and the wrong values are generated for e darn it. tried to compare to Tonokip firmware and this section is completely rewritten. ~~so until a real fix is posted for firmware then use this workaround~~

erase this from repsnapper:

G1 E0 FXXXX

if not able to find a true fix, then I'll cheat and replace the string in buffer with G92 E0 Fxxxx ; the fxxxx is ignored

any one else look into sprinter firmware, and dive into the code at all??

I think this is a firmware bug. G1 E0 Fxxxx although poor form, should process normally.

thx.

hooked up o-scope to e step pin and it still was turning on for very short perieds. set 1us delay for step hi/low pulse and extruder was working. it was backtracking its filament to g1 e0. my bad. of course this is with changed adc to interrupt.could not get firmware to work for very long with analog read method.

a workaround is this
// comm variables
#define e_backStepsAllowed 1000 //how many steps back allowed for e- prevents long pauses, and wtf builds.

xdiff = (destination_x - current_x);
ydiff = (destination_y - current_y);
zdiff = (destination_z - current_z);
ediff = (destination_e - current_e);
x_steps_to_take = abs(xdiff) * x_steps_per_unit;
y_steps_to_take = abs(ydiff) * y_steps_per_unit;
z_steps_to_take = abs(zdiff) * z_steps_per_unit;
e_steps_to_take = abs(ediff) * e_steps_per_unit;
//************* moded code
if(x_steps_to_take || y_steps_to_take){
e_steps_to_take = abs(ediff) * e_steps_per_unit;
}
else{e_steps_to_take = abs(ediff) * e_steps_per_unit;
if (ediff<0 ){ if(e_steps_to_take>e_backStepsAllowed) e_steps_to_take =e_backStepsAllowed ;}}
///************************************************************************************************************
//max back steps

so far the following changes. probably should comment on git.
interrupt sampling of adc (so far only reads pin0)
digitalfastwrite (25 times faster);
digitalreadfast (50 times faster)
#define e_backStepsAllowed
buffers 64 (not sure it is really buffering :/)

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jamesdanielv — Tue, 14 Jun 2011 08:49:36 -0400

teacup->teacup forum. this is for sprinter!!

Quote
Triffid_Hunter
I wonder why it's even trying to work out move times if the distance is zero? If teacup detects a zero distance move with a feedrate, it simply updates the stored feedrate and moves on, without queueing anything.

sorry. your right. sprinter does this in most cases. it just tries to move the e axis even if zero steps and somehow crashes.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

Triffid_Hunter — Tue, 14 Jun 2011 08:43:04 -0400

I wonder why it's even trying to work out move times if the distance is zero? If teacup detects a zero distance move with a feedrate, it simply updates the stored feedrate and moves on, without queueing anything.

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jamesdanielv — Tue, 14 Jun 2011 08:20:22 -0400

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.

change this line in sprinter (line 978ish)

if(e_steps_to_take && (x_steps_to_take + y_steps_to_take <= 0) ) e_interval = time_for_move / e_steps_to_take * 100;

to this:
if(e_steps_to_take && (x_steps_to_take + y_steps_to_take <= 0) ) e_interval = time_for_move +1/ e_steps_to_take * 100;

there is a bug in the firmware for when no e movements are calculated. it causes a division by zero. processor locks up!

or remove this line

G1 E0 FXXXX ; from beginning of gcode. either way rep snapper is allowed to do G1 E0, so the firmware should not crash!

you will now be able to use gcode generated in repsnapper!

i have not checked to be sure my hack is correct in the sense of distance but it seems to prevent the crash!

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

Triffid_Hunter — Sat, 11 Jun 2011 21:01:57 -0400

sprinter is [github.com]

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

jamesdanielv — Sat, 11 Jun 2011 18:25:46 -0400

how does sprinter read adc data? also where is the direct link download. i might already be playing around with it if it is the latest caruKlip release. with a buffer of 64 and char size of 64 it runs directly from host without sd card.

please post a page in the reprap wiki. firmwares are growing like weeds...

Re: Sprinter (was Klimentkip/caruKlip) with acceleration

Triffid_Hunter — Thu, 09 Jun 2011 05:50:46 -0400

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.