Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: stirling on September 01, 2010, 12:25:38 PM
-
There's been a few threads re: THCs not working with smoothstepper and I think I understand why. But what about probing? doesn't that suffer from exactly the same issues as THC through the smoothstepper? i.e. lack of synchronization between smoothstepper and Mach because of USB. In fact come to that - what about homing? Limits I can understand (kinda) because as long as the thing stops within a few steps of where it should have - who's to know - but probing, THC and homing have to be step perfect.
Just interested if anyone is in the know.
Cheers
Ian
-
Dont know about probing but THC doesnt work, however homing does. I think the time sensitive nature of homing is overcome because the homing is done in the SS and then Mach is told.
Hood
-
THCs not working with smoothstepper and I think I understand why
Why ? ;D
Amir
-
I think the time sensitive nature of homing is overcome because the homing is done in the SS and then Mach is told.
Thanks Hood - that makes perfect sense.
THCs not working with smoothstepper and I think I understand why
Why ? ;D
Thanks Amir - thinking I understand it is one thing - trying to explain it is another - but I'll give it a go...
In order for Mach to process inputs in a timely manner there has to be as good as possible "real time" loop between Mach and the hardware it's controling. With the parallel port this is fine and all works well.
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.
So if by hardware we consider a THC, imagine what happens when the THC commands "UP". It tells the smoothstepper and that communication is "instant". BUT the smoothstepper then has to tell Mach and that communication is NOT instant and will take a period of time that is totally under the control of the USB system. Therefore the "UP" signal will reach Mach late - how late? who knows but late it is. By that time the THC could well be saying "DOWN". Result - We have a variable phase shift between the THC and Mach - Anarchy.
With homing - as Hood has explained, the smoothstepper takes control of the process. I see it working like this: as soon as a home switch is hit, the smoothstepper doesn't JUST tell Mach to stop sending pulses, it stops sending them itself and also tells Mach. It doesn't matter that Mach has sent too many because they're just discarded. The same happens for the backoff part of homing. Of course by this time Mach has effectively lost track of where it is - it doesn't know how many pulses the smoothstepper has discarded, but it doesn't matter - it just sets home to whatever home is and all is back in synch.
Limits is similar except that Mach WILL lose track of where it is - but again that doesn't matter because we accept that hitting a limit more than likely loses position anyway (even with the parallel port) and should be followed by homing.
But - that still leaves me with a problem understanding how probing can work with the smoothstepper. I'd be surprised if it doesn't because I think we'd have heard about it - but at the moment I can't figure out how. On the face of it when it trips, the smoothstepper could just stop sending pulses and tell mach it's tripped - but by then Mach has no idea of where it is. It's different from homing because home is a fixed position known to Mach - but a probe trip is - well - wherever it trips - How can Mach know where that is? Anybody know?
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.
Well you did ask... ;D
Cheers
Ian
-
very thx for information
A proposal:
Can we use the Modbus?
Amir
-
Can we use the Modbus?
For what?
Ian
-
for connect THC to mach3
Amir
-
I don't think so - nowhere near fast enough nor synchronized. The thing is, in any feedback loop the outputs cause a change (movement), that changes things (arc voltage), the input comes in, you process it and the result is (hopefully) an output that brings things back to where you wanted. BUT even in a "perfect" system you're allways playing catchup. In Mach this would ideally translate to: every single step in the XY plane may result in a change to arc voltage so before we take another step or at the very least AS we take another step we step the Z. That obviously means that the input is processed for each and every single step i.e. at kernel speed AND in synch.
Ian
...but whatever, I'd still be interested to hear from anyone using a probe with the SS for their thoughts.
-
Had a quick chat with Greg, was a bit rushed so never got full details. It seems the way probing works with the SS is when a contact is made the SS sends the info to Mach and once Mach receives it then the SS will go onto the next. Kind of ties in with something another user mentioned when using the SS for probing, he mentioned a 1/2 second delay between probes, all fits into place now.
Hood
-
1/2 second delay
i think this time is very long.
i build card modbus and speed refresh is about 70ms .if i have free time, 'll Test it
Amir
-
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
-
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. :'(
-
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.
-
Some folks have no interest in civlized conversations or facts they just want to bash others, how sad...
-
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.
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.
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.
-
. . . . 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.
Fortunately, I'm sure the fix will come with Mach4 or Smoothstepper II . . . in 'the next few weeks' . .
I am not content to sit back and just toss another complaint on a very tall pile. What made this topic interesting was to discuss the possibility of performing the missing Mach functions outside of the SS as I did with swapaxis. As I mentioned at the onset, I don't know much about THC, but on the surface, it does not seem terribly complex. More so than swapaxis, perhaps, but certainly not more than a dynamic balancer. It just needs a team of people with expertise in different areas willing to donate the time to come together and come up with something doable, starting with a clear explanation of exactly what is required for THC. I have a smoothstepper now and was willing to contribute, but staying on topic has proved impossible whenever Smoothstepper is part of the discussion and it quickly becomes uninteresting. I have no need for THC or backlash compensation, so I will not persue it further.
-
Gentlemen - I think we're getting closer - but as always - the devil is in the detail. Can I push a little deeper.
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)
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?
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
-
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.
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.
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.
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)
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?
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
The SS *knows* what the accleration and velocity settings are for all axes. So, when it needs to do an acceleration, or deceleration, it knows how to do it. Mach3, through the SS plug-in, does not tell the SS "issue a step pulse on this axis", it tells it "move this axis to this position", and the SS hardware handles all the details of the move. And the step pulses, including accleration and deceleration ramps, are generated entirely by hardware. The firmware on the SS simply programs the hardware so it knows what to do. Once motion starts, the hardware is doing everything autonamously.
Communications between Mach3 and the SS is by messages, not parallel port pin signals. Each message consists of a sequence of bytes, some short, some long, using a protocol defined specifically for SS. Those messages tell the SS to do things like "jog this axis at this speed", "move this axis to this position", "set this output to this state", "read this input", "home this axis", etc. Of course, the actual communications is far more complex than that, but that is the general idea. Messages are flowing pretty much continuously, with the PC telling the SS what to do, and the SS returning status to Mach3, so it knows what it needs to know about what is going on. But, with the SS, the PC is doing FAR less work than it does using the PP, because all the "heavy lifting" is done by the SS itself. The PC is left to run the UI, and do the trajectory planning, but no longer needs to concern itself with the details of the trajectory execution.
Regards,
Ray L.
-
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 ;D
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
-
i think only delay time
-
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 ;D
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
Ian,
I suspect there's no reason the SS *can't* do THC, it simply doesn't (yet), same as with backlash comp. The hardware is entirely capable, but the firmware and plug-in code has yet to be writtento support it. SS development largely stopped about a year ago, as Greg has had other, higher-priority, more profitable work to get done (a higher-end motion controller aimed at commercial and industrial machines). The sadfact is, the hobby CNC market is quite small, and tough to make money in. So, for now, the SS is very good at some things, not so good at others. For those that don't need backlash comp, THC, and the few other features it doesn't yet support, it's a great product. It dramatically improved the performance of my mill, so it serves a very useful purpose for me. But, it's not yet the "Swiss Army Knife" of motion controllers. That may, or may not, change in the future.
Regards,
Ray L.
-
Thanks Ray - I appreciate your help on this and as I said, everyone elses input too. I now have a better understanding of the whole shabang. I do have a couple of new questions that have occurred, but I'll leave them for now whilst I digest.
Cheers
Ian