- User Since
- Oct 13 2015, 9:16 AM (126 w, 3 d)
@ruffle : With rCT644f5c3b22bb58bb6f8509014a632269d0b0a5f7 and rCT895f1276c4197d3f37dafc431aa201ff25fe23da the issue should be fixed starting with v3.2.11.
Feel free to reopen if you still have high CPU consumption problem.
Thu, Mar 15
Wed, Mar 14
@ruffle, This is the right place.
Mon, Mar 12
Wed, Mar 7
Tue, Mar 6
@jdSD , This is how Cura is designed to talk to CuraEngine via netsockets (protobuffers) on localhost. I don't think we would want to change it.
Mon, Mar 5
Thu, Mar 1
Tue, Feb 27
@logan, I did add udev rule that is supposed to turn USB power management off too:
Same as T1609?
@logan Hubs are known to cause problems, because they are managing power settings to the device (they can turn it off for example which results in RAMBO reboot)
@logan, sounds like it might be FW related too... In the past USB communication problems were caused by faulty USB cables/faulty RAMBOs/USB power management/Some serial device monitoring programs like ModemManager
@victor_larchenko , Let's leave the guarads there for now. I'd like to exclude any possible way of USB thread crashing. I'll add Warning log message in there, so that it just not silently sets timing to zero.
Mon, Feb 26
@karrad , Make sure you are running only one instance of CuraLE, also seems like you'll need to clear cache.
Fri, Feb 23
@victor_larchenko : Minor but imortant comment. All of these
Thu, Feb 22
@MikeR, I was thinking about it. We can provide any calibration Code from within Cura, instead of via USB, this way we shouldn't worry about how old the g-code on USB is.
@MikeR , g-code that was generated with older cura version (or has old start g-code) would not work with new Marlin FW.
@karrad, Ah nvm it works OK, just forgot to slice the model and by default the printing mode comes up as it's trying to print: With Pause and Abort Print buttons...
@karrad: About Printer status state swap. It wasn't upstream. I just checked it was working on Monday. Most probably something wrong happened
in this commit rCTe31d694c9a0fb2f66f6f9bba152922d3906757f0. Could you please create a new ticket for it, and assign it to @victor_larchenko to check?
Wed, Feb 21
@mcoronado : The color of the model is set to the material color, and I think it should be. Extremely helpful for multiextruder.
@TKostennov , The Connect button should never be disabled for situations like this. This applies to v2.6 also.
@mcoronado, Could you please revisit the colors in https://code.alephobjects.com/source/Cura2/browse/master/resources/themes/lulzbot/theme.json
Mon, Feb 19
@spotrh , thanks for bringing our attention to this. The fix should be in stable_2.6 branch now rCTE82426d69fc545519e328a2159fc67ceba4f7fd41. I tested it a bit and it seems like it's not breaking anything.
@karrad , There are 2 options for this:
Fri, Feb 16
I didn't find any CuraLE problems that might cause the crash in the provided logs.
@OHShiks , This crash seems like a problem with your graphics drivers:
@victor_larchenko , could we please sync all of the materials from fdm_materials repo to 3.2 CuraLE?