Stringman

Thanks for the detailed scenario! That is consistent with what I saw (and with the fact that it was my oldest SD card, which I will now toss.)

Welp, re-slicing (with all the same settings) seems to have fixed this, so I speculate that maybe data corruption in the process of writing or reading the print to/from the SD card, or a damaged SD card (it's been heavily used) maybe made the UM "think" it saw a gcode to retract/unload the filament completely. I wouldn't have thought such a code could be a thing but that was before a quick web search turned up several results similar to this: https://www.bondtech.se/2018/05/03/load-unload-script/

This is a strange one, never seen this in years of using a couple of Ultimaker 2 + extended systems. (firmware ver 2.6.2ex). About an hour and a couple if millimeters in height into a print, I checked the progress and realized that while the head was still darting around, all the filament had unloaded from the head and the bowden tube. It was as the result you'd get if you paused it to change filament - all the filament reversed out of the extrusion path - BUT THE PRINT WAS STILL EXECUTING. The filament had not broken and the end was rounded like it had been pulled out while hot. Well, huh. Fortunately not that far into the print, so clean the plate, start it over. ..... And it happened AGAIN. Was printing great, about 2mm in height on the model, extruding fine. Go away, come back in a few minutes and again, it had retracted and dumped all the filament out of the tube, but was still cheerfully pretending it was printing. I'm going to try it again, but first I'm going to re-slice the model. I mean, I don't know of anything that you can put into gcode that tells the printer to dump the filament, but it seems to have happened at the same point in the print, maybe there was some data error somehow. Anybody else ever seen that happen?

JUST TOO SLOW: adding my 2 cents on Cura 3.5 for the Mac. I'm running High Sierra on a dual-core iMac late 2009 machine with 12 Gb RAM and solid state drive: not seeing the errors people describe here BUT it is far, far too slow for any practical use. Rendering, panning, zooming, all take PHENOMENALLY long times to execute. And this appears to be platform specific. I have a tiny Lenovo "windows chromebook" - Chromebook-class hardware, Windows 10 - with a 1.6 Celeron, just 4 Gb RAM, so very low powered, bought it for portability in connecting to research gear. Running Cura 3.4.1 on it, panning/zooming/rendering/slicings is easily twice as fast as my iMac running 3.4.1. (I've reverted on the Mac to 3.4.1 - it's slow, but still usable. 3.5 crosses the line to where I can't actually get our work done due to the speed issue.

I wanted to pass along how our shop approaches buildplate adhesion with our four Ultimakers, after having used a lot of different methods. First off, I roughen our glass plates. I was told to sand them, but I have access to a sandblaster down the hall. I go REAL EASY on this: a few fast passes with the sandblaster nozzle, turn plate 90 degrees, repeat, rotate 45 degrees, repeat, rotate 90 degrees, once more. I'm not trying to get every last bit of smooth glass worn away, I want to just barely frost or roughen it, evenly. Sanding would probably give you better control. Dust/rinse all the dust off the plate. To prepare for printing, I get the plate wet, tip it for a couple seconds to let most of the water run off, then lay it flat. I grab my big bottle of white casein glue (Elmer's or similar) and dump a dollop about an inch across in the middle of the plate. Now I smear it over the entire plate with my fingers, mixing it with the water that's still on there, smoothing out any concentrations but not obsessing over getting it absolutely maniacally uniform. Set it aside and let it dry, which doesn't take long at all if you put a fan on it, or you put it on the heated buildplate. This seems to give me excellent adhesion with almost any filament - PLA, PETG, nylon, Taulman 910 - those last two can be a real challenge - and yeah, sometimes ABS. Let a print cool completely and usually it releases very nicely (more on that in a moment.) After printing and removing the models, I plop the buildplate in a sink of water to soak for a couple minutes, and then the glue can be scrubbed away easily with a pot scrubber or brush. While the plate is wet and clean, I grab the glue bottle and prep it for the next print. Now, I used to use gluesticks on the rough plate, and that works OK, but it tends to build up if you don't clean it off every time. (I didn't.) I think part of why I'm getting consistent results with the Elmer's-Glue-on-wet-plate approach is because I'm removing the glue down to the bare rough glass after EVERY print. For ABS, early on we caught on to the practice of either 1) dribbling some acetone on the buildplate and rubbing it with an ABS print fragment to create a haze/glaze of ABS plastic, or 2) I prepare some ABS/acetone slurry in advance and store it in old film canisters, ready to spread on the plate when I'm doing ABS. The stuff is messy and you need good ventilation, but it's really the only way I know to be super sure your ABS print doesn't lift. I used to only do this on smooth glass plates, but now I use the sandblasted sides for all prints. Downsides: if you've had to pop a lot of prints off of your borosilicate glass buildplate, you've probably had chips pop out of the surface of the plate before. I think it is possible that sandblasting or sanding may make your plate more prone to spalling/chipping, but then again, I did buy a stack of cheap no-name buildplates from overseas, and I'm beginning to think they aren't actually tempered glass, so maybe that's to blame. And while *usually* the white glue method releases quite easily, a few times it stuck so firmly that when I got my model off, it actually took some of the glass with it. Again, maybe my cheapo glass buildplates, I don't know. Anyway, glue and sandblasting has been giving me really consistent results, such that I sometimes don't bother with printing a brim on models any longer.

Interestingly, additional "sketchiness": sometimes I can get 2.1.2 to run on my Mac, but when I'm viewing in "layers" mode - sometimes I can see all the layers, but other times, when I scroll to some of the bottom layers, the object disappears and straight lines of many colors are drawn all over my screen. Very pretty, but not very useful.

Understandable. I will say that the V.15 Cura's time estimates were usually very close to spot on. It's not usually urgent for me to know much more than "this'll be done yet this morning" or "this one will probably have to run overnight."

Hmm, obviously I'm going to keep researching this and digging through all possible settings, but at the moment, I'm seeing the strange situation where the gcode I'm generating with the new Cura 2.1.2 release takes about 20% longer to print than the gcode generated from the same model using v.15* Yep, there are a LOT of settings that influence print times, and I'm trying to make this "apples-to-apples" by making the settings the same in the two versions: initial layer speed and thickness, all print speeds, travel speeds, density, top/bottom thickness, shell thickness, adhesion type, nozzle size, layer thickness. Still, on the test file I'm looking at, the older version slices it into a 9 hour print while 2.1.2 calls it 11 hours 43 minutes. I *thought* some earlier tests seemed longer. I mean, I get why the actual program takes longer to slice stuff - more options being processed - but for equal speed/density/thickness settings, I can't think why there should be any difference in the print times.

OK, as per suggestions, although the desktop in question appeared to have latest/best drivers, I let AMD's utilities weigh in on that and installed all the drivers and extra widgets their system scanner suggested. That seems to have fixed it on the desktop computer. Probably can't expect to have it run in a 32-bit VM apparently - but the 64 bit version runs OK in a Win 10 VM. Now I just need to figure out what's up with the OS X version (runs, except when it doesn't. That's over in a different thread.)

That's possible, I see in the cura log that things go south right after this point: 2016-06-15 08:40:01,127 - DEBUG - OpenGL Renderer: ATI Radeon HD 2400 Pro 2016-06-15 08:40:09,153 - WARNING - No active machine found when trying to save setting visibility But I also note that the 32bit build crashed on a notebook computer as well, and that the desktop system has no issues running graphics-intensive apps like scanners, Altium circuit design software, webcam streamers, etc. often all at the same time. I'll go take a look and see if I've got the best possible drivers. Oh, and I also installed it in a Windows virtual machine, and got the same failure. Installed the 64 bit version in a 64 bit virtual Windows machine, and it ran OK. Three out of three failures on very different hardware (fast desktop, virtual machine, slow older notebook) seems odd - is there a minimum graphics capability that none of these machines achieves? Although, why would the 64 bit version work in a VM, then?

Parallel to the problem with running Cura 2.1.2 in 32 bit Windows, it *does* run on my Core 2 Duo iMac with 12 Gb RAM . . . sometimes. And then sometimes it gets only as far as "setting up scenes", and then it hangs. This new version of Cura doesn't appear to have a log file in the user app directories like the version 15* instances keep. When I kill the hung application, I can ask for a log of what happened, but it's pretty huge.

That's possible, I see in the cura log that things go south right after this point: 2016-06-15 08:40:01,127 - DEBUG - OpenGL Renderer: ATI Radeon HD 2400 Pro 2016-06-15 08:40:09,153 - WARNING - No active machine found when trying to save setting visibility But I also note that the 32bit build crashed on a notebook computer as well, and that the desktop system has no issues running graphics-intensive apps like scanners, Altium circuit design software, webcam streamers, etc. often all at the same time. I'll go take a look and see if I've got the best possible drivers.

Additional info: I installed the 64-bit Windows Cura 2.1.2 version into a virtual Windows 10 machine and it runs fine. Problem seems to be the 32 bit version.

Cura 2.1.2 for Windows 32-bit crashes for me. On my old Windows 7/32 laptop (not a lot of memory, old/slow) it doesn't even make it to any of the initial screens before I get a crash. Not suprised, so I put it on a newer desktop system that has plenty of oomph and memory (routinely handles some intense multiple applications and monitors), and I get the initial splash screen and dialog asking which Ultimaker I have, but then it crashes, and if I ask Windows for the crash details, it shows me this: Problem signature: Problem Event Name: APPCRASH Application Name: Cura.exe Application Version: 0.0.0.0 Application Timestamp: 54467a51 Fault Module Name: atioglxx.dll Fault Module Version: 6.14.10.11318 Fault Module Timestamp: 4ebb3dc2 Exception Code: c0000005 Exception Offset: 0068f40b OS Version: 6.1.7601.2.1.0.256.4 Locale ID: 1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 I'll go see if any of my virtual Windows machines are 64-bit and see if I the problem is confined to the 32-bit version.

Just a followup . . . . at the end of the day, with excellent e-mail support from fcbrc8 technicians, we found out that yes, the display itself had failed, and they sent me a replacement free under warranty that worked. It is really strange that it died at the exact time I ran the firmware update, but it is what it is. Works fine now with latest firmware (which, yes, is a definite improvement.)

This student model mystifies me. All the struts in this model are supposed to be straight, as viewed in Cura. We printed it in PLA on our Ultimaker 2 in the orientation you see in the photo, with the side that has two beams (fat and thin) across the front of the Ultimaker in the X axis, and the side with the un-bent beam running along the Y axis to the back of the machine. As I watched the print, the unsupported angles did vibrate with the machine and the action of the print head, yet only the skinny angle beam in the X axis turned out curved (it is straight in the model) . . . . and an identically sized and angled strut in the Y axis was straight as an arrow. All corners are exactly where they should be so this mates up fine to the rest of the model they designed, but the selective distortion begs for an explanation. I'm an electronics tech and not a mechanical engineer so I my background is limited, but I'm going to throw out a guess here: the unsupported front edge of the Ultimaker 2 build platform can vibrate up and down. So the entire angle beam in the X axis is able to bounce up and down during the print. By contrast, the beam printing in the Y axis is supported firmly at the back of the machine and only vibrates at one end. WHY that would result in a curve beats me, but it's the only distinction I can see between the two sides. And obviously, as you can see by the fat angle brace in the X axis, parts that are thick enough to not vibrate don't have any problem at all.

Additional note: fooling with the menu dial after this failure, when I spin and push it, I do get the little beeps of various pitches that suggest it thinks I am selecting a menu item, but I have nothing on the display. I have never had an issue with the display before. Another note: I did uninstall Cura 15.04, install Cura 15.02, and do the whole thing over again. Similar results. I can click around on the menu, blindly, and something I selected started the printer moving, so it appears that I just have no display working. I would blame the display except that this happened with the firmware update, so it seems to be cause/effect.

My attempt to upgrade the firmware on our Ultimaker 2 from 15.02 to 15.04 results in an Ultimaker 2 that no longer operates. We just got an additional Ultimaker 2 Extended and I noticed a couple of improvements in its operation so I wanted to bring those changes to the older UM2 we bought at the beginning of the year. What I Did: - Installed the latest download of Cura on a laptop, including the Arduino drivers. TOLD IT I HAVE AN UM2. - connected it to the running UM2 - Windows 7 thinks for a while and succeeds in setting up the USB drivers. Connecting and disconnecting the UM2 gives the appropriate "ka-thunks" in Windows. - Open Cura, choose menu "Machine>Install default firmware ...." - small dialog/progress bar appears, says it is uploading firmware. At the same time, the illumination LEDs on the UM2 and the text display go dark. - Progress bar completes, dialog says that update complete: MarlinUltimaker 2.hex - LEDs come back up, illuminated dial gets brighter, then dims. BUT ...... - NOTHING ON THE TEXT DISPLAY. No menus, nothing happens when operating the dial or pushing it in. - Power cycled, including completely disconnecting power. Can't get an operational startup. - Repeat the firmware installation several times. Always appears to be uploading, always claims success. - Yes, the Cura software says it is set for the UM2. - But my Ultimaker is now not usable. I never get anything on the display. - Thankful that I have the new UM2x to finish pending print jobs, but I NEED THIS MACHINE running too. Note that we are an electronics shop servicing, designing and building engineering research instrumentation, so we can dig into this thing if need be, but it seems to be a software issue. Is there a way to revert? I suppose I should go look for an earlier version of Cura and try to reload from that?