• rebase

• rebase

• remove unneeed i18n call

Unfortunately I'm pretty busy with other things for the next few days so maybe someone else can take the reins on the maintenance & manual control page. :) If you'd like me in the group, feel free to send an invitation!

@ngraham You can join the group on telegram to brainstorm the interface if you want to.
Also there's a lot of screenshots that @patrickelectric added to this task that you can look for inspiration.

What do you need from us? You can join our telegram group @KDEAtelier and talk to us =D

The reason why I've saved the Maintenance & Machine Control page for last is because I have the least strong opinions regarding how it should look, feel, and behave. Manual control IMO should not be a very common thing to do and I think it's okay if it has a powerful and nerdy UI that exposes all functionality so that when you do need to use it, everything is right there. If you two want to just use your judgment on that, I'm fine with it.

• rebase

Will do, sorry for the lack of progress recently. Will make it a priority.

Hey @ngraham thanks for working on this for us!
Can you work on the Maintenance & Machine Control screen?
Because we are planning to start to work on this soon!

• Typo fix
• Default to disabled

• rebase

• rebase

I liked that!
Now I would like to see more about the Maintenance & Machine Control ^^

Okay, here's version 2, with incorporating feedback, features I forgot, and a more: traditional KDE-style UI (e.g. rectangular buttons with icons on the left rather than square with the icons on top)

Can't answer that since none of mine came with a camera installed. Cameras can be any camera. currently we are able to connect to local devices in our camera viewer (idk that anyone has tested an ip camera there).

In T9542#174432, @ngraham wrote:

Thanks for the comments. This is designed not only for embedded but also desktop use. A 3D printer app is one of those cases where I'm not sure a more complicated interface on the desktop makes sense. The workflow and capabilities are basically the same in both cases.

• The last time I had a print farm set up for commercial purposes (granted, this was a few years ago) I personally never had problems with serial ports changing. What is the sanest technical way to handle multiple 3D printers from your perspective?

In that case we would expect them to change. When they can change is for users who use several printers with the same tty controller that do not always have them all atttached. (or any other serial tty device.)

• Does Atelier support exporting gcode to SD cards for printers that have SD card slots? If not, can it?

There is a patch for this but its VERY VERY Slow about 1Kb/s (again serial devices..) D14136

• Does Atelier support connecting via wifi to printers that support it? If not, can it?

Currently no only because I don't have a machine that connects to anything but usb.

• Another question: how is an integrated build camera configured? Is it connected to the printer itself, connected directly to the host and seen as a camera, available via a web URL, or something else? Or any combination of those? Etc.

Can't answer that since none of mine came with a camera installed. Cameras can be any camera. currently we are able to connect to local devices in our camera viewer (idk that anyone has tested an ip camera there).

Another question: how is an integrated build camera configured? Is it connected to the printer itself, connected directly to the host and seen as a camera, available via a web URL, or something else? Or any combination of those? Etc.

Thanks for the comments. This is designed not only for embedded but also desktop use. A 3D printer app is one of those cases where I'm not sure a more complicated interface on the desktop makes sense. The workflow and capabilities are basically the same in both cases.

The basic issue with the auto detect idea is that 3d printers restart when you try to connect to them. If you have more then one and one is printing trying to probe devices can be problematic. The other issue with hard coding a device is the device name can change since its just a serial device and ttyAMC/ ttyUSB devices are common and number will changed based on the order they are plugged in.

I like the general workflow here. This can work nicely for an embedded interface .

In T9542#174428, @laysrodrigues wrote:

@ngraham Liked that.
But a few things:

• The user can print different files for different printers, so he needs a window to select which file it will print for each printer.

@ngraham Liked that.
But a few things:

• The user can print different files for different printers, so he needs a window to select which file it will print for each printer.
• About the connections(baud and port) it can be more than one device connected to, so your idea doesn't look much useful. It should be drop down menu for those options.
• The screen with temperatures can be more than two dials because the printer can have 1 bed and N extruders...

Load the file is not my main concern.
Manipulate, multiplicate, and put more than one different models is my concern.
Idk how further the other hosts that have this feature goes on...

Here's my idea:

Loading STL's with qt3d for the preview seams trivial (with assimp): http://amin-ahmadi.com/2018/01/28/viewing-3d-models-using-qt/