Your original post made assumptions that were just not factual, such as the SmoothStepper not being a 'real' USB device.
From the FTDI site page one: Welcome to FTDI - specialists in converting legacy peripherals to Universal Serial Bus (USB).
There is no assumption for you to label as factual or not. Smoothstepper uses the FTDI interface. That is not good or bad, it IS simply fact. FTDI has a single purpose and if my saying that this is not 'real' USB offends your fanboi sensibility, then please feel free to choose whatever word you like, it is really not relevant to the discussion.The only point to be made is that any signal conversion is going to impose some latency and when speculating about the inability of the smoothstepper to perform certain function that require 'real time' response, the FTDI or ANY other device that would create latency is a logical suspect. I did not say it does or does not, I merely pointed out that this is the method smoothstepper uses, and obviously therefor the potential exists.
As to insulting your character, Jeff, that was not my intention at all. I was simply making an observation based on what I have read many times. This is a forum. Words vs words. It is what it is and not more than that. You are very helpfull on this forum as are many others and that is admirable, but that does not give you immunity from consequences if you choose to sarcastic remarks, even if you backpedal later. Put another way, if you start a fight, don't cry if you go home with a bloody nose.
Not a "Real" USB device? It's either a USB device or it isn't. USB is USB. FTDI makes USB chips, and provides drivers, that emulate serial and parallel ports. That emulation is *entirely* a software feature on the PC side, and has no effect whatsoever on timing. latency, or anything else. It is purely in how the driver presents itself to the OS. This is done so software written to talk to a COM: port will see an FTDI device as a COM: port, even though it really isn't. Regardless of what interface is being emulated, or whether it's some completely new device type, the data going over the USB interface always looks the same, and it's sent and received using the exact same protocol, timing, etc. as every other USB device. Were it not so, no two USB devices would ever be able to communicate. USB is nothing but a high-speed (1Mbps, 12Mbps, or 480Mbps, depending on the hardware used, and operating mode) self-clocking serial interface, not unlike IEEE-1394 (Firewire), Ethernet, and many others. Any significant latency is primarily a function of Windows itself, as I/O requests from applications, like Mach3, get buffered up inside Windows, and only passed down to the device driver periodically. With Windows, there can be as much as 10mSec of latency from the time an application makes an I/O request, until the driver is actually called. Once the driver is called, unless there is already so much data buffered up that all the USB bandwidth is already being used, the data will generally make it from the PC to the device at other end of the USB cable in no more than one USB frame (1mSec) or so. The SS is a "Full Speed" USB device, so all data transfers are 12Mbps.
This all has little or nothing to do with why THC doesn't work, or probing. When probing, the Mach3 parallel port driver issues a step pulse, then immediately checks the PROBE input to see if it's gone active. If so, then it knows the probe is complete. With the SS, Mach3 tells the SS to probe. The SS issues the step pulses, and tests the PROBE input. When the PROBE input goes active, the SS stops stepping, and sends the position back to Mach3. And, except for the communications with Mach3, this is all handled in hardware, not software. I would assume THC, like probing, requires a short latency between the THC input signal and the Mach3 driver. But, because of the ~1mSec nominal latency of the USB bus, and the OS delays getting from the USB driver to Mach3, there is too much latency for the THC to work correctly. This could be fixed by handling THC in much the same way as probing - "closing the loop" within the SS itself, but that is not how it currently works.
Regards,
Ray L.