Currently all machine definitions are JSON files in Cura 2.1.x itself.
(On MacOS this makes them part of the .app package)
Feature Request:
I propose locations:
Cura already supports loading from the local user storage directories:
On linux, you can put them into ~/.local/share/cura/machines for 2.1 or ~/.local/share/cura/definitions for 2.2
On OS X, you can put them into ~/.cura/machines for 2.1 or ~/Library/Application Support/cura/definitions
On Windows, you can put them into ~/AppData/Local/cura/machines for 2.1 or ~/AppData/Local/cura/definitions for 2.2
But this isn't well documented or clear. We should perhaps always create the folders, even though nothing is found. That would make it a bit more clear.
I think ~/.cura/machines already exists and contains the .cfg files.
I'll try putting .json machine definitions there too. Thanks!
Please mention these 3 locations in
https://ultimaker.com/en/resources/20511-change-machine-settings
too
https://ultimaker.com/en/community/20538-cura-21-open-beta-has-been-released?page=10&sort=#reply-150501
those seeds to be a bug when stories json files there.
open a separate rocket for this?
s/rocket /ticket
damn keyboard an no edit button in phone view.
@nallath For users like @MarcusWolschon it would be more useful to log this instead of doing mess I think.
Something like:
<> Looking for user definitions..
<> Couldn't find directory ~/.local/share/cura/definitions
Or for the case an user just wants to override definitions.
<> Looking for user definitions..
<> Using for the current printer local definiton ~/.local/share/cura/definitions/XY instead!
Yeah, good point.
@awhiemstra
On linux, you can put them into ~/.local/share/cura/machines for 2.1 or ~/.local/share/cura/definitions for 2.2
Is this still true for __Cura-2.4.0-BETA.AppImage__?
sudo strace -f ./Cura-2.4.0-BETA.AppImage 2>&1 | grep definitions | grep "/home/" | cut -d '"' -f 2
shows no signs of trying to load definitions from ~/.local/share/cura/definitions
. It is accessing ~/.cache/cura/definitions/2.4.0-BETA/
though, but the files there are not json files.
We create "pickled" files of the definitions. It should try and read all the json files and then create caches, but it seems that isn't working correctly.
+1 for this on the documentation side. Is this still valid for cura 2.4 ?
Can we add materials, meshes and quality profiles in the same manner ?
Figured out what was going wrong. We never tried to read from the definitions or other directories since they are not considered "writable" and thus were never added to the list of locations to consider when loading. That is now fixed.
@arthurlutz Materials and qualities were already handled properly, but now everything else that is considered a "resource" will also be loaded from local config. In addition, local config is read first which allows overriding definitions and other files with customised versions. (Note that in case of definitions, you may need to clear the cache before the changes show up.)
@awhiemstra great news. thanks for the heads up. How do I clear the cache ?
On Windows and Mac, Delete the "cache" dir in your local configuration folder. On Linux, delete ~/.cache/cura .
@awhiemstra
That is now fixed.
Excellent. Do you provide a nightly AppImage somewhere for me to test?
Not yet, I'm afraid. We are working on a continuous integration system at the moment that should be able to better take care of it. In addition, I would like to backport it to 2.4 so it will be in final 2.4, but I am not sure if it will be considered important enough.
With cura 2.4 on ubuntu linux (installed via PPA) the customization in userland is still partial. At least "definitions" and "meshes" are not searched by cura the locations mentioned above. Copying the resources in /usr/share/cura/resources/meshes/ get cura to take them into account.
With the 2.4 AppImage they still don't seem to get loaded from ~/.local/share/cura/definitions
...
Yeah, the commit was not backported unfortunately. It will be fixed in 2.5.
In the meantime, on Linux you can mount the AppImage, copy out its contents, and modify them like so:
sudo mount /home/me/Downloads/Cura-2.4.0.AppImage /mnt
sudo cp -r /mnt/ Cura.AppImage
sudo umount /mnt
sudo chown -R $USER Cura.AppImage/
wget "https://raw.githubusercontent.com/Ultimaker/Cura/master/resources/definitions/renkforce_rf100.def.json" -O Cura.AppImage/usr/bin/resources/definitions/renkforce_rf100.def.json
Then you can either repack the AppImage or run the AppRun
file inside the AppDir directly (this is useful during development).
This has been implemented in the meanwhile.
This has been implemented in the meanwhile.
Looks like in 2.7, $HOME/.local/share/cura/2.7/definitions/
gets accessed.
But then, I can't get it to show a definition from there. strace
shows open()
calls, but the machine does not appear in the machine selection dialog. Would a defective definition give a warning or would it just silently be ignored?
What's is the correct path for 2.5?
@cr41g1w I think it is being implemented only beginning with 2.7 Beta.
@probonopd I am trying to use FABtotum configs designed for Cura 2.5 from https://github.com/FABtotum/FAB_Configs/tree/master/Cura2.x_configs_FABtotum but not 100% sure how to load them. Documentation is lacking.
Putting the contents of /resources/ in to ~/.local/share/cura/. has maybe worked. I'm waiting on confirmation.
Please reopen. This is not working properly in 2.7 BETA yet.
$HOME/.local/share/cura/2.7/definitions/
does __not__ get created, unlike $HOME/.local/share/cura/2.7/definition_changes/
.
But I can confirm that when manually doing
mkdir -p $HOME/.local/share/cura/2.7/definitions/
and then placing a new printer definition there, then it gets picked up in 2.7 BETA. 馃憤
__However__, $HOME/.local/share/cura/2.7/definitions/
does __not__ override definitions coming with the application. This would be super useful.
To reproduce:
Place https://raw.githubusercontent.com/probonopd/RF100-Firmware/community/cura/renkforce_rf100.def.json into $HOME/.local/share/cura/2.7/definitions/
. Note that it has "version": 3
which is higher than what comes with Cura 2.7 BETA. Also, the print bed area has been increased from 100x100x100 to 105x135x100.
Now open Cura 2.7 BETA, add a new printer, select Renkforce RF100. I would expect it to use the (newer) definiton from $HOME/.local/share/cura/2.7/definitions/
but it does __not__ do that.
~/.local/share/cura/ does seem the correct path for Cura 2.5.
This was the commit that implemented it, I think: https://github.com/Ultimaker/Uranium/commit/c0e057b5d4fb68f73b16717c1e204b2d28e14f60
Note that it has
"version": 3
which is higher than what comes with Cura 2.7 BETA.
Please keep it on "version": 2
! That is not meant as a version number for the file but rather as a version number for the file format of definition files. This could be the reason why it's not loading, though I don't think we've ever explicitly set the precedence for local files to get loaded before the installation's files.
Sorry @Ghostkeeper, my mistake. I had misinterpreted the meaning of the key. So my only wish would be that Cura would create an empty directory at $HOME/.local/share/cura/2.7/definitions/
if it does not exist, like it does with other directories. This will make it easier for users to know where to put their custom definitions.
I second @probonopd 's request
I agree. I've added the definitions folder to be created upon start-up: https://github.com/Ultimaker/Uranium/commit/a3c77e86fc23c91d5084a7530616ead95776f86e
Thank you very much.
Most helpful comment
I agree. I've added the definitions folder to be created upon start-up: https://github.com/Ultimaker/Uranium/commit/a3c77e86fc23c91d5084a7530616ead95776f86e