SmoothStepperUSBDriver2.08.02.zip
This driver works on the following operating systems:
Windows Server 2008 R2The 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 essentially the same as the Microsoft WHQL certified driver that is available on the FTDI website (http://ftdichip.com/Drivers/D2XX.htm). 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.
---------------------------------------------------
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.
- 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.