QCAD.org Forum

Discussion forum for contributors and developers who are using the QCAD ECMAScript development platform or the C++ plugin interface or who are otherwise looking to contribute to QCAD (translations, documentation, etc).

Is it possible to call an external c library from within the EMCA script environment? Or are scripts executed in a "sandbox" that not allow that, and would I instead have to modify C++ source (getting the applicable license of course) accomplish that kind of functionality?

Typically, you would implement your C / C++ functions and classes in the plugin and expose a part of that functionality to ECMAScript.

The C++ classes are compiled into a library, together with a C++ class that implements the plugin interface (RPluginInterface). The compiled library is placed into the 'plugins' folder of the QCAD installation. Plugins are found and loaded automatically. A list of all loaded plugins can be found in the about dialog, plugins tab.

For your use case, you might have a C++ class UsbUploader with a function uploadFile(const QString& fileName).
After making that class and function scriptable, you can create an ECMAScript that calls the C++ member function as follows:

Please keep in mind that all this information relates to the latest code available in the Git repository. Nothing is cast in stone, but the classes directly involved in custom plugins (RPluginInterface and RPluginInfo) are unlikely to change significantly at this point. A QCAD 3.1 Beta release is scheduled to be released in the coming days.

EDIT3: OK, I get the plugin to work when I use the source tree. So obviously the issues are with configuring for deployment (OS X typical) and/or differences to 3.0.9. I will continue to develop in the GIT tree in the hopes that the plugin will eventually wrk in the public version.

I've just uploaded QCAD 3.1 Beta which has support for these types of C++ plugins.

A new version of the CAM add-on for QCAD is now also available as a first beta version. Although it does not compute tool radius compensation, it might still be interesting to try it out. Please refer to this thread for details:viewtopic.php?f=17&t=2078&p=7850#p7850

Thanks. With all the code available, I had a fair chance of digging up things that work.

I currently have a binary plugin that talks USB (libusb is very nice!) and makes a QObject available named RLaser. I can then call RLaser.move Home(), etc. from any script file. I also added a dockable box for basic Laser Cutter control (see snapshot, to be expanded).

With the CAM output dialog, there is room for improvement.

I think that the layers should not be in a pulldown menu, but instead all layers should be visible in a scrollable multi-column view. It should be possible to sort the layers, so text marking comes before cutting, for example.

There should be one check box per layer (second column) to switch CAM export off for that layer alone. The following columns can then be managed by the CAM plugin (for the laser, that would be a pulldown (cut/engrave), power and speed (or even better, a pulldown with presets)). The settings would be saved with the layer in the .dxf file.

Also, from within the plugin, I would like to be able to send the data directly to the laser instead of saving them in a file.

The two panels at the right side of the CAM export dialog ("Global options" and "Layer options") are very flexible and configurable.

For example, the configuration "GCode" is based on the file "scripts/Cam/CamConfigurations/GCode.js".
In the constructor, this exporter defines the files "GCode.ui" and "GCodeLayer.ui" to be the global and layer specific option panels to be shown for that configuration. Your own configuration can for example inherit GCode but use different global options and layer specific options. You can use "Qt Designer" to design such individual option panels (.ui files). Object names that are used for the widgets in the .ui file are directly mapped to document variables and layer properties.

Example:
We want to create a new configuration called "MyLaser", based on "GCode". But instead of GCode.ui and GCodeLayer.ui, we want to use our own .ui files:

Document variables and layer properties can be saved to the DXF file if XData is enabled. Since XData support is considered experimental, you will have to enable it on the command line when starting QCAD:

That's probably a lot of information to digest. The reason for this relatively complex design is flexibility. The information that has to be collected from the user greatly depends on the configuration and the target machine. Configurations might use lists, tables, combo boxes, check boxes, line edits or even multiline text fields. This is somewhat unpredictable at this point, but I didn't want to impose any unnecessary limits for the user interface. Users are usually more creative than expected at first If someone only engraves text for example, an exporter might only ask for a line of text and a font and not even require any CAD input.