[escott76]

A little OT at work, and I'm contemplating a smooth stepper. I don't use backlash comp, nor do I plan to. I had issues losing steps until I engaged sherline mode, and dropped my accel and velocity. It would be nice to gain a little bit back, my theory is that the steppers and G540 are up to the task of going faster, but the computer is struggling with the pulse rate.
Anybody run a G540 with a Smoothstepper? What kind/size machine? Did you run without it and then upgrade, and if so what differences do you notice?
Thanks for any help folks can provide,

[ger21]

If you need to use Sherline Mode, you should call Gecko. You may have a defective drive.

The Smoothstepper really shouldn't make a speed difference, if the parallel port is functioning properly. If you run the drivertest, what kind of results do you get?

[escott76]

If you need to use Sherline Mode, you should call Gecko. You may have a defective drive.

The Smoothstepper really shouldn't make a speed difference, if the parallel port is functioning properly. If you run the drivertest, what kind of results do you get?

<sigh> No offense, but this issue is not singular to myself, and it is NOT my drive. It is a common issue described by multiple people on these boards. The driver test shows excellent results throughout, but when running complex 3D contouring I lose steps in multiple axis, unless I have Sherline mode enabled. Axis are physically free to move easily, they are linear guides and ball screws, and have been tested for free movement. When this is enabled, the same programs run fine at the same speeds. I am actually under the impression that it is the computer that is at fault, and not generating a clean pulse stream at speeds. Hence the idea of shifting the pulse generation out of the computer itself.
The Smoothstepper CAN make a speed difference, if the machine can't handle generating a clean pulse stream at speed or when changing speeds. Honestly I'm less concerned about overall speed, and more concerned with acceleration.
Although I do appreciate the sentiment, I'm specifically looking for information from people who OWN and USE both a Smoothstepper and a G540.

[acondit]

<sigh> No offense, but this issue is not singular to myself, and it is NOT my drive. It is a common issue described by multiple people on these boards. The driver test shows excellent results throughout, but when running complex 3D contouring I lose steps in multiple axis, unless I have Sherline mode enabled. Axis are physically free to move easily, they are linear guides and ball screws, and have been tested for free movement. When this is enabled, the same programs run fine at the same speeds. I am actually under the impression that it is the computer that is at fault, and not generating a clean pulse stream at speeds. Hence the idea of shifting the pulse generation out of the computer itself.
The Smoothstepper CAN make a speed difference, if the machine can't handle generating a clean pulse stream at speed or when changing speeds. Honestly I'm less concerned about overall speed, and more concerned with acceleration.
Although I do appreciate the sentiment, I'm specifically looking for information from people who OWN and USE both a Smoothstepper and a G540.

Escott,

Gerry was just trying to be helpful and gave you good advice. Mariss recently reported that about three percent of the G540 drives are exhibiting this symptom. It has been identified as a xilinx (chip maker) problem but not yet resolved. Mariss has some specific testing procedures to identify whether your drive is exhibiting these specific symptoms. So contacting Gecko is good advice.

Alan

[escott76]

Escott,

Gerry was just trying to be helpful and gave you good advice. Mariss recently reported that about three percent of the G540 drives are exhibiting this symptom. It has been identified as a xilinx (chip maker) problem but not yet resolved. Mariss has some specific testing procedures to identify whether your drive is exhibiting these specific symptoms. So contacting Gecko is good advice.

Alan

That is a little clearer, I've not heard this before. I have heard of a number of cases of the issue though, with similar resolutions. I will contact Mariss, thank you.
Any link to this discussion? Is it an issue with the stepper drive's themselves, or the BOB present in the G540?

[ger21]

http://cnczone.com/forums/showthread.php?t=86339

Post #27

[heymoeheylarry]

This post talks about it in more detail, it has been about a year since the problem started.

http://www.cnczone.com/forums/showthread.php?t=64932

[Starleper1]

I had the same issue with losing steps until i check the sherline mode. I have never lost a step since. Everything is running great.

[Jeff-Birt]

If you PC has significant jitter in the output pulse-stream from the parallel port it can actually produce pulses that are not long enough for the drive to see properly. Checking 'Sherline Mode' helps in many cases, not just with the G540, because it lengthens the pulse width and makes it easier for the drive to 'see' it.

The SmoothStepper produces a 'Smooth' pulse stream and that makes the drives job much easier. On my shop computer, 1.5 MHZ processor, I can run the parallel port with up to a 45KHZ kernel, driving a G540. This will give me a max of 90 IPM on a Taig mill, but it is really pushing it on a slow PC and if you try to open a file or change screens while running the mill you will have problems. With the same mill and G540 and SmoothStepper I have cranked it us as high as 250 IPM, although that is in no way a reliable speed for the Taig. It will however so 100 IPM all day long.

The only way to know for sure if the pulse stream from your parallel port is causing problems is to look at it with an oscilloscope. I like to recommend the SmoothStepper as it eliminates all the hassles of trying to find a PC/LPT that will produce a good pulse stream. All the feedback from all the SmoothSteppers I have sold go something like this, "Wow! My machine runs so much smoother now. I have been able to raise my rapids a bit."

[Torchhead]

For little more than the cost of a SmoothStepper ($169.95 free shipping) you can upgrade to a 2.8 to 3 GHZ refurbed HP desktop WITH XP Pro loaded (EBAY store) and with an integral Parallel Port, and run 65 KHZ pulse streams all day. It also reduces jitter running at the higher pulse streams. Most loss of steps comes from running the motors outside their torque-RPM range rather than missing steps. We all accept the fact that steppers lose torque at a non-linear rate based on RPM. They start to stall (lose steps) once the torque curve crosses the RPM curve of the motor. Evenly spaced pulses can effect that curve slightly but it's still the physics of the motor and drive that have the most influence.

You should not have to take the pulse width on Gecko drives above more than 5us. We set all of them at 2 us. We go thought hundreds per month. Going to Sherline Mode makes the pulses wider but it just masks the base problem.

The G540 uses the G250 drives and the pulse width problem occurs on a few of those drives. The pulse width setting in MACH is global so it affects all axis.

Pulse polarity is important too. Set wrong and it can cause poor stepper performance.

If you have a G540 or the G251 drives and you have to run in Sherline Mode to keep from having position problems then contact Gecko. If you can slow down the velocity and acceleration and the problem goes away (without changing step pulse size) then it's not a driver pulse issue.

There are background processes in XP that can cause pulse jitter (or actual "ticks" in the pulse stream. If you have a NIC (network card) enabled but not connected it can cause a pulse stream tick everytime it polls trying to find a connection. There are other things running that will cause parallel port timing issues. Video (toolpath) refresh can be an problem on slower machine with integrated video controllers.

While the SmoothStepper will solve parallel port timing issues it comes with it's own set of limitations. Your software is no longer in perfect sync with the table position. Anything that relies on real time feedback (threading, RPM , encoder feedback, THC, or repeatable home signals) is not going to work with any serial to parallel communications solution. Not a problem with simple milling (except for the variable home switch timing).

TOM Caudle
www. CandCNC.com
Totally Modular CNC Electronics

[escott76]

For little more than the cost of a SmoothStepper ($169.95 free shipping) you can upgrade to a 2.8 to 3 GHZ refurbed HP desktop WITH XP Pro loaded (EBAY store) and with an integral Parallel Port, and run 65 KHZ pulse streams all day. It also reduces jitter running at the higher pulse streams. Most loss of steps comes from running the motors outside their torque-RPM range rather than missing steps. We all accept the fact that steppers lose torque at a non-linear rate based on RPM. They start to stall (lose steps) once the torque curve crosses the RPM curve of the motor. Evenly spaced pulses can effect that curve slightly but it's still the physics of the motor and drive that have the most influence.

You should not have to take the pulse width on Gecko drives above more than 5us. We set all of them at 2 us. We go thought hundreds per month. Going to Sherline Mode makes the pulses wider but it just masks the base problem.

The G540 uses the G250 drives and the pulse width problem occurs on a few of those drives. The pulse width setting in MACH is global so it affects all axis.

Pulse polarity is important too. Set wrong and it can cause poor stepper performance.

If you have a G540 or the G251 drives and you have to run in Sherline Mode to keep from having position problems then contact Gecko. If you can slow down the velocity and acceleration and the problem goes away (without changing step pulse size) then it's not a driver pulse issue.

There are background processes in XP that can cause pulse jitter (or actual "ticks" in the pulse stream. If you have a NIC (network card) enabled but not connected it can cause a pulse stream tick everytime it polls trying to find a connection. There are other things running that will cause parallel port timing issues. Video (toolpath) refresh can be an problem on slower machine with integrated video controllers.

While the SmoothStepper will solve parallel port timing issues it comes with it's own set of limitations. Your software is no longer in perfect sync with the table position. Anything that relies on real time feedback (threading, RPM , encoder feedback, THC, or repeatable home signals) is not going to work with any serial to parallel communications solution. Not a problem with simple milling (except for the variable home switch timing).

TOM Caudle
www. CandCNC.com
Totally Modular CNC Electronics

Brand new PC, built ONLY to handle Mach 3 and Mach 3 alone. G540 profile came direct from Gecko, I would hope they set their pulse polarity correct for their own drive. Fresh install of XP, never once connected to the internet, never will be. Been building PC's since the 8088, so I know how to handle hardware.
Best guess here is that I need to contact Gecko about my issue, I'm going to run Maris's tests this weekend as well.

[Jeff-Birt]

Your software is no longer in perfect sync with the table position. Anything that relies on real time feedback (threading, RPM , encoder feedback, THC, or repeatable home signals) is not going to work with any serial to parallel communications solution

Well, not entirely accurate. The SS does not just 'emulate' a parallel port. It provides the functionality of two parallel ports (and more) while maintaining the same interface to the user from inside Mach. Mach and the SS are in constant communication so Mach tells it how far to move things and it tells Mach how far it has actually moved. The two are always in Sync (there was an issue about a year ago if you tried to jog while Gcode was running, but that was fixed.)

While Mach can sync axis movements to a spindle tach encoder, it supports no other real time encoder feedback. You can use an MPG with a SS (it even has its own encoder inputs) with no issues. As for threading I believe 'Hood' has been threading with the SS on his lathe for quite a while now. Homing is just as accurate with the SS as with the LPT.

THC and Backlash Comp are not supported at this time. I have heard that backlash comp will be added soon and Backlash comp is waiting on some core changes in Mach (that will the the SS and any other Mach compatible motion control board) make use of Machs backlash comp.

None of this is to say that the SS would help the OP at all. The first thing to look at is the output waveform of your parallel port, you need to see what type of waveform your PC is producing. Unless you know if your input to the drive is OK you can't say whether the drive is working properly or not. One of the great things about Gecko is that they do stand behind their products. I'm sure they will be glad to help you.

For an example of a poor pulse stream of a parallel port and one from a SmoothStepper se post #3: http://www.machsupport.com/forum/ind...c,12174.0.html

[Torchhead]

Well, not entirely accurate. The SS does not just 'emulate' a parallel port. It provides the functionality of two parallel ports (and more) while maintaining the same interface to the user from inside Mach. Mach and the SS are in constant communication so Mach tells it how far to move things and it tells Mach how far it has actually moved. The two are always in Sync (there was an issue about a year ago if you tried to jog while Gcode was running, but that was fixed.)

I would like to understand this better: So the trajectory engine in MACH sends the commands to the SS, it executes and sends back information that MACH uses to establish the actual position? Sounds like a feedback loop to me but maybe I missed something. If it's as realtime as the PP inputs, there should be no problem with supporting other realtime signals. I need to tell the OEM's that have contacted me that their homing results (repeatability) are wrong and they need to use ungraded firmware (?). I guess I am confused (not unusual for an old EE) and my conversations with the SS developer were not understood by myself. Since we do C level development for MACH I am going to have a stern talk with my developer about the whole trajectory engine/latency/feedback issue. It appears he and I don't understand the inputs to MACH sufficiently and need to go back and read the SDK documentation more thoroughly.

TOM Caudle
www.CandCNC.com

[SCzEngrgGroup]

I would like to understand this better: So the trajectory engine in MACH sends the commands to the SS, it executes and sends back information that MACH uses to establish the actual position? Sounds like a feedback loop to me but maybe I missed something. If it's as realtime as the PP inputs, there should be no problem with supporting other realtime signals. I need to tell the OEM's that have contacted me that their homing results (repeatability) are wrong and they need to use ungraded firmware (?). I guess I am confused (not unusual for an old EE) and my conversations with the SS developer were not understood by myself. Since we do C level development for MACH I am going to have a stern talk with my developer about the whole trajectory engine/latency/feedback issue. It appears he and I don't understand the inputs to MACH sufficiently and need to go back and read the SDK documentation more thoroughly.

TOM Caudle
www.CandCNC.com

Tom,

The communications between the SS and the rest of Mach3 is not fundamentally any different than it is between the PP and the rest of Mach3, since both communicate over the same interface. "Real-time" operations, like probing, are handled entirely within the SmoothStepper, so they work just as well as with the PP. Mach3 tells the SS where to move to, and how fast, and the SS handles the details of the move. Mach3 can ask the SS where it is at any given time. SS *does* already do threading just fine on the lathe. There is no "feedback", and it is certainly not any more or less "closed loop" than the PP.

Regards,
Ray L.

[Jeff-Birt]

I would like to understand this better: So the trajectory engine in MACH sends the commands to the SS, it executes and sends back information that MACH uses to establish the actual position?

I stated that poorly. Mach send the SS movement commands from the trajectory buffer and the SS executes them. Same as if Mach sent the LPT driver a command. For a closed loop-operation the SS would have to receive encoder signals from the motors and know what to do with it (it does not do this) OR be sending S/D signals to a drive that closes the loop.

The point I was trying to make is that the communication between Mach and the SS is most definitely two way. That is what allows the SS to execute home commands, do probing, etc. It is by no means a 'dumb' form of LPT emulation.

[Torchhead]

The point I was trying to make is that the communication between Mach and the SS is most definitely two way. That is what allows the SS to execute home commands, do probing, etc. It is by no means a 'dumb' form of LPT emulation.

I never said the communication was not two way (send/receive). What my misunderstanding was was about where MACH thinks it is versus where the machine really is...aka communications latency. The parallel input read is done in a defined time slice. The pin states are read at a specific interval that provides a predictable latency.

Look, I probably posted this on the wrong forum because the issues faced by someone running a tabletop mill are minimal compared to bigger machines and complex operations that need lower latency inputs. If you can get the steps to the drivers and move three axis in coordination then that is 90% of the battle. I also know that table top guys like things compact and easy to move so using a laptop as the controller PC is attractive. That approach is different than what we suggest for shop tables and multi-function tables is noisy environments.

TOM Caudle
www.CandCNC.com

[Torchhead]

Tom,

The communications between the SS and the rest of Mach3 is not fundamentally any different than it is between the PP and the rest of Mach3, since both communicate over the same interface. "Real-time" operations, like probing, are handled entirely within the SmoothStepper, so they work just as well as with the PP. Mach3 tells the SS where to move to, and how fast, and the SS handles the details of the move. Mach3 can ask the SS where it is at any given time. SS *does* already do threading just fine on the lathe. There is no "feedback", and it is certainly not any more or less "closed loop" than the PP.

Regards,
Ray L.

Ray: Now I'm more confused. If the communications are the same then why does the SS have to close the probe in the hardware?

Are you saying that MACH reads the parallel input signals one at a time (serially)?

I know you can look at any pin on any port but using an external dll you have to operate within MACH's time slice to run external programs. Can I get better response talking back across USB and through some API interface to MACH that is faster than the 40 CPS loop?

If the input gets there at a different rate/time does that not effect the point at which it "sees" the condition? Are there any numbers on the repeatability of the Homing; how close to the same point does it stop over multiple home (ref) moves? Maybe I am just concerned over something that has a value so small it can be ignored.

The THC logic functions in MACH are as close to a true feedback loop (closed loop) as you can get. The overall "loop" timing is critical (i.e Software has to know where hardware is so correction moves don't cause massive over/under shoot in the motion).

Once again for desktop mills it's a non-issue.

I apologize for posting in the wrong forum. (wrong)


TOM Caudle
www.CandCNC.com

[escott76]

I never said the communication was not two way (send/receive). What my misunderstanding was was about where MACH thinks it is versus where the machine really is...aka communications latency. The parallel input read is done in a defined time slice. The pin states are read at a specific interval that provides a predictable latency.

Look, I probably posted this on the wrong forum because the issues faced by someone running a tabletop mill are minimal compared to bigger machines and complex operations that need lower latency inputs. If you can get the steps to the drivers and move three axis in coordination then that is 90% of the battle. I also know that table top guys like things compact and easy to move so using a laptop as the controller PC is attractive. That approach is different than what we suggest for shop tables and multi-function tables is noisy environments.

TOM Caudle
www.CandCNC.com

I'm not using a laptop, and although this discussion is interesting, it's not in the right place. If you want to discuss the issues that your techs have programming code for products you sell, please seek a more appropriate place to do so. If you are unfamiliar with "the issues faced by someone running a tabletop mill" as if that really makes any difference in this context, why are you telling me what will work and what won't? I was looking for people who have experience running two specific pieces of hardware together, not a diagnosis of my issue, and not an exploration of THC, and how the SS talks to Mach. I appreciate the willingness to help, but we are veering far off course from the question I asked in the first place.

To everyone else, I have run the tests outlined by Mariss in the thread that was posted earlier, namely removing sherline mode, setting a pulse width and running the axis at a given speed. According to that thread, this should demonstrate if any of the drives have an issue. Thus far none of the drives in the particular G540 that I own show these symptoms.
Setting up the scope is next, but I doubt highly that this will show anything, as it's only during long programs with many small 3D moves will cause any issue. Power supply is more than up to the task.
Again, I'm back to the machine creating clean pulses as the issue, and before I drop the coin on another board I specifically want to find out what people's end user experience are running the two items together. With all due respect I am not looking for a diagnosis of my particular issue. Just people's experience with these items so that I can make an informed decision about a purchase. Thanks.

[Jeff-Birt]

The SS and G540 are like peanut butter and chocolate; two great taste that taste great together. I have been using this combination for about a year now and have sold lots of SS and G540s (as a set) to happy folks. I give them two thumbs up!

[SCzEngrgGroup]

Ray: Now I'm more confused. If the communications are the same then why does the SS have to close the probe in the hardware?

Are you saying that MACH reads the parallel input signals one at a time (serially)?

I know you can look at any pin on any port but using an external dll you have to operate within MACH's time slice to run external programs. Can I get better response talking back across USB and through some API interface to MACH that is faster than the 40 CPS loop?

If the input gets there at a different rate/time does that not effect the point at which it "sees" the condition? Are there any numbers on the repeatability of the Homing; how close to the same point does it stop over multiple home (ref) moves? Maybe I am just concerned over something that has a value so small it can be ignored.

The THC logic functions in MACH are as close to a true feedback loop (closed loop) as you can get. The overall "loop" timing is critical (i.e Software has to know where hardware is so correction moves don't cause massive over/under shoot in the motion).

Once again for desktop mills it's a non-issue.

I apologize for posting in the wrong forum. (wrong)


TOM Caudle
www.CandCNC.com

Tom,

First, Mach rarely asks the SS where the machine is. Mach sends a bunch of move commands, and it *can* ask where the machine is, but I don't believe it does so very often, and certainly not when the machine is moving. Mach and the SS do "sync-up" at specific times, but those times are pretty rare, and only occur under circumstances where Mach cannot know where the machine actually is. For example, when a jog ends, Mach cannot know exactly where it ended, as the command Mach sends the SS simply says "Move that way at this rate". It later sends a "Stop" command, but the SS will decel and stop at some unknown (to Mach) position. When probing, the SS must handle the entire probe operation itself, and report back to Mach when it's done. (Actually, IIRC, the SS "busy" status is polled by Mach periodically) Mach will then ask where it stopped. The USB latency makes this necessary. Otherwise, you'd either have to probe at very low step rates (100s of Hz at best), or live with very innacurate results, and borken probes. Homing is the same situation. But, the vast majority of the time, Mach has its idea of where the machine is, and the SS has it's idea, and the two are, hopefully, the same, at least when the machine is at rest. Mach does not know, nor care, where the machine is at any instant in time, when it is in motion. Mach sends commands to the SS, and it trusts the SS to execute them faithfully. The communications is at a high level, completely divorced from ports and pins. Dealing with ports and pins is a driver-level concern that is handled entirely within the PP driver or the SS driver.

The PP driver is similar - the high-level trajectory planner figures out what needs to be done, and commands the PP driver to do it. It is up to the PP driver to figure out *how* to do what its commanded to do.

Regards,
Ray L.