Right, I failed to elaborate on those specifics:
BitRunner is the easiest: there is nothing specific to do, because the BitRunner just picks up the PWM signal from the controller, that gets activated whenever there is a “M3” (start spindle) command found in the G-code file being executed, and all GRBL post-processors in existence will insert those M3 commands automatically.
BitZero requires a little more adaptation if moving away from CM. You will need to either use the built-in “Probe” modules in the other alternate G-code senders, or use a probing macro. Whenever I am not using CM and use CNCjs instead, I rely on @neilferreri’s macros to leverage the BitZero.
Leveraging the BitSetter outside of CM also involves using macros (and again, when I use CNCjs I use Neil’s macros for initial probing and tool change probing). But you lose the “integrated” workflow that CM does for you (with e.g. the tool change prompts), and you have to execute the tool length measurements macros yourself, at the right time, in the right order. At CAD software level, when using VCarve you will need to use a post-processor that supports the BitSetter, i.e. that inserts M6Txx commands in the code between toolpaths. Again, @neilferreri to the rescue.
So basically, you can leverage the BitRunner, BitSetter, and BitZero with other senders, it’s just less integrated (since those alternate G-code senders are generic, they don’t natively and specifically support C3D’s gizmos, but they can be made to use them)
To each their own: some like CM’s workflow, some like to have more workflow freedom offered by other senders (but with freedom comes more responsibility to not screw up, that’s the name of the game).