Guest
Show Posts
671
General Mach Discussion / Re: Smoothstepper and probing, home and THC
« on: September 05, 2010, 10:28:32 AM »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.QuoteFTDI 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.QuoteThis 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.
it already has live tooling for small tools (5/16" dia max), a 16c large bore spindle with auto collet closer and is about 40cm x 800cm c 40cm in size. 