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.
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.
- 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.