Independent Z move

The Reprap Java Host generates Gcode that moves the Z axis independently from the X and Y axis, with its own Z feedrate. That works fine for my Darwin. But Skeinforge's Gcode squeezes the Z moves together with X and Y moves with a feed rate that seems to be an average of the three. Everytime the Z axis has to move, the Z stepper makes strange noises but barely moves and the next layer gets printed at the same Z height as the preceding one. I increased the Z stepper trimpot setting and even installed a second power supply dedicated to the Z stepper. That didn't help. Is there a solution to that problem?

Brew

Reprap Darwin, Gen 2 electronics, Mark II extruder, Arduino 17, firmware 1.4, Java 6 update 14, Host 3D, Skeinforge 18

Here There are no moves that move Z together with X and Y.
The current coordinate for X and Y is supplied for every Z move and the
current Z coordinate for every XY-move but they never change
at the same time.

---

-------------------------------------------
* homeprototype free 3d design repository
* Blog
* Google+

There's a "max z-feedrate" option in the speed section. The default value was for me way too high, I reduced it to 2mm/s.

... maybe the "2mm/s" is now more like "0.002mm/s"?

Check what's suitable for your setup ...

---

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]

Try enabling the Home tab and put a dummy M code in homing.gcode
For example I use the following line

M105 ;need filler code for homing.gcode to get isolated Z movement

This should cause skeinforge to filter the Z moves and apply the correct max z-feedrate

I use
Maximum Z Feed Rate (mm/s): 2.5
which is the same 150mm/min (reprap host's default??)


LWK


p.s. thanks to tonokip for giveing me this tip in the first place

Thank you all for your suggestions,

-->Marcus Wolschon: Sorry for the confusion; I should have said that Skeinforge doesn't provide a "proper Z feedrate" in its Gcode.

-->Markus Amsler: Even when I set the "max z-feedrate" option in the speed section, it is not fed into the Gcode. Here are the lines of Gcode that correspond to a layer change; Max z-feedrate was set to 1.0 mm/s in speed section.

G1 X-9.25 Y-12.05 Z3.57 F1800.0
G1 X-9.48 Y-10.88 Z3.57 F1800.0
G1 X-9.25 Y-10.65 Z3.57 F1800.0
M103
G1 X-12.79 Y-11.96 Z4.23 F348.397 <---- See! Feedrate is 348 instead of being 60
M101 (or 1 mm/s as set in Skeinforge )
G1 X-20.32 Y-11.96 Z4.23 F1800.0
G1 X-20.32 Y-13.09 Z4.23 F1800.0
G1 X-12.56 Y-13.09 Z4.23 F1800.0

-->VDX <.. maybe the "2mm/s" is now more like "0.002mm/s"?> I tried 0.002 mm/s and it sent the Z-axis in orbit around Saturn ;-)

--> DPS.LWK : Wow! I don't understand why, but your tip works! Here are the lines of code for a layer change with Tonokip's dummy code in homing.gcode

G1 X-8.87 Y-9.8 Z-2.37 F1800.0
G1 X-5.76 Y-9.8 Z-2.37 F1800.0
M103
G1 X-5.76 Y-9.8 Z-1.71 F60.0 <--- See! The feedrate is 60, just as it should be!
M105 ;need filler code for homing.gcode to get isolated Z movement
G1 X-5.76 Y-9.89 Z-1.71 F3000.0
G1 X-5.76 Y-8.96 Z-1.71 F97.258
M101
G1 X-10.32 Y-8.96 Z-1.71 F1800.0
G1 X-10.32 Y-11.96 Z-1.71 F1800.0


Curiously, other problems have arisen at the same time. They might be unrelated to the Z feedrate though. But... I kinda succombed to "Skeinforge fatigue" and will go back to the Reprap Host.

Thanks again for your invaluable help !

BREW

Brilliant! I'm having the identical issue, so it's good to see a clever workaround like this.

Actually, both GCode's from Skeinforge are correct - the difference is that the first example, there is a combined X, Y and Z move all together. Skeinforge correctly adjusts the feedrate so that the Z component doesn't go past the set point. In the second example, the X and Y moves are 0, due to the homing code M105, so you get 60 mm/min, since it's a straight vertical movement.

The problem is that Adrian's firmware sometimes doesn't always do combined Z moves nicely. It works for me using the 20100308 5D firmware with acceleration turned off.

Wade

I have this problem as well. I activated the homing.gcode file and re-crafted the piece. Same thing happens. The homing.gcode file only contains "M105", should there be anything else?

I have found a work around for this for the time being though. I so a find on M103 and replace all with M103[]G1 F30.0 the [] is a return but the website one let me paste it in here. I just copied the box out of one of the example alteration gcode files. More or less the end result is:
M103
G1 F30.0
G1 X-7.75 Y8.92 Z0.6 F30.0

Even though my z raise command has the correct feed rate, I have to 'declare' it right before the command or it just make a quick vrrpt noise and doesn't raise.

steveo290 Wrote:
-------------------------------------------------------
> G1 F30.0
> G1 X-7.75 Y8.92 Z0.6 F30.0
>
> Even though my z raise command has the correct
> feed rate, I have to 'declare' it right before the
> command or it just make a quick vrrpt noise and
> doesn't raise.


That sounds like a firmware bug then - the g-code interpreter in your adruino should handle either case correctly. Which firmware are you using?

---

--
I'm building it with Baling Wire

Quote

Even though my z raise command has the correct feed rate, I have to 'declare' it right before the command or it just make a quick vrrpt noise and doesn't raise.

Look at which feedrate is given _before_ the M103. To cite Wiki page about RepRap Gcode:

Quote

RepRap does subtle things with feedrates.

... and Skeinforge runs into this "subtle" trap: it tries to raise the Z axis starting at a speed meant for the belt driven axes. The solution is to either change RepRap's acceleration strategy or fix Skeinforge the way you described.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I believe this was fixed for me when I disabled acceleration in the firmware. Running 5D firmware also.

Edited 1 time(s). Last edit at 08/23/2010 12:26AM by steveo290.

I appear to be having this same issue as the root of all things wrong with my mendel.
I'm using the techzone remix electronics.
I've tried inserting a M105 homing code which is added correctly.
I've also tried replacing all M103 commands with different variations of the "M103 ^p G1 F30.0" and "G1 F30.0 ^p M103" commands but the code itself is always inserting some movement right before the actual Z axis move takes place.

G1 F30.0 <---replace all
M103 <--- replace all
G1 X127.06 Y127.38 Z0.8 F595.705
G1 X126.54 Y127.68 Z0.8 F360.0
G1 X126.01 Y127.96 Z0.8 F120.0 <--- command right before move is F120
G1 X126.01 Y127.93 Z1.2 F30.084
M105 ;<----Homing code
G1 X126.08 Y128.36 Z1.2 F720.0

when the Z axis goes to move, i hear a high pitch noise that sounds like it's trying to move too fast.
I've tried turning off Acceleration in the firmware by commenting out the #define ACCELERATION_ON line but that causes my printer to come to a crawl and only move one step at a time when trying to print.

Any other suggestions?

Thanks,
Chad C

Just a thought,
Anyone have a Microsoft Word macro that will insert the G1 F30 command right before any line where the Z value has changed?

From::::
G1 F30.0
M103
G1 X127.06 Y127.38 Z0.8 F595.705
G1 X126.54 Y127.68 Z0.8 F360.0
G1 X126.01 Y127.96 Z0.8 F120.0
G1 X126.01 Y127.93 Z1.2 F30.084
M105
G1 X126.08 Y128.36 Z1.2 F720.0

TO::::::
G1 F30.0
M103
G1 X127.06 Y127.38 Z0.8 F595.705
G1 X126.54 Y127.68 Z0.8 F360.0
G1 X126.01 Y127.96 Z0.8 F120.0
G1 F30.0
G1 X126.01 Y127.93 Z1.2 F30.084
M105
G1 X126.08 Y128.36 Z1.2 F720.0

Maybe just ask enrique to update it instead? He's usually good about bug fixes, and this is a clearly defined problem with an easy (and known) fix.

---

--
I'm building it with Baling Wire

You use the CRAFT - LIMIT to limit the Z-axis speed in Skeinforge.

---

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

I currently have Skeinforge set to a maximum Z axis speed of 0.5 mm/sec.
The code for that actual z axis move is generated correctly, but there appears to be somewhat of a gray area between the printer mainboard firmware requirements and the skeinforge gcode requirements.

I've been trying to create a batch file to post process the skeinforge exported gcode to add the G1 F40.0 line before any Z axis movement takes place. Hopefully, I'll be able to free up some time to finish it.

Chad C

Quote
Chad C
Anyone have a Microsoft Word macro that will insert the G1 F30 command right before any line where the Z value has changed?

I can send you an AWK script in about one hour (when I get home from work) that will do this for you.

---

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

Sure, send what you have and I'll take a look.
Thanks in advance,
Chad C

AddG1F30.awk:

##----------------------------------------------------------------------------
##	Filename:	AddG1F30.awk
##	Author:		Robert H. Morrison
##	Date:		1 Feb 2011
##
##-[ D e s c r i p t i o n ]--------------------------------------------------
##
##  Written for "Chad C" in forums.reprap.org.
##  Add LAYER comments so LAYER M/N is displayed in the RepRap Host software.
##  Add G1 F30.0 before each change in the layer height.
##----------------------------------------------------------------------------

FNR == 1 { ++file_num; Z = 0; layer = 0 } #; found_first = 0 }

/^G1 X[0-9.]+ Y[0-9.]+ Z[0-9.]+ F[0-9.]+[ \t]*$/ {

	for (i = 2; i <= 5; i++)
	{
		Axis[substr($i,1,1)] = substr($i,2)
	}
	
	if (Axis["Z"] != Z)
	{
		Z = Axis["Z"]
		
		if (file_num == 2)
		{
			++layer
			printf(";#!LAYER: %d/%d\n", layer, layers-1)
			printf("G1 F30\n")
		}
		else
		{
			++layers
		}
	}
}

{ if (file_num == 2) print }

Invoke using AddG1F30.bat:

AWK -f AddG1F30.awk "%1" "%1" > "Fixed_%1"

You then invoke the BATCH FILE with:

AddG1F30 MyFile.gcode

and it will create a new file "Fixed_MyFile.gcode".

AWK can be awk.exe, gawk.exe, gawk-w32.exe (my favorite) or whatever other version of AWK that you want to use.
I prefer GNU AWK (gawk-w32).

BTW this also adds the proper layer comments (if you are using Skeinforge to create the gcode and the RepRap Host to send). If you don't want this then simply comment out (precede with a #) Line #29.

---

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

I have been having the same problem with a TZ Gen3 Mendel with 5D firmware. This is the code surrounding the move, which I suspect is being overdriven since G1 F2400 followed by the Z move means it's decelerating from F2400 to F120, causing the stutter rather than the move. Is this logical reasoning? Would replacing all M103s with M105s or something similar eliminate this problem?

G1 X34.79 Y41.64 E49.258
G1 F960.0
G1 E47.258
G1 F2400.0
;M103
G1 X24.17 Y40.86 Z0.6 F120.0
G1 X22.26 Y40.14

Nix,

I believe the issue is stemming from how the firmware processes the code. It's almost as if the firmware doesn't process a whole gcode line at once but rather processes each individual command separately.
In your example code, the last "F" value given right before your Z axis movement command is "F2400.0" which sets the speed on the mainboard to 2400. Next, your example code moves the Z axis to "Z0.6" while also moving the X and Y axis and while setting a new speed of 120.0. I believe that the mainboard is moving the Z axis stepper motor too fast for the motor to keep up and it misses some steps.

I've done a couple things to eliminate the inconsistent Z layer height issue.
I made a homing code that only says "M105" in the homing.gcode file.
This seems to force the skeinforge software to do Z axis movements separately from X and Y axis movements.

Next, I placed a "G1 F40.0" command on the line immediately prior to every Z axis movement. The script shown above should do the trick.

Also, make sure that you set the Limit-> Maximum Z Feed Rate in skeinforge to a small enough value. I use 0.66667 which comes out to a F40.0 in the processed gcode.

Hope this helps

Regards,
Chad C

so chad,
Does this mean you can leave accelleration on? Do you notice accelleration helping?

I was able to leave acceleration on doing the things i mentioned in my previous post.

I really haven't noticed acceleration helping or hurting much at all, but I've also have only been printing at a speed of 16mm/sec. Possibly acceleration would have more of an impact when printing at higher speeds to reduce under/overshoot, but I'm not sure.

Chad C

Chad C Wrote:
-------------------------------------------------------
> AWK

Thanks a million Chad, the AWK script enabled us to finally get our second working print out of skeinforge! I have no idea why it printed fine that first time, and we've spent weeks trying everything else, but at least it did teach me a valuable lesson about backing up settings. Remember kids, it's not where you might import them, in windows, it's in docs and settings\user\.skeinforge

Edited 1 time(s). Last edit at 02/11/2011 05:23PM by Nix-7c0.

This File is a .exe program that does the same as rhmorrison's script. You do need the .net framework to run this file as I created it using visual studio. If anyone does not have this I can see about getting you an install file.

Thanks,
Trevor H.

BTW
This Forum thread has made Skeinforge possible for me... Thanks!!

Also if anyone has any problems with this program let me know.

Edited 1 time(s). Last edit at 06/03/2011 11:09PM by tcool1008.

I have been experimenting with how fast my printer will print with gen6.

Over a certain speed it has this z axis problem. It makes the movement stutter horrendously and the z axis doesn't move the correct distance. The erratic movement on the other axis makes them skip steps as it does it without any acceleration.

I tried the home M015 code which makes it raze the z separate but the machine them pauses.

What other codes or additional lines do I need to add?

Sorry but I'm a dummy with this.

BTW I have me prints printing at 60mm/s and skipping only because of this problem.

Many thanks to any solutions for the coding.

---

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

Think I have solved it.

Put G4 P000 instead and that seems to work.

So the pause command is better for gen6 it seems.

---

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

I tried to use both SF40 (beanshell) and SF41 (portable) with exactly the same profile (copied-skirt), and exact same stl, and looking between layers (Limit Z range of ~0.2-0.5). Export is "without changing the output" so includes positions even if no move is done:

SF40(looks fine?):
G1 X82.75 Y117.44 Z0.3 F37.0425 E81.8183
G1 F1800.0
G1 E78.8183
G1 F37.0425
G1 X82.78 Y117.2 Z0.6 F38.6567

SF41(does Z at speeds for X&Y?):
G1 X82.74 Y117.44 Z0.2 F1800.0 E81.5864
G1 F1800.0
G1 E78.5864
G1 F1800.0
G1 X82.88 Y83.01 Z0.6 F2400.0

Why is this difference?
Edit:
Updated python to 2.7.1 to get SF41(beanshell) working, and result is identical to the previous, so the protable and beanshell confirms to be same thing.
Edit2:
Further on some layers Z layer height move is packed in 2 or 3 combined moves/lines; where some is done on decelerating from high speeds, but some other parts are done ok-ish slightly higher (approx +20%? higher) than "Limit" max_Z_speed - SF seems to aim at max_Z +something (instead of - something).
Edit3:
Looking at further objects and Z moves, seems to be more situational where having a slow speed is more of an exception, but only can see it for some certain objects&layers and so far only seen it with SF40.
Interesting for the object which makes the difference like above: when trying to use of home to separate Z as suggested above - the slicing stops midway in errors for me (something with a division to 0 i think). The other objects which do slice with home file (M105 or G4) get the previous speed high - so it would make a deceleration i guess.

Edited 3 time(s). Last edit at 06/25/2011 12:00PM by NoobMan.

NoobMan Wrote:
-------------------------------------------------------
when trying to use of home
> to separate Z as suggested above - the slicing
> stops midway in errors for me (something with a
> division to 0 i think). The other objects which do
> slice with home file (M105 or G4) get the previous
> speed high - so it would make a deceleration i
> guess.

I started seeing that divide by 0 error for some STL files, and if I change the scale of the STL even by just a few % Skeinforge slices it just fine, so something odd is going on?

I also managed to generate a file without any problems in SF41 but the firmware stops in exactly the same point in every print with a comms error, and does not recover I'm using Java host to send the SK41 Gcode and using 5D firmware on Ramps.

Even with these issues SF41 is great if you can tame it for your machine.

Rich.

---

[richrap.blogspot.com]