Cura2 LulzBot Edition Beta Testers Needed!

Control of heats for Extruder #2 in dual extrusion is completely whacked.

I did not notice yesterday when printing two materials that had the same heat profile.

Extruder #1 seems to work and switch properly between standby temps and printing temps.

Extruder #2.

  1. When Extruder #1 is finishing the printing temp is correctly set to start warming up
  2. As soon as it gets to within 10 degrees of setpoint(225 in my case) the setpoint drops to 200 degrees and starts to print the first layer.
  3. Interesting that 200 degrees is not ANY temperature in EITHER profile for Extruder #2 or Extruder #1.
  4. I manually set the temp back to complete the first layer.
  5. When it comes time to print the second layer it again drops to 200–sometimes it does and sometimes it doesn’t.

I’m printing off SD card.

Well I tried the latest and greatest, and went back to 21.08? Tried to print a replacement ABS part and the extruder cooled to 200C on the second layer and on the 3/4 layer turned off the heat bed. Needless to say a few layers later the print popped off the bed. :laughing:

That doesn’t seem to be it. The temperature stayed consistent while printing…

pi@octopi:~/.octoprint/uploads $ grep ‘M1[49]0’ LM_Auger.gcode
M140 S85 ; start bed heating up
M190 S85 ; wait for bed to reach printing temp
M140 S85
M140 S50 ; start bed cooling
M190 R50 ; wait for bed to cool down to removal temp
M140 S50; keep temperature or cool down

Although wait a minute… 85? It’s 110 in the old version of Cura. This may be a raging clue.

Not only that, but the print temperature is 200 instead of 240. That seems way too low for HIPS and doesn’t seem healthy. I’m going to try with proper temperatures and see what happens.

So when I set the “build plate temperature” to 110, the part no longer pops off, which is great. The print temperature was tricky: apparently there’s a default value for “Flow Temperature Graph” of “[[3.5,200],[7.0,240]]”, which overrides the other temperature settings. I can’t find any real documentation for this, and it’s not clear that Lulzbot intends for this setting to take effect, so instead I just deleted the value and it seems to go back to using the statically configured temperatures. I’m out of time for today but I’ll use this for my next print.

This is great feedback, thanks!

I tried to use the beta but I get no material selection nor can I create a new material. I searched the forum and I don’t see this issue mentioned, so I’m thinking I’m just not doing something right.

In the drop-down box bambooFill(colorFabb) is listed but cannot be changed.

Using beta 2.6.45
Windows 10 64 bit

Any help would be appreciated.

Thanks,
Steve

Version number on the windows desktop icon doesnt change when you upgrade to new versions.

Hello,

What are the plans to compile this for 64bit?

dh

In version 2.6.43 it´s not possible to create or duplicate a material, nothing happens.
Dual extrussion is useless until we can manage materials with specific configuration (temperature, density, etc).

EDIT: I found a temporary fix to create materials. You must export an existing one, make a copy of that .XML file, edit it with different values (also change the GUID parameter to random values with same string format). Then, if you import the material it will appear on the list and you can use it.

material_bed_temperature is still set to 85 in quality/lulzbot_mini/HIPS_(Village_Plastics)_*.cfg in 2.6.43. I’m still overriding this setting to 110 in order to prevent failed prints, as well as removing the “Flow Temperature Graph” setting. I think Lulzbot have moved away from HIPS, but it’s still the material of choice for our makerspace so it would be great to see this profile work correctly out of the box.

I’m disappointed to see that the version was released with this simple mistake in the config, reported months ago, still present. This will prevent anyone from successfully printing with HIPS unless they know which settings to override. :frowning:

We specifically lowered the bed temp to 85c to prevent the yellowing of the base layer on longer prints. Through our testing we have found a glue stick on PEI at 85c does a great job! You can find details on this post: https://forum.lulzbot.com/t/hips-profiles-in-lulzbot-cura-2-6-52/5356/1

Cura 3.2.8

After putting in the API key for Octoprint, then -
Try to uncheck “the start as soon as uploaded” for Octoprint, Cura program crashes.

3.2.9

After putting in the API key for Octoprint, then -
Try to uncheck “the start as soon as uploaded” for Octoprint, Cura program crashes.

We’re sorry to hear about the issues. The Cura LE 3.2.x branch is in early alpha at the moment, and every report helps us get this program in a better position. If you can pull an error log from the crash, it will greatly help us track it down. We are currently logging 3.2.x critical failures here: https://code.alephobjects.com/T1273

In windows it will be:

\Users<username>\AppData\Local\cura-lulzbot\2.6\cura-lulzbot.log

or \Users<username>\AppData\Roaming\cura-lulzbot\2.6\cura-lulzbot.log

Linux: /home//.local/share/cura-lulzbot/2.6/cura-lulzbot.log

Mac: /Users//Library/Application Support/cura-lulzbot/2.6/cura-lulzbot.log

We appreciate the help!

3.2.14

After putting in the API key for Octoprint, then -
Try to uncheck “the start as soon as uploaded” for Octoprint, Cura program crashes.

\Users<username>\AppData\Local\cura-lulzbot\2.6\cura-lulzbot.log

or \Users<username>\AppData\Roaming\cura-lulzbot\2.6\cura-lulzbot.log

Linux: /home//.local/share/cura-lulzbot/2.6/cura-lulzbot.log

Mac: /Users//Library/Application Support/cura-lulzbot/2.6/cura-lulzbot.log

log was not where u said, i found it here:
Users//AppData/Roaming/cura-lulzbot/3.2

2018-03-24 19:06:07,475 - CRITICAL - [(31964)-MainThread] cura.CrashHandler.init [61]: An uncaught error has occurred!
2018-03-24 19:06:07,476 - CRITICAL - [(31964)-MainThread] cura.CrashHandler.init [64]: Traceback (most recent call last):
2018-03-24 19:06:07,477 - CRITICAL - [(31964)-MainThread] cura.CrashHandler.init [64]: File “d:\Program Files (x86)\cura-lulzbot 3.2\plugins\OctoPrintPlugin\DiscoverOctoPrintAction.py”, line 202, in setContainerMetaDataEntry
2018-03-24 19:06:07,478 - CRITICAL - [(31964)-MainThread] cura.CrashHandler.init [64]: containers = ContainerRegistry.getInstance().findContainers(None, id = container_id)
2018-03-24 19:06:07,479 - CRITICAL - [(31964)-MainThread] cura.CrashHandler.init [64]: TypeError: findContainers() takes 1 positional argument but 2 were given

my log attached
cura-lulzbot.log (322 KB)

3.2.16

After putting in the API key for Octoprint, then -
Try to uncheck “the start as soon as uploaded” for Octoprint, Cura program crashes.

Well i’ve tried it and to be very blunt it sucks. I realize it probably has a lot of improvements to features like probably honeycomb infill pattern or stuff like that but the old cura version was MUCH better. Was easier on the eyes, and used less resources on the computer itself thereby not slowing down old computers who lacked memory or speed.

Go back to the old light version of cura! Or create a new light version of cura for those of us who hate the new one. You don’t need to copy everything ultimaker does in terms of software.