Hood - this is all starting to make sense. I doubt you'll remember but ages ago I asked (on the yahoo board I think) why you needed the PP driver loaded even when you just wanted to EMULATE probing and THC. The answer was effectively that probing and THC have some of their "code" in the driver. At the time I couldn't figure out why - now it makes sense why. Really appreciate your time on this.

Ian 

Just wish I had more time to speak to Greg but we were both heading out so just got the brief outline of how it works.
Hood

BUT with the smoothstepper, the "real time" loop is between the smoothstepper and the hardware. The loop between Mach and the smoothstepper is NOT "real time" because of the very nature of USB (the real clue is in the B for BUS - think bus contention). So this means there is NOT a "real time" loop between the hardware and Mach.

The parallel port is also on a bus as is just about everything else in a PC. Although USB is compute intensive, I would speculate that it has far less lag time than the parallel port, however, the smoothstepper is not a true USB device.  Smoothstepper uses an 'off-the-shelf' serial to USB 'converter' that consists of a driver and hardware from a third party.
99% of the Smoothstepper install is actually that driver which is the basically the same, in my experience, for the many devices that use the interface ( I have about 4 differnet ones, including coincidentally some servo drives).
Perhaps the lag imposed by the signal conversion may be the unsolvable dilemma here.

Why am I interested in all this nonesense? I've been working on my own THC design for a while and have a few vague ideas how I can make it work with the smoothstepper.

I don't know much about THC, and I don't know much about smoothstepper either at this point (although I did aquire one recently to play around with) Nevertheless it occurs to me that perhaps the THC function could be done in hardware independent of both Mach2 and the smoothstepper . . IF . . as I *think* is the case, the function is simply duplicated following certain Gcode commands. It would be a matter of programming the required process into a chip and triggering it in some way from within Mach or by sensing a certain condition. I did something like this for automatic spindle lock control on my 4th axis project.

Just a thought on an interesting problem.

99% of the Smoothstepper install is actually that driver

I don't know much about THC, and I don't know much about smoothstepper either at this point

Interesting to claim that you don't know very much about something right after making several huge assumptions about how something works  Actually about 99% of the SmoothStepper functionality is the plug-in. The FTDI driver provides a 'translator' between the USB hardware and an application.

The FTDI driver

in fact convert to serial, and this can cause slow speed.
in ARM processor ,This feature is embedded in the controller, and this is their strength

Amir

Quote

99% of the Smoothstepper install is actually that driver
I don't know much about THC, and I don't know much about smoothstepper either at this point

Interesting to claim that you don't know very much about something right after making several huge assumptions about how something works  

Jeff, as usual, it seems you are looking for a fight. So be it, I shall accomodate you this time. The difference between us is that I have no problem saying what I do NOT know and when I am speculating on something so that people know exactly what they are reading. Other people   just throw out answers that they are in fact 'guessing' at, but do not state so and have little or even zero actual knowledge of the topic they are commenting on.

I made no assumptions about how smoothstepper works. I made only the observation that there are many, many posts from people having various problems with the device and that certain functionality such as THC, backlash compensation, swapaxis, etc are NOT supported. This info as you know comes from very reliable sources, one of which, ironically is you. However, again some people   just hype the product and forget to mention the shortcomings . . .  perhaps because they sell the product.

Actually about 99% of the SmoothStepper functionality is the plug-in.

Irrelevant in this instance as the discussion, if you had bothered to read it,  was about the interface and not the functionality, and in any case, my comment was on the installation, a point which which you obviously also missed.

The FTDI driver provides a 'translator' between the USB hardware and an application.

I already made note of that interface, except that I correctly identified the interface as a driver AND hardware . . which is not an assumption, it is fact. Again, you may want to actually read a post and perhaps do some homework before you make sarcastic remarks. And incidentally, the FTDI driver does not 'translate' between the USB hardware and any application.

Well, in fact USB is serial, and so is Ethernet, using a serial connection in and of itself does not say anything about the potential data rate. If you'll look at the FTDI chip on the SS you'll find it is a parallel FIFO.

I'm not trying to be a smart ass guys, just trying to dispel myths.

Well, in fact USB is serial, and so is Ethernet, using a serial connection in and of itself does not say anything about the potential data rate. If you'll look at the FTDI chip on the SS you'll find it is a parallel FIFO.

I'm not trying to be a smart ass guys, just trying to dispel myths.

Jeff, again you are commenting before reading. Data rate is not at issue, and is irrelevant in any case. The discussion was about latency, so if you care to 'dispel some myths' about that topic, then you would be on topic.

My last post was in response to this statement:

in fact convert to serial, and this can cause slow speed.
in ARM processor ,This feature is embedded in the controller, and this is their strength

When I sent the post you had already posted simpson36, when I tried to modify my response with the text so denoted below I found the forum was down for a few minutes. My response to Amir was relevant to his comments.

As to your question about latency is an issue with any form of communication. Inside the PC much of the communication is synchronous, the signals are sent and received in time with a shared clock (there are different clock sources for different things.) With the parallel port driver the latency between when the driver should be called by the OS and when it actually is called is the issue. With an external motion control device operating over USB or Ethernet, which are both synchronous forms of communication (no shared clock), latency comes from the nature of the communication system itself and is much more variable. External motion controls have built in hardware to generate the step/direction signals and respond to time critical things like limit switches or probing. Since the time critical stuff is done in dedicated hardware you get better performance, but anything requiring a 'real time' interaction with the PC will have a split second lag.


This section is what I tried to post before:
simpson36, I'm never looking for a fight.  I was trying to use an emoticon  to show that. I guess I must come across much differently than I intend to. You said you did not know much about the SmoothStepper and made an incorrect assumption and I tried to point out the irony whilst correcting misinformation. It was not meant to be offensive, sorry it made you feel otherwise.
My last post was in response to this:

Your original post made assumptions that were just not factual, such as the SmoothStepper not being a 'real' USB device. That is like saying device that uses a RS232 to TTL level translator chip is not a real RS232 serial device. Most Ethernet devices use an external Ethernet chip, does that not make them real? My point was that the functionality of a bus translator is the same no matter if it is built into a uC or a separate device. It dose not make it any more or less real or lead to any loss of speed or functionality.

There is some of the parallel port functionality that the SS does not yet emulate, and as you said I've been one of the first one to mention that fact. I also sell them as you say but I try to cover the benefits and drawbacks of all the items I purvey; I like folks to be able to make an informed decision. I do not appreciate the personal insult against my character by you suggesting otherwise, that is uncalled for. I spend a great deal of my time trying to help other folks on forums, in email and by phone, and I don't get a dime for it 99.9% of the time. I do it because I like to help other folks have a good time learning about CNC.

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.