johank

How you can end up at an XYZ Da Vinci without answering "I don't care about quality at all" is perhaps not that good. Funny chart.

I think Cura already supports manual slicing, Once you've written your g-code you can load it into Cura for visualization.

Dim3nsioneer: Thanks, I missed your post That is really interesting. I guess it's too late to fix this problem hardware-wise for the UM2. The question is if it can be tweaked in software so that the EMC stays within limits.

Has someone tried the P(ID)- approach Daid suggested with a really high P coefficient and the I and D values ignored?

I did a test today to print with different firmware versions using the gcode provided by undeviljur. I asked two persons to order the quality of the prints. I compiled 14.03 and the dev version with and without PIDTEMPBED defined and also used firmware 14.09 provided with Cura. These were just one off prints but the result was in accordance with previous results. Pretty much both person said 14.03 print was the best one followed by dev with PIDTEMPBED defined. I think some problem arise when not using PIDTEMPBED, but I can't believe it has something to do with the bed temp. If this is a real effect we're observing maybe it has something to do with scheduling. But that is just pure speculation at this point.

arapp, Could you post some photos of the printer itself? Feeder and hot end mainly. It your feeder starts eating filament it is a good idea to check whether there is ground up filament reducing the efficiency of the knurled wheel. Seeing the result of your atomic cleaning the main residue seems to come from the interface between the PTFE- isolator and the integrated nozzle. If there is a gap between the isolator and the nozzle this could be the source of your problems causing temporary blockages. /J

It may be worth pointing out that Marlin defines some pins as sensitive and won't allow you to change their value with M42. The default list of sensitive pins is something like this: 0, 1, X_STEP_PIN, X_DIR_PIN, X_ENABLE_PIN, X_MIN_PIN, X_MAX_PIN, Y_STEP_PIN, Y_DIR_PIN, Y_ENABLE_PIN, Y_MIN_PIN, Y_MAX_PIN, Z_STEP_PIN, Z_DIR_PIN, Z_ENABLE_PIN, Z_MIN_PIN, Z_MAX_PIN, PS_ON_PIN, HEATER_BED_PIN, FAN_PIN, E0_STEP_PIN, E0_DIR_PIN, E0_ENABLE_PIN, HEATER_0_PIN, analogInputToDigitalPin( TEMP_0_PIN), analogInputToDigitalPin( TEMP_1_PIN), analogInputToDigitalPin( TEMP2_PIN), analogInputToDigitalPin( TEMP_BED_PIN), (E1_STEP_PIN, E1_DIR_PIN, E1_ENABLE_PIN, HEATER_1_PIN; if dual extrusion enabled ) which for me translates to 0, 1, 25, 23, 27, 22, 24, 31, 33, 29, 26, 28, 37, 39, 35, 30, 32, 12, 4, 7, 43, 45, 41, 2, ((8 < 16) ? (8) + 54 : -1), ((9 < 16) ? (9) + 54 : -1), ((-1 < 16) ? (-1) + 54 : -1), ((10 < 16) ? (10) + 54 : -1) (49, 47, 48, 3, if dual extrusion enabled) The reason your code wont work is P4 is by default the HEATER_BED_PIN which is sensitive. /Johan @Daid: TEMP2_PIN defined to -1 doesn't play well with analogInputToDigitalPin(). Pin 53 is protected unintentionally. Perhaps use, #define alt_analogInputToDigitalPin(p) ( ((p) < 16) ? ( ((p) >= 0 ) ? (p) + 54 : -1 ) : -1 )

I resolved my similar problem by using pronterface for printing instead. There seems to be some bug with latest Cura. Im sorry to say it, but pronterface appears to be much more reliable right now. As for Ulticontroller, I'm simply not interested. There is no way you get the same level of potential control over your printer using a Ulticontroller.

The Ultimaker shows up as a serial port om your computer. The commands to control The Ultimaker via the Marlin firmware are Plain text command called G-Code. I don't know if a Marlin specific reference of G-code exists, but a general documentation for reprap descendant machines like the ultimaker is available at http://reprap.org/wiki/G-code. For the actual command set you can check https://github.com/bkubicek/Marlin/blob/master/Marlin/Marlin.pde, which contains the Marlin source code for communications. regards, Johan

I get a similar error after printing for an hour or so. Happened two times so far. Now I will try using pronterface.

Hi Daid, I'm one of the Swedish users of Cura, and I have some problems. Using the standard settings of Cura, the program wont slice anything 3 days a week. All I get is a Ubuntu crash report, however Cura keeps running, and creating more crash reports. I have located the source of this error to the fact that my Ubuntu is set to use the Swedish language. The problem is that 3 weekdays in Swedish contains special characters (Måndag,Lördag,Söndag), and when Cura generates ascii string from "{day}" in start.gcode these days are represented with ("mån","lör","sön"), which gets a representation containing something like 0xC3A5. If I start Cura with "LANG=en_us; cura", all is well, and my model slice. the error is reported like: Traceback (most recent call last): File "/usr/share/cura/Cura/gui/sceneView.py", line 420, in _onRunSlicer self._slicer.runSlicer(self._scene) File "/usr/share/cura/Cura/util/sliceEngine.py", line 116, in runSlicer for k, v in self._engineSettings(extruderCount).iteritems(): File "/usr/share/cura/Cura/util/sliceEngine.py", line 259, in _engineSettings 'startCode': profile.getAlterationFileContents('start.gcode', extruderCount), File "/usr/share/cura/Cura/util/profile.py", line 797, in getAlterationFileContents return unicode(prefix + re.sub("(.)\{([^\}]*)\}", replaceTagMatch, alterationContents).rstrip() + '\n' + postfix).strip().encode('utf-8') + '\n' File "/usr/lib/python2.7/re.py", line 151, in sub return _compile(pattern, flags).sub(repl, string, count) File "/usr/share/cura/Cura/util/profile.py", line 685, in replaceTagMatch return pre + time.strftime('%a').encode('utf-8', 'replace') UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128) I'm not a python guy and I don't know how to fix this, but the problem is as described above. On a related note, I really must say I appreciate the new slicing engine. The only question I have so far is if Cura isn't a little to eager to slice the models. I know you don't like unnecessary stages in the printing process but I find the ever appearing slice process indicator a little annoying. The fact that Cura is eager to slice resulted in quite a few error reports as well. best regards, Johan K

Really, If the ultimaker is still BYOB then why have they dropped the "beta" classification? My Ultimaker is a great machine and I don't use a UC. I would also be able to find a bad soldering point on my board and fix it. However, this is not something that can be expected of every user. The specification on the shop page for the kit (kit!, not even assembled machine) clearly states "Soldering skills are not required", which I would rate a much lower on a difficulty scale than troubleshoot pre-soldered electronics. I think the Ultimaker should still be classified as "beta" or similar as it still is a BYOB machine. And I don't think users shold be blamed for not properly functioning electronics. It's one thing to test a board for DC connectivity before shipping and another thing to claim all electronics is functioning properly on delivery. I have searched for some proper documentation for the ulticontroller but didn't find any (strange being a OHW company?). From the pictures on the assembly page it seems the support for the UC board is pretty sparse allowing the board to bend, e.g. when pushing the knob. This is not something a PCB is fond of ( no, I don't really think the PCB has any feelings ) and this could be a possible cause of errors. If the position of ultimaker is as described in this thread I find that deeply troublesome. regards, Johan

Här är en till iaf. Johan

Hi, It sounds as though you're trying to push a really large amount of plastic through the hotend (? 70mm/s * 0.3 mm * 0.6mm ?). Is the hotend really able to keep the temerature up? Perhaps someone with some experience simulating heat flow could give an answer, but the measured temperature is of the heating block, not the plastic.

Daid, A little off topic but, I have wondered for some time now, how do you play Carcassonne using these tiles? When I've played you pick tiles facing down to get a random tile, doesen't seem to work with 3D-tiles.. Oh well they are nice anyway Johan