CNC troubles after update

Sorry, I missed your post.
Lots of good info there, but difficult to dig in to.

Please put your tinyG into mm mode and repost the new parameter set.

Something clearly is wrong somewhere – 440.20 should fix numerous bugs in this area, not create them.

What do you use for sending Gcode? CoolTerm, Chilipeppr, …?

Problem **may** be that Gcode is sending circles as 360 degree arcs.
Try regenerating your Gcode with circles sent as 2 arcs, which is a typical option to fix what appears to be a long standing issue with the definition of arcs and circles in Gcode.
tinyG has, of necessity, become more strict on what it accepts as Gcode and this is an area of great confusion.

mm vs. inch: tinyG saves its internals in mm, converts to/from inch when necessary. Most reference setups are in mm, so it is easier to spot issues with parameters when they are posted in mm.

I forgot to ask an important question, knowing that you use Chilipeppr – how did you enter your new machine parameters? If you used the configuretinyG widget in CP, that may be the issue here – it seems to be corrupting settings.

What I typically look for in parameter settings is wacky precision in values that don’t require precision, for example your $zvm=787 mm/sec, vs the typically suggested 800 mm/sec.
I also wonder about $1tr, $2tr and $4tr, which likely should nominally be 60mm unless you tweaked them (in mm or inch) to ‘tune up’ your machine for precision.
Also, $3tr=8mm looks unusual to me – what sort of lead screw do you have for Z? I am familiar with 8mm diam, 2mm pitch ($3tr=2) and ACME screws with $tr=2.117mm(yes, this particular ACME is an inch based design).
Additionally, your X and Y jerk settings look strange. Recommended starting points are JerkMax=5000, JerkHoming=10000.

Here is another interesting result; I imported the Gcode file your posted above into my CAD program of choice, QCAD.
Here is it’s interpretation:

https://dl.dropboxusercontent.com/u/50261731/banshee_control_horn_3.png

Looks a lot like what you are getting.
Note that QCAD and tinyG have nothing in common, except that the software developers read the same documents specifying how Gcode is supposed to be translated to machine motion.
I also opened your DXF file in QCAD, looks OK to me.

Dragging the same Gcode into CP looks OK. ???

Whatever CamBam is doing, it may be contributing here.

1. Please comment on my parameter comments – perhaps there are reasons you chose those values.
1.5 Was there some guideline document you were following to initially set up your tinyG?
2. Please comment on how you entered parameters after FW upgrade. If you used the configuretinyG widget, I’ll likely walk you thru a parameter reset. Usually fixes issues like this. Underlying cause not well understood.
3. Remember, always enter, manipulate and report tinyG parameters in mm mode; seems to work better. Inch mode Gcode should then run OK.

OOps, $3tr=(2/25.4) = 0.079 inches

One more item I missed

Is there some sort of filtering of the input .nc file prior to sending the code to the machine?

The ChiliPeppr UI has several selectable ‘filters’ that are able to modify Gcode. The auto-level capability, for example, modifies Z position based on pre-determined Z=0 variation across an X,Y workspace. There is also an ability to modify velocity with setting in the Gcode Widget (a static, or whole job modifier) and now in the tinyG widget for dynamic changes while a job is running. Velocity modification is achieved by manipulating F value settings on the fly.
Other custom macros, including your own, can be inserted into the logical path between the Gcode file that is dropped into CP and the input to tinyG.

A default CP set up does not modify Gcode on the fly.
SPJS, in managing the buffer flows into tinyG, inserts control commands as necessary for it to maintain knowledge of the tinyG state, but those are acted upon by the tinyG FW, not passed to the GCode interpreter processes within tinyG.

Geeze, this is messy.

When you made the following updates

$3tr= 0.079
$xjm= 197
$xjh= 384
$yjm= 197
$yjh= 384

Was the machine in inch mode or mm mode?

I took a look at all your hole_test files.
Just as before, your .dxf file opens and displays for me as I believe you intended.
If I import your .nc file to the QCAD CAM importer(simulator), same bogus arcs as I saw with the control_horn series of files.

From what I see, we might have two issues going on here.
1. Arc errors
2. tinyG Parameter interpretation errors.

Lets try this:
1. With your current Parameter set, rerun a quick test that confirms that commanding Z to move 1 inch moves Z by 1 inch (or, as you reported, 0.9996″)
I assume you are using a 1″ jog?
2. Change the $3mi parameter : $3mi=4 This cuts the number of microsteps per step in half.
3. Resend your 1″ jog command. How far does Z move? I am testing a theory that the $3mi interface is for some reason broken. There has to be an explaination for your needing to set $3tr to a value 4 times as large as it should be.

When you are done with the test, please dump and post another parameter list, IN MM MODE, and give it a clearly identifiable name. We may need that listing in a follow-on test.