joatrash

Haha, well looking at the screenshot... the red line seems to indicate a moment of 9000mm per minute! But I did more digging. It looks like the problem might be hardware-related on my end. I suspect a faulty SD-card reader. (Or if it's not, then Windows is indexing the SD card even though it's not supposed to be.) Looks like errors start showing up in files when the SD card is removed. Information in the files goes missing, like here: Broken copy on the left, error-free copy on the right. Apologies for thinking it was a Tinker issue. ONE puzzling thing though... the UM firmware seems to IGNORE the error and carry on, but Tinker stops. is there an extra-sensitive error-check in there?

OK... more testing. Look at this: I imported the gcode files into Simplify3d just to look at them. It looks like Cura has inserted random super-fast print head movements because the red lines are exactly where the print failed. UMs original firmware seems to be able to handle the files anyway, but Tinker stops printing when it reaches those lines every time. Any thoughts as to what could be going on?

Ok... I've spent a couple days experimenting now and there's something going on with Tinker on a specific 3d model I am trying to print. If I go back to the original (latest) UM2+ firmware it prints fine. I now tried slicing with cura 2.5, 4.1 and 4.7 and the results are similar- the print just stops after a while as if it were finished. The same model, sliced waaaaaaay back with an early cura (2.1 I think) still prints. The weird thing is that I went back and redid the model with different topology, made it 100% error free, manifold and watertight but the result is the same. If IS a rather detailed model though, at around 50MB. Unfortunately, I can't share this particular model, since it's a confidential file, but I'll try a different model (that I CAN share) and see if I get errors on that too.

Is anyone having troubles with this firmware and Cura 4.7? All of a sudden, files I'm slicing will stop printing after a couple hours as if they are finished. Had two cut out after around 2 hours and one just now after about 8 hours. No error message... the print just stops and it says "print completed" on the screen. I've verified that the gcode file is not truncted and the SD card has no errors. I can still print old gcodes just fine.

I don't know if this is what was meant, but every time a print is completed, the printer has to be powered off, then on again before a new print is started. If not, when you start a new print, as the printer runs thought the prep-cycle where it "resets" the print head location and raises the bed, the print head stop switch does not register when the head reaches the back, and the motor keeps going, making the belt "jump" over gears and the entire machine shakes until you turn it off. (I personally don't have a film clip of it and I'm a little hesitant to make one for fear of causing any damage. I've just learned to power the thing off between prints... most of the time!)

The same thing happened to me once with TW. Luckily, I was nearby and could stop it.

I haven't really studied all the settings, but I know that in the material settings menu, there are 4-5 different temps to set. Maybe it thinks you are printing ABS or something?

Tinker has settings for different nozzles and things that are automatically detected through info in the gcode file. Go into the materials settings and make sure the temp is set to 210 on the material+nozzle you are using. (If it's an old gcode file, the default nozzle is automatically set to 0.4 for heat purposes)

So material flow is controlled by the slicer calculations? (I mean, it needs to move more material with a 0.6 than with 0.4 nozzle.)

Yes, it seems that the line is missing from Cura_steamengine 13.12. I'll add the line when I get a chance and see. (I usually name my files accordingly... was mainly worried about the print.) But I'm guessing the information for printing with the nozzle must be contained somewhere, or I'd have had a lot of underextrusion this last year since switching to the Olsson block! (I got an OB long before doing the full UM2+ upgrade.) So far the print seems to be working fine. Thanks for the response! : ) I assume that the old versions of CuraEngine do not provide any information about the nozzle size in the header of the gcode file. The UM2+ firmware will use the material temperature for the 0.4mm nozzle as a default in those cases. This is what it looks like with the current version of Cura. If in doubt you can add the missing line and see, if it makes a difference. ; ;FLAVOR:UltiGCode ;TIME:4875 ;MATERIAL:5528 ;MATERIAL2:0 ;NOZZLE_DIAMETER:0.4 ;Generated with Cura_SteamEngine 3.0.3

Hello all! So, after upgrading my UM2 to a PLUS, I needed to try this out since I wanted to keep using PID bed heating since my prints were horrible as soon as I went past Cura 14.05. However, it seems to be misreporting which nozzle my gcode files are set for. (Didn't find anything about this upon a search, unless I completely missed it?) Files that were exported (from Cura 14.01 or .05... OLD I know... but it has always worked) with a 0.6 nozzle setting show "nozzle 0.4" in the Tinker display. Is this just a display bug? I'm going to run a print now ans see what happens. Cheers! //Joe

I've been getting a lot of horizontal banding lately as well and I can't find the cause. It's driving me crazy. It MUST be hardware related because I'm using the same gcodes and firmware as I always have and i was getting perfect prints before. At this time I've checked just about everything I can check, from what I reckon. My last remaining things are: Faulty feeder giving uneven amounts of plastic Worn nozzle (doesn't really look worn though) Loose belts (hard to know how tight is enough... I can move them easily up and down but they're not "floppy". Tried attaching a belt tightener but the belts are too tight to get it on there so I might have to make a custom one.) Z-motor or axis problem. I DO hear an unveven "grinding sound" when I manually press the build plate DOWN.. sounds a little like in the video you linked above... like there is sand in the mechanism. But I don't really hear any grinding when I LIFT the bed manually... only when I push it down. I wonder... when I first got my UM2, the threaded Z-axis nut was faulty, causing the bed to drop several mm in intervals. This also placed a bit of sideways pressure on the z-screw. Maybe that extra pressure has caused the motor to break down prematurely?

OK, can you tell me what file(s) besides "curaengine.exe" that needs access? Can't seem to find the right one in my block list... Thanks!

Aha... that may be it then. I routinely block program access to the internet, sometimes without even thinking about it. The only things I allow access to are things that actually MUST have access (like browsers). Why would Cura need firewall access just to calculate g-code?

Also, I don't know if this is relevant or not, but if I load Gcode generated by 14.01 it doesn't display properly...