We are going to a new UI for Atelier written with QML.
That interface needs to be adaptative for small screens like a RaspPi 7" touchscreen, and desktop screens.

Features that we need:
-> View for 3D Rendering of GCode
-> View for camera monitoring
-> View for Gcode Edition (Only for desktops I think)
-> View for controlling the printer with:

-> Axis(X, Y and Z) 
-> Extrusion/Retract control (Normally Up/Down arrows)
-> Temperatures for Bed and Extruder Controls(This one can be more than one)

-> Screen with Graphs to monitor temperatures for all controls
-> Screen for Log system

Pls @rizzitello and @patrickelectric add anything that you would like to and I maybe missed here.

Note: Let's keep this simple for starting.

Some corrections/notes:

• Should be able to use in smartphones as well.
• 3D rendering of the gcode and update of the viewer while showing the printing progress.
• View for multiple camera monitoring
• The extruder and extrusion/retract need to handle multiple extruders.
• The extrusion and retract should allow the user to control the length of the filament (not a simple up down arrow).
• Panel for connectivity configuration (connecting to remote service of atcore).
• Show notifications for when:
  • print start
  • print finish
  • Something is wrong (YOUR PRINTER IS IN FIRE !)
    • If possible, showing a picture with the notification, showing the actual state of the printer.
  • Allow specific notifications like: Changing layer and etc.

Ok team, here is a first take at a mobile interface. Right now I am only thinking of this as an interface for phones. For a tablet or horizontal device, we would only stretch the UI horizontally or just do better placement but the same elements would be there. Please note that these are pre-made wireframes. They are meant to convey an idea only and not a final design. Focus on elements, menus and main ideas.

The 3 interfaces of 3d printng that i find are most common.

1. Standard Desktop size, this has all our controls and options. Most people don't really like to use this to print because you have to leave your computer on for several days at a time and that will usually use more power then the printer to run the device.

2. Mobile interface. for interacting with remotely . This should mainly be used to view the progress of your jobs and or to start remote print jobs from the sd card or connected embed device.

3. On device interface. This would be an option for those with an embeded machine hooked up to the device with a touch screen. this would provide all the basic controls that the machines lcd would normally but with a much better interface and some additional options.

We should consider this in our design. I personally think we should try to make 1 and 3 the same interface and the user is free to use the machine how they like while still using our software.

@abetts I Like the moc up for a mobile interface. Its a decent start for this.

In T9542#158105, @rizzitello wrote:

The 3 interfaces of 3d printng that i find are most common.

1. Standard Desktop size, this has all our controls and options. Most people don't really like to use this to print because you have to leave your computer on for several days at a time and that will usually use more power than the printer to run the device.

I have seen only some interfaces that have this. That might be due to the fact that there are only just some applications that can control 3D printers.

2. Mobile interface. for interacting with remotely . This should mainly be used to view the progress of your jobs and or to start remote print jobs from the sd card or connected embed device.

I mentioned this to the team at Atelier but they didn't think this was possible yet with their software.

3. On device interface. This would be an option for those with an embedded machine hooked up to the device with a touch screen. this would provide all the basic controls that the machines lcd would normally but with a

much better interface and some additional options.

I believe this is where my design is trying to go.

We should consider this in our design. I personally think we should try to make 1 and 3 the same interface and the user is free to use the machine how they like while still using our software.

@abetts I Like the moc up for a mobile interface. Its a decent start for this.

I am hoping we can get more people from the Atelier team to also add comments and suggestions. Thank you for your comments @rizzitello I also think these are areas to be taken into account.

Hello Andres, Thank you for your first mockup.
But I would like to comment some points.

• The interface puts a much bigger focus in the 3D objects than the 3D printer itself.
  • That's really a good nice approach and we really would love to add such thing like in Atelier, but we have a huge problem with it, right now it's not possible to slice 3D objects in Atelier. Just to explain it better. The 3D printer process start with download a .stl or any other file that represents the 3D object. After that, the user will need to slice the object, transform the .stl file in machine code (.gcode) that is used in the printer host to print it in the 3D printer. This is actually a pretty normal workflow, but there is some others printer hosts that uses embedded slicer applications on it, but we don`t have any plans to add such thing in Atelier. But the entire idea it's really awesome, maybe we can add such thing in the future.

About some points that Sith brought to light.

• I think that is totally possible to use the same interface to mobile, tablets and laptops/desktop, we did some tests with a qml application for it last year with kirigami.

I'll add here some things with others printer hosts, some mockups and kirigami tests that we did.

@abetts, Let me know if you need any further information from us :)

And thank you very much for you time and your mockup !

Thank you for the comments. If you were to take anything out or add anything to the mockup, what would that be?

The who model downloading / purchase section. We can't slice on atelier so this is currently not useful to our users.

In T9542#158509, @rizzitello wrote:

The who model downloading / purchase section. We can't slice on atelier so this is currently not useful to our users.

Oh I see, I can remove that.

We do not know who our target users are. We really really need to decide upon a few "User Profiles" I think that will guide us alot in our interface choices.

In T9542#158511, @rizzitello wrote:

We do not know who our target users are. We really really need to decide upon a few "User Profiles" I think that will guide us alot in our interface choices.

What a great point!

Can the team review the Personas HIG and then let us know which of them seems like a best fit?

None of those really apply to the people who are 3d printing today.

From the users of printers I know they tend to fall into one of 3 groups.

1. Artists - They make some model want to just easily make it physical they dont understand the tech and are prone to unrealistic expectations for what the machines will produce.
2. Tinkerers - They want to build things they will care more about the settings. Might have made their machines. This makes up most of the users I know.
3. Factories - Want to run farms of machines don't care about much more then pushing a job to them .

I think we should focus on Group #2 . since they have the most needs and we can easily reduce what is visible for the other groups

@abetts One of the most important things in a 3D printer are:

• 4 Axis control
  • To control X, Y, Z, and E (the extruder, the guy that extrude plastic to create the 3D object)
  • The control need to be able to move with steps from 10cm to 0.01mm. (This values can change from printer to printer).
  • The extruder control should have a extruder multiplier that changes the extrusion quantity from 0.5x to 2x.
• Temperature control
  • This sets the temperature in the extruder and the heated bed. The max values should be set by the user.
• Command mode
  • The user should be able to send machine code to the printer, allowing some personalization.
  • This command code should output data from the printer and show to the user as well, like a normal terminal.

• Visualization tools.
  • Should show any temperature indicator with target and actual temperature, from both extruder and bed.
  • Should show the 3D model in a widget and what is already done by the printer and what should be done yet, this is usually done painting the lines in the 3D model with different colours.

• Connection widget:
  • This tool is used to select the serial port, or the tcp connection used to connect in the 3D printer.
  • Is also necessary to select the baud rate in a combobox, but also be able to allow the user to put the baudrate value as a normal text.
  • Should have a connec button
  • And also shows if the printer is connect or disconnected.

Others usable widgets:

• Profile settings:
  • Set the settings of the 3D printer, like X, Y , Z max distance
  • Colour of the filament
  • Price of the filament (this is used to calculate the price of the model that is printing)
  • Max bed and extruder temperature per filament.
  • Printer name
  • Firmware type and etc

This are the necessary widgets and to allow a minimum functionality in a 3D printer host.

In T9542#158516, @patrickelectric wrote:

@abetts One of the most important things in a 3D printer are:

• 4 Axis control
  • To control X, Y, Z, and E (the extruder, the guy that extrude plastic to create the 3D object)
  • The control need to be able to move with steps from 10cm to 0.01mm. (This values can change from printer to printer).
  • The extruder control should have a extruder multiplier that changes the extrusion quantity from 0.5x to 2x.
• Temperature control
  • This sets the temperature in the extruder and the heated bed. The max values should be set by the user.
• Command mode
  • The user should be able to send machine code to the printer, allowing some personalization.
  • This command code should output data from the printer and show to the user as well, like a normal terminal.
• Visualization tools.
  • Should show any temperature indicator with target and actual temperature, from both extruder and bed.
  • Should show the 3D model in a widget and what is already done by the printer and what should be done yet, this is usually done painting the lines in the 3D model with different colours.
• Connection widget:
  • This tool is used to select the serial port, or the tcp connection used to connect in the 3D printer.
  • Is also necessary to select the baud rate in a combobox, but also be able to allow the user to put the baudrate value as a normal text.
  • Should have a connec button
  • And also shows if the printer is connect or disconnected.
    
    Others usable widgets:
• Profile settings:
  • Set the settings of the 3D printer, like X, Y , Z max distance
  • Colour of the filament
  • Price of the filament (this is used to calculate the price of the model that is printing)
  • Max bed and extruder temperature per filament.
  • Printer name
  • Firmware type and etc
    
    This are the necessary widgets and to allow a minimum functionality in a 3D printer host.

Thanks for the extra feedback. I will try to put this into graphics! Stay tuned!

Hello people, I've been working in a couple of mockups that are kind of my view for this atelier interface.
Of course its a mockup and you can do any inputs that you feel want to, but I think that this version is a good place for a start.
Attached you have the png and svg files.

As promised in the VDG chat yesterday, I'm working on something comprehensive for you!

One thing that I'll mention is that I think the ability to slice STL files should be considered a part of the Minimum Viable Product, or else there just isn't that much value for the user over other simple offerings like Pronterface that just send GCode to the machine.

This doesn't mean implementing slicing functionality yourself though! I recommend adding slic3r as a dependency and calling it via the command-line interface to do the slicing for you. Atelier could ship with some pre-generated slic3r profiles for different print quality levels (e.g. quick draft, normal, and fine detail), and it could be smart enough to display other profiles already available for advanced users who customize them. The full UI mockup is coming soon!

We have plans for slicer plugin support. Just never made a task for it. So I've done that now T10396

Here's my idea:

Deliberately omitted from this mockup are:

• Filament price
• Filament color selection interface
• Multi-color slicing interface

Those would be awesome, but are advanced features not necessary for round 1.

@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...

+1 Choose 3DPrinter screen
+1 Printing screen

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.

The idea here is that after starting one object on one printer, you would just use the Back button while on the printing page, which takes you back to the page that lets you choose what to print and what printer to print it on. That way you can print different objects on different printers at the same time.

• 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.

Are you saying that one machine can have multiple wired connections to the host? If not, then each machine will be connected with a single serial port and a single baud rate, right? But yeah, I can make those into dropdown menus.

• The screen with temperatures can be more than two dials because the printer can have 1 bed and N extruders...

Ah yes. You can show however many dials you need. :)

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

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.

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.

A few technical questions:

• 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?
• Does Atelier support exporting gcode to SD cards for printers that have SD card slots? If not, can it?
• Does Atelier support connecting via wifi to printers that support it? If not, can it?

I'll work on version 2 soon incorporating your answers to these questions and other feedback, plus a few basic features I see now that I missed (e.g. printing multiple objects or duplicates of the same object on the same printer, camera view).

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.

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).

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).

The widget that I made supports an ip camera, but is not tested =/

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)

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

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!

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

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.

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

@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.

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!