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.

By the way, the QCAD Gcode simulator (import Gcode) generally works OK with 360 degree arcs, so not at all clear why it is not working with your CamBam file.

QCAD has a GCode generator and a GCode importer.
In the generator, it has a specific option to draw circles as two arcs.
I found out (the hard way) that tinyG does not like 360 degree arcs.

At issue here are the formalized rules in the GCode language specification as to the permissible values of the Arc command (G2, G3) parameters.
Also, some GCode readers/interpreters check the Command Parameters against the Gcode specification and error if out of spec, others apparently do not.
There are academic arguments for both modes of behavior.

I am not adequately fluent in GCode specification to look at your GCode and say one way or the other good/not good.

Let's do the easy stuff first
Open the URL for Z axis lead screw.
Pitch = 2mm, a.k.a 2 mm between threads, so $3tr=2mm in your case.
I have no idea what "Tr8*8-4" means - some sort of Prod ID?

Lets assume the dxf is what you want, dimensionally.

The .nc file "looks" OK, but two ( tinyG, QCAD importer) interpreters make "incorrect" interpretations of the G code while the CP 3D viewer displays "correctly".
That says to me that while the .nc file "looks" good, only a detailed analysis of the exact parameters against what the GCode standard specifies can reveal if it is really 'compliant to standard' GCode.
In this world, GCode generators are supposed to implement the standard precisely as written.
There is no explicit expectation that interpreters implement tests on the validity of the parameters. In the 'old days', e.g. 438.02, tinyG did little, if any, boundary checking. It does a whole lot more now.

AN observation: I reopened your dxf file. As imported, your active lines (cuts) are on two different layers of the dxf. I have no idea if that is important to CAMBAM.

Here is a Gcode file output by Qcad, using 360 deg arcs

https://dl.dropboxusercontent.com/u/50261731/banshee_control_horn_circles.nc

Here is a Gcode file output by QCAD using 2 180deg arcs per circle

https://dl.dropboxusercontent.com/u/50261731/banshee_control_horn_2arcs.nc

See if one, or maybe both, work for you.
NB: this uses my typical depth and speed parameters, may not be what you want. Maybe run in air first.

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

Forgot to address jerk
These are the Synthetos recommended starting values for x and Y axis
[xjm] x jerk maximum 5000 mm/min^3 * 1 million
[xjh] x jerk homing 10000 mm/min^3 * 1 million

5000/25.4 = 197 10000/25.4 = 384

I don't think jerk is a contributor to this current issue, but you are low for normal movement (non-homing) jerk.

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.

I am using your issue to play with various potential debug tools.

I notice something interesting.
If I open your .dxf file, I observe that in dxf space, each of the 4 small circles on each part are single elements - circles.

Looking at the Gcode file banshee_control_horn_3.nc, that first circle is shown as 3 sequential G2 arcs, repeated at two different depths. The machine then moves to the second small circle, but this time it is processed as 4 sequential G2 commands, repeated twice.

I am rather suspicious of the CamBam GCode.

I am not a user, so cannot be much help.
Are you using a post processor on CamBam? Which one?

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.

By the way; yes, you really did need to upgrade your FW. There were several releases between 438.02 and 440.20. The need for the upgrade, in addition to many arc related fixes, was a bug fix for changes in alternate coordinate space manipulation that you are probably not using at the moment, but when you do in the future, it could be(have been) ugly.