Now that I have all my parts I've been able to do more testing. I had to report a bug to the folks at UCCNC - PORT4/PIN6 can't be used for homing. It wasn't clear what the issue was, I'm assuming firmware. It will be fixed in versions after 1.2036. Since the bug only affected PORT4 I moved to PORT5 - problem solved.

The next issue that I encountered was with fusion360 post for UCCNC and the way my Z-axis was configured. I kept the same configuration that CRP uses - Z homes upward and sets the offset to 8. The UCCNC post commands a G0 G53 Z0 at the beginning and end of the GCode (//retract to safe plane). This causes the Z axis to start driving to machine 0 at rapid speed. I thought of three way to correct the issue:

1. create a zOffSet property in the post and set it to 8. Then the beginning and end move will move to Z<zOffSet> instead of a hardcoded 0.
2. re-configure the Z-axis so 0 is at the top and -8 at the bottom (this is what I did for now)
3. change the retract method in the post (it looks like Mach3 CRP uses a G28 move, still not sure how that retracts)

Otherwise I'm happy with the cut quality so far with UCCNC.

EDIT - I remembered an additional behavior that doesn't seem correct - I'm using a relay in the PnP electronics to control the router. When I first turn on the PnP the router comes on. The relays are active low so that must be the initial state of the outputs on the UC300. The software can't be on before the UC300 because of licensing. I'm not sure if that is an oversight on UCCNC's part, or if there is nothing that can be done other than powering off the router when I power down the PnP. I'll post on the UCCNC support forum and report back.