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 (same as quadrature) for stepper drivers that take this signal form. Step pulse rates of 300,000 steps/second per axis are easily achieved. Step pulse timing will be much smoother than software generated steps.
The HAL parameter ppmc.0.stepgen.00-03.pulse-width-ns sets the width of the step pulse in nanoseconds, so 3500 would be 3.5 us.
The HAL parameter ppmc.0.stepgen.00-03.setup-time-ns sets the minimum delay between the step pulse and a change in the direction signal in nanoseconds, so 10000 would be 10 us.
Both of these parameters can range from 200 to 25400, and they apply to ALL axes on that board.
This board also has 4 axes of 24-bit encoder counters to read position from incremental encoders, if present. LinuxCNC 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 Input 15 is reserved for E-stop. This input pin 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 LinuxCNC will know it is OK to come out of estop. The other SSR positions are controlled by LinuxCNC, and can be assigned in the config files to particular functions, such as spindle, coolant, etc. Some of the digital inputs are assigned by the config files 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 never had a problem EVER with Dell motherboards.
I have also got it to work with the PCI4008A chip used on some PCI plug-in parallel port boards, and with SIIG PCI parallel ports. The latter may have a configuration PROM on board that needs to be set for EPP mode using their DOS utility. Contact firstname.lastname@example.org for more info on this procedure. The NetMos 9805 parallel port chip does not perform EPP mode properly. SIIG PCI cards work, but SIIG's PCIe card (and others that use the Oxford OXPCIe952 chip, such as Startech and Rosewill) do not work. The Syba PCIe card with the NetMos 9900 chip works fine.
(I'll be glad to put LinuxCNC on your Dell desktop or Intel D525 motherboard.)
I have a diagnostic program (currently separate from EMC, available for download from the USC web page at http://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
First, you want to run it to check if the board can even be seen :
sudo ./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. Make sure your BIOS settings for the parallel port are set to EPP mode. 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 serial 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.
Included in the LinuxCNC distribution is a default configuration 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 USCHalFile? for the USC controller.