anon4321

Cool, I'll give that a try tonight and let you know...

Oh yes, that was a qualified everyone. Everyone printing over USB and over a certain size. Although, the size is relatively small. This issue occurs on the first 60-70 or so lines of gcode. I'm not sure plugins factor into this as I'm not using any and it is occurring in the load of the output of the slicer. The slicer output looks OK. However, just after the slicer output is loaded into the BigDataStorage object, dumping the BigDataStorage object shows that the issue occurred. I'm not sure plugins intercept things between those two points. I'll look into it more tonight (EDT) and let you know what I find.

I'm leaning towards an issue in BigDataStorage. I was able to capture the raw data sent back from the slicer and it looks fine with only a space where it is broken in the output previously posted. http://umforum.ultimaker.com/index.php?/gallery/sizes/12031-curaissue/large/

I've tracked this back in the code and it is HIGHER up in the processing. EVERYONE is potentially affected by this. I added some logging lines in serialConnection.py. This routine loads the output of the slicer into memory - #Load the data into memory for printing, returns True on success def loadGCodeData(self, dataStream): if self.isPrinting() is None: return False self._gcodeData = [] tempLog = open("c:\\users\\Internet\Desktop\\CuraIssue0.log", "a") tempLog.write('Stream:\n') for line in dataStream: tempLog.write(line) tempLog.write('-----') #Strip out comments, we do not need to send comments if ';' in line: line = line[:line.index(';')] #Strip out whitespace at the beginning/end this saves data to send. line = line.strip() if len(line) < 1: continue self._gcodeData.append(line) tempLog.close(); return True The output of the test is: -----G1 X70.801 Y108.700 E47.97552 -----G1 X70.801 Y96.300 E48.96752 -----G1 X65.801 Y96.300 E49.36752 -----G1 X65.801 Y90.600 E49.82352 -----G0 F13500 X66.201----- Y91.000 -----G1 F600 X75.601 Y91.000 E50.57552 -----G1 X75.601 Y100.300 E51.31952 -----G1 X138.800 Y100.300 E56.37544 -----G1 X138.800 Y104.700 E56.72744 -----G1 X75.601 Y104.700 E61.78336 Noticed the ----- in the middle of the line. This indicates that the code is interpreting this single line as two lines when it is sent down stream. This will result in bad gcode being sent to the printer causing the original problem. Cura is using a class called BigDataStorage which is doing some manipulation to get around memory limits. I haven't been able to walk back into that code to know if the problem occurs in that code or if it originates in the slicer or in the code that receives the output of the slicer. Hopefully Daid will see this. This could cause some random quality issues as the split gcode can't be recovered.

Daid, it looks likes there could be an issue with Cura. Not sure, could be a hardware problem on my machine. For the files below, I'll PM you a link to a zip. With Cura 15.1-RC8, if I slice Tresse_Arm.stl using the Tresse_Arm.ini, the results are shown in Cura.log. To get Cura.log, I added this a line to machineCom.py: self._log("Unexpected error: %s" % (getExceptionString())) checksum = reduce(lambda x,y:x^y, map(ord, "N%d%s" % (self._gcodePos, line))) self._callback.mcMessage("Sending N%d%s*%d" % (self._gcodePos, line, checksum)) self._sendCommand("N%d%s*%d" % (self._gcodePos, line, checksum)) Cura sends a two lines that looks like this (from Cura.log): < Sending N54G0 F13500 X66.20*61 < Sending N551 Y91.000*16 But the gocde should have been (as shown in Tresse_Arm.gcode): G0 F13500 X66.201 Y91.000 This seems to confuse the firmware. If I clear the platform and use Tresse_Arm.gcode directly, the problem doesn't occur. Thoughts?

One way to check if the pulley roundness is causing this problem. Load the part as you have in the first picture. then use Cura to scale the Y axis (you need to unlock the Lock X,Y,Z together icon). Now with the part longer in the Y direction, use Cura to rotate the part 45 degrees. If you see reoccurring changes in width, it's a problem with the pulley roundness.

Is nylon food safe? My understanding is it is durable even above 100C. Apparently, it behaves differently above Tg which is still listed under 100C. However, for obvious reasons it needs to be printed very hot and therefore probably with an all metal hot end. And it is about 4x the price of PLA. Note that I think these are half the weight of a normal spool: http://fbrc8.com/products/pa6-nylon-filament

From http://colorfabb.com/xt-copolyester : All these efforts have lead to a unique formulation for 3D Printing that features excellent properties : High strength and very high toughness, Odor Neutral processing, High Tg / improved temp. resistance, Styrene free formulation, FDA food contact compliance, BPA (Bisphenol A ) free formulation.

I think Colorfabb's XT is PET or PET like and is food safe. You can order directly from ColorFabb. Delivery takes about 5-6 days via UPS. http://www.printedsolid.com/ is the official CF US reseller. I've ordered from them and shipment was very quick. Their problem is stock or lack thereof...

Thanks Daid, yeah I noticed that no matter where the drivers come from, they are all 1.0.0. Wonder if you could tell me - Have there been any changes in Cura that would impact the checksum calculation? Is there a way in Cura to log the serial comm so I can see if the checksum is correct? Thanks in advance.

Just to be clear to everyone, the material cooling fan is driven at 19V. Some fans won't like this and instantly release the magic smoke. If you use a 12V fan, you can use a zener diode to drop the voltage such as: http://www.newark.com/fairchild-semiconductor/1n4735a/zener-diode-1w-6-2v-do-41/dp/18C8951?CMP=TREML008-005 Mind the power rating. That zener is a 1W which limits the max current of the fan you should use to 160ma. However, at that current, the fan's rating can be as high as 1.9 watts which is a large amount for fans this size.

Nope spoke too soon....

Most likely something on my end. I uninstalled the driver and reinstalled using the instructions here: Step 4: http://arduino.cc/en/guide/windows Same version uninstalled was the same version reinstalled. However, my issue went away....

Today I updated to RC9 after using RC8 successfully for many prints. Now I get checksum errors and the print stops. I went back to RC8 and still have the issue with checksum error. However, it is printing successfully from the SD card. I can't say for sure that something isn't broken on my side. The last set of prints were running off of a pcduino running octoprint. It's possible the pcduino overdrove the usb input and the board might be oversensitive to noise but IDK....

XT?

Oh, I didn't think about that... Never mind, move along, nothing to see here....

:sad: We HBK owners have clips too ....

Is it attempting to fill the top layers or is it just not printing the top layers? If it is the latter and if you sliced with Cura, make sure the top and bottom options are checked in Expert menu -> Open expert settings / Infill section / Solid infill top & solid infill bottom.

I think you are overly concerned about the couplers. Couplers are very common in CNC systems.

I disagree with George on two things. First is that going slower will help. For the part I was printing, slower made the part warm even after removing it from the bed. And two, not more fan .... more COWBELL! Actually, George has a lot of experience so his advice is worth trying.

I just discovered something last night that might be of help. I was printing the small gear from this gear set for the UMO extruder: http://www.thingiverse.com/thing:40334 I was having a hell of a time getting a decent print in XT. Too hot and the teeth would deform and too cold cause under extrusion. The reason might be relevant to this discussion. I watched as the edges of the teeth were printing and I could see that as the extruder laid down the next layer, the part was so soft that the extruder deformed a few layers below it. After much trial and error I think I hit on the solution. It's simply that because of the small layer size, the extruder simply puts too much heat into the part. This is especially a problem with XT as requires hotter temps to flow and then remains very soft due to those very hot temps. So I figured that I would add more fan and reduce the temp but that only caused underextrusion. Printing slower only seemed to put more heat into the part. The fix was to get the nozzle off the part preferably by moving the fan over the part for extra cooling. Cool head lift will meet some of this but it's problem is that the extruder begins to seep molten filament when you lift for too long of a time. The My best result was achieved by printing a circular column next to the part in "all at once mode". This caused the extruder to move onto the column giving time for the small gear to cool. Since it was actually printing a part (even if it was later discarded), the nozzle didn't have extra plastic seeping from it to ruining the start of the next layer. Even better, I positioned the column such that the circular motion of the extruder while the column is printed bathed the gear in cooling air. TLDR; small parts with quick to print layers will have bad overhangs because the part gets too hot. Use cool head lift and minimum layer time or print other parts "all at once" so the part gets a chance to cool and firm up before the extruder revisits it for the next layer. Too much heat causes sagging. Try printing 2 or three copies of the test at one time....

I agree with Jonny, It's the force from the set screw that distorts the pulley.

Do you have a heated bed? Or did you select UMO w/HBK ? This issue is probably due to the HBK having a different steps/mm. In Cura, go to FIle -> Preferences and select PronterFace as the Print Window UI. Then select File->Print to open the Pronterface UI. On the right there is a window that shows output from the printer. At the bottom of that window there is a small input box that is used to send commands to the printer. In the small input box, enter: M503 and the printer will response with information about the current settings. Look for the value that is prefixed with Z under the heading "Steps per unit:" Without the HBK upgrade, the Z value for steps per unit is: 533.33 With the HBK upgrade or the firmware for it, it will be: 200 So if you use the HBK firmware but do NOT have the HBK, the firmware steps 200 steps for every 1 mm of Z movement where it should step 533.33 steps. The result will be that the height will be squashed to about 40% of normal. It's best to find and use the correct firmware. However, if you reflash the firmware you used before, you can probably correct it by copying the entire line under the "Steps per unit:" that begins with M92 and paste it into the small input box and then edit the Z value to be 533.33 and press return. Reissue M503 to ensure the value is set correctly. Then issue: M500 which will save the settings in non-volatile memory.

Frederik, this is most likely because when you install things, you need to have elevated/admin permissions and the installer is started under an admin account. When installers like the one Cura uses offer to launch Cura at the end, it too is run with elevated/admin privileges under the admin account. Win7 won't let you drag/drop from a non-elevated process (Windows Explorer) to the elevated copy of Cura started by the installer or from one program under one user to a program running under a different user. Simply restarting Cura gets it running under normal permissions so Drag/Drop works.

I did notice that with the single set screws original pulleys, the out-of-roundness problem was always in the direction opposite the force the set screw applies. So when people say tighten the heck out of the set screws, be careful. I think with two, the force required is much less so is less likely to distort the pulley. One, the force is split between two pulleys and two because two screws biting into the shaft "grabs" more.