bradk3

And, of course, after asking the question, I found the answer. For the benefit of future me, as well as others looking to do the same thing, you can, indeed, retrieve this for the active extruder stack. For example: # Get the active extruder stack extruder = ExtruderManager.getInstance().getActiveExtruderStack() # Get the material for the active extruder stack material = extruder.material # You can retrieve the brand, material, and brand from the material metadata metadata = material.getMetaData() brand = metadata.get('brand', '') material = metadata.get('material', '') color = metadata.get('color_name', '')

How can my plugin get information about the currently-selected material? For example, I would like to retrieve the brand, material type, and color. I'm guessing that I should be able to find it through the active extruder stack, but my understanding of the stacks is embarrassingly limited.

I'm sorry to hear you're having trouble. For some reason, getting this plugin to talk to OpenSCAD has been a huge challenge that I haven't been able to fix yet. Would you be able to post your cura.log file? That may help to figure out the problem.

@Jmacwill, thank you for the kind words! Again, I'm very glad that what started out largely as a way for me to procrastinate homework is useful for other people! Getting my plugin to find the openscad executable has been far trickier than I expected. I'm not sure why it's failing in your case, though. With openscad installed in /usr/bin, it should be in the path and the plugin should be able to find it by default. Can I ask a couple of questions? What version of openscad do you have? I believe only the newest, 2021, version will work. If you have the 2019 version installed, it is not supported. Can you run openscad from a terminal window by just typing 'openscad'? Honestly, this really shouldn't matter since you've already tried specifying the full path to it, but I'm interested in understanding this better. I don't think my plugin provides any helpful error messages when trying to find openscad. I'll see if I can change that. In the meantime, I'll do some investigating on my own to see if I can figure out what's going wrong. Thank you for letting me know!

I, clearly, need to check in here more often. Thank you for the write-up, @Torgeir! That's incredibly kind and useful of you. I'm very glad people are finding this plugin helpful! I'm also relieved that it's still working with Cura 4.13.1, since I haven't had a chance to test it for a while. Thank you for the kind words and the help you've given me in the past!

Fantastic! I'm not sure how I missed that in my searching through the source code, but I did. Thank you for the information. That was exactly what I needed.

I would like my plugin to be able to detect when a model is added to or removed to the build platform in Cura. It seems like it should be simple, but I'm clearly not smart enough. The approach I've tried is to connect to the CuraApplication sceneChanged event and watch for changes involving CuraSceneNodes. This works, in that, I can detect when a model is added or removed from the scene, but it also fires when a model is translated or resized, which I do not want. I can't seem to find more information about the scene change, but I may just be clueless. The CuraSceneNode object that is passed to the callback doesn't appear to have any relevant information, nor does the SceneNode object it inherits from. If anyone has any hints, I would appreciate it very much.

Great question! The flow tower changes the amount of filament extruded through the nozzle and should be the same as adjusting Cura's "Flow" setting. So, for example, a flow rate of 50% will result in your printer laying down half the filament as it normally would. I hope that makes sense. Thank you for asking! I'm very glad it's working for you!

Yeah, okay. Thanks for watching me talk to myself. It looks like the problem is that the Cura AppImage sets LD_LIBRARY_PATH to point to its own library directory. Simply 'unset'ing LD_LIBRARY_PATH before executing OpenScad solves the issue for me. Nothing to see here. Move along.

And, of course, after posting this, I just discovered that manually correcting LD_LIBRARY_PATH before executing OpenScad seems to allow the program to run normally. Solved, maybe?

I have a rather involved problem that is entirely beyond my skill to figure out. I'm hoping that *someone* here can help. I'll try to lay out the problem as clearly as possible. I'm developing a plugin that relies on being able to launch OpenScad to automatically generate an STL file. This worked fine for me in Cura 4.13.1, but not now with Cura 5.1. I use Linux (Xubuntu), where Cura is only available as an AppImage. I suspect this is the source of the problem, although I'm not positive. OpenScad runs just fine when I launch it from a normal terminal. My plugin runs OpenScad using the processing.run() function. Under Cura 4.13.1, OpenScad runs fine and generates STLs. Under Cura 5.1, OpenScad fails with messages (see below) that suggest to me that it can't find the correct version of Qt it needs to run. OpenScad seems to use Qt 5, while Cura 5.1 now uses Qt 6. I would hope that, by launching OpenScad as a separate process, there wouldn't be any dependencies between it and Cura, but I'm guessing that OpenScad is stuck running within Cura's AppImage environment. I've created a test plugin that does nothing other than attempt to launch OpenScad, so that I can rule out everything else. The plugin simply creates a menu item that allows me to launch OpenScad and report any error messages. Here's the command I'm using: errorMessage = subprocess.run('openscad', capture_output=True, text=True, shell=False).stderr.strip() and here are the error messages that result: openscad: /tmp/.mount_curaUfAqOM/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libboost_program_options.so.1.74.0) openscad: /tmp/.mount_curaUfAqOM/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libboost_regex.so.1.74.0) openscad: /tmp/.mount_curaUfAqOM/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/libqscintilla2_qt5.so.15) openscad: /tmp/.mount_curaUfAqOM/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libQt5Widgets.so.5) openscad: /tmp/.mount_curaUfAqOM/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libQt5Network.so.5) openscad: /tmp/.mount_curaUfAqOM/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libQt5Core.so.5) openscad: /tmp/.mount_curaUfAqOM/libstdc++.so.6: version `CXXABI_1.3.13' not found (required by /lib/x86_64-linux-gnu/libQt5Core.so.5) Again, it appears that OpenScad is being launched inside the Cura AppImage sandbox and that's the source of the problem - since the AppImage environment doesn't have the correct Qt (and other) libraries, OpenScad fails. Any idea if it's possible to launch OpenScad outside of the AppImage sandbox so that it can run normally? Alternatively, is it possible for my plugin to include the needed libraries for Linux? Again, this is a complicated problem. Not sure if that entirely makes sense or if anyone can help.

I really appreciate you taking the time to try this out. I knew Windows was going to be trouble. If you get a moment, and don't mind, it would help if you could send me your cura.log file, so I can see what's causing my plugin not to load. Regardless, I'll see what I can figure out.

Thanks for the note! It sounds like I still have some issues to work out (at least on Windows), but I'll be sure to follow up with my progress.

Have you started by printing a temperature tower and retraction towers (distance and speed)? That would be a good first step. I've recently played with settings for PETG in Cura and have it dialed in pretty well for my Anycubic I3 Mega (with a Bowden extruder). I can't remember everything I tried, but I'll go through the settings I can remember. Your mileage will almost certainly vary. Finding the right temperature and retraction settings helped. Printing Temperature: 250 C Retraction Distance: 6.0 mm Retraction Speed: 40 mm/s Speed seemed to play a part in it for me - specifically, printing slowly. It's agonizing, but it works. Print Speed: 40 mm/s Outer Wall Speed: 30 mm/s Playing around with combing also seemed to help. Specifically, the following settings: Combing Mode: "Within Infill" Max Comb Distance Without Retract: 8.0 mm I hope some of that helps.

First, thank you for taking the time to try this. I was afraid something like this would happen. I'm going to get access to a Windows machine and do some more testing and get back with you to sort this out. Cheers!