Mendel and Skeinforge problems

Hi All:

I am trying to run a Mendel (Gen 3 electronics with wades extruder and Pololu stripboard driven extruder) with reprap host software, and use skeinforge for gcode generation. So far, it seems hopeless....

I have been working on this for a long time, and really not gotten closer. From all the descriptions, it seems others are doing it...

By comparing the gcode from repraphost and skeinforge, I was able to get most settings correct. My extruder now moves with proper e codes, etc. The problem I have not been able to solve is the already documented one of z moves not being executed. I can't get skeinforge to put in the home command that properly breaks up the file to lower the z feed rate.

So I would like to ask one or a few users to post their working solution (Mendel-host-skeinforge) so it can be replicated by others. We would need:

1. Firmware version
2. Firmware setting changes (i.e. acceleration on/off....)
3. Skeinforge version.
4. Zipped skeinforge profile directory.
5. All alterations files (home, start, end, etc.), and their proper location.

If this is not a good way to run the system, can anyone suggest a better toolchain and firmware/software for Mendel/Gen 3?

many thanks,

j

What do you have your Pololu's set to? With my Techzone Gen 3 remix motherboard and Pololu controllers, I've found that I can't run it with all 4 the steppers set to 1/16 steps. It seems that the the processor is not fast enough to pulse the steppers at that rate. I've been able to run with 1/8 step on x and y and 1/2 step on z and E. I noticed that the print time is usually longer than Skeinforge calculates and I'm concerned that the E doesn't have enough resolution. So today, I decided to go back to 1/2 step on x, y and z and 1/4 step on E. We'll see how it works.

Hi:

I have x, y and z on the standard Gen 3 stepper drivers. Only the extruder is Pololu. It is 1/16 stepping. I can get all to work with the host software, just not with the gcode generated in skeinforge, due to the z move issue (I think). I am just wondering of anyone has this working. I have read some gave up on the task, or edited every layer by hand (yuck...). I want to be able to print good quality parts, and everyone says use skeinforge, not the host software.

many thanks,

john

1. Turn OFF acceleration in the RepRap firmware.
2. Turn on Dimension in Skeinforge.
3. Activate Limit (max 1 mm/s)

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Hi Bob:

I have done all this, and first z move is still too fast. I used limit x,y = 40, z=1mm/s.The gcode produced is:

G90
G21
M113 S1.0
M108 S100.0
M104 S245.0
M108 S100.0
G1 X-9.11 Y-9.64 Z0.28 F2400.0
G1 F90000.0
G1 E10.0
G1 F2400.0
G92 E0
M101
G1 X9.64 Y-9.64 Z0.28 F1200.0 E5.1587
G1 X9.64 Y9.64 Z0.28 F1200.0 E10.4632
G1 X-9.64 Y9.64 Z0.28 F1200.0 E15.7677
G1 X-9.64 Y-9.45 Z0.28 F1200.0 E21.0199
G1 X-8.56 Y-8.92 Z0.28 F1200.0 E21.3509
G1 X8.92 Y-8.92 Z0.28 F1200.0 E26.1602
G1 X8.92 Y8.92 Z0.28 F1200.0 E31.0685
G1 X-8.92 Y8.92 Z0.28 F1200.0 E35.9768
G1 X-8.92 Y-8.56 Z0.28 F1200.0 E40.7861

which has a very high feed rate for the first z move to 0.28mm. Many posts say skeinforge does some average feed for the z move.

john

@j_andberg - You need to turn on Multiply and set the center to 100,100 with 1 column and 1 row to center your part in the middle of the bed. You're starting from a negative number which is not recognized by the firmware. So I'm guessing that the move is starting from 0,0,0 to 0,0,0.28 at a rate of 2400 mm/min which all happens in the z direction. Skeinforge assumes that you're starting from one corner of the bed and going to the origin which it thinks is the middle of the bed. It sets a high speed of since most of the move is happening along the x and y at a distance of 13.26 mm.

Also, in my experience, turning the extruder to 1/16 steps will not allow you to retract/restart fast enough and the processor will be too busy during the retract/restart to receive commands from the computer.

@j_andberg

see this post

The solution seemed to work for me.

I don't have that homing option on and my z moves are still separate. I'm not sure if that trick is still necessary with version 40.

Hi All:

Many thanks for the suggestions. I tried the multiply one, and it was already on. I changed the center to 100x100 and got the gcode:

G90
G21
M113 S1.0
M108 S100.0
M104 S245.0
M108 S100.0
G1 X90.89 Y90.36 Z0.28 F2400.0
G1 F90000.0
G1 E10.0
G1 F2400.0
G92 E0
M101
G1 X109.64 Y90.36 Z0.28 F1200.0 E5.1587
G1 X109.64 Y109.64 Z0.28 F1200.0 E10.4632
G1 X90.36 Y109.64 Z0.28 F1200.0 E15.7677
G1 X90.36 Y90.55 Z0.28 F1200.0 E21.0199
G1 X91.44 Y91.08 Z0.28 F1200.0 E21.3509
G1 X108.92 Y91.08 Z0.28 F1200.0 E26.1602
G1 X108.92 Y108.92 Z0.28 F1200.0 E31.0685
G1 X91.08 Y108.92 Z0.28 F1200.0 E35.9768
G1 X91.08 Y91.44 Z0.28 F1200.0 E40.7861
G1 F90000.0
G1 E30.7861

which is no different on the feed rate for the first z move.

I already tried the homing suggestion, but this does not seem to work. I put the proper file in the specified directory, and it never inserts the code. Is there a skeinforge version that someone has working for this feature? I could install that version and try again.

j

Did you try to print with that g-code. Most of that speed is going in the X-Y direction so the speed in the z axis is probably still within the 1 mm/s limit. I'm too lazy to work out the actual z speed.

At 2400 mm/min feed rate in that move, the z rate is only a little over 5 mm/min or 0.09 mm/s. This is well below the z axis limit. It should move without a problem.

Edited 1 time(s). Last edit at 03/30/2011 01:38AM by brnrd.

I ran into exactly the same problem with too high z-feedrates. Limit didn't do the trick for me. I wrote a php script that separates the xy move from the z-move and makes the z-move go slow.

@north90ty - did you turn of acceleration in the firmware as well as the do the other things Bob wrote?

Edited 1 time(s). Last edit at 03/30/2011 01:59AM by brnrd.

No, i did not turn off acceleration in the firmware, i do use the dimension module but not limit.
Tonight i will give limit a new try.

Hi All:

Problem may be solved...

I tried Skeinforge 40, with a fake homing command. It did not do the proper feedrate at the first z move:

G90
G21
M113 S1.0
M108 S100.0
M104 S245.0
M108 S100.0
G1 X0.89 Y0.36 Z0.28 F2400.0
G1 F90000.0
G1 E10.0
G1 F2400.0
G92 E0
M101
G1 X19.64 Y0.36 Z0.28 F1200.0 E5.1587
G1 X19.64 Y19.64 Z0.28 F1200.0 E10.4632

But at the second, it did

G1 X2.02 Y18.31 Z0.28 F1200.0 E114.5521
G1 F90000.0
G1 E104.5521
G1 F1200.0
M103
G1 X2.02 Y18.31 Z0.68 F60.0
M105 <---- this line is my fake homing command
G1 X2.13 Y18.37 Z0.68 F1200.0
G1 X1.82 Y18.2 Z0.68 F1200.0
G1 F90000.0
G1 E114.5521
G1 F1200.0
G92 E0
M101
G1 X1.8 Y18.2 Z0.68 F1200.0 E0.0055
G1 X1.8 Y1.8 Z0.68 F1200.0 E4.5177

All subsequent layers are OK, also. I can edit the first by hand to fix, or just set the bed to extruder height to compensate.

I wonder if the lack of the homing function on layer 1 is intentional, or a bug? Do others have this same behavior?

many thanks,

john

north90ty Wrote:
-------------------------------------------------------
> No, i did not turn off acceleration in the
> firmware, i do use the dimension module but not
> limit.
> Tonight i will give limit a new try.


If you don't turn off acceleration in the firmware, then you will probably have a problem with your z axis not moving. Unless you modify the g-code after SF generates it to issue a G1 F60.0 or something before each z move, it will probably be too fast for the z stepper and it won't budge. I had the same problem when I started using SF.

j_andberg Wrote:
-------------------------------------------------------
> Hi All:
>
> Problem may be solved...
>
> I tried Skeinforge 40, with a fake homing command.
> It did not do the proper feedrate at the first z
> move:
>
> G90
> G21
> M113 S1.0
> M108 S100.0
> M104 S245.0
> M108 S100.0
> G1 X0.89 Y0.36 Z0.28 F2400.0
> G1 F90000.0
> G1 E10.0
> G1 F2400.0
> G92 E0

Are you sure Multiply is on with the center at 100,100? It doesn't look like it from this g-code. Also, your extruder retract rate of 90000 mm/m is probably too fast. Your E values seem too high for SF 40 which now uses mm of feed instead of extrudate. That first extrude is usually the restart value which should be a few mm. I use 3 mm but others use as little as 1.

j_andberg, I'm pretty much having the same problem as you. Have also been working on this for a long time, but still can't even print a decent looking part. Sigh....maybe I should've just gone with a Thing-O-Matic!

Running techzone gen 3 (also got the monotronic board), and no luck with skeinforge 40 gcodes. Repsnapper seems to be running alright though, but the prints don't look very good. Repsnapper gcodes seem to be of "poor" quality.

Would anyone be kind enough to like send over your Skeinforge 40 profile(s) for both ABS, and PLA? That would be very much appreciated.

Hi,
Here are mine, but slow down feed and extrusionrate under speed, as you wont probably be able to reach them. (I use klimentkip fw)
The file is settings are for ,33 layer thickness PLA.

Hi All:

Sorry to not post sooner, but my problems are largely solved. I had originally not wanted to use v40, since it was too new. I switched to that, and with homing turned on (and firmware acceleration off), it is working. I have a few issues I would like to mention. The first is that the print stops just before the end. Please see attached image for a screen print of the results. My G code file in the pertinent area is:

G1 X44.62 Y46.27 Z18.33 F1200.0 E0.927
G1 X45.58 Y45.3 Z18.33 F1200.0 E1.0055
G1 X45.58 Y44.47 Z18.33 F1200.0 E1.0531
G1 X44.62 Y45.44 Z18.33 F1200.0 E1.1315
G1 F1800.0
G1 E-0.8685
G1 F1200.0
M103
M113 S0.0

The M113 S0.0 is the last line of g code.

Any ideas?

The second is that the infill is biased to one side of the print, resulting in a gap between infill and perimiter on one side. Any idea which setting controls this?

many thanks,

john

There isn't any way to bias the infill in SF. The uneven gap is probably due to backlash see: [hydraraptor.blogspot.com]

---

[www.hydraraptor.blogspot.com]

Is your extruder barell, square to your printbed (90odeg)?

If your gears are printed, you may not have your timing belt matched to the gears. This causes adjacent infill strokes to bunch up together. It's most eveident on diagonals, when both axes are being used.

Hi:

Many thanks to all. I think I have a lead on both things. After several more prints, I think it did not stop early. It just put the warning on the screen and stopped at the end. I presumed it stopped early. I will put a travel to 0,0 command as the last line to test it.

On the offset, it must be backlash somewhere. The display of skeinforge output does not show it. I am using a laser cut mendel, so the pulleys should be OK. However the x axis design is poor. I will rebuild it yet again and check. Another clue is that the y dimensions of a 28mm cube I printed are spot on, while the x is 27.3mm. Identical pulleys and firmware settings for both axes, that should not happen...

j