Pico Systems Universal Stepper Controller

The Pico Systems Universal Stepper Controller board controls up to 4 step & Direction axes. (The boards can be "daisy-chained" together, if needed, on one parallel port. The EMC driver doesn't currently support this, if anyone needs this feature, let me (Jon Elson) know, and I'll get it working for you.)

Early CD's of EMC do not support the Univ. Stepper Controller. The best way to set it up right now is to use the BDI 4.30 CD or one of the net mirrors with the ISO image of that CD to install Linux and EMC on your computer. I can also provide a complete computer with the proper drivers added to EMC and completely configured for the controller. Linux gurus can download the original source of EMC (not EMC2) from the SourceForge repository and recompile it. This is not for the faint of heart!

This board produces step pulses of adjustable pulse width to control any stepper driver or servo drive that accepts step and direction signals. It can also generate full-step drive waveforms for stepper drivers that take this signal form.

As of June 3, 2005, I have added the SETUP_TIME and HOLD_TIME parameters from the ini file, and made them configure the following: SETUP_TIME sets the setup and hold time between step and direction pulses to a value between 0.3 and 25.4 uS. So, no change in direction can be closer to the step pulse, either before or after. HOLD_TIME sets the width of the step pulse, from 0.3 to 25.4 uS. Note that these parameters apply to ALL axes, and only the parameters in [AXIS_0] are used. The big push for this was caused by a user who is the first one to try the Gecko G202 stepper drive with the USC, and the EMC default step pulses were too narrow to be accepted by the drive. Mariss at Gecko says there is no difference in the drive, but there must be at least some slight change.

This board also has 4 axes of 24-bit encoder counters to read position from incremental encoders, if present. EMC will sign-extend and overflow the 24-bit count to a floating-point value of practically unlimited range in a floating "long" variable, so the 24-bits of hardware counter do not impose a limit on machine size. The digital filter on the encoder inputs limits the encoder count rate to roughly 300,000 counts/second (per axis). If you should need a higher count rate, a simple change can allow this to be increased.

The board also has 16 opto-isolated digital inputs and positions where up to 8 solid state relays can be installed. SSR 8 is turned on whenever EMC is out of estop. Digital Inputs 14 and 15 need to be connected together (15 causes an e-stop, 14 informs EMC whether it is safe to get out of estop or not.) These input pins can be wired through any N.C. overtravel switches, manual E-stop (N.C.) switches and axis fault circuits (again, N.C.) and then connected to the pin marked EG (external ground). When the entire chain is a closed circuit, the green LED will light, and EMC will know it is OK to come out of estop. The other SSR positions are controlled by EMC, and can be assigned in the ini file to particular fucntions, such as spindle, coolant, etc. Some of the digital inputs are assigned by hard-coding to axis limit and home switches.

This board is interfaced to the PC through an EPP parallel port. An IEEE-1284 compliant cable must be used. I have tested it with 2', 6' and 10' cables. I have observed communications errors with a 15' cable, so you should not try to use more than 10' of cable. I have had much trouble getting this board to work with random Taiwan motherboards, due to poor operation of the EPP IEEE-1284 communication mode of certain parallel port chips. I have never had a problem EVER with Dell motherboards. I have also seen the SMC37C665, 37C666 and 37C669 family of chips work fine. The Winbond W83977TF-AM chip on a Supero motherboard has also worked fine when set to EPP mode. The UMC chips have not worked at all, and the timing of the signals clearly demonstrates serious problems with the chip or the integration of the chip to the motherboard. Don't even try with these!

I have also got it to work with the PCI4008A chip used on some PCI plug-in parallel port boards. Watch out for Comp USA, as they sell several different PCI parallel port boards under the SAME SKU number, and they have different chips. The ITE8875F chip does not work. I have also tried the NetMos board and had no luck with that one either.

(I'll be glad to put EMC on a used Dell PC and supply that with the boards to prevent these sorts of disasters.)

One other quirk: On the Dell computers, you have to force the parallel port to EPP mode with the pcisetup program. This is available at http://jelinux.pico-systems.com/codes/pcisetup You would run this from the current directory on the first parallel port with this command :
./pcisetup 378 where 378 is the parallel port's data register in hexadecimal. (Don't enter it as 0x378, this program doesn't have a parser to handle the 'x'.) You have to be root to run this, or use :
sudo ./pcisetup 378

I have a diagnostic program (currently separate from EMC, avaliable for download from the UPC web page at http://jelinux.pico-systems.com/univstep.html , look for "Download Linux Diagnostic Program..."

Again, this needs to be run as root, or with sudo, as it directly accesses the parallel port. First, you want to run it to check if the board can even be seen :
./univstepdiags bus

You should get a report of 15 possible addresses, and the first one should read
Univ. Stepper at 0x10, Ver 1
address 0x20 will be skipped, since this address group is also occupied by the controller, and then addresses 0x30 through 0xF0 will show up as "No Board". If you get all "No Board" or "Unknown" responses, then the communication is not working, the board is not plugged into the right parallel port, or the board was not powered on properly. When you power the board on, the red "Load Fail" light should blink on for about 1/4 second, and then go out. If it doesn't do this, the FPGA did not load its configuration correctly from the serieal PROM, for some reason.

If the bus test has run correctly, then run the communications test : ./univstepdiags commtest

You should get a report like :
1000 cycles completed, no errors
2000 cycles completed, no errors
3000 cycles completed, no errors

Let this run for 100,000 cycles (about 30 seconds) to see if any errors show up. If you have encoders connected, they can cause errors if they dither between adjacent states, so you may want to unhook them. If you get 100,000 test cycles without any errors, you can be pretty confident the computer and UPC board are communicating well.

From the USC web page, you can download a sample ini file which will configure EMC for the USC board. You will still have to set the INPUT_SCALE parameter for each axis to correspond to the number of steps per user unit for that axis. If the axis moves the wrong way when you jog it, change the signs of both INPUT_SCALE and OUTPUT_SCALE. (They should always be opposite signs unless you have encoders feeding back to the USC board). Set the P parameter to a modest value, such as 1000. Hit F1 to power up the servo amps and then F2 to activate the positioning loop.

 You now have to "tune" the (simulated) servo loop!  Mostly, just increase the P term until

you don't get following errors at the highest jogging speed.

The USCIniFile for the USC controller.