Getting really F'n frustrated

I’m actually a bit surprised that a set screw being that loose resulted in such a small, therefor hard to detect, error. Perhaps it was on one of the Y motors, leaving the other to do most of the work?
Anyway, good find.

Your use of the term ‘pocket’ leads me to think you are milling a 2.5D job of some sort.
Perhaps now is the time to upgrade your machine to the latest tinyG FW, 438.02 if not already, I have lost track of where you are at.
While the differences between 435.10 and 438.02 are minor, they were changes to fix machine dynamics when Gcode calls for very short moves. Many 2.5D code generators seem to be outputting code with move increments at or below the minimum capability of the machine. TinyG seeks to accumulate such short moves until a physical move can be made, there were some bugs up thru 438.02.
BEWARE- Loading new FW will reset all your configs, you will have to re-enter. Make sure you have a copy of where you are at.

This forum tool is tough on images and long files. What we suggest is to set up a dropbox or equivalent clould sharing account. put images, configuration files and Gcode examples in files, and post here a URL.

And, very long threads become difficult to look back into as well.
Since you seem to be more or less up and running now , with all your screws tight ( 🙂 ), I suggest start a new topic, with new Subject that refocuses on more specific issues.

And now perhaps an opportunity to address your CAMBAM post processor question. I don’t use CAMBAM, so don’t have specific suggestions, but here are some fundamentals that the post processor might address.
1. Configure to use arcs – Gcode G2 and G3 commands. Work well with tinyG.
2. Use reasonable precision – tinyG will keep track of line segment requests down to 0.08mm and arc segments down to 0.10mm. not much point in requesting a 1.0001 mm move.
3. Do the math and understand the fundamentals of your setup, specifically the minimum moves that it can make in the X,Y and Z directions. The minimum move a stepper can make is a microstep. The number of steps per revolution is a physical parameter of you motor. The number of microsteps is programmable, [1,2,4,8]. Pulley diameter and belt pitch determine the travel per revolution. From all those parameters, compute travel per microstep in each direction. You will find these to be larger than the tinyG minimums for a typical NEMA23 machine. It is then a personal preference how precise you have your Gcode generated. Maybe 2x, meaning that if a microstep is 0.2 mm, generate Gcode with 0.1mm accuracy. Super accurate Gcode will run, but it will be a much larger file, will take longer for tinyG to interpret (i.e. slow the machine sometimes) and won’t deliver any additional accuracy in the final job, because of the machine fundamentals.

Enjoy

An additional suggestion, since you use tgFX.
Only one application; Coolterm, tgFX, avrdude can be attached to your USB port connecting to tinyG.

Earlier versions of tgFX had an issue of not exiting cleanly if you did not first disconnect from the USB port. The GUI would terminate but a tgFX process would remain running (as seen in Task Manager). If you get a ‘can’t connect to port’ error from avrdude (or CoolTerm), check Task Manager and kill the tgFX process, or just pull out the USB cable and reinsert it.