Because torch height isn't controlled by G31....

At what point did I suggest it was?

It's a completely different, and less accurate, control loop. ONLY G31 behaves as I described.

That's what I'm trying to get at and obviously failing miserably... I'll try again as simply as I can...

If the G31 control loop tests the probe input at kernel speed then WHY does the THC control loop not test THC UP/DOWN inputs at kernel speed?

That's what I'm trying to get at and obviously failing miserably... I'll try again as simply as I can...

If the G31 control loop tests the probe input at kernel speed then WHY does the THC control loop not test THC UP/DOWN inputs at kernel speed?

 Probably G31 is part of the driver code and THC is not.
Hood

You may well be right Hood. I guess the thing is that at first the view was that inputs were ALL polled at 10Hz. Then came the issue of the index input which we agreed must be much faster than 10Hz in order to work as it does. We then learned that it's fundamental to probing that it's input is read at kernel frequency. My contention is that IF THC was done at kernel frequency or at least a deal faster then it too would benefit greatly. I wonder why therefore, that the great and good chose to leave it slower. To be honest I'm not entirely sure this IS why THC is sluggish, which is where I was trying to go but somehow got distracted. I was just attempting to see if I could figure out why it's slow and if there was anything I could do to improve it's response.

Cheers

Ian

Next time I see Brian online I will ask just to make sure.
Hood

Got a message from Brian, THC is in the driver so should be fast. Not had a chance to actually chat with Brian but will try and get more details later although I am thinking it will really need to be Art as he is the guy that does the driver.
Hood

Thanks Hood - be interested in your findings.

Ian