nallath

What is that you want to do and why use labview for it?

The one thing the UM2 nozzle is indeed better with is with fine detail. The hotzone of the original nozzle was shorter, so you had a bit finer contorl. The main advantages of the UM2+ are the removal of the spring, so you don't get degraded teflon and a way better (stronger) feeder + switchable nozzles.

The UM2+ is superior to the UM2 in every single aspect. As for firmware upgrades, the only firmware upgrades that we've done in the past time is adding more material profiles. Since the UM2(+) is essentially running marlin with a bit of menu stuff on top of it, there isn't much need for change. All that being said; We still test Cura if it works correctly with UM2's

Because there are multiple reasons to change something. Eg; A material needs to change the temperature, but the same can be true for quality or the type of nozzle you are using. Not by means of the GUI.

Since we never built it for anything like that, I don't think it's that feasible to change it. Ahoeben's solution will probably work, but it will probably not be very stable (since it's a big change to the way of working)

My best guess is that the model has mistakes in it, which causes the auto arrange to fail.

It's not intended to be used without the front end. You could try and see if you can get the meshTweaker (my plugin wraps that) to work in command line.

In order to diagnose this issue, we require the following log files; (Windows) %APPDATA%\cura\<Cura version>\cura.log, or usually C:\Users\\<your username>\AppData\Roaming\cura\<Cura version>\cura.log (OSX) $USER/Library/Application Support/cura/<Cura version>/cura.log (Ubuntu / Linux) $USER/.local/share/cura/<Cura version>/cura.log (Ubuntu/Linux) If the Cura user interface still starts, you can also reach this directory from the application menu by Help -> Show settings folder

We always appreciate more plugins!

That's not temperature control per layer. That's temperature control on certain parts of the print (hence my confusion of what it was you meant). You could also save a project file and share it with us. Since we can read the elvish moon script that Cura generates to sing the song of it's people to other Cura's, we can use that to figure out what is going wrong.

Cura has never had what you describe. The closest thing is using the tweak at Z plugin, which is still available within Cura. I don't know what you mean by the per-layer setting found under material tab though. I'm pretty sure that there has not been a setting like that in Cura.

Unfortunately, there are always more things that are incorrect then there is time/resources to actually fix them with.

In order to fix this issue, we require the following log files; (Windows) The log as produced by dxdiag (start -> run -> dxdiag -> save output) The Cura GUI log file, located at; (Windows) %APPDATA%\cura\<Cura version>\cura.log, or usually C:\Users\\<your username>\AppData\Roaming\cura\<Cura version>\cura.log (OSX) $USER/Library/Application Support/cura/<Cura version>/cura.log (Ubuntu / Linux) $USER/.local/share/cura/<Cura version>/cura.log (Ubuntu/Linux) If the Cura user interface still starts, you can also reach this directory from the application menu by Help -> Show settings folder

And not to mention a ton of extra memory usage.

Space + mouse move will zoom the camera. Same goes for ctrl + mouse.

This shouldn't matter. But if you could share your logs, i can have a look at what happened (and maybe fix it)

No. Only the UM2 does this.

comand_util.py is a debug script, so mostly meant for our convenience. This also means that it has a horrible outward facing interface, which assumes that you know how the internal system actually works. That being said; The internal system uses a pretty complicated system of procedures. As things can and will go wrong, it can occasionally be convenient to trigger specific procedures (or parts there of). That's what the startProcedure does. All that being said; You're right on account of having to trigger those procedures to do what you want. If you want a full list of the procedures, you can find those on the machine, located at /usr/share/griffin/griffin/machines/um3.json

It highlights areas in the model that are incorrect by making them red.

Err. That is weird. What do you see if you look at the model in xray mode? Could you try and run the model through a model fixing tool?

It's not for calibration. Some settings can be set globally *and* per extruder. Infill density can be set globally and per extruder. This means that if the extruder does not provide a value, it uses the global value. If it does provide a value, that one is used instead.

I've forwarded this to the engineer that built it. He is on a holiday, so he might take a bit longer to respond.

Well, that's windows for you ?

The cura logs only mention the sending of statistics that failed. What version of the firmware are you on?

CuraEngine doesn't have default values (or well; it gets them from the fdmprinter.def.json). So in order for this to work, it needs to know where to find the file.