calinb

I've noticed what I think are a couple of Ulticontroller bugs. I might as well bring them up here: 1. Sometimes when scrolling past the end of the file names in the file menu, all the file names disappear from the listing and it's impossible to select a gcode file. Refresh doesn't work. The only way to get the file names back is to remove and replace the SD card. 2, Sometimes (often/usually) after manipulating the machine via the Ulticontroller menus and knob (usually Z-axis height adjustment to clean the nozzle or do a test extrusion using Prepare >> Axes >> Extrude) a problem arises after a gcode file is selected for printing. As the stage seeks home in Z (stage rises), it doesn't move smoothly. The Z-stepper motor starts and stops periodically all the way home. The only way to stop the stuttering is to power down the Ultimaker and start over. :( Obviously, I find #2 to be the bigger PITA! Has anyone else seen these problems? Thanks, -Cal

:geek: And experts must pay their penance with extra clicking during process development!

I don't have time to explain all the details that motivate my frequent use of the Expert pull-down menu right now, but here is a snapshot. I'm printing a variety of production parts for our product ( http://www.smartfirearms.us ) Some parts need to be strong. Some parts need to be very straight (minimum ABS warping). Some parts need to look pretty. All parts need to be ABS! I also frequently use the Cura Project feature to print to layout up to 40 parts per sheet. I use the Fan on Layer Number,Fan Speed (min/max),Infill Pattern, and Retract on Jumps Only adjustments. These settings have proven to be valuable and improve my prints. Other settings may also prove to further my goal to produce the best parts for their application and I am experimenting with a couple of other settings. Maybe a DOE (Design of Experiments) analysis is in order! You have admitted that you don't use ABS and have no interest in it. I think ABS requires more massaging of settings to achieve optimal results than PLA. I've been tweaking settings much more aggressively since I switched from PLA to ABS and the quality of the parts has benefited from it much more so than PLA parts. The parts I'm printing today are far superior to the ones I printed only three days ago, using mostly standard, non-"expert" settings for this reason. ABS is much more picky about temperature than PLA. Too little nozzle heat, you get a weak part. Too much heat and it warps. Controlling the fan at different layers is often beneficial. I started on PLA and I think ABS is more sensitive to a variety of parameters than PLA--for better and worse, obviously.. I change the fill pattern for strength vs. appearance. (I've done the destructive testing of the parts.) One part prints better with retraction on every move. I can save configurations in .ini files. of course, but I've made great improvements in the 40 hours I've spent tweaking and printing using the expert screen. I think continuous improvement will motivate me to continue to use it heavily. I grow tired of the extra menu (instead of a tab) and I find it to be logically inconsistent with the tab settings user interface. If you wish to discourage users from entering the Expert menu, I don't think your strategy to put it in a pull-down is effective to realize that goal regardless. I believe that it's not elegant too,! Also, I think you should put the new retraction checkbox in the same tab as the other retraction stuff (Advanced tab). Anyone who is using retraction will be modifying those settings too! If retraction worked on netfabb, I'd probably use it instead of Cura, because of the incredible power of the Build Style settings (and the NF speed is nice too.) I prefer Cura's skirt and brim feature to NF's nearly useless "primer lines", however, and the Cura Project mode saves time, though I've imported Project mode .stl "temp" files into NF too. A 40 part sheet takes about 10 hours to generate gcode using Cura (Skeinforge). It's takes something like 20 minutes in NF! Thanks, -Cal

Oh..and as long as you're still here in the forum, Daid, may I make a contructively-intended suggestion for the Cura user interface? Given that Cura has "Quickprint" mode for true non-experts, I think "Normal Mode" should have "Print," Advanced," and "Expert" config tabs, instead of its current two config tabs plus one pull down menu (for "Expert"). I think this user interface design change would result in improved consistency. Expert stuff is frequently needed--even by non-experts like me! I'd rather just click away on the tabs, instead of needing to open a pulldown menu and then close a window. Thanks! -Cal

No--I missed the new box. :oops: :( Does setting "Retraction-distance" to zero under the "Advanced" tab still disable it? Personally, I think that redundant controls in a user interface are not usually a good thing; it's sometimes hard for one hand to know what the other hand is doing! Another problem I'd planned to post to github is I have a small part that I'm producing using "Project" mode ("Print all the objects at once" selected). I used "Automatically organize" to place three parts. It took Cura a little more than 10 mins. to obtain gcode. When I place twenty-one parts in the same manner, it takes over six hours to obtain gcode! Task Manager says there's plenty of physical memory available (2GB / 3 GB used) and I see no signs of page swap to disk thrashing. Thanks, -Cal

I assume that you prefer to get bug reports on github, Daid. I posted my bug report for 12.12 there ("Cura 12.12 for Windows doesn't do retraction (at least not in project "all at once" mode). Oops--I meant Cura 12.11. Sorry

I'm still posting, Ian! And I know Daid is still posting (with prompt replies to my posts). The spam is annoying, but I still prefer it to the inferior usability of the Google group. Thanks for your efforts. I wish I had time to help. -Cal

Wow--has it been that long already? I downloaded 12.08 for Linux on Sept. 28th and 12.08 for Windoze on Oct. 3rd. Thanks, Daid! Time for an upgrade, I guess. -Cal

My first project gcode was compiled in "Print all the objects at once" mode. The second project was "Print one object at a time" mode. The problem correlates to the former mode.

It was ugly to watch the head plow through a dozen new parts, stuck well to the heated bed on rafts even (ABS) ;TYPE:CUSTOM G1 Z0.000000 F180.000000 ;End GCode Takes the head to the bed before homing! Ouch! Normal Cura gcode: G1 X103.398 Y101.324 E0.0093G92 E0M107;TYPE:CUSTOM;End GCodeM104 S0 ;extruder heater offM140 S0 ;heated bed heater off (if you have it)G91 ;relative positioningG1 F300 E-1G1 X-20.0 Y-20.0 Z0.5 F6000 E-5G28 X0 Y0 ;move X/Y to min endstops, so the head is out of the wayM84 ;steppers offG90 ;absolute positioning Project gcode with the extra destructive line: G1 X159.514 Y158.219 E2.4386G92 E0M107;TYPE:CUSTOMG1 Z0.000000 F180.000000;End GCodeM104 S0 ;extruder heater offM140 S0 ;heated bed heater off (if you have it)G91 ;relative positioningG1 E-1 F300 ;retract the filament a bit before lifting the nozzle, to release some of the pressureG1 Z+0.5 E-5 X-20 Y-20 F6000 ;move Z up a bit and retract filament even moreG28 X0 Y0 ;move X/Y to min endstops, so the head is out of the wayM84 ;steppers offG90 ;absolute positioning Joergen helped me find the culprit! UPDATE: i just generated a new project sheet. It's pretty much the same thing but I moved the parts slightly. Now the crash-creating G1 Z value is non-zero. G92 E0M107;TYPE:CUSTOMG1 Z12.978001 F180.000000;End GCodeM104 S0 ;extruder heater offM140 S0 ;heated bed heater off (if you have it)G91 ;relative positioningG1 E-1 F300 ;retract the filament a bit before lifting the nozzle, to release some of the pressureG1 Z+0.5 E-5 X-20 Y-20 F6000 ;move Z up a bit and retract filament even moreG28 X0 Y0 ;move X/Y to min endstops, so the head is out of the wayM84 ;steppers offG90 ;absolute positioning Strange! I used auto-placement the first time so I can probably re-create the crash code.

I'm not sure that 85% will stand-up, in general. for netfabb. I was printing a simple test cylinder (both hollow and solid). Although the black ABS I was using was up to these simple test prints, it completely failed to print a more difficult part with some details. I discovered that no matter what temperature I tried (from about 225 to 260) it extruded little "droplets" or "balls" in the molten extruded stream. It also didn't seem to be very sticky so it tended to ball up when printing overhangs on top of support and even sometimes even fill. E-steps per mm, packing density, and extrusion multiplier all amount to the same thing--they are all just adjustments affecting how many turns the extruder drive bolt must make to supply an appropriate amount of extruded plastic. They are actually redundant parameters when more than one of them is provided as an adjustment to the user. In volumetric mode, netfabb provides only "packing density" (more correctly called extrusion multiplier in this case). The user must hack the gcode header to change E-steps / mm. I've learned to examine gcode to see what software is really doing! I switched to some yellow ABS and it was like a new material compared to my yucky black ABS! Nice smooth extrusion and much better at handling the complexity of my part. The black ABS reminds me of fluxline's experience. I'm contacting the vendor, because it's completely unusable for printing anything of value.

I'm tweaking my settings for my first ABS prints and I've discovered that, at least in netfab, reducing the "packing density" setting reduces extrusion. Other software and devs are now referring to this parameter as the "extrusion multiplier," which I agree is a better term than "packing density." I was getting over-extrusion at 100% and I've found that 85% is about right for printing small solid objects in ABS. Looking at the gcode, it is clear that a smaller netfabb extrusion multiplier results in less rapid extrusion in volumetric mode. Scroll the following code windows to the bottom to inspect the G1 E values in the last lines of code: 100% M104 S255.00M92 E866G21G91G1 X0.00 Y0.00 Z5.00 F500G90M109 S255.00G28G92 X0.00 Y0.00 Z0.00 E0.00G1 E0.00G1 X0.00 Y0.00 Z5.00 F600.00M106 S255G1 X205.00 Y200.00 Z5.00 F5000.00G1 X205.00 Y200.00 Z0.35 F5000.00G1 X205.00 Y100.00 Z0.35 F2500.00 E3.23G1 X204.00 Y100.00 Z0.35 F2500.00 E3.27G1 X204.00 Y200.00 Z0.35 F2500 E6.50G1 X203.00 Y200.00 Z0.35 F2500 E6.53G1 X203.00 Y100.00 Z0.35 F2500 E9.76G1 X202.00 Y100.00 Z0.35 F2500 E9.80G1 X202.00 Y200.00 Z0.35 F2500 E13.03G1 X201.00 Y200.00 Z0.35 F2500 E13.06G1 X201.00 Y100.00 Z0.35 F2500 E16.30G1 X202.00 Y100.00 Z0.35 F50000 E11.44G1 X0.00 Y200.00 Z0.00 F15000G92 E-4.85 G1 X0.0000 Y200.0000 Z0.2000 F3240.0000 M107G1 X0.0000 Y200.0000 Z0.3800 F1200.0000 G1 X0.0000 Y200.0000 Z0.4000 F1200.0000 M104 S255.0000 (minimal layer time: 10.00 / Time Entry: 0)(#0-#3: extrusion time: 77.93 / jump time: 5.03)(printing at normal speed)(begin layer 1 at 0.040)G1 X0.0000 Y200.0000 Z0.0600 F1200.0000 G1 X0.0000 Y200.0000 Z0.0400 F1200.0000 G1 X97.3200 Y86.9100 Z0.0400 F10500.0000 E0.0000 G1 X98.7468 Y85.2519 Z0.0400 F10500.0000 E0.0000 G1 X99.9800 Y84.2500 Z0.0400 F1200.0000 E0.0150 G1 X101.6100 Y83.3600 Z0.0400 F1200.0000 E0.0325 G1 X103.3800 Y82.8100 Z0.0400 F1200.0000 E0.0500 G1 X105.2100 Y82.6100 Z0.0400 F1200.0000 E0.0674 G1 X107.3200 Y82.8300 Z0.0400 F1200.0000 E0.0874 85% M104 S255.00M92 E866G21G91G1 X0.00 Y0.00 Z5.00 F500G90M109 S255.00G28G92 X0.00 Y0.00 Z0.00 E0.00G1 E0.00G1 X0.00 Y0.00 Z5.00 F600.00M106 S255G1 X205.00 Y200.00 Z5.00 F5000.00G1 X205.00 Y200.00 Z0.35 F5000.00G1 X205.00 Y100.00 Z0.35 F2500.00 E3.23G1 X204.00 Y100.00 Z0.35 F2500.00 E3.27G1 X204.00 Y200.00 Z0.35 F2500 E6.50G1 X203.00 Y200.00 Z0.35 F2500 E6.53G1 X203.00 Y100.00 Z0.35 F2500 E9.76G1 X202.00 Y100.00 Z0.35 F2500 E9.80G1 X202.00 Y200.00 Z0.35 F2500 E13.03G1 X201.00 Y200.00 Z0.35 F2500 E13.06G1 X201.00 Y100.00 Z0.35 F2500 E16.30G1 X202.00 Y100.00 Z0.35 F50000 E11.44G1 X0.00 Y200.00 Z0.00 F15000G92 E-4.85 G1 X0.0000 Y200.0000 Z0.2000 F3240.0000 M107G1 X0.0000 Y200.0000 Z0.3800 F1200.0000 G1 X0.0000 Y200.0000 Z0.4000 F1200.0000 M104 S255.0000 (minimal layer time: 10.00 / Time Entry: 0)(#0-#3: extrusion time: 77.93 / jump time: 5.03)(printing at normal speed)(begin layer 1 at 0.040)G1 X0.0000 Y200.0000 Z0.0600 F1200.0000 G1 X0.0000 Y200.0000 Z0.0400 F1200.0000 G1 X97.3200 Y86.9100 Z0.0400 F10500.0000 E0.0000 G1 X98.7468 Y85.2519 Z0.0400 F10500.0000 E0.0000 G1 X99.9800 Y84.2500 Z0.0400 F1200.0000 E0.0128 G1 X101.6100 Y83.3600 Z0.0400 F1200.0000 E0.0277 G1 X103.3800 Y82.8100 Z0.0400 F1200.0000 E0.0425 G1 X105.2100 Y82.6100 Z0.0400 F1200.0000 E0.0573 G1 X107.3200 Y82.8300 Z0.0400 F1200.0000 E0.0743 Furthermore, note that the E-steps "M92 E866" statement is identical in both sets of gcode. The G1 E values are reduced by 15% in the 85% case. I think ABS expands more than PLA after it's cooked! If the softer ABS filament rode deeper into the knurling of the hobbed drive bolt, MORE turns of the (effectively smaller diameter) bolt would be required to drive the same length of filament compared to PLA. This would require a LARGER "packing density" setting, instead of a smaller one. I did use a micrometer to measure the ABS filament in several places and updated my netfabb materials settings.

No problem and the new spec in the shop looks good, Daid! I'd rather have the current bed than the extra 1-1/2 cm! In fact, I like the spring loaded bed so much, I just milled the same style slots in two 2.5 mm glass plates for my new heated build plate. Milling glass is painstakingly slow! I'm pleased Ultimaker was responsive and changed it promptly. I was a sort of a "specmeister" in my last job and it's my nature to verify specs, I guess!

Thanks, Troy. I didn't look carefully and missed the cases where the retractions deviate from the obvious pattern. -Cal

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!

My shipping costs to the west coast of the U.S. were somewhat brutal ($USD 154.41) but, on the upside, DHL did a great job. My printer was shipped on Friday and it arrived on Monday! I was in a hurry to get the printer for my business so I probably would have paid for next day air delivery on a state-side purchase too, which would've cost somewhere around $100 or a bit more.

I forgot to mention that it's Speedball brand indigo blue ink. I used an airbrush to spray it thinned 1 part ink to 2 parts denatured alcohol (ethanol poisoned with methanol by the tax man here in the US, who would rather have blinded citizens than have them dodge the liquor taxes!) I selected ink instead of water base stain or paint because the more volatile ink carrier flashes off more quickly than water, and I figured it would be less likely to raise the wood grain or swell parts. Two 2 oz. bottles of Speedball ink could be carefully stretched to completely paint an Ultimaker but it would be tough to even add an Ulticontroller to the job. I used three bottles and have plenty of ink left-over for touch-ups. I was running out of my second bottle before I started to paint my Ulticontroller. If I were to do it again, I'd lightly sand the faces of the plywood panels to remove any splinter fingers before painting.

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.

It's a rev.2: http://wiki.ultimaker.com/Ultimaker_rev ... usion_head I have the latest model with the V2 hot end, but no Bertho drive mod yet. I just liked the way they positioned the aluminum heating block and routed the wires in this rev.2 wiki so I re-configured my new re.3 in this configuration when I re-assembled the hot end after a tear-down to debug my feeding problems, which are now solved.

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! :(

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

Yes--I will install the Bertho upgrade! > edit: I just noticed another difference. You have a white clip in the grey part where the filament enters the bowden tube. With the repeated tear-downs and reassembly necessary for debug, I broke my original gray clip. I used one of the extra white clips from the old hot end parts. It seems to work fine and I also printed the spacer to remove play from Thingiverse: http://www.thingiverse.com/thing:22851 (I'm using both this spacer and the white clip.) The Bowden tube seems to hold well and it does not move at all at either end with firm tugging and pushing.

Thanks, Daid! That's good to know. I screwed my plexiglass down nearly all the way so my printer is around 206-207 mm now too. Given your accounting for 5 mm in the bed design change, the shortage becomes a mysteriously-missing 8mm. I'm not very motivated to find the missing millimeters because, like most users, my Z-travel is adequate for my needs. I mostly wanted people to be aware of the true Z-travel capability of a currently shipping kit.

My duct was hitting the right table arm in back so I cut the interfering tab off the duct and super-glued it in that corner. Rubberized superglue with "kicker" (superglue / CA accelerator) works best. Superglue alone will not stick well, requiring this bond "promoter." Note the superglue filet in the corner of the duct to glue the hold the corner together after removing the snap tab and increase the corner strength, should it still make light contact. However, removing the tab still did not provide the needed clearance with the table arm so I used a Dremel tool to elongate the holes in the duct. I've now moved the duct as far as possible toward the front of the printer and away from the right table arm. (The flats of the back nuts are hard up against the inside wall of the duct.) This mod still resulted in very light contact with the table arm (but probably would've run okay) so I used a fine cutting tool on a Dremel tools to shave another few tenths of a millimeter from the outer wall of the duct where it made contact with the table arm. This photo does not show the shroud in its current position--all the way forward. It is flush with the side of the fan here but actually needs to go as far as possible to the front of the printer (until the flats of the rear nuts make contact with the duct inner wall), where the outer wall of the duct will be slightly "past flush" with the rear edge of the fan. After tending to this duct problem, my Ultimaker meets spec for travel in X and Y (210.3 mm and 210.3 mm measured at mechanical hard stop). With careful setting of the limit switches, 210 mm should be possible in operation. However, in its standard configuration and building from the parts ship in factory kit, the Ultimaker is not even close to making 220 mm in Z-travel! My table only travels 204.8 mm before hitting mechanical limits. I could obtain another 2 mm in Z by screwing the table adjusters all the way down but, to achieve the advertised Z-travel spec, I would need to replace the 10 mm thick acrylic plate with a thin build plate (2.5 mm glass?) and rework the table arms to place the Z-axes bearings right down on the bottom floor of the printer frame at max-Z. This would provide barely over 220 mm of Z-travel, but the table modifications would require a significant effort. Additionally, the hot end could be raised to increase Z-travel to a small degree and reduce the magnitude of the modifications to the table, but that would be even more difficult than modifying the table arms or designing and building an entirely new table. I don't see how this machine can be advertised as a 210 x 210 x 220 printer, except that most people don't care much about Z and never check the printer's actual performance on the Z-axis. To achieve 220 mm of Z-travel requires much more than adjustment of the printer; it requires a redesign of two or more components! The design, as shipped, is a 210 x 210 x 206 printer (after fixing the fan duct interference and dropping the build acrylic plate nearly all the way down.

The bolts can be easily cut to custom lengths with a Dremel tool and small cutoff wheel. Screw a couple of nuts past the cut line first--just in case the threads need some cleanup near the cut afterwards. Put a drop of oil on the end of the threads after cutting but before removing the nuts too. I've found the threads usually remain very clean and nice, if a fine cutoff wheel is used with a steady hand and low cutting force. The extra precautions to "chase" the threads afterwards are not necessarily required. One place that I found cutting bolts to be indicated was the the hot end assembly. I shortened two of the four m3 studding bolts holding my hot end together (the ones not retaining the fan), because I preferred the orientation of the aluminum heater block, as depicted in the older Rev.2 instructions: The left side of the hot end is facing up here: The heater and TC wires are more relaxed in this position, I think. However, if the aluminum block is assembled in this position, the new longer m3 studding bolt in the right front corner interferes with it. At least this one studding bolt must be cut. I cut the one in the back left corner too, because a shorter length is more appropriate and better looking! I changed to this configuration when I reassembled my V2 hot end after a tear down to search for signs of plastic leakage inside my PEEK. I wanted to correct the tendency of the binding heater power cable trying to twist the aluminum block and unscrew it from the brass tube or rotate the peek in the aluminum plate. Now that my wires are completely relaxed in the new orientation, my aluminum block will tend to stay put.