Context: We’re developing software to support a facility that uses FormLabs printers (specifically the Form4 series) doing production manufacturing (i.e. not just prototyping), so we’ve been using the API to integrate them and provide remote / programmatic access. We’re not using the API to create scenes; we do that using PreForm a priori and just upload the generated .form files with the API. One important requirement for this facility is that we can’t use PreForm or the cloud dashboard to interact with the printers: we have to go through the API or use the touchscreens.
We’re trying to reduce the amount of interaction a technician needs to have with the touchscreens for several reasons, one of which is so that they have a single place to interact with all the hardware in the facility (which is much more than just these printers). In trying to do that, we’ve run into several issues that seem unsolvable without getting updates to the API, and a few things that would be nice to have.
Our current list of issues with the API are, in rough order of importance:
- A print cannot be aborted via the API. If a user wants to cancel a print, they have to interact with the touchscreen.
- Follow-on from that: An aborted print cannot be detected via the API. If a user cancels a print with the touchscreen, there’s no way for our software to know it has happened, except through inference by detecting (through polling) that the print is no longer happening before the expected completion time. Put together, these two issues make cancelled/errored/aborted print job management quite brittle.
- Error details cannot be reported through the API. If there is an error with a print, the technician needs to go to that printer and read the screen to get the details. This also means we can’t log and track errors properly across our printers.
print_now: trueon a print doesn’t print now if the printer isn’t ready to print at the moment that it was sent; it adds it to the queue. The expected behavior, to me, is that the API call returns an error and the print is not added to the queue. Importantly, we don’t want our technicians to have to manage the queue on any of the printers, and this limitation somewhat forces it to happen. We can first check that the printer status is ready to print before sending the request, but the printer status is only updated every ~5-10 seconds, which is long enough for the status to change. This also leads me to…- The queue cannot be interacted with from the API. The above would not be a problem if the API could modify (or even just read) queued print jobs for a printer like we can from the touchscreen.
- The
/devices/endpoint doesn’t return the currentjob_id(as returned from/print/). This seems like a simple fix, and would allow robust print job tracking through API client restarts / disconnects. - The
statusmember returned from the/devices/endpoint is a plain string, not an enum, so API clients can’t really use it to make automatic decisions with confidence - discovering every possible string isn’t feasible. Enumerating the options in the documentation (and putting them in the OpenAPI spec) would be helpful. - The color of colored resins (specifically Color V5) is not reported through the API; they all have the material code “FLGPCO05”. This means that for prints that need specific colors, the technician has to manually check the resin tank & cartridge each time they run a colored-resin print, because we cannot confidently verify that the resin is correct just through the API (which we normally can do for other resins).
- The OpenAPI spec doesn’t use explicit discriminators in its
OneOfdefinitions, which causes problems with some tools (specifically Microsoft’s Kiota in our case) when trying to generate APIs for it. Adding these would make the API more robust, and allow us to not have to manually modify the spec and/or the generated code to make it work, as we are doing now. /discover-devices/with noip_addressdoesn’t appear to actually discover all the formlabs devices on the network, it only connects to those that the computer has connected to before via IP (having recorded their IPs in the windows registry, and looking there for the devices to connect to). This isn’t necessarily an error, per se, but it should be documented because the name is a little misleading, and because it forces the API client to manually keep track of the IPs of the formlabs devices and connect to each directly (with theip_addressset) at least once after a device IP changes, a new device is added, or the API client is run on a new computer.
That’s what we have so far. I hope that the level of detail is useful, and I’d be happy to elaborate if further context is needed. We’ve been glad to see that there is active development on the API and we look forward to seeing where it goes in the future. As a general piece of feedback, we would appreciate seeing more emphasis on making the API more useful for automation and printer/print job management, rather than just for scene creation and editing. Thanks!