I still have not seen anyone 'pushing the SmoothStepper', so the phrasing of the question seemed odd to me.
What about the slaved axis homing?
Slaved homing has actually worked for quite a long while now. Depending on how you had you machien set up, how the home sensors were configured etc you could experiance some problems (clunking as the axis de-slaved was one of them). The homing sequence has been completly redone the last couple of months and it seems to be working very well according to the feedback on the SS forum.
Here is a list of recent changes from teh downloads page of the Warp9TD website:
2011-01-19 PlugIn: SmoothStepper_v17bd.zip
- Optimized USB data packets so that data is transmitted without delay.
- Homing changed from gcode movements to jog movements. Max Homing distances needed to be removed from the options.
- Homing is very accurate now. A variability in the timing was removed.
- Trajectory data from Mach was optimized to reduce the time for Feed Hold and Feed Rate Override to take effect.
- The Verify function was implemented, though it does not operate the same as the Parallel Port driver. To operate the same will require a change in Mach. Verify for slaved axes needs to be modified since it does not report both axes (TBD).
- SwapAxis is implemented now. Please see
http://machsupport.com/docs/Mach3_V3.x_Macro_Prog_Ref.pdf. Page 97 of the PDF (91 of the document) shows the documentation for SwapAxis. ResetSwapAxis is on page 70.
- "Current Hi/Low" is now functional. This output will be asserted when the device has been idle for a few seconds. It's purpose is to put motor drivers in a low power state.
- A bug was discovered in the routine that receives data from the device. If the data is corrupt, the software would get into an infinite loop. This should never happen when using the Bulk mode of USB since the protocol implements CRC checks and data is retransmitted until the CRC check passes. But it happens with the FTDI driver when heavy amounts of noise is present.
- Pin validity checking outputs friendlier text in the pin descriptions. Several bugs were also identified and fixed in the routine. The software cannot catch every problem, but it can find some. For example, if you define an output on Port 5, it can't catch that because that could be a valid setting for another I/O board.
- Added an option to suppress warnings about suspected pin violations.
- Issues with STOP and ESC were cleared up. In particular there was an issue with a warning about the "SmoothStepper ran out of data in the middle of a move" when the Stop button was pressed.
- Spindle RPM is calculated and set only if the Index input is enabled and assigned to a SmoothStepper input.
- Considerable changes were made in the FPGA. To the user most of these changes will not be evident, but this is where most of the changes took place. Most of the change was a result of the new pulsing algorithm without the hysteresis.
- The motion should reach its commanded position now. In previous designs, hysteresis was built into the step & direction signals. If a direction change occurred, the hysteresis would prevent the step from being output too close to the direction change. This resulted in an offset of up to one step. Error was never accumulated, but could be off by one step at any time. The new plugin has a new method of ensuring setup & hold times are met without the hysteresis.
- Fixed a bug in the debounce circuit. When a new threshold was written, the current count was not being reset.
- For what it is worth, the drive current from the FPGA to the USB chip was doubled.
- A bug was fixed where the motion could speed up briefly when a home or limit switch was asserted.
- Filtering of the USB chip's control signals was implemented. The data lines are read multiple times and operation will not continue until it two consecutive reads are identical.
Backlash comp is being worked on now, there has been quite a bit of chatter about it on the SS forum as well. I would suggest looking there for updates.
Guest
Show Posts