Why f/32 for THCAD?

Thanks for all the great work on plasmac! Is the f/32 recommendation in the user guide aimed at folks using parport? Since I've got mine plugged into a Mesa encoder port, seems like f/32 is throwing away 5 of my ~10 bits of ADC resolution.

Lunkwill wrote: Thanks for all the great work on plasmac! Is the f/32 recommendation in the user guide aimed at folks using parport? Since I've got mine plugged into a Mesa encoder port, seems like f/32 is throwing away 5 of my ~10 bits of ADC resolution.

f/32 is recommended by PCW of Mesa fame

I think guys using a parallel port are using f/64

Thanks for the quick response. Also, looks like people generally leave the reference frequency output unconnected?

Physical connections for the THCAD are described here linuxcnc.org/docs/devel/html/plasma/plas...l#_thcad_connections

Re the 1/32 divider, I think its something to do with the relatively slow speed of the Servo thread. The THCAD uses a pretty smart voltage to frequency converter IC which averages values between readings so the slower frequency is a better match for Linuxcnc. But PCW might have a better description than my laymans version.

Sending 1MHz signals through wire in an RFI rich environment leads to some issues.
1/32 is recomended for Mesa boards, with parallel use 1/64 or 1/128, depending on the latency of the used PC.
(edited) That it is still plenty for THC.
Last machine i built has THCAD set at 1/64, although the PC could reliably read 1/32 up to 185V ( could not test it higher ), and that is still very fine and very fast for tracking the torch at some pretty extreme slopes.
You will most probably be more limited by the speed of the Z axis, so do not worry about the THCAD.
To put is simple, no matter what or how, THCAD with Linuxcnc will beat any other THC i had the chance to play with, even some industrial ones costing 10 of thousands $.

Lunkwill wrote: Thanks for all the great work on plasmac! Is the f/32 recommendation in the user guide aimed at folks using parport? Since I've got mine plugged into a Mesa encoder port, seems like f/32 is throwing away 5 of my ~10 bits of ADC resolution.

As tommylight noted 1 MHz signals and counting 0.5 usec pulses is susceptible to noise issues,
and due to the way the encoder counter measures frequency, you do not lose A-D resolution at lower
frequencies.

The encoder counter measures frequency (velocity) with a N/T algorithm where N is the number of counts
and T is not the sample time but rather the time between the first and last changes of the counter during
the sample interval