Formlabs Form 3L

Formlabs Form 3L - root causing its issues (literally)

This printer might be the most unreliable printer ive never touched. The Formlabs support makes the nightmare bearable.

Ok jokes aside this printer proved to be much more of a project than a tool. Over my summer internship I used a form4 religiously and was impressed with the quality and speed so much so I wanted to buy a formlabs printer for my own work. little did I know this would have proven to be a mistake. I ran into all sorts of issues from code 67 to code 234 but let me take you through the process that I went down to figure this thing out.

I first saw a listing on facebook marketplace. I drove with my friend Adam to Vacville and loaded a car to the brim with formlabs equipment. Picture below of how much filling happened. The second one was picked up in San Jose.

And it worked. Prints were reliable for the first 2 prints worked great. Then continous errors. Formlabs support said the machine is broken and beyond repair. To their credit these machines are second hand and im not sure how they ended up with thier respecigve owners. Support was fast to respond and always works on doing right by the customer. Using dmesg we were able to see faults for ourselves.

And so the printer was taken apart to unviel a bunch of redunancy. Below is the sitara module. it's made by compulab but I think formlabs bought the design? Im not sure how that works and im impressed that compulab allowed formlabs to do this.

Below is the QSPI for the Sitara. UART boot log off of the momo (the mainboard its just what formalbs calls it). The most amount of security on this device was the crappy programmer I bought CH341a preventing device readout. This thing was so flaky - but I just bought a nice FPGA based programmer coming soon. yay!

Adam spliced and diced some sdk uboot to generate cooked.bin. and boom we are in. Once in we dumped the entire file system to a USB drive for further analysis. That was a cooked USB cable lol

One we were in dmesg we were able to see the printer for what it is, chalked fully of URB errors. I didnt know much about USB but this was a masterclass in unreliable USB connections. URB (USB Request Block) is any revelant infomration to execute USB trasciotn to deliver data and status back. Its kernel level and structured to faciliate comms throughout linux and to different conrol nodes of the printer. URB code -71 error was was being fired on prints that were failing.

Interestingly both of the printers had these errors when combing through the logs. Formlabs seems to have attempted to fix the problem by retrying transmission a few times and then resulting in error 67. This leads us to believe that this problem plagues all Form 3L albeit to differing extents.

I opened up the printer and with Adam started to work on understanding the issue.

The printer has a -24v and +24v bus sent to the LPU(light processing unit). These devices use a solid state laser and galvo system to scan the base of the resin vat in order to cure the resin. From my undersatnding this was done to circumvent a patent (I totally could be wrong) but fromy my perspetive this is far inferior in every single way to MSLA due to a massive increase in overall machine complexity and worse performance (slower) albiet lower forced on FEP film.

These +/-24v supplies has terrible ripple. Vpp was close to 500mv at idle and under load the story was the same. Bottom line there was a ton of noise. This noise was being injected into the LPUs and the xhub board.

The xhub board is shown below. its a PCB interposer used as a USB hub as well as power supply breakout for the 2x LPUs inside ofthe form3l. This board was at the heart of our problems.

The USB hub on the xhub is a cypress job. below is the operating characterisitcs of the device. We noticed that the Vmin and Vmax of the 3.3v rail supply generated by the on xhub buck converter was +-/300mv. This could cause our URB issues that dmesg log was firing as the device was subjected to out of normal operating range.

To confirm this we shorted out the crystal during operation (forcing the hubs clock to 0) and was able to recreate the URB issue. At this point we where beinging to understanding the issues.

It was clear that the problem was hardware related so Adam traced the PCB to obtain a netlist.

Once Adam made the nets I set to Alitum to develop a custom board. This time pulling out all the stops.

Due to signal integrity being questionable. a TUSB221 was added in conjunction with a high USB hub with tunable DC bias from SMSC (microchip). This hub, the USB2512I proved to be a good tool for the job. The configuration to load from was generated with a EEPROM packer code tool that microchip provided.

The boards were fabbed and programmed. turns out there was too much capacitance so I depopped the tants.

Also had an issue with the -24v power supply generating 1v it was due to a broken resistor but I believe we caused that not formlabs so skill issue.

The printer has not fired another URB issue and prints have been successful thus far. A resin tank leaked which sucks but thats a solveable problem. Thank you formlabs support for squaring me away with a new thank!

This was a difficult project but I learned a ton about USB and continued to sharpen my debugging skills. Shout out Adam for being as crazy obessed as me and wanting to get to the bottom of these machines