Production mode and production options for Form4/4L

Feature Requests & Ideas
1

As the Form 4 (and several current resins) are approaching the reliability and capabilities required for production, it’s time to develop some production-centric components.

There is another universe, where people do production printing. In that universe, there are VERY different needs and expectations for interfaces. This is the same universe which exists in say, machine shops and production plants, where they make the things that make the world turn.
In that universe, menu popups, needless warnings, and stupid annoyances are b*slapped out of existence. Entire businesses are formed and fortunes are made simply in the development of tools which save time and material in these universes - that’s how important it is. Time waste is scoffed at, while developments which save time, money, and resources are rewarded with higher pay and more purchase orders.

Unfortunately, the current iteration of PreForm and the 4/4L interface is still NOT a production development. or even close to it.

I’d suggest the following considerations for production:

  • A machine setting (likely via PreForm) to flip a printer from custom to production.
  • The ability to send products to production mode or custom mode.

The production mode would change the GUI on the printer away from the consumer/prototyping interface, into something which would approximate production usage:

  • Files could be called repeatedly from the interface without adding additional iterations for each print job (more on this later).
  • The printer would have an option to adjust build plates with an X/Y offset option, so iterative prints would be jogged around on the build plate by a preset factor (say 1-10mm in x/y on the build plate in iterative prints), to avoid over-permeation of the same area for builds (thereby prolonging tank life).
  • Files could be managed in folders on the printer, accessed via the GUI, and called to print from that GUI.
  • A print-count would be implemented on the GUI, instead of the current scrolling list of useless data.
  • I’d suggest a general folder hierarchy on the printer interface: first layer could have general ‘custom’ print folder and production folder (so that all production files would automatically be sent to that folder). IN this situation, it would be VERY helpful to be able to send prints directly to a sub-folder within the printer.
  • Although it’s helpful to send from Preform, having a PC in the print room/print area is counter to conventional production floors, where engineering (or floor management) has file control authority, and equipment operators do not access or load files to the equipment. If FL is intending to see this become an actual production system, this paradigm must be both understood and implemented.
  • The GUI would have to get rid of all the superfluous (and highly annoying) reminders & popups.

We’ve printed just over 60 liters of black in Sept and Oct, on the same 4 files. and we’ll be printing 40-50 liters/month for the known future. I can’t even come close to approximating the level of annoyance the printer GUI presents to me. every. single. blasted. time. I. print. a. job.

The GUI desperately needs an overhaul for those who do production.

Anybody else have thoughts on production and how a production mode should operate? I’m sure it’s not just me.

6 Likes
2

I also work in this production environment, I’d add a digital warehouse feature, where we would inside preform add parts and have insights like, parts printed / month or even previsibility (statistically) of parts that needs to be printed etc… This would me an awesome production feature and it is totally alligned with the industry 4.0.

Totally agree with a “Production Mode” :clap:

2 Likes
3

I would love to see some of these features implemented for the Fuse 1/1+ as well. I’m not doing nearly as much volume as you, but I am working in a production environment and see lots of value in offering different GUI configurations.

And to @JoaoMarcos point, detailed part tracking would be fantastic. The part cost calculator in PreForm is great since cost varies so much on the Fuse (powder cost, packing density, refresh rate, etc.) but the data is cumbersome to track.

4

It seems to me that FL’s focus has been to put lots of features in PreForm, but in a production environment, the GUI on the unit becomes the valuepoint.

  • Iterative/repeat printing should be a simple process.
  • Prints should include a print count (number of print cycles completed) - this is paramount.
  • A “repeat” button would be good
  • Simplified/faster access to frequently accessed actions should be prioritized.
1 Like
5

I agree, PreForm is robust print preparation platform IMO, but the GUI is a bottleneck.

These 2 items have been the biggest requests at my company and seem fairly simple to integrate:

1 Like
6

Thank you all for your ideas and feedback, it’s much appreciated and very useful!
I have passed this along to the responsible team and they greatly value all of this detailed input. Thanks again for taking the time to contribute!

3 Likes
7

Hey,
You can temporarily automate your workflow using PreForm server and local API.
For me, the problem is that PreForm Server is only for Mac and Windows, and in many cases, I prefer Linux. It is a better choice, and a special version compiled for ARM like RPi for smaller environments will be great.
Then, you could add a small screen, buttons, and repeat prints.

@Sophia_M If you can forward request to Product Owners to prepare Linux version of PreForm Server for x86_64 and RPi ARM I will be grateful (I think everyone)

Best Regards,
Sebastian

1 Like
8

I’m curious what usefulness you see in doing local API.

From my perspective (at least working in a production environment), Preform exists purely to slice and prep files, and get them loaded to the printer. It is handy to remotely view resin levels and expected finish times, but these data are also available by a tech working the floor.

Of course there is usefulness in the serialization aspect, but I’d argue that should be a production aspect by FL, not something the user has to develop.