Quote from: Jeff_Birt on September 04, 2010, 01:23:27 PM

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.

. . . .  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.

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.

Quote from: HimyKabibble on September 04, 2010, 06:47:48 PM

Not a "Real" USB device?  It's either a USB device or it isn't.  USB is USB.

There are all manner of interface converters on the market. Parallel to 'serial', USB to parallel, USB to IDE, etc. In my view, a 'legacy' printer with only a parallel port does not become a 'USB device' if a USB to parallel cable is used to connect it to a PC. I can see now that instead of 'real', perhaps 'native' might be a better word. That said, many of these 'converted' interfaces do not have all of the features of the native devices, for example in USB, the inability to run thru a hub.

[RSL] You're misinterpreting how the SS works.  The communications between the SS and the PC *IS* 100% standard bulk-mode USB.  The USB "host" hardware is built into the PC, and the USB "device" hardware is on the SS board itself.  The cable is a simple, off-the-shelf passive USB cable, with no chips, converters or active electronics of any kind.  The 15-foot cable I use with my SS came from Radio Shack.  The SS is absolutely every bit as much of a USB device as your iPod, or digital camera, scanner, or any other device.  The SS absolutely CAN run through a USB hub.  It's not recommended, as running through a hub is not desirable, because a hub adds latency to the communications, because the data has to be received by the hub, then re-transmitted from thub to the device, potentially doubling the "transport" time.

ANY USB interface can be made to present itself to the PC as any kind of device it wants.  It IS simply software, or actualyl firmware.  Each USB device, when connected to the PC, provides a "descriptor", which is a table of information that tells the USB "host" device in the PC what it is.  Whether the device chooses to tell the PC it's a "serial" port, "parallel" port, mass storage device (like a FLASH drive), camera, audio device, or whatever, is strictly a matter of what data is loaded into the descriptor, which is determined by the firmware controlling the USB hardware.  This does nothing more than tell the PC which driver to load so it knows how to "talk" to the device.  In the case of the FTDI converters you reference, the ONLY thing unique about those chips is they have the firmware built-in, to make them appear to the system as a specific device.  This is done purely so anyone can take that chip, wire it up, and be talking to a PC immediately, without having to write any firmware.  If you look at one of the many "Serial" cables made with FTDI chips, they typically have a "Wart" at the far end fo the cable, where the DB9 connector is.  The chip is in that wart.  The communications over the cable is pure, standatd, bulk-mode USB.  Each byte of data sent from the PC is received by the chip, which then puts it directly into a UART, whose TX pin is connected to the DB9 connector, so it can be sent to any standard RS232 device.  Data received from the RS232 device is sent to the UART, which converts it back to parallel data, which is put back on the USB cable, and sent to the PC.  This is no less of a USB device than an iPod.  You can plug the cable into a hub, rather than directly into the PC.

Quote

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. 

The FTDI that I have seen require hardware as well as the driver. In most cases, the chip is in the device, as is the case with the SS. However, FTDI sells a series of cables that include the chip in the cable itself. Granite devices drives use this method, for example, and if one was not aware that the chip was in the cable, then it would appear that the drive was a 'native' USB device, but it is not. Emulation or conversion of any kind would introduce latency, it seems to me. There is no 'pin 15' in USB speak, for example, so this must be codec somewhere in the process, and that is going to take time in each direction . . which = latency.  It would be a question of how much and if that amount had any significance to a 'real time' process.

[RSL] The SS makes no attempt whatsoever to emulate a parallel port as its interface to Mach3.  Mach3 and the SS are continuously passing messages back and forth to each other so keep both sides informed as to what is going on.  Where the Mach3 PP driver busies itself with actually generating step and direction pulses, when the SS is used, Mach3 instead tells the SS something much more like "move this axis to this position at this speed, and tell me when you're done".  Of course, it's a lot more complex than that, but that is the general idea.  All actual motion control comes from the SS hardware and firmware, NOT Mach3.  The step pulses are actually generated entirely by dedicated hardware, which is why the SS is able to generate a far smoother, faster pulsetrain than Mach3 can through the PP.  The fact that the SS "maps" it's inputs and outputs to virtual parallel port pins is strictly a user convenience, and avoids the SS requiring more extensive changes within Mach3 than it already did.  But it is simple mapping, and nothing else.  If Mach3 needs to set the output called "Pin 15", it sends a message to the SS which says, effectively "Please set Pin 15 High".  Which physical connector on the SS it chooses to label "Pin 15" is completely arbitrary, and has no real meaning beyond providing a means for Mach3 and the SS to know which output is being manipulated.

Quote

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.

This is my point exactly, down to the use of the word 'really'. There is not one universal method of doing this. I have older converted USB devices that have drivers that attach to a specific physical USB port. If you want to use a different USB port, you have to reinstall. Others show up as a virtual LPT or COM port. The SS shows up as a device on the the USB bus.


 

Gentlemen - I think we're getting closer - but as always - the devil is in the detail. Can I push a little deeper.

Quote from: HimyKabibble on September 04, 2010, 06:47:48 PM

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.

Well not quite complete - we're not done yet. What then "goes on" between the PP and "Mach3"? i.e. the probe trips. Then...? (see the next bit for what I'm getting at)

Quote from: HimyKabibble on September 04, 2010, 06:47:48 PM

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

Well not quite - it DECELERATES to a stop. How does it (the SS) know how to do a deceleration curve?

Quote from: HimyKabibble on September 04, 2010, 06:47:48 PM

and sends the position back to Mach3.

Ah - one of my earlier questions - How?

Cheers - and let's keep it cool guys - I'm grateful for ALL your input.

Ian

All making sense and understood but get a grip with the old quoting mechanism Ray - I've just about done my already poor eyesight right in 

I'll go away and have a bit more thinks but at the moment I'm thinking so why no THC - it (now)sounds to me relatively trivial - THC to SS: "UP", SS to Z: "pulse", and then the occasional SS to Mach: Update the Z dro/pos to: "3.142".
Job done and we all go down the pub.

Cheers

Ian