Selective solder driver
Contributor. Built with the team.
Solders only the joints a board actually has, cutting cycle time 18%.
- 18%
- cycle time reduction
+60 boards per day
The terminal service in a three-service pipeline that automates selective solder program selection. It receives resolved board data over RabbitMQ from the two services upstream of it, and talks down to the machine over MQTT on a TCP connection it holds open.
The 18% comes from program selection, not from running anything faster. A recipe on its own covers every variant of a board the machine might see, so told only the recipe it runs the union: every solder point any variant could need. This service sends the recipe and the revision together, so the machine loads the program for the exact board in front of it and solders only the joints that board actually has. The joints this variant does not have are the 18%.
It also decides whether a board may enter at all, and the mechanism is quieter than it sounds. The machine asks for the scan of the board arriving; if board data comes back ineligible, the driver simply does not answer. There is no handshake to withhold and no stop to assert. The machine waits, which is the safe state, rather than failing open and soldering something unverified.
Failures publish structured error events to a dedicated exchange, so an operator sees the specific reason a board was rejected and can resolve it without escalating to engineering.
The machines were bought to be driven this way, so this is not automation of a job someone used to do by hand. It is the software the plan assumed: without it, every board and every variant would need an operator to change the program over before it ran.
Running continuously in production since launch.
C# / .NET, RabbitMQ, IPC-CFX, MQTT, TCP sockets, Azure, Splunk