NetFabb Retraction

[codemaven 0]

Hi,

Has anyone managed to get retraction working on NetFabb 4.9? Can someone tell me what the approximate settings required are? I don't even know where to begin. I've tried everything from 10rpm to 400rpm in the retraction field on the material defs but haven not managed to make anything happen at all except at the high end - in which case instead of retracting it seems to push forward at high rate just before it does a fast jump causing a HUGE blob and string.... and usually stripping the filament.

What are the other fields - travel RPM and push-on for? Are those related?

Thanks,

Troy.

[joergen 2]

Has anyone managed to get retraction working on NetFabb 4.9? Can someone tell me what the approximate settings required are? I don't even know where to begin. I've tried everything from 10rpm to 400rpm in the retraction field on the material defs but haven not managed to make anything happen at all except at the high end - in which case instead of retracting it seems to push forward at high rate just before it does a fast jump causing a HUGE blob and string.... and usually stripping the filament.

What are the other fields - travel RPM and push-on for? Are those related?

The Max input value Netfabb allows for retraction is 1000 (not sure what unit).

The normal, volumetric Marlin (i.e. 865 E steps per mm filament, and max speed of 45mm/s via firmware), is about 62 times "faster" than the E14 netfabb is using, meaning to get something useful out of the netfabb retraction, the marlin FW needs to be adjusted to allow (pretty much) insane E speeds (i.e. 3000mm/sec, practically insane), and the input field would need to allow huge numbers as inputs (i.e. 100000). so, yeah, it doesn't work, it's broken, and it's pretty low on the list of things to fix for netfabb.

I would suggest to slice things in netfabb that don't require retraction, i.e. things without many jumps, or increase the printing speed and lower the temp to decrease the stringing. or use cura or slic3r, which have great retraction functions.

[codemaven 0]

Hi Joergen,

As of the latest version of NetFabb (4.9) which come out last month this feature is supposedly fixed. I did at one time find some settings that caused it to retract a while back, but i don't know what settings I had exactly at the time... I can't seem to find any that work at all now.

Also, I believe the z-offset option is supposed to make the bed move down slightly on fast jumps and then return... I set this to 0.12 and it does indeed move down for fast jumps, but it doesn't return to what it was so the layers stop sticking after a fast jump with the z-offset on... any ideas on that?

Thanks,

Troy.

[joergen 2]

As of the latest version of NetFabb (4.9) which come out last month this feature is supposedly fixed. I did at one time find some settings that caused it to retract a while back, but i don't know what settings I had exactly at the time... I can't seem to find any that work at all now.

I was talking about the latest version, 4.9... I tried retraction speed 1000... it does indeed retract, and it solves some of the stringing issues... it is just very very slow, and it's using retraction very very often.

 

Also, I believe the z-offset option is supposed to make the bed move down slightly on fast jumps and then return... I set this to 0.12 and it does indeed move down for fast jumps, but it doesn't return to what it was so the layers stop sticking after a fast jump with the z-offset on... any ideas on that?

i didn't try "hopping", but I am not surprised.

[frodeheg 0]

I tried to configure retraction in NetFabb 4.9.1, and it seems like the retraction speed is very high, however it does not retract, it "pushes", so the higher I set the retraction speed the more filament is pushed through... And I cannot configure a negative value for retraction speed. Is the retraction still buggy or is it something I can do to fix it?

...or as a last resort, is it possible if I use perl or some text parser to search/replace some of the gcode to do proper retraction after netfabb has done the slicing?

[frodeheg 0]

Correction... I can use a negative value for "Travel RPM", but if I do that it also makes the Pull back and push on speed both retract... so I can either get a constant retraction or constant push, not a push forward equal to the retraction...

[thereza 0]

Is it just me or does it seem like this would be a simple thing for Netfabb to implement/fix. What's the status of their support for the Ultimaker - is there active work or do they have an intern working on it when he/she has free time?

Reza

[frodeheg 0]

I assume there is some work being done since the latest version is only a month old. (23.04.2012)

This should be a simple thing to fix, so I hope it makes it into the next release. And yes, I really think they should fix all the bugs in Netfabb, the price should reflect the quality of the program, and right now the quality has many holes...

[calinb 11]

This netfabb Ultimaker Engine bug is really a shame, because nf generates gcode very quickly and my Ultra profile prints feature a great surface finish, except for the jumps. And does netfabb ever love to jump! It should be very easy to fix this problem in the source code, but that's the downside of closed source commercial software--customers are at the mercy of the software developer. (The other problem is the nf Ultimaker Engine is expensive!)

I'm trying to discover Cura settings that duplicate the nf Ultra profile quality, but also mitigate the jumps with functional and correct retraction. Also, Skeinforge seems to jump much less than nf.

The nf gcode snippet, below, clearly shows the bug. I'm already editing nf gcode to fix other problems (errors after nf cuts a model so I cut it in gcode myself) but i cannot think of a workaround for this bug. Perhaps someone more experienced or clever with gcode can devise a work-around that is simple to implement.

As reported in this thread, nf gocde "pushes-on" filament before the jump and "pulls-off" filament after the jump, which is backwards. It's unfortunate that nf does not accept the obvious workaround (entering negative numbers in the Speed and Jump Settings tab). I guess this is a case of the programmer thinking they could keep users from committing a stupid mistake in parameter entry, but then the programmer commits a stupid mistake themselves in the code!

 

This bug is unfortunate, because the otherwise excellent quality of the Ultra mode is trashed by messy jumps.

I added the comments in the gcode:

 

G1 X188.4400 Y179.7400 Z0.3600 F743.3198 E0.0621 G1 X188.0600 Y180.3600 Z0.3600 F743.3198 E0.0666 ; E before the jump(begin layer 10 at 0.400)(begin layer 11 at 0.440)G1 X188.0600 Y180.3600 Z0.4200 F1200.0000 G1 X188.0600 Y180.3600 Z0.4400 F1200.0000 G1 E1.5130 F5994000.0000 ;backwards "pull-back" from E0.0666;the jump followsG1 X184.6700 Y180.5000 Z0.4400 F10800.0000 E1.5130 G1 X177.1700 Y172.5000 Z0.4400 F10800.0000 E1.5130 G1 X172.6300 Y172.4500 Z0.4400 F10500.0000 E1.5130 G1 X170.4426 Y172.4289 Z0.4400 F10500.0000 E1.5130 G1 E0.0666 F5994000.0000 ;backwards "push-on"G1 X170.7200 Y171.6100 Z0.4400 F743.3198 E0.0720 G1 X171.2100 Y170.6400 Z0.4400 F743.3198 E0.0787

 

[joergen 2]

feel free to send an email to netfabb, or open a support case. maybe if more than 1 to 10 to 50 people mentioned it, they may feel inclined to fix it... probably not, or maybe for the xmas 2013 release.

[calinb 11]

Yes--I've already submitted a ticket containing the explanation and gcode above--just in case they've never opened their eyes (or their own gcode) and looked at it! :(

[joergen 2]

Yes--I've already submitted a ticket containing the explanation and gcode above--just in case they've never opened their eyes (or their own gcode) and looked at it! :(

I submitted another ticket as well, if others would join in submitting tickets, maybe something will happen.

Florian or Paul, since you are the only people with an almost direct line to Alex, please ask him to fix this finally.

[codemaven 0]

I too have submitted a ticket with a similar snippet of GCode. The response I got back was pretty much along the lines of "Yes, we're working on it, but we have many customers and the Ultimaker Engine is only a small component. It'll be ready when it's ready".

I also tried manually editing the profile in the XML file to put a negative number in... which strangely enough made no difference. The model sliced just fine and the resulting g-code was the same.

Regards,

Troy.

[calinb 11]

I too have submitted a ticket with a similar snippet of GCode. The response I got back was pretty much along the lines of "Yes, we're working on it, but we have many customers and the Ultimaker Engine is only a small component. It'll be ready when it's ready"

.

That's an okay response for free software (as in beer or GPL), but completely unacceptable for software that fetches $USD200! Very disappointing. I wish I'd sent the $200 to Daid! Maybe Ultimaker can refund my money and send it directly to Daid.

[calinb 11]

It think it would be a simple matter to write a program to post-process the netfabb gcode file and remove the error in gcode (not that netfabb users should have to do this).

I haven't done much programming in the last 20 years but I wrote a bunch of C and assembly code a long time ago in my job and as a grad student. I don't have time to do it now, but I might dust-off the cover on my copy of K&R when I have more time. For someone who is currently writing code, I don't think it would take long to write, compile, and debug a post-processor to correct this netfabb bug.

The program could ask the user to enter the gcode filename and the retraction G1 F value (F5994000.0000 in the code above). This F value appears to be constant and it denotes all retractions present in the file. It is also likely to be unique to jumps using retraction within any given file.

The program would parse the gcode for instances of this value and correct the arithmetic in the appropriate lines of surrounding code to create a "pull-off" before the jump and a "push-on" after the jump.

Optionally, the program could permit the user to enter values beyond the range permitted by netfabb and patch them into the gcode too.

I hope someone else has time to look into my idea and develop it. I'm just too busy to do it right now, and I don't think netfabb will fix it anytime soon, based on their past customer support performance!

[janosch 0]

There might be another retract aproach to get around the retraction problem in netFabb:

I found it looking into the current Marlin code. There might be another approach

Uncomment line 252 in the Configuration_adv.h an recompile the firmware.

// #define FWRETRACT //ONLY PARTIALLY TESTED into

#define FWRETRACT //ONLY PARTIALLY TESTED

You should get an additional menu item in the LCD-panel where you could manually set the retract settings.

Maybe this is a solution...

I haven't it yet, but it might do what (we) want….

(and - trying to understand the code - maybe it is possible to optimize the retraction settings even during the print….)

Janosch

[codemaven 0]

Post-processing the G-Code from NetFabb is harder than it may seem... I took a look at it with that idea of hacking together a Perl script to do this, but there is no easy way to identify the retractions in the code because they are not all the exact same pattern. it depends on where in the model the retraction is occurring. You need virus-scanner style heuristics to identify the spots where Netfabb tried to retract. You would have to read the lines above and below to find the correct new E Values and modify a few lines after... It could be done, but it's just not worth it my opinion... Now the Harware retract... that's interesting. I doubt it works or we would have hear more mention of it. I can't see how the GCode interpreter could know what is supposed to be a retraction vs a bridge. It could assume that a fast jump above a certain threshold should be a retraction and automatically insert a retraction there... that would create a lot of unnecessary retractions over in-fill and would also be problematic for something like fluff supports... and what would you set the threshold at? When the machine is interpreting G-Code is has no idea if a movement is over empty space or not so even if it works at all there's no way it could be optimal.

NetFabb needs to be fixed. I think that is the correct and proper solution.

Regards,

Troy.

[calinb 11]

Thanks, Troy.

I didn't look carefully and missed the cases where the retractions deviate from the obvious pattern.

-Cal

[codemaven 0]

Hi All,

I got a response from NetFabb support today on retraction. Apparently they are "Finally in the testing phase of the retraction and we plan to release it with the next 4.9.4 version of netfabb by the end of the year".

It sure would be nice if they would release a beta to the community or something....

Troy.

[IRobertI 521]

Personally I've pretty much given up on Netfabb, they're just too damn slow to respond to the community. For me it has been delegated to rotate models (as cura flips everything rather than rotate which is annoying). Daid has faster turnaround time and he is ONE guy working for free (up until very very recently). Netfabb is a pretty damn expensive software and they put out an update once or twice a year, that's pathetic in my opinion.

It's too bad as it has the potential to be the best slicer out there.

Oh and another thing, if it was my product I'd be all over threads like these making sure my customers were happy.

[snowygrouch 1]

I also only use Netfabb for flipping STL models now, but honestly if KISSLICER and CURA sorted out

their model rotation features I probably will not use it at all.

Once I saw the retraction peformance from Kisslicer, complared to the mess from NetFabb, its a no-brainer.

If the do an updated release, I will try it again.

[calinb 11]

i just got a netfabb popup. There's an update available, which I downloaded. I'm in the "manage materials" screen and I'm trying to figure out what numbers to try for retraction. If anyone gets some good results (or bad) please post your settings and results.

[joergen 2]

I also only use Netfabb for flipping STL models now, but honestly if KISSLICER and CURA sorted out

their model rotation features I probably will not use it at all.

I use repg for flipping/rotating STLs... the model opens, you click the rotations you need/want, and hit apple/command-s. boom. done.

Netfabb kills me with the unnecessary popups and confirmation dialogs

 

Once I saw the retraction peformance from Kisslicer, complared to the mess from NetFabb, its a no-brainer.

yeah, KS is pretty nice in that regard.

 

If the do an updated release, I will try it again.

came out today, will try later.

[calinb 11]

RPM is a PITA, but only arithmetic is required to convert from the more customary and familiar units of mm and seconds used by Cura and KS.

If someone could check these UM constants and my arithmetic, I'd appreciate it:

UM stepper motor: 200 steps / rev.

UM motor control: 1/16 stepping

866 e-steps / mm

the above constants yield:

3200 e-steps / rev.

0.271 rev. / mm

My Cura settings are:

Minimal travel: 4.0 mm (1.08 rev.)

Speed: 45.0 mm / sec. (732 rpm)

Distance: 2.0 mm (0.54 rev)

Extra length on start 0.0 mm (0.0 rev.)

My KS settings are more aggressive (4.0 mm retraction instead of 2.0 mm):

Suck: 4.0 mm (1.08 rev)

Prime: 4.0 mm (1.08 rev)

Destring Speed: 45 mm / sec. (732 rpm)

Destring Min: 4.0 mm (1.08 rev)

nf uses a somewhat different concept in retraction. It's obvious how the speeds should be mapped but

nf also has "Travel RPM" which is described in the nf manual's description of retraction settings:

The Jump Speed is the speed of the horizontal movement of the extruder between two hatches. The Z-Jump Speed is the speed with which the extruder moves up before the jump and down after the jump. The Pull-back Speed and the Push-On Speed determine the RPM rate with which the material is pulled back before the jump and pushed forwards again after the jump. The Z-Offset is the distance by which the extruder moves up for the jump. The Travel RPM is the rate with which the material is pulled further back during the jump.

There is also a new setting called "Initial Reverse (turns), which is not documented yet.

So is the amount of filament pulled or pushed "baked into" the Pull-Back and Push-On speeds and "Travel RPM" and "Initial Revers" can be set to zero, because they are "extra" add-ons?

Now I'll go make some nf gcode and inspect the result to see if nf still gets retraction backwards.

Edit:

I'll wager that "Initial Reverse" is the amount of material that is pushed and pulled. I'll try 4.0 mm (1.08 rev.) worth to start.

[calinb 11]

Maybe I'm doing something wrong but my initial test indicates that nf just gave us a lump of coal for Christmas (WRT retraction).

From my tests, it appears that only the "Travel RPM" setting produces retraction. If it is zero, the gcode is unaffected. None of the other settings make a difference.

Even worse, about 10% of the way through my test print, nf retracted the filament all the way out of the Bowden tube!

Maybe someone else can figure out how to get something useful out of it.

-Cal