Variant of Goopyplastic's Tantillus Variant (Ingentis)

Alright, so I've gone to bed as it's been a hard week and my brain wasn't functioning very well. The extra G92 E0 didn't have effect but only because I forgot to include a carriage return at the end of the line.

Learnings from this evening:

For tgalse, it's pretty much mandatory to have a prime tower or prime area or something because it oozes like crazy even when you drop it to 200 degrees and by the time you switch to the tglase nozzle most of the plastic in the hot zone has dribbled out so a prime equal to the previous retract doesn't push any plastic out. Getting a prime tower for every layer is pretty much a must have I think, or I could easily set up a 'prime and clean' area in a corner where the nozzle could go to prime without having to worry about a tower - this would be easy enough to implement each time a tool changes (I imagine) as it's not too far off the original TCL idea.

If M109 is enabled the tool head needs to move back to origin or somewhere out of the way, otherwise it melts the print and oozes over it.

I am gradually getting my head around Lua, I can pretty much read and understand your code now, even if some of the syntax isn't very familiar .

The Python tidy-up script looks very useful. I'll have a play with it when I get a spare moment. I discovered this evening that (the current github commit of) Cura now lets you configure the support threashold angle so I'm trying a support heavy model out overnight - I have to say that Cura is nearly there with all the features I want from a slicer, it's not very multi extruder friendly yet but then neither is kiss unless you pay for it.

The wormdrive Z looks very intriguing - I'm pretty happy with the gt2 belt system on the Ingentis but it would be nice if the bed stayed put when the motor wasn't active. Have you tested the wormdrive and pulleys in meat space yet?

I wonder if getting a cheap blower off ebay and aiming it right at the nozzle and turning this fan on only when the nozzle is inactive would stop the ooze. I know I aimed a blower at my print area without a shroud and the 24v cartridge couldn't maintain temp so I'm sure if you keep it right at the nozzle it would maybe stop this issue.

For the missing G92 E0 it would be easier to set Kisslicer to Relative and for Cura run my Absolute to Relative script before this one. Or Set Kisslicer to ABS E (no reset). In my testing I have not found a reset in Cura code unless its threshold is way above the value my test part produced. Also I do not see the original G92 E0 in your example. I assume it was there and it should have recorded its value as the last E value. It is not hard to look for G92 E0 and force it as the next value.

To use Kisslicer in Relative mode be sure to add M83 to the start code to set the firmware to Relative. If you are using Cura be sure to put M82 in the start code before running the ABS to REL script and it will change it to M83 when it converts the E values.

The prime pillar on every layer should be easy enough that I can get it out today along with the G92 E solution.

Yeah Lua seemed strange at first to me as well. The lack of braces and brackets looks odd after using other languages and it is missing some internal functions that you would expect like rounding or pi . But it does have its advantages, it is the fastest scripting language available with the exception of an offshoot of it that is even faster, it is tiny and can be included with scripts without worry of hard drive space and it was the language that the creator of Kisslicer wrote an example script in to show me the basics of Kisslicer post-processing.

In Cura there is a setting for number of extruders. What does it use the multiple exruders for?

The worm drive is built and does work. I do not know how accurate yet since I have not printed with it yet. The entire machine is built I just need to finish wiring it and figure out the extruders and hotends.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Ok the G92 E0 issue should now be fixed and the prime pillar is forced on layers without a tool change. re-link [github.com]

Edited 1 time(s). Last edit at 01/17/2014 04:22PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Forgive me if I have not read the post very well. The professional machines have a brush and silicone squeegee. Every time they do head change they drive the head over to the brush and wiper and give it a few wipes, then extruder a few cm of plastic then wipe again, then back to printing. It works really well. If my printer was not limited to 100mm I would have added one already for pre printing prep.

You probably know this but there it is just in case.

Quote
Robonz
Forgive me if I have not read the post very well. The professional machines have a brush and silicone squeegee. Every time they do head change they drive the head over to the brush and wiper and give it a few wipes, then extruder a few cm of plastic then wipe again, then back to printing. It works really well. If my printer was not limited to 100mm I would have added one already for pre printing prep.

You probably know this but there it is just in case.

I knew they existed but that extra detail is very useful, thanks! - I will at some point get around to doing this on Ingentis but I have so many things to do on the list ATM .
For all that I'm not the one writing it, I'd like this toolchange script to be as accessible as possible, so a prime pillar is a friendly option for most bots out there.

Quote
Sublime
Ok the G92 E0 issue should now be fixed and the prime pillar is forced on layers without a tool change. re-link [github.com]

alright, further progress this evening.

Prime pillar works well for E0 although I found I needed to add a layer of blue tape in the prime pillar location to get the first layer to adhere, in an ideal world I think the first layer of the prime pillar should be a solid infill square deposited at a slower rate and with slightly higher flow than subsequent layers to ensure good adhesion. Blue tape is fin in the short term though.
I did have to disable Z settle ( definitely improves layer consistency with belt z) as when the head travelled to prime location, the bed would drop as usual for Z settle moves but not come back up when the prime pillar stated to the pillar was being extruded into thin air.

I've set Kiss to relative E and added an M83 in the start gcode. All works fine.

Perimeters and solid went down without issue. Infill didn't though - seemed like the same issue we were having with perimeters last night. I put a piece of tape on the tgalse and it would move back and forth for primes but pretty much stayed where it was for the 10 or so layers I let it run for. I found the problem - at the end of the prime pillar, the correct retract takes place (10mm) but the prime that occurs afterwards before it starts infill is the E1 value (3.7mm). I haven't had a chance to see if I can fix it in the code yet though.

Change tool for infill.
G1 F6000 E-3.7
G0 F9000 X35 Y35
T1
M104 S215
G92 X35 Y55
G0 F9000 X35 Y55
;
;Prime pillar
G1 F6000 E10
G0 F9000 X34.6 Y34.6
G1 F1600 X37.725 E0.1012
G1 F1600 Y37.725 E0.1012
G1 F1600 X32.275 E0.1012
G1 F1600 Y32.275 E0.1012
G1 F1600 X40.85 E0.1552
G1 F1600 Y40.85 E0.1552
G1 F1600 X29.15 E0.2092
G1 F1600 Y29.15 E0.2092
G1 F1600 X43.975 E0.2633
G1 F1600 Y43.975 E0.2633
G1 F1600 X26.025 E0.3173
G1 F1600 Y26.025 E0.3173
G1 F1600 X47.1 E0.3713
G1 F1600 Y47.1 E0.3713
G1 F1600 X22.9 E0.4254
G1 F1600 Y22.9 E0.4254
G1 F1600 X47.1 E0.4254
G1 F6000 E-10 <----- Right Retract value
G0 F9000 X35 Y35
;
G0 F9000 X157.17 Y117.66
G1 F6000 E3.7 <------ Wrong prime value.
; Set sparse infill flow rate.
M221 S120
;
; 'Stacked Sparse Infill', 1.1 [feed mm/s], 63.1 [head mm/s]
G1 X154.93 Y117 E0 F7800
G1 X156.59 Y115.34 E0.0416 F3784.1
G1 X156.59 Y113.64 E0.03
G1 X153.23 Y117 E0.0841

Quote
jimjimma
Prime pillar works well for E0 although I found I needed to add a layer of blue tape in the prime pillar location to get the first layer to adhere, in an ideal world I think the first layer of the prime pillar should be a solid infill square deposited at a slower rate and with slightly higher flow than subsequent layers to ensure good adhesion. Blue tape is fin in the short term though.

This is something I was a little worried about. I think better than a solid bottom would be a raft style base with thick lines spaced apart by the same distance.

One thing that could cause this issue is having a thicker first layer set in the slicer. The tower assumes all layers will be the same and creates E values based on that.

Quote
jimjimma
I did have to disable Z settle ( definitely improves layer consistency with belt z) as when the head travelled to prime location, the bed would drop as usual for Z settle moves but not come back up when the prime pillar stated to the pillar was being extruded into thin air.

Yeah that is something you shouldn't have on anyway unless you are using a lead screw Z axis with a bed that goes down and no anti-backlash nut. Or in other words a Darwin or BFB machine.

Quote
jimjimma
I've set Kiss to relative E and added an M83 in the start gcode. All works fine.

Did you try it in Absolute? I did add some code that should solve the E reset.

Quote
jimjimma
Perimeters and solid went down without issue. Infill didn't though - seemed like the same issue we were having with perimeters last night. I put a piece of tape on the tgalse and it would move back and forth for primes but pretty much stayed where it was for the 10 or so layers I let it run for. I found the problem - at the end of the prime pillar, the correct retract takes place (10mm) but the prime that occurs afterwards before it starts infill is the E1 value (3.7mm). I haven't had a chance to see if I can fix it in the code yet though.

OK this one was a result of individual code blocks for each section which makes it easy to have mistakes like this.

        TOOL_CHANGE(SPARSE_X_OFFSET,SPARSE_Y_OFFSET,SPARSE_NOZZLE,SPARSE_RETRACT,SPARSE_F_AREA)
        UN_RETRACT(LOOP_RETRACT) <-- Should have said SPARSE_RETRACT

This is something that should not happen any more. I moved a lot of code into functions and the sorting is done with arrays on the fly now. So we no longer have a code block for each section type but rather just one that gets filled in based on the extruder number pulling from a bunch of arrays. I pushed that code late last night before I went to bed and you were using the earlier one. I do not think there will be many more major changes like that. The code is getting mature enough to share with others for further testing.

Edited 1 time(s). Last edit at 01/18/2014 01:14PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

The built in wipers do seem like a good idea but with a head like the Kraken you would either have to one in each corner or one large area that would reach all four nozzles. Either way you would lose a lot of possible build area on any size machine where as the prime pillar takes up as little as a 16mm square when priming all four nozzles. Another advantage to a prime pillar is being able to place it anywhere even in a hole in a part.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Hmm,

Sorry it's been a few days - life interfering with printers.

There is still something up with the new code.You'll see in the gcode snippet below, it seems to be putting in G92 commands with a negative E value even though it's using relative E. It's also retracting but not priming as far as I can see. The end result is the T1 filament gradually backing out of the extruder. I had a quick look for the culprit this evening but a 9 hour work day plus 3 hours manic toddler wrangling is not conducive to reading unfamiliar code it seems. I'm guessing the G92 command should in fact be a G1 to prime the nozzle after retract.

;Prime pillar
G92 E-9.9979 <------not sure why this is here as it's set for relative e
G1 F4800 E0.0021
G0 F9000 X25 Y25
G1 F1800 X26.6 E0.0643
G1 F1800 Y26.6 E0.1265
G1 F1800 X23.4 E0.1887
G1 F1800 Y23.4 E0.2509
G1 F1800 X28.6 E0.3477
G1 F1800 Y28.6 E0.4445
G1 F1800 X21.4 E0.5759
G1 F1800 Y21.4 E0.7073
G1 F1800 X30.6 E0.8733
G1 F1800 Y30.6 E1.0393
G1 F1800 X19.4 E1.2399
G1 F1800 Y19.4 E1.4405
G1 F1800 X32.6 E1.6757
G1 F1800 Y32.6 E1.9109
G1 F1800 X17.4 E2.1806
G1 F1800 Y17.4 E2.4503
G1 F1800 X32.6 E2.72
G92 E0.0021
G1 F4800 E-9.9979 <----retract
G0 F9000 X25 Y25
;
;Go to last print location
G0 F9000 X157.17 Y117.53
G92 E-9.9979 <------not sure why this is here as it's set for relative e
G1 F4800 E0.0021
; Set flow rate for infill
M221 S100
;
; 'Stacked Sparse Infill', 0.4 [feed mm/s], 39.2 [head mm/s]
G1 X152.38 Y116.87 E0 F7800
G1 X156.59 Y112.66 E0.0601 F2351.7
;
; 'Stacked Sparse Infill', 0.4 [feed mm/s], 39.2 [head mm/s]
G1 X155.32 Y109.69 E0 F7800
G1 X148.14 Y116.87 E0.1024 F2351.7
G1 X143.9 Y116.87 E0.0428
G1 X151.08 Y109.69 E0.1025
G1 X146.83 Y109.69 E0.0427
G1 X139.65 Y116.87 E0.1025
G1 X135.41 Y116.87 E0.0428
G1 X142.59 Y109.69 E0.1024
G1 X138.35 Y109.69 E0.0428
G1 X131.17 Y116.87 E0.1024
G1 X126.92 Y116.87 E0.0428
G1 X134.11 Y109.69 E0.1025
G1 X129.86 Y109.69 E0.0428
G1 X122.68 Y116.87 E0.1024
G1 X118.44 Y116.87 E0.0428
G1 X125.62 Y109.69 E0.1024
G1 X121.38 Y109.69 E0.0428
G1 X114.2 Y116.87 E0.1024
G1 X109.95 Y116.87 E0.0428
G1 X117.14 Y109.69 E0.1025
G1 X112.89 Y109.69 E0.0428
G1 X105.71 Y116.87 E0.1024
G1 X101.47 Y116.87 E0.0428
G1 X108.65 Y109.69 E0.1024
G1 X104.41 Y109.69 E0.0428
G1 X97.23 Y116.87 E0.1025
;
; 'Stacked Sparse Infill', 0.4 [feed mm/s], 39.2 [head mm/s]
G1 X93.41 Y116.44 E0 F7800
G1 X100.17 Y109.69 E0.0963 F2351.7
G1 X95.92 Y109.69 E0.0428
G1 X93.41 Y112.2 E0.0359
;
; 'Wipe (and De-string)', 0.0 [feed mm/s], 39.2 [head mm/s]
G1 E-3.9 F6000
G1 X93.41 Y112.2 Z0.4 E0 F210
; END_LAYER_OBJECT z=0.30
; BEGIN_LAYER_OBJECT z=0.40
; *** Slowing to match Min Layer Time (speed multiplier is 0.793536) ***
;
;
; Change tool for loop
G1 F4800 E-9.9641

Since the pillar is generated in Absolute I would guess and say you did not change the Absolute switch to false.

Ok i just pushed an updated version that has a raft for the prime pillar and it automatically detects the M82 or M83 to set the E mode so the above issue will not happen.

But I also found a compatibility issue with the gcode you uploaded earlier. In at least that absolute gcode example from Kisslicer we find it doing a retract right before a tool change which is then followed by the tool change retract. Then next time it selects that tool it does not compensate for that extra retract resulting in starving the extruder of plastic. It is made worse because these are hard to track as a result of Kisslicer repeating the E value when not turning the extruder. Then to compensate for the un-retract we would have to read ahead in the file being processed or process it twice. I am not sure if I can figure this one out. One work around for it would be to set up Kisslicer so it does not retract as often or at all. I have not found this issue in Cura yet.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Hiya Sublime,
Just wanted to let you know that I've not lost interest in this. Just have had very little spare time and on top of that, I've found the airtripper cold end I'm using isn't performing well with Tglase and as a result I've embarked on finalising the design for 2:1 ratio belt driven extruder which uses a MK7 hobbed pulley rather than a hobbed bolt. As soon as I've got dual extrusion working again, I'll get back on to testing.

WRT to you new robot, how did you produce the worm drive components? Printed? If so, I'm keen to here what your experiences were as I'd like to upgrade ingentis Z to worm drive at some point.

Cheers

I too have not given up on this. I have finally figured out the Kisslicer retraction before a tool change issue. I will upload it later.

The new machines wormdrive is completely printed and turned out relatively smooth. I do not foresee any issues with them being printed. But I do have a lot of play in the gears and it will only increase with wear. This is not a concern to me because the bed is so heavy it removes the backlash as well as not using Z-lift.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Ok I think it is done. It now tracks all the retractions and replaces them with the one set for that extrusion type. It also now avoids double retractions as a result of the slicer retracting right before a tool change retraction, etc. It also removes the tool change commands inserted by Kisslicer that would have caused some seriously wacky results that could have been hard to track down. Last thing is you now have the option of removing the comments from the output file. Let me know if it works.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Tim,

I'm getting ready to start design work on my next printer, based on your Ingentis. IIRC, there have been some changes since you published to Youmagine. Is there a more recent repository somewhere?

Thanks in advance.

Hey Dale

No, I've been slack and keep changing things and have limited spare time and I'm over committed wrt to half finished projects and I'm slack.
Would the currecnt version as a complete STEP help in the short term.

Yes, I would love to start from your latest version as STEP. Just point me to whichever location is most convenient for you, please.

I totally get the overcommitted with limited spare time thing. Thanks in advance.

Edited 1 time(s). Last edit at 02/17/2014 08:24AM by Dale Dunn.

@ JimJimma

It turns out that Repetier firmware supports different steps per mm for each extruder. The config file only shows settings for two extruders but if you use this [www.repetier.com] config generator you can have four. It also allows separate PID and and offset values for each extruder so all you would have to do is insert the tool change command (T0, T1, etc) and it can do the rest. It will even allow you to insert gcode into the tool change to do the extra retractions etc. I wish I had known about this before spending so much time writing the tool change script to work around Marlin's shortcomings.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I see there is a new Ingentis google group and there seems to be a lot of concern of the bed dropping at an uncontrolled rate when the motors disengage. I would post there but being signed into Google is not good enough and Google tries to force a G- page on you so I will post it here and hope it makes it there.

A nice simple way of slowing down the movement is with a fluid filled cavity. These are just quick mock ups to explain it a little better.

This one you you would fill with a something like grease (this is how some volume knobs are given resistance).


These two you would use a thick fluid like Lucas oil stabilizer or for speed variable resistance you could use a non newtonian fluid like cornstarch and water.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

It made it over there. (I opened the thread), and it's something I had considered, but I was coming from things like this:
[s135.photobucket.com]

(It's a hydraulic shock with a restrictor in between the input and output sides to restrict the flow of oil.

I'd expect fluid containment to be a problem that needs solving...o-rings? Or can things be printed tight enough to avoid it?

Quote
Sniglet
It made it over there. (I opened the thread), and it's something I had considered, but I was coming from things like this:
[s135.photobucket.com]

(It's a hydraulic shock with a restrictor in between the input and output sides to restrict the flow of oil.

I'd expect fluid containment to be a problem that needs solving...o-rings? Or can things be printed tight enough to avoid it?

That is a good one and would be simple enough to use. But I think it would require a proper cylinder and not be printable (at least not the cylinder wall).

For the the ones I proposed you would need an O-ring or a stuffing box [en.wikipedia.org] which are still used to seal drive shafts on boats to prevent water from coming in. It consists of a chamber around the axle that gets packed with fibres (like cotton) and then packed with grease and/or wax. Since the chamber will not be under pressure it should be able to hold most liquids (especially the thicker ones). I do not think you would have to worry about contaminants in these systems unless it was larger than the space between the impeller and the housing.

As a child I used to build RC boats with my father and the shaft seals were a piece of brass tubing that ran the length of the drive shaft and it had brass plates soldered to the ends with simple holes drilled in the ends for the axle and a small grease fitting in the side of the tube to pack the entire tube full of grease. I do not ever remember having to repack them at all (although it was grease resisting water).

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote
Sniglet
It made it over there. (I opened the thread)
...

I don't see it on the community page.

It is under "Deviations from norm"

Brian

Sorry I've been absent and not very responsive recently. Just started new job and wifey was finishing PhD. Plus I've been printing prosthetic fingers for a guy in the US.
Anyway, enough excuses.
Sublime, I really like the water wheel damper idea .
I'm also getting back onto the multimateral script as I'm keen to see what happens with combining Taulman bridge an tglase. Will post once I've made progress.

Quote
jimjimma

Sublime, I really like the water wheel damper idea .

If you add a weight to opposite Z-cable to balance weight of empty bed, does it solve the problem?

Edited 2 time(s). Last edit at 03/17/2014 08:28AM by karabas.

Quote
karabas

Quote
jimjimma

Sublime, I really like the water wheel damper idea .

If you add a weight to opposite Z-cable to balance weight of empty bed, does it solve the problem?

Stepper motors have some resistance without power right? If you make a pulley system for spectra line with a crazy ratio like 50:1, the stepper itself might dampen the motion. Also it would eliminate the need for the printed z gear and give ridiculous z resolution.

Quote
naxem42

Quote
karabas

Quote
jimjimma

Sublime, I really like the water wheel damper idea .

If you add a weight to opposite Z-cable to balance weight of empty bed, does it solve the problem?

Stepper motors have some resistance without power right? If you make a pulley system for spectra line with a crazy ratio like 50:1, the stepper itself might dampen the motion. Also it would eliminate the need for the printed z gear and give ridiculous z resolution.

The counter weight idea was discussed in the Ingentis builders group on google. I think the issue is the amount of weight required, the fact it will change as something is printed and the space it would take to implement.

The high gear ratio solution has also been discussed and I believe one person is going that way by using a planetary gear stepper motor.

Also Ingentis is using belts on Z not cables if that makes any difference.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Has anyone toyed with a constant force spring to counter the bed weight? Seems like a simple post with a coiled spring anchored to the bed would hold the empty bed steady against the modest holding force in the stepper motor. A fully loaded bed might still fall once the power was removed, of course.

I'd try prototyping it myself, but 3D printer time is hard to find these days.

Quote
robster34
Has anyone toyed with a constant force spring to counter the bed weight? Seems like a simple post with a coiled spring anchored to the bed would hold the empty bed steady against the modest holding force in the stepper motor. A fully loaded bed might still fall once the power was removed, of course.

I'd try prototyping it myself, but 3D printer time is hard to find these days.

I think it was briefly discussed but most of the people building an Ingentis are convinced that a lead screw has to be better for some unknown reason and a lot of them are going with dual lead screws. I can not see any reason myself for a lead screw that can add wobble and even worse dual motors that can become out of sync with each other. But to each their own I guess.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

jimjamma: I saw the video on Z-axis with the belt and big pulley. Is the big pulley printed or did you get it from sdp/si ?

if its printed, how do you like it ? is it working ok and if so, what are the print specs ?

i'm looking into building this kind of mecanism on my z-axis too.

Thanks :-)

J-F