Looking for an economical XY (well and Z) solution that is not for the normal use

[Doddy]

The cheaper machines look like they have a simple protocol that I could talk with a micro controller or if it comes to it cannibalise the manual controller to simulate button presses.

In the interests of transparency: I'm not convinced that anything you're proposing will be easily viable - but not for the reasons that you've identified - the bits that scare me is the whole component management and handling. XYZ is straightforward, and to some extent the machines that you've identified would be broadly usable (but think of the ancillaries that you'd need to add - you need something that you can build upon). But it could be an interesting experiment, and you'll learn from it.

You mention "simple protocols" - for the machines linked they either come with a little Arduino / combined stepper driver module running the GRBL software, or with some form of BoB controller intended to connect to a PC to be driven from Mach3. The latter could be USB (popular), parallel (old-hat) or ethernet (not in your price range). Just to explain what these options are doing: The typical tool chain involved with 2.5d routing/engraving takes a design from modelling software into a CAM process (software) that generates a series of machine motion commands (e.g. goto X,Y... goto Z(down).... gotoZ(up), goto X...) - most typically in a format called 'g-code'. What the GRBL and Mach3 software does is trajectory planning - translating these "simple" instructions into a complex series of motion events to the steppers (including acceleration/deceleration, linearisation of arcs, etc) as well as affording some manual control. That, you *could* use, but it would be clunky - and it wouldn't integrate well with the component feed system (you'd have to play around with some form of hacked A/B/C axis) or a more complex macro system driving external hardware, or with the man-in-loop verification before a component is released to the board (e.g. component rotation prior to placement). It'd result in spaghetti code of the worst form. A g-code solution is not appropriate, in my mind, for your problem.

Far easier, in my mind, considering the very simple, and very different requirement that you have, to disregard (or re-appropriate) the control hardware to move away from GRBL/Mach3 and simply generate the motor stepping signalling. All you need for each axis is a "step" (clock) signal and a coincident direction (boolean) signal to move the stepper one step in the necessary direction. You can/should consider some simple mechanical sympathy with gentle acceleration but the basic behaviour is to simply Seek-home-position, move-to-component-tray, pick-up component, move to target XYZ, verify with operator / machine-vision/control for orientation - rotate as necessary, micro-step to adjust for component holding offset on tool, move to board (Z0 minus component height), release component, recover to safe-Z, then traverse-to-home and rinse-repeat. In describing this general placement strategy it should be clear why P&P needs a very different approach than the usual g-code interpreters - there's too much closed-loop control required - and in my view needs a different solution. That's why I say to cut your losses at the steppers (or stepper drivers) and throw another control system in its place. You may find there's open-source software out these with the usual hobbyist/hackspace type of sites that can help with that, although the software shouldn't be difficult to derive a basic capability.

BTW, the USB/Ethernet controllers mentioned - you probably want to avoid these (or replace them) - these migrate parts of the trajectory solution from the Mach3 software into a local microcontroller - Mach3 would packetise elements of the trajectory solution to the controller for localised signal generation... that's the worst place to try to "hack" into the protocol. The simpler parallel-port BoBs are much easier to interface to, or bin all of that and use local signal generation.

My view: You could cobble something together, but unless there's already an open source hardware/software solution then this forms a substantial project in itself. Don't expect that you can find a COTS/turnkey solution.