The Ethernet SmoothStepper uses the Ethernet driver that is already installed on your computer.
Here is the current Ethernet SmoothStepper plugin, which is the software that Mach uses to control the Ethernet SmoothStepper:
- Fixed a bug in the microcontroller code that did not handle Ethernet data retransmissions properly in some cases where the packets were delayed and then burst quickly. This resulted in the communications hanging. This affected very few computers, but even if you have not had this happen you should upgrade to this plugin.
- Added a quadrature output mode for the spindle.
- M10/M11 support for turning THC on and off (untested but should work).
- Exposes the acceleration and velocity parameters for backlash compensation.
- Tests for Mach being in single step mode or not. This affected the reporting of gcode line numbers.
- When reading inputs, fixed a bug where it didn't ignore emulated signals.
The following are older Ethernet SmoothStepper plugins:
A detailed changelog will be provided within a few days from now.
This driver works on the following operating systems:Windows Server 2008 R2
The driver files should be unzipped on your computer. When you plug in the SmoothStepper, point the "New Hardware Found Wizard" to the files, and follow the prompts. To upgrade, plug in your SmoothStepper and find it under the USB devices in Device Manager. If you right-click you should be able to select "Properties", and there will be an option for updating or re-installing the driver. I installed a SmoothStepper on a Windows 7 machine and I was not prompted to point the New Hardware Found Wizard to the new driver files. It tried to find the driver files for the device by searching the Internet and local directories, but it did not find them which would be expected. After it gets finished and says it was unable to find a suitable driver, go to the Device Manager and find the SmoothStepper. Right-click on it and select "Properties". It is there that you should see an option to update or install the driver. Point it to the unzipped files that you downloaded via the link above, and it will install the driver files.
These driver files are a modified version of the Microsoft WHQL certified driver that is available on the FTDI website (http://ftdichip.com/Drivers/D2XX.htm). Don't use the drivers from the FTDI website. I am only mentioning this information for informational purposes. There are two "inf" files that need modification to work with the SmoothStepper. The most important modification is to match the SmoothStepper's Vendor ID (VID) that is programmed into the EEPROM of the FT245RL chip that is on the SmoothStepper board. Unfortunately, this small change invalidates the Microsoft certification, which means you will see a warning when you install the driver. It is OK to accept this warning.
Here are links to previous drivers if you want to use one of them:
An "m3p" file is a "Mach 3 Plugin" file. Once downloaded, double-click the file and it will self install itself as a dll in the PlugIns directory of your Mach3 installation.
Please use the lockdown version or a newer version of Mach with the SmoothStepper. No other versions are supported at this time. There are many functions that will not work with older versions of Mach. Please note that the development version of Mach does not have the same meaning as it has in the past. Very few features are being added, and those features are not major ones. In general, the development version is the bug-fixed version of the lockdown. Aside from bug fixes, a typical feature that would be added is access to internal Mach variables so that an external device (such as the SmoothStepper) can perform threading. Because the SmoothStepper is requiring access to more of Mach than it is currently set up for, you really should use the development version.
Note: When you run Mach and choose a motion control device, there is a box you can check that says "Don't ask me again". Next time you run Mach it won't ask you which plugin you want to use, and it will automatically run the same one. This has caused a lot of headaches for users in the past, so please be aware of it. What you will need to do is reset this option. In Mach, go to the pull-down menus and choose "Function Cfg's". Under this menu you will find an option named "Reset Device Sel...". If you choose this, then next time you run Mach with the same profile it will ask you which device you want to use. A lot of users have banged their heads against the wall trying to figure out why the features of the new plugin weren't working. It was because they weren't running it...    Another note to make is that it isn't a good idea to have more than one SmoothStepper plugin active in the plugins directory. It might be more broad than that, in that you should only have one motion control device plugin in the folder at the same time. I don't know that for a fact but it would not surprise me. For some reason the files interact with each other because Mach loads all of them at startup. The best way to manage plugins is to rename the ones that you are not using. If you change the extension from ".dll" to ".m3p" (Mach 3 Plugin), Mach will leave them alone. If you ever want to reinstall a plugin, simply double-click it and Mach will rename the file from .m3p to .dll.
I recently discovered that changes have been made to Mach that affect PlugIns, and the developers have not been informed of the changes (at least I was not). I am not sure of the extent to which this affects the plugins, but I know that certain variables within the Mach structures are not being read properly. This might not be as big of a deal as I make it out to be, but because I don't know, I am taking a fairly conservative stance until I do know. I have been given the latest Mach Include files, which are essentially a template for the structure of Mach's data structures. This update has fixed the problem I was experiencing. Unfortunately, it is very disconcerting that I do not have any idea when changes were made to Mach that affect the plugins in this way. Along the way, Mach changed in a way that likely breaks previous plugins. I don't know when it happened, so therefore I can't say which of the past SmoothStepper plugins are compatible with the current version(s) of Mach. The only thing I am certain of is that I compiled the latest plugin using the latest Mach Include files and it is compatible with the current development version of Mach (R3.043.050). I am going to temporarily remove the older plugins from the Warp9 server and request that you use the latest Development version of Mach because it is the only combination that I know is compatible. Hopefully I will learn more information soon and be able to restore the older plugins so that they are compatible.
- Fixed Watchdog Timer timeout problem when Mach stops talking to the plugin for an extended amount of time. This typically happens when loading screens or running wizards.
- There have been more changes than this. A detailed list will be provided soon.
- Added support for M10 and M11. These M codes are used for Lasers and Water Jets. The easiest way to describe it is with a link to a discussion where someone has already described it very well.
There are a few differences between my implementation and the way it works with the Parallel Port. Normally the M10 command turns off the output that drives the laser or water jet. I thought it would be better to add a feature that turns off the output when it is not moving. That way you can use M10/M11 when using MDI. M10 works as expected, but you don't need to issue it as long as there is no movement. There is a limitation that Mach does not conveniently provide the M10/M11 gcode parameters to the plugin. I figured out a way to get this information, but I don't trust it 100% so in the end I decided not to use it. Instead, I added a config in the SmoothStepper plugin where you can specify the output number that you are using for M10/M11 commands. If you are switching between outputs during a Mach session, this config value would need to be updated. Please let me know if this is a feature you need. It could be added as a VB call. Another feature I added is the ability to dwell before and after M11 and M10 commands. This is primarily for water jets, where you issue an M11 command and then want to wait for it to pierce through the material. There is a similar option for delaying after an M10 command. These values can be set via user DROs. You will see them on the config dialog of the SmoothStepper. Normally a laser is given a PWM signal for the laser intensity, and another signal to turn it on and off. The S command (spindle) is used to control the PWM value, where max RPM is max (100%) PWM. There may be instances where you only have one signal, which is the PWM signal. Instead of another signal for on/off, the PWM signal may be turned on and off instead. In the SmoothStepper config you will see this option as "M11Px/M10Px Gates Spindle Output". If you check this box, the M11/M10 commands will turn the PWM on and off. The PWM base frequency for the SmoothStepper may be quite high. Typical frequencies for lasers are between 1 and 50 kHz. The higher the frequency, the lower the resolution in the SmoothStepper. I believe that at 64 kHz base frequency, the resolution is 9 bits. At 32 kHz it would be 10 bits, at 16 kHz it would be 11 bits, and so on.
- There is a config parameter to specify how much data Mach pre-calculates. This will affect the amount of time it takes for a Feed Hold or Feed Rate Override to take effect. The only reason for increasing this value is if your computer is a little on the slow side and buffering more data could keep it from running out of data.
- Soft Limits will now work for the A, B, and C axes.
- Backlash compensation has been added. This version works great as long as you do not enter moves that are shorter than the amount of backlash you have. In particular, you will notice this if you use MDI or Step Jogs and you inch towards something and then back off. I am working on a version that will make that work properly.
- 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.
- There was a problem with the version of "include files" that I was using when I compiled the plugin. Brian has sent the latest version and I recompiled the plugin. Version "ogx" has been replaced with version "ogx2".
- FRO can now be made to go as high as Mach allows, since Mach is in control of it now.
- There was a problem with an asymmetry between CW and CCW when jogging. The asymmetry was evident at very low step rates. This is fixed now.
- The debounce filter has been improved. Now its behavior mimics a low-pass filter.
- Offline mode has been added. It saves the machine coordinates before entering Offline mode and restores them upon exiting.
- The Homing routine has changed significantly. The old routine reset the machine coordinates as it progressed through the state machine. It shouldn't do that if the homing routine is also to be used for the Verify command. Verify will perform a home operation, but in the end it will not change the machine coordinates. As long as your homing is repeatable, the Verify routine will let you know if you have lost any steps. If you have no backlash and you're not losing electrical pulses, when the machine comes back to machine zero, it should read zero. I added a feature to limit the amount of distance the machine will travel when searching for a home switch. This feature was mostly for when a slaved axis is de-slaved from its master. You can specify a short distance so that the gantry does not get twisted up. Unfortunately, I don't think the homing routine is working perfectly well yet. The problem is in syncing with Mach. As soon as the axes are de-slaved, there is a tiny adjustment that is made and it should not move at all. I need to dig into this to figure out why this is happening. I have not tested the Verify function, though the code is in the homing routine now. It should work, but it has not been tested. I need to get a new release out, so this is something I can fix for next time, if it needs fixing.
- The ESC key used to cause great pain in the last plugin. It is handled properly now. It does the same thing that Stop does, except for stopping the spindle. Please note that Stop is an abrupt stop, just like EStop.
- There was a bug in limits, where the EStop would not occur in the device. Instead the data was being relayed from the device, to Mach, and then back to the device. This took too long and if the machine was moving rapidly it would overtravel. Now it is trapped in the device and it stops in an instant (or a bit later if you are running it through the debounce filter).
- If you hit a limit switch, you should be able to back off of the limit now.
- There was a bug in the spindle acceleration. It was 8 times too fast, so if you got your spindle working just right you are going to need to tune it again. Sorry about that, but the acceleration is right now.
- If a G28.1 was performed as part of a gcode program, there was a bug in the homing routine that would not permit the program to continue after it had executed the G28.1. That has been fixed.
- There is an option now for de-referencing the axes if an EStop occurs. By default that is turned off, so that it will be the same as it has been. But if you want the axes to be de-referenced, you can check off that box in the SmoothStepper's config and it will do that when you EStop.
- The previous version (not listed anymore) had fixed a couple of bugs related to the timing between jogging and gcode commands, but it created another in the process. This version should fix that. The bug was that a JogOff command could be lost due to a certain jogging variable of Mach being reset at the wrong time.
- Found the bugs that caused the SS to cut the right shape in the wrong place. The problems were in the JogOn and JogOff routines. They did not properly identify when motion was occuring and when it was okay for Mach to sync to the position that the SmoothStepper was reporting. This version also has a watchdog feature in case the device is jogging and the device loses communications with the PC. You can specify how much time may elapse without communication between the SS and the PC without the watchdog timing out. This is in the config screen of the SS. I would recommend a value at least equal to the amount of buffer available. The amount of buffer is dependent on the controller frequency. So at 1 kHz, I would set the buffer for at least one second. At 2 kHz, 0.5 seconds. These are minimums. I would recommend a little more, but it really comes down to how much time you feel comfortable with allowing the SS to operate without communications. Normally, Windows can easily leave gaps in time of about 0.3 to 0.5 seconds, and it would not be unheard of to have gaps almost as long as 1 second. This version will also will stop motion if the data buffer in the device empties when it is not supposed to. This would most likely happen if Windows is taking too much time doing something other than servicing the USB port. This could be a hard drive access (or thumb drives, CDROMs, etc.), or moving a window around, or something like that. If this happens, the plugin might not handle it very well. I will work on that in future revisions. It also might not handle hitting ESC very well, which is due to the code that catches the "FIFO Ran Dry" error. This replaces all other versions due to the potential for position loss in the previous revisions.
- Found the bug that caused the SS to cut the right shape in the wrong place. This plugin was a quick fix, but it should work. Regardless of whether this works well or not, I plan to clean up the whole Update loop code, so it will get fixed soon if this does not. Please let me know how this works. I do not think it handles hitting ESC very well, which is due to the code that catches the "FIFO Ran Dry" error. This replaces version v015ob. The other versions in between are other development versions with diagnostics built in.
- Found a bug that made the plugin behave very badly if soft limits were enabled and they were exceeded. This version replaces v015o.
- Because this new plugin adds a feature that must be tracked in the XML, it is advisable to make a backup of your XML just in case this plugin does not work out for you and you want to revert back to the previous plugin.
- Fixed a bug with jogging in CSS mode. You should be able to jog with CSS enabled now.
- Fixed a bug where a JogOn/JogOff sequence could occur faster than 10Hz updates. Thus it wouldn't see motion had occurred if the whole jog sequence was faster than 100 ms (possible if you lightly tap the keyboard jog key).
- Fixed a bug where the Spindle Mode (Relay, PWM, or Step & Direction) was clobbered in the XML. This happened when no SmoothStepper was detected when the user ran Mach and selected the SmoothStepper. When it exited, it wrote the wrong data to the XML.
- Fixed TrueSpindleRPM when the pulley ratio is not 1:1.
- Fixed bug in debounce. The wrong version of a variable was being used and so it was possible that it applied a debounce when it wasn't supposed to.
- Added code in FPGA to halt motion if the motion data fifo runs dry. I don't think the plugin handles this very well yet, but having the FIFO run dry is not a good thing to have happen. Let's see how this works out and I can make changes. Ultimately, I would like to see it slow down before the fifo runs dry. The fifo running dry is most likely caused by a slow computer or if you are doing something in Windows that is keeping Mach from servicing the plugin and USB driver.
- Added a circuit to halt motion if the plugin fails to communicate with the device within a specified amount of time. The watchdog timeout is specified on the SmoothStepper's config screen, and has a maximum value of 3.1 seconds. Do not set this too low, or it will trip unnecessarily.
- Fixed a bug with homing without home switches. The problem was that of stale data. Mach could rip through all of the axes so fast (because there were no real switches to wait for) that it didn't get a position update in between referencing each axis.
- Because this new plugin has additional features that must be tracked in the XML, it is advisable to make a backup of your XML just in case this plugin does not work out for you and you want to revert back to the previous plugin.
- Threading. What more can I say? It threads! You must use a recent development version of Mach for this to work properly. With threading comes spindle RPM display. Right now the only mode supported is the same as the PP, which is one pulse per rev of the spindle. Assign the spindle index to the INDEX input in Ports & Pins and it will display Spindle RPM. In threading, it will read this value and plan the threading pass based on this value. Once the threading pass has begun, any changes in the spindle speed will change the feedrate by the same percentage. Once the threading pass has ended, the synchronization mode is over and it returns to the beginning of the thread to start again. It would not be terribly difficult to create a mode where the feedrate is always synchronized to the spindle. Every time the commanded spindle speed were changed, a new synchronization command could be issued. This mode would be very useful for saving your bit if the spindle stopped but the feed didn't.
- Soft Limits is finally finished. It operates practically identically to the PP version. The difference is in the speed at which the software operates. In the PP version, velocity updates occur at 10 Hz as it enters the slow zone. The SmoothStepper adjusts it at 1 kHz. In the PP version, it is monitoring the edge of the soft limit at 25 kHz or more. In the SS, it is only monitoring it at 1 kHz. This can be evidenced by what happens when you exceed a soft limit if your slow zone is too narrow or your accel value too low. It will overshoot by the amount it can travel in approximately 1 ms. In reality, momentum will probably carry it further because the motion is stopped abruptly at the soft limit if you do not appropriately set the slow zone or the acceleration in motor tuning. Properly set, it will slow down gradually as it enters the slow zone. Because of the mathematics involved, soft limits reduces the available travel in the axes to +/- 1,073,741,823 steps. That is probably not a limiting factor for anyone.
-GCODE that produced very small amounts of movement with gaps in time in between could get the SmoothStepper confused about whether it was OK for its buffer (a First-In First-Out (FIFO) buffer) to empty or not. I replaced the logic with a new method that can handle this. When the buffer does empty when it isn't supposed to (I often used the words "run dry"), I need to have the SmoothStepper act appropriately. I haven't done anything yet because I had been waiting for functionality that would come with threading. The time has come, but there are a few other things I need to attend to first. For all plugins, you can see if the FIFO ran dry by looking for the status in the SmoothStepper's Config screen. In older plugins, it might not be accurate though if the data burst to the SS was short. My plans are to have the device look ahead, and if the buffer is getting low, throttle back on the consumption of data in hopes that the PC would be able to download more data soon. In the event data never comes, it will become a "STOP" situation and the device will abruptly halt. It has to because there is no more data. Currently it will continue again as soon as more data does arrive.
- Fixed a bug in the initialization of axis position at startup. Forgot about slaved axes.
- There is now support for any combination of 5 encoders or MPGs. In the Settings tab of Mach3 Mill, the "Encoder Position" controls now operate and function properly for the SS. You should be able to transfer the Encoder values to and from the main DROs. This is very useful if you have encoders on your axes and you have an EStop or some other reason for losing position. If you have encoders, you will be able to regain position using these controls.
- There was a bug in homing limits that caused it to home in the wrong direction depending upon the size of the table or where the switches were mounted.
- There is a new output mode in addition to Step & Direction. Some higher-end drives can accept Quadrature. In the Config screen you can select whether you want Step & Direction or Quadrature for the output mode.
-I have identified a bug in the older plugin versions that affects the polarity of Port 2 Pins 2, 3, 4, 5, and 6. I have recompiled the code with this fix, in case someone has been using 13c and are happy with it. Some people may prefer to let other people live on the edge. Some users have had issues running pendents on port 2, and this might be the reason.
- Noise filtering had a bug when it assigned values for MPGs.
- Some motor drivers require the step signal to be in the inactive level in order to go into a low-power idle state. At the end of a move, the SS will now deassert the signal if no steps are taken for about 120 us.
- Fixed a bug where Encoder 1 was not being recognized.
- I recently added code to initialize the DROs to the position Mach was at when it last closed. While I initialized the position in the SS device, I forgot to initialize some of the internal plugin values. This would produce a thunk in the axes at the beginning of homing.
- The plugin did some unnecessary syncing with Mach whenever the device was still. I believe this was causing some minor errors in position.
- Noise filtering is complete. Since this plugin adds data to the XML, I would advise making a backup of your XML before you use it. When you run this plugin, go to the SS Config dialog and read the instructions there.
- If the SS sees a short pulse on the EStop line, it will EStop the device. It also reports the information to Mach, but the plugin did not use the information before. If the EStop does not last long enough for Mach to see it on the input data (which is only sampled at 10 Hz), Mach would not go into EStop. Now the plugin looks at the EStop flag from the device (not just the input pin), and will EStop Mach if it is set.
- If the option to disable menus is selected, the plugin will not try to add any menus.
- Changing the Controller Frequency should have an immediate effect now, though you will still need to restart Mach if a Max Step Frequency is changed. This is max Step Frequency affects motor tuning.
- Incremental probing moves are now functional.
- MPGs assigned to ModIO should work well now. The SS interfered with them before.
- Dwell times should now be honored.
- Removed the obnoxious warning that the dir line for the spindle was assigned to an invalid port/pin.
- The position may be saved and restored between Mach sessions.
- EStop is local to the device. This was implemented poorly the first time around. Having it local means it will be an instantaneous stop.
- The reason for the jump between version 6 and 11 is because there are a bunch of unfinished plugins in between (Expansion Port, Soft Limits, Spindle Sync, and Noise Filtering). I'm working on them and hope to release soon.
- This release fixes a problem with estop being registered improperly in the device. This caused a variety of odd behavior in some installations, but not all.
- This release is all bug fixes. I'm working on the new features release, but there were a few bug fixes that needed to be made first. Please note that this version has changes that affect the XML file. I encourage you to make a backup before using this new plugin.
- The homing routine had a bug where a function was being called incorrectly. Those that have a homing offset, or anyone that had trouble with it zeroing an axis after homing should see that fixed now.
- The plugin did not pay attention to whether a signal's port was a SmoothStepper port (1, 2, or 3). People that use ModBus, or anyone that has a G100 in I/O mode, or uses a port other than 1, 2, or 3 should be happy.
- Spindle output was not working well for most people. I tracked the problem down to the duty cycle of the Spindle step frequency. It was 50%, but the parallel port is much narrower. I modified the SmoothStepper config dialog to include a way to specify the spindle pulse width in microseconds. It may be a fractional amount if you wish (i.e. 4.8 us). This change resulted in an additional tag for XML for Spindle Mode, and another for the pulse width.
- EStop is now registered in the SS for quick response
- Fixed bug in discrete outputs (did not do anything if the signal was negated)
- Removed "Accel Warning"
- When exiting, it disables the outputs (puts them in high impedance) before resetting the device. Just in case the reset circuitry is broken, this will reset the outputs to an inactive state.
- Added a check box in the monitoring dialog to select between the physical or logical representation of the inputs. "Physical" reflects the voltage of the actual pin, whereas "Logical" takes into account whether or not you've configured the input as negated in Ports & Pins.
- Added Port 3 to the inputs in the monitoring dialog.
- Version 005 (not 005a) seems to have some problems, so I pulled it and put up version 004a.  This version is the same as 004 but fixes the negate problem on outputs.