Pico Systems can also provide very cost effective servo amps compatible with this controller for both brush and brushless motors. See http://pico-systems.com/osc2.5/catalog/index.php?cPath=3 for further info on these products.
This board produces constant-frequency pulses of varying pulse width to regulate the speed and torque of the servo motors. It also produces a direction signal to tell the motor which direction to move in. The PWM frequency is settable by LinuxCNC software. All 4 axes on a specific UPC board will be the same, but if more than one UPC is used, each can have a different PWM frequency.
This board has 4 axes of 24-bit encoder counters to read position from the encoders. LinuxCNC will sign-extend and overflow the 24-bit count to a 32-bit integer and then convert to a floating-point scaled position value. The digital filter on the encoder inputs limits the encoder count rate to roughly 1 million counts/second (per axis). The latest version has switch- selectable digital filter rates, for 1, 2.5, 5 and 10 MHz count rates. The latest version of the firmware also supports velocity estimation by time-stamping encoder counts. The PPMC driver in LinuxCNC 2.5 supports this feature when enabled by a command-line option setting.
The board also has 16 opto-isolated digital inputs and sockets where up to 8 solid state relays can be installed. Opening the circuit to digital Input 15 causes an e-stop. This input pin can be wired in series 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. SSR 8 is turned on whenever LinuxCNC is out of estop. The other SSR positions are controlled by LinuxCNC, and can be assigned in a HAL file to particular functions, such as spindle, coolant, etc. Some of the digital inputs can be assigned to axis limit and home switches, or any other inputs that need communication back to LinuxCNC. The SSR outputs and the PWM generators are disabled in hardware by an E-stop condition, so failure of the CPU or communication with it does not compromise the ability of the system to go to the E-stop condition.
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 also gotten 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. The NetMos NM9805 does not perform EPP mode properly. SIIG PCI parallel ports work well. Also, Dell motherboard parallel ports work well. 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.
First, you want to run it to check if the board can even be seen :
sudo ./univpwmdiags 378 bus
"378" in the above command is the hex address of the parallel port. If the port is at a different address, enter that address instead.
You should get a report of 15 possible addresses, and the first one should read
PWM Controller at 0x10, Ver 3
address 0x20 will be skipped, since this address group is also occupied by the PWM 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 serial PROM, for some reason.
If the bus test has run correctly, then run the communications test : sudo ./pwmdiags 378 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.
The LinuxCNC distribution has a set of sample configuration files which will configure LinuxCNC for the UPC board, look in sample configs for univpwm. You will still have to set the INPUT_SCALE parameter for each axis to correspond to the number of encoder counts per user unit for that axis. If the axis counts the wrong way when you move it, change the sign of INPUT_SCALE. Set the P parameter to a small value, such as 100. Hit F1 to power up the servo amps and then F2 to activate the positioning loop. If it runs away, hit F1 to stop motion. Edit the ini file and change the sign of OUTPUT_SCALE from 1.0 to -1.0 (or vice versa) and try again. It should now attempt to hold position, and roughly follow the commanded position when you jog slowly. You now have to "tune" the servo loop!
There are two components of this, one is Halscope, a part of LinuxCNC's Hardware Abstraction Layer. It is brought up from the settings menu in either the Axis or TKEMC screens of LinuxCNC. Once you've gotten the halscope working on the X screen, you can then click on settings, and start the calibration menu. In Halscope, you probably want to put ppmc.0.encoder.00.delta and pid.00.error on the channels to display, and trigger the trace on the delta signal (which is the instantaneous velocity derived from the encoder.)
Make a jog move, then check the Halscope display to see how small the error is.
The IniFile for the PWM controller.
Tuning the PWM controller with Pico Systems PWM servo amplifiers.