DaHai8

I would suggest you run through the calibration steps in this guide: Triffid Hunter's Calibration Guide Like you said, overextruding the bottom layer is not the answer - you should never need to do that. All the layers look poor (sorry). What printer did you select in Cura to base your Maker Select on? Not sure selecting the wrong one could make this much of a difference, but best to examine everything...

It appears that if the vertical thickness of any given set of layers is less than the top or bottom layer thickness, Cura fills it in with yellow 'infill', and jumps around to set all these areas. You can minimize this somewhat by setting the bottom layers number to a smaller number (like 1) - leaving the top at 0.

Ok, let's level-set on what is a good, smooth bottom layer. I consider this to be a near perfect bottom layer (others may disagree ): You can still see the filament lines but it is all uniform with no gaps and no blobing and butter smooth. Now we need to see what your bottom layer looks like. On the other points in your post: Without a Raft: Layer 0 in the gCode is the same as Layer 1 in Cura (don't ask me why its done this way, 'cause I dunno). So Layer 0 is a real printed object layer, not an 'extra' layer, but part of your print. Skirts and Brims are printed on the same layer as the first real layer of your object (not a layer below it). Increasing the filament temperature is not necessarily the best option in getting a smooth bottom layer. I print at 200c nozzle and a bed heated to 75c (PrintBite bed, not glass). Glass is good, though, better than Blue Tape! Higher than required printing temperatures can lead to blobbing, stringing and holes. Having to over extrude the bottom layer may just be covering up another issue. Perhaps your Extruder is not calibrate correctly and is always under extruding. You should not need to over extrude the bottom layer to get a smooth finish. Something else is amiss there. Look at your Speed settings in Cura. The first layer should print at a slower speed than the rest of the layers to improve adhesion. This automatically slows down the extrusion rate to account for the slower speed on the first layer. Here are the settings for the Prusa I3 MK2 as an example: Check you Speed setting and your Material Flow rate (should be around 100%). You could also be dealing with a partially clogged nozzle. If you manually extrude filament (with the nozzle at printing temperatures), does the filament come out in a nice smooth straight line or does it get all twisty around the nozzle? Twistyness indicates a partially clogged nozzle.

To someone who is not a programmer and new to 3D Printing, this is not an invalid assumption. After-all, there are many data formats that are 'universal' or self-defining (PDF, Postscript, HTML, XML, etc.) Why gcode, as an open-source data format, doesn't contain standard setting definitions is a valid question (IMO). As 3D Printing matures, I see this a necessity...

[] are sets ? is match 0 or 1 times * is match 0 or more times Basically, its says: Start at the beginning of the string (sub_part) : ^ Look for 0 or 1 '-' or '+' signs: [-+]? Look for 0 or more digits: [0-9]* Look for 0 or 1 decimal point: \.? Look for 0 or more digits: [0-9]* If it finds a match to that pattern, that sub-string is returned. P.S. decimal points (periods) are escaped (\.) as they can have special meanings in Regular Expressions. And I added the signs (-+) for relative moves, which can be negative - even through that's hardly ever used.

Sometimes the hardest bugs to find are the ones that Are NOT in your code! Your script was not failing if the Layer didn't start with a G code, it was failing if the Z height was less that 1. ;LAYER:1M106 S255M204 S750M205 X10G0 F5100 X116.836 Y75.235 Z.4 The getValue def from the Script.py file in Cura assumes all numerical values have at least one digit to the left of the decimal point: m = re.search('^[0-9]+\.?[0-9]*', sub_part) Clearly this is not the case for layers less than 1mm ... My solution was to replace their getValue def with my own: # def getMyValue(self, line, key, default = None): if not key in line or (';' in line and line.find(key) > line.find(';')): return default sub_part = line[line.find(key) + len(key):] m = re.search('^[-+]?[0-9]*\.?[0-9]*', sub_part) if m is None: return default try: return float(m.group(0)) except: return default It also handles keys with lengths greater than 1. You will also need to add this to the second line of the script: import re That should get you going again - it worked for me. Cheers.

Cura v 2.3.0: "No New Version was found" I don't recall Cura 2.x ever telling me when a new version was available. I use it every day and the only times I found there was a new version was someone mentioning it in this forum.

Use WordPad in Windows. It will split the lines properly.

P.S. On Python, the indentations size does not really matter, as long as its consistent (2, 4, or 8 spaces: .def (new function) commands in def loop commands within loop commands outside of loop return def (new function) ... Python is a position oriented language on its functions/subroutines and code blocks - unlike C or Perl that used braces { }. So a code block is an indent, a sub-block is an additional indent. To end a code block you place your commands a the previous indent.

You're on the right track. for layer in data: The data part is the whole gCode of your object. The layer part splits that gCode into sections by Layer: ;LAYER:0M117 0/124L, 0.00%.M107M204 S500M205 X5G1 F2100 E-2G0 F1200 X70.225 Y72.273 Z.2;TYPE:SKIRTG1 F2100 E0G1 F1200 X70.676 Y71.863 E0.02027G1 X71.099 Y71.533 E0.03812G1 X71.619 Y71.245 E0.05789G1 X72.045 Y71.053 E0.07343G1 X72.549 Y70.87 E0.09126G1 X73.241 Y70.746 E0.11464... Then: lines = layer.split("\n")for line in lines: Splits the Layer data into lines terminated with the '\n' into an array called 'lines'. Then the 'for' loop just loops over each line in the 'lines' array. Since you're only wanting to make changes at the start of every layer, you may not need the 'for lines in lines' loop at all. Just: index = data.index(layer)layer = wipe_gcode + layerdata[index] = layer on each 'layer' of the data. And you should not need the 'break' either, since you're only working at the layer resolution. Hope this helps

Kin, It's all about the indents. If they are not perfectly aligned, the Python interpreter just tosses out the whole script. The last return at the bottom of you script is not perfectly indented from the def execute subroutine declaration. If NotePad++ has an 'Untabify' function (remove tabs and replace with spaces), use that after aligning the 'return' statement. Otherwise, might I suggest Kimodo Edit from ActiveState. It's free, easy to use and understands a lot of different programming languages (including Python). And it has a function under the 'Code' menu to 'Untabify Region' (which basically removed tabs and replaces with spaces all the lines you have highlighted). That's is how I got you script to load and show up in Cura. Hope this helps.

Disconnect your printer. Then try to start Cura and select your Printer. The log shows it failing after it connects to your printer. Could be just a coincidence...or not...

You model is inverted (inside-out). In .stl, walls have faces (inside and outside). Your model has been inverted (inside faces are facing out, outside faces are facing in). If you load your model into an editor (like Sketchup), it will show outside faces in white and inside faces in grey. I'm betting your model is all grey on the outside.

I'll recreate the STL file as I've already deleted it. Buy I have a question about this approach of no retraction between supports: 1) The stringing puts pressure on the supports, doesn't it? I found my thin supports fell over - I believe because as the head is moving and stringing it's pulling on the support it left behind. As a result, my print failed as the thinner support towers fell over (so I tried a raft, but that issues is in a different post) 2) With strinning, the filament is oozing and being pulled out of the nozzle. So when it reaches the next support tower, it starts printing with no filament at the tip and so prints nothing for a few millimeters. So the target support is weaker. Other than reducing retractions, I think the Cons outweigh the Pros. Perhaps a maximum distance to do travel between supports without retraction? So short distances would not retract, but longer ones would (user defined) Thanks

I understand (maybe) a one layer air gap, buy two layers (.4mm) ?? I don't think that's gonna stick to anything and just drag filament all over. Also v15.x didn't do this and I never had problems removing the raft.

Awesome!!! Thanks!!!!!

There does not appear to be any retraction performed between supports to supports and supports to objects, thus resulting in massive stringing issues.

With Rafts and Supports, the parts of the object that should touch the raft are being printed 3 layers up (in mid-air)

Are you sure its not just making a single print pass and then a travel pass over it? Have you check the Layer view in Cura to see if it is a single wall or not? Do you have any calipers to put on the wall to see exactly how thick it is? Cura 15.04.4 [/br] Cura 2.3 (Release) I've printed single wall items in both versions of Cura and not seen what you are experiencing. Perhaps there is a setting that's not right.

I got my feet wet writing Cura Post-Processing Plugins (that's what you'd want) just by examining the code and hacking at it until I got what I wanted. All the Post Processing Scripts for Cura 2.3 can be found here: C:\Program Files\Cura 2.3\plugins\PostProcessingPlugin\scripts There's not a lot to them: A Class Name that matches the Filename that must contain: def __init__(self): init the class def getSettingDataString(self): Get the data from the dialogbox def execute(self, data): do the modifications to the g-code pass in the data structure The python file must also import Script at the top: from ..Script import Script That's the basics, its just wack and hack from there!

User defined (add/move/remove) individual supports would be awesome. I'd bet Cura developers are already working on that. This would address a host of issues/requests regarding supports.

Here's a wiki page on all the g-code commands and which flavors of firmware they apply to: http://reprap.org/wiki/G-code Just be aware that if you don't know what you are doing in editing g-code manually, you could seriously mess up your printer (head crashes, stepper motor malfuctions, filament jams, etc.)

Any ideas where the location could be on a Mac...?! changed and added some machines, but cannot find any .cfg in the user/.cura folder with the date of today and/or a name that I would recognize. Sorry, that's where I would've looked. Any Mac users know where the Cura Printer configs are??

My Cura 2.3 beta had version 2.3 in the about box. 2.3 Release also warned me that version 2.3 was already installed (it was the beta). I downloaded that beta the second day it was released (Sept 2) and even the install file is named "Cura-2.3.0-BETA-win64.exe". Then when the second 2.3 beta was released, it was given the same number, adding to the confusion. If its to be Cura 2, then why not Cura 2 v1.3 ? (Probably even more confusing...sigh) Or Cura++, Cura Turbo, Cura - TNG

For me, it did. While Cura was running and connected (via WiFi) to my OctoPi, it was streaming video at the Mbps level on my 802.11n network (2.4G). I use the RainMeter Windows 10 Widgets to monitor my PC's network, HD, CPU, etc. and saw my PC receiving that much data continuously. I was streaming video (Internet TV) at the same time (on my tablet, not my PC) and it was constantly pausing and chopping until I exited Cura. The Network Receive rate on my PC dropped to 0 and my Internet TV stream flowed smoothly from then on. I like the idea of a toggle switch to display, or not, the streaming video so I can turn it on/off whenever I need to. Wouldn't the high-speed slide-show be less bandwidth efficient than video streaming? I mean, with a slide show there's probably no frame-to-frame compression going on, just single image compression. Just like when you take 1,000 frames of time-lapse photos that are Gigabytes in size (even with jpeg compression), after you generate an mp4 video from it, its only a few Megabytes do to the cross-frame compressions. So I'm thinking going from high-speed slide-show to video streaming would be even less of a bandwidth impact. I'm just guessing here, I'm by no means a bandwidth guru. Thanks for the response. I liked the OctoPrint Plug in a lot and would love to be able to use it more.