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!

That looks interesting. I'll check it out. Thank you!

Well, it's not the answer I was hoping for, but you saved me a lot of fruitless searching. Thank you!

Is it possible for a plugin to communicate directly with a connected printer without worrying about the underlying communication method? By this, I mean send gcode directly and read the printer's response whether the printer is connected directly using USB or through something like Octoprint? I'm combing through the source code but am having trouble figuring out how to do this. I've found UM's OutputDevice, for instance, which provides a "requestWrite" function, that looks promising, but doesn't give me much hope to be able to read the printer's response. Is there a plugin that already does this sort of thing I could look at? Cheers and thanks!

I believe you can query all those settings from the Global Container Stack. Here's some code I've used to get the layer height setting: from UM.Application import Application ... layerHeight = Application.getInstance().getGlobalContainerStack().getProperty("layer_height", "value") It looks like "line_width" and "machine_nozzle_size"should also be an available settings. I'm not sure where to find a definite listing of the setting names, but I was able to find these by looking through this file here: https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json But, that was just sort of a wag. Good luck!

I was hoping to get some feedback first, but that may be the best first step. Thank you!

Hi, everybody! After quite a lot of struggle, learning, and some very valuable help from this forum, I've written the initial version of a plugin to automate the creation of calibration towers in Cura (temperature towers, retraction towers, and fan towers). This plugin takes 5axes' excellent "calibration shapes" plugin to the next level by automating nearly the entire process of creating a calibration tower, including adding post-processing. Creating a temperature tower for PLA, for instance, is as easy as selecting the "Temp Tower (PLA)" item from the "Auto Towers" menu, slicing, and printing. I've done fairly extensive testing on my Linux machine and some very limited testing on a Windows machine, but I would love some feedback before I introduce it to the marketplace. If anyone would like to try it out and let me know how it works for you, the plugin is hosted on GitHub here: https://github.com/kartchnb/AutoTowersPlugin. Any feedback is welcome - advice for improvements, especially so. I'm still fairly new at GitHub (and Cura plugins), but I believe you should be able to install this by downloading the latest release from here: https://github.com/kartchnb/AutoTowersPlugin/releases and saving it in your Cura plugin directory in an "AutoTowersPlugin' folder. Although it works for me, there is no guarantee it will work for you and not blow up your printer. Sorry if it does, but you've been warned.

Thank you! I sort of found the right callback, but had to do some work-arounds because I didn't know about the need to connect to the globalContainerChanged callback. Thank you for taking the time to explain that. This is exactly what I needed.

Hi, everybody! I'm working on a Cura plugin that needs to be able to detect when a change has been made to the print settings (in particular, Layer Height). I've looked around and can't seem to find the event to attach to. Does anyone know off-hand how I could do this?

*Sigh* Never mind. It looks like my problem was not inheriting from QObject. I Changed the class definition to this: class TempTower(QObject, Extension): And it seems to work now.

I'm trying to develop a Cura extension, while, at the same time, figuring out Qt. Unfortunately, I'm struggling with something that seems like it should be very basic and can't figure out where I'm going wrong. Essentially, I want to display a dialog and call a Python function when the dialog is accepted. My understanding is that, by decorating a function with the @pyqtSlot decorator, it should be callable from my QML. However, attempting to do this results in a complaint that my decorated Python function "is not a function". What I'm doing seems to match what I've seen in other plugins and online, but it's just not working. Here's the Python code that's not working: import os.path from PyQt5.QtCore import QObject, pyqtSlot from UM.Application import Application from UM.Extension import Extension from UM.Logger import Logger from UM.PluginRegistry import PluginRegistry class TempTower(Extension): def __init__(self): super().__init__() # Add menu items for this plugin self.setMenuName("TempTower") self.addMenuItem("Generate a Temp Tower", self._showTempTowerDialog) # The dialog is generated the first time it's needed self._settingsDialog = None ## Creates a modal dialogue with information about the selection. def _createDialogue(self, filename): qml_file_path = os.path.join(PluginRegistry.getInstance().getPluginPath(self.getPluginId()), filename) component = Application.getInstance().createQmlComponent(qml_file_path, {"manager": self}) return component def _showTempTowerDialog(self): if self._settingsDialog is None: self._settingsDialog = self._createDialogue("test.qml") self._settingsDialog.show() Logger.log('d', 'Dialog dismissed') @pyqtSlot() def tempTowerDialogAccepted(self): Logger.log('d', 'Dialog was accepted') And the corresponding QML file: import QtQuick 2.3 import QtQuick.Controls 1.2 import QtQuick.Layouts 1.1 import UM 1.1 as UM UM.Dialog { id: dialog rightButtons: Button { text: "Generate" onClicked: { manager.tempTowerDialogAccepted() dialog.accept() } } } When I click the "Generate" button in the QML dialog, Cura displays the following error (snipped somewhat for clarity): file:/TempTower/test.qml:23: TypeError: Property 'tempTowerDialogAccepted' of object QVariant(PyQt_PyObject, ) is not a function Can anyone give me a hint as to what I'm doing wrong here? It's embarrassing, but I simply cannot figure this out.