Firmware/Software/Documentation, 04/07/2013 =========================================== Firmware V3.0.1 --------------- o Long standing bug that caused non-stop steps with maximum "Kernel Speed" if Programmed Motion ended with Step as last cycle fixed. It was very interesting bug. CENTIPEDE hardware outputs Step/Dir data it receives from Mach3. This data is loaded in the board FIFO by the driver and the board outputs it at the fixed rate fetching from the other end of FIFO. The last Step/Dir data (when motion ends) stay on the boards output until new data received. Dir is logical level, Step is also output from the FIFO as logical level (1 - do step, 0 - do NOT do step.) Stepper motors (and servos with Step/Dir interface) do not make steps on logical levels; they need a PULSE on Step output and they make steps on either rising or falling edge. CENTIPEDE INVERTS Step output in the middle of a Pulse cycle and returns it to normal at the end of the cycle IF STEP output from FIFO is logical 1. If it is 0 (no step) it stays at zero for the entire cycle. Cycle is 1 / Kernel Frequency i.e. 10 microseconds for 100kHz kernel frequency. That means that if there IS step in that cycle on that axis it will output logical 1 for 5 microseconds then logical 0 for the remaining 5 microseconds. At the end of the cycle it will return to 1 if there is a pulse in the next cycle and the entire sequence will repeat. If there is no pulse in the next cycle Step output will remain at 0 for the entire cycle so there will be NO PULSE. That 0 or 1 can be inverted on the output by setting "Active Low" config option for that output in Mach3 configuration if it better suits one's motors so output can be any polarity required for a particular machine. Logical 1 for Step is internal signal, not something that is output to external pins. Vast majority of jobs have a "No Step" as their last data so it was never discovered that I have a bug in firmware. But when one starts STOPPING a running job Mach3 simply stops outputting step data and CENTIPEDE stops with whatever last data it received. In this case there is non-zero probability that that last data will actually have a Step. When this happened last data left on FIFO output will have logical 1 i.e. "Do Make Step". If this happens the long existing bug in the FIRMWARE makes it output NOT one step but keep outputting them every cycle because it sees logical 1 at every cycle. So if one happened to interrupt a job (or job finishes like that by itself) with a Step in last data packet on some axis one will get a constant stream of pulses on that axis with a maximum speed possible (e.g. at 100kHz kernel speed one will get pulses coming at 100kHz.) That would do no particular harm if one has steppers because it is way beyond their capabilities and all he'll have will be high pitch noise from the stepper but no motion. High resolution servos are different and they WILL MOVE as fast as they can, not whine like steppers. This is fixed in v3.0.1 firmware so everybody is encouraged to upgrade. o ChargePump added to the firmware. Works as regular one with configurable 12.5kHz/5kHz, either stops in EStop or keeps running while Mach3 is running. Configurable as usual from Mach3 config. Added to documentation and supported by the new driver, v2.2.1.6. o Hardware Watchdog added to the firmware. Use Mach3 config to enable. Will put hardware in EStop if Mach3/Windows/Driver crashed or system is too busy. Added to documentation and supported by the new driver, v2.2.1.6. o Step Sequencers added on all axes Step/Dir outputs. They can be either activated so Step Sequences will be output instead of usual Step/Dir signals or disabled so outputs will be regular Step/Dir. This is done to allow quick and cheap retrofit for older Bridgeport Series II Boss 6 CNC mills keeping their existing motors and motor drives. They do NOT work with Step/Dir signals because there is no Step Sequencers in their drives. But there is nothing wrong with them otherwise and they are still up to the job if external sequencers are used. So such sequencers are built in the firmware and now one can make an easy retrofit by just disconnecting Axis Drives from existing ZDI board and connecting them to CENTIPEDE-BRK outputs leaving everything else in place. Easy job, probably doable in one weekend instead of long and painful job of replacing everything, installing new motors, etc. And saves lots of money too because there is no need to purchase new motors, drives, power supplies etc. Added to documentation and supported by the new driver, 2.2.1.6. o Overall VHDL code cleanup, removal of some unnecessary logic, better fit, better timing, fixing some potential bottlenecks that could've caused occasional choking for a hundred microseconds or so. Hardly noticeable on actual performance but anyways... ==================================================================== Driver V2.2.4.1 --------------- o THC is now active when jogging with Torch On so "Manual" cutting is possible. o There were some bugs in jogging code that didn't allow to jog on multiple axes simultaneously. This is fixed now so it is possible to e.g. do jogs on Y axis while jogging on X axis. o Limit Switches override works properly now. When Limit Switch is hit Mach3 goes in EStop immediately. Then there are 2 ways to jog off the Limit Switch. First, Manual Limit Switch override can be activated in "Settings" screen that would allow the machine to go off EStop by pushing EStop button. That allows to jog off Limit Switch. Override is cleared immediately once Limit Switch is cleared so Limits will be active again. AutoOverride, if enabled in "Settings" screen would activate override automatically i.e. it will push "Override" button once Limit is hit. Machine will go in EStop but override will be active so it would allow to go off EStop and jog off the Limit switch. Once the Limit Switch is cleared override will be turned off. Second way involves a hardware switch that should be mapped to LimitOverride signal in Ports&Pins config. Limit Switches will be deactivated for as long as the override switch is active. Driver V2.2.1.6 --------------- o Added full Torch Height Control (THC) so it can be used on Plasmas now with all features required for Plasma cutting. Added to documentation. o Added support for all new firmware features. Documentation updated with descriptions, explanations, and configuration advices. o Fixed some long-standing bugs with stopping jobs and other activities (e.g. Homing) by StopCycle button in Mach3. o Overall code cleanup, some speedups and reliability improvements. Documentation ------------- o All new features fully documented -- pin mappings, register bits, Mach3 configuration etc. o Full schematics added to BRK and PCI board manuals, both for older rev.1.0 and newer rev.1.1 hardware so people can learn what's on those boards, make their own extenders/breakout boards and whatever else, repair them if they broke etc. =============================== V2.1.0.5, 07/29/2012 -------------------- o First of all, versions 2.1.0.3 and 2.1.0.4 were skipped. Those were release candidates that didn't make it to the public release. o Occasional Mach3 buffer underflow while Lathe Threading fixed. That caused wrong thread and very slow tool retract when happened. It was system and load dependent so it only happened from time to time and not all systems were affected. o Long standing Homing bug finally fixed. That made _SOME_ setups to stop exactly on the switch trip poing i.e. the final move to clear switches didn't work. Now it should work with any combination of home switches. o Some minor changes to Z-axis / Spindle RPM syncronization while threading. Now it works reliably with 100 PPR timing sensor at all speeds. V2.1.0.2, 06/04/2012 -------------------- o Emergency fix for a bug with Output signals introduced in 2.1.0.1. Mach3 controlled outputs (those mapped to Mach3 signals) were stuck at Active state (LED on) once set to Active by Mach3 and did not return to inactive state once signals have been deactivated. V2.1.0.1, 06/03/2012 -------------------- o Programmed motion in MINUS direction fixed. It caused erratic behaviour with some stepper drives. o Home switches are now disablable. o Added support for reading _ANY_ input terminal state and writing to _ANY_ output terminal with Mach3 GetPortByte() and PutPortByte macros. Just use those macros as you see fit, port addresses are: Terminals 0 to 7 0x30 Terminals 8 to 15 0x31 Terminals 16 to 23 0x32 Terminals 24 to 31 0x33 Terminal 0 is bit 0, terminal 7 is bit 7 in the port byte and other ports are mapped like this to remaining 3 bytes. There is no need to read/write all 4 bytes, just use whatever you need. GetPortByte() will give the actual physical signal state on the BRK Input terminal no matter what it is mapped to (e.g. even if it is mapped to an MPG in Mach3 config you'll get the actual signal value at the moment GetPortByte() macro has been called). PutPortByte() writes to any BRK Output terminal _BUT_ writing to an output mapped to any signal in Mach3 config will have no effect because this particular output will be overwritten with Mach3 signal value before it is propagated to the actual hardware. Other than that it works exactly like GetPortByte(). o Added support for reading all 4 ADC channels with GetPortByte() macro. ADCs are 10-bit and GetPortByte() only allows to read 8 bits so ADC readings should be done as a sequence of 2 reads. First, the lower 8 bits should be read. That freezes the current reading so it is not updated until the the upper byte is read. When it is done that particular ADC channel is released and starts updating again. Full ADC scale is +10V so 0x3ff reading corresponds to +10V. The port addresses for ADC channels are: ADC_0_L_DIN 0x20 ADC_0_H_DIN 0x21 ADC_1_L_DIN 0x22 ADC_1_H_DIN 0x23 ADC_2_L_DIN 0x24 ADC_2_H_DIN 0x25 ADC_3_L_DIN 0x26 ADC_3_H_DIN 0x27 where 'L' stands for a lower 8 bits and 'H' is the upper byte. There is no need to read all ADC channels, just read those you need. But no matter what channel is read you MUST read BOTH its bytes starting with a lower one ('L'). There is no requirements however on ADC channels sequence so if you use several ADC channels you can read those in any order. Just make sure you read BOTH bytes for each channel before reading another one. o Added support for analog output with PutPortByte() macros. There are 2 DACs on the BRK boards. DAC_B is always available, DAC_A is only available when Spindle PWM is disabled. If Spindle PWM is enabled all writes to DAC_A are ignored. DACs work exactly the same as ADCs with 2 byte writes sequences lower byte first. Data is transferred to the DAC on the HIGH byte write. DACs are also +10V full scale so 0x3ff will output +10V, 0 will output 0V. DAC ports addresses are: DAC_A_L_DOUT 0x10 DAC_A_H_DOUT 0x11 DAC_B_L_DOUT 0x12 DAC_B_H_DOUT 0x13 o Driver is no longer called mach3.sys, it is now properly named centipede.sys with corresponding centipede.inf INF file. It will delete older mach3.sys drivers on driver update. V2.0.0.3, 05/12/2011 -------------------- o Last minute changes -- Mach3 timebase was wrong that lead to wrong threads. Fixed. 2 source code lines fix, so it simply replaces v.2.0.0.2 on the website, no 2.0.0.2 code posted. V2.0.0.2, 05/11/2011 -------------------- o Lathe Threading bugs fixed, it works now as it's supposed to. o Minor fixes and changes here and there, some source cleanup. o More information added on setting Spindle Timing/Index (mostly on debouncing settings) to "Setup for Mach3" manual. o No new firmware needed, it runs with the same v2.0.0 firmware. V2.0.0.1, 05/07/2011 -------------------- o Added option for combining Limit/Home switches. Mach3 Setup manual is updated accordingly. o Spindle Index signal state is now properly displayed on Diagnostic Screen. o Machine now moves just off of Home switches on final Homing pass. That makes it come to final stop with something other than all zeroes in DROs but they are setup properly, it is just machine moving PAST zero point on dereferencing move. Zero point is exactly at Home switch hit point. o Information about connecting Motor Drives with braindead common GROUND and separate optocouplers ANODES, eg. Gecko G203V, is added to Mach3 Setup manual. o Some other minor fixes, mostly cosmetic. o No new firmware needed, it runs with the same v2.0.0 firmware. V2.0.0.0, 03/28/2011 -------------------- o Fixed bug with Step Pulse Width that was in v.1.0. Wrong assumption was made when developing v.1.0 -- that width is in CPU CLOCKs, NOT microseconds. It does NOT apply to v.2.0 at all because there is NO Step Pulse width at all in this version. o As a followup to the previous one -- there is NO Step Pulse Width in this version. Step/Dir values from Motor Tuning Dialog are ignored. They were a bad idea to start with because they are NOT per-Axis but one value for the entire system. That means they assumed ALL motors in the system are the same that is not always true. CENTIPEDE will output 50% Duty Cycle pulses on Step outputs regardless of step frequency. As far as we know ALL stepper/servo drives only limit MINIMUM pulse width. They ALL perform steps on a TRANSITION on their Step inputs i.e. when signal goes from high to low or vice versa. That means there is no sence making fixed width pulses as long as minimal width is maintained. So CENTIPEDE makes a transition exactly at the middle of a Step pulse. That has some additional benefits. First of all step happens at the right moment when pulse rate is changed during threading operations. That is not the case with pulses fixed to the beginning of the pulse cycle. Then it will allow to use those pulses (on e.g. Step/Dir Spindle) for controlling those VFD invertors that use 50% Duty Cycle square wave for synchronizing motor RPM. o Full Step/Dir Spindle is implemented. It is a Variable Frequency 50% Duty Cycle square wave generator that does NOT require any software support for its operation at steady speed; it is all hardware. Single register write is only required for starting/stopping the spindle and changing its speed. Ramp up / slow down is implemented so real stepper/servo motors should work fine as a Spindle drives. Step/Dir Spindle can go as high as 1MHz pulse rate if required with no effect on other parts or software. It can go even higher than that up to approximately 8MHz (33MHz PCI clock frequency divided by 4) but it would require special interconnection cable and something other than optocouplers in Spindle motor drive. So 1MHz is a conservative upper limit. o Spindle Index (single pulse per revolution) and Timing (multiple pulses per revolution) are both implemented. Index is required for lathe threading because it is used for starting thread at exactly same spot on each consecutive pass. It is also used for RPM reporting to Mach and for Z-Axis velocity compensation wrt Spindle RPM when threading or rigid tapping if no Timing sensor installed. There is no practical limit on Index/Timing pulse duration al long as it is more than ~60 NANOsecons. Both Index and Timing inputs have independent hardware debouncing. That is implemented as a configurable period of ignoring state changes after some initial signal transition (either high to low or low to high.) That is not actually necessary for hardware if those signals are clean (i.e. they are not from noisy mechanical switches) but they are here anyways. o Lathe threading is implemented with both single pulse per revolution Index sensor and with ADDITIONAL multi pulse per revolution Timing sensor. If both are installed Timing sensor is used to compensate for Spindle RPM changes while threading. This is done by measuring RPM at each Timing pulse (i.e. as many times per rev as how many pulses Timing sensor generates,) comparing that actual measured RPM to the fixed RPM used by Mach for planning and changing kernel frequency to keep constant per-rev feed rate. There is no pulse skipping; it is constantly changing kernel speed that closely resembles manual lathe thread gear feed. Single pulse per revolution Index sensor is used for starting each and every threading pass at exactly the same spot. It is kinda that half-nut engagement lever on a manual lathe. It is also used for RPM measurement and once-per-rev feed compensation if there is no Timing sensor installed. All RPM measurement and clock generation is done in hardware so no software intervention is required. When threading Index pulse is used to start fetching step data from hardware FIFO that is stopped when Mach notifies the driver it is about to start a threading pass. CENTIPEDE driver keeps stuffing step data in the hardware FIFO but they just sit there. At some moment FIFO is full and driver just waits for some room to free to continue moving step data from Mach queue to the FIFO. When Index pulse comes it pulls the hardware trigger and CENTIPEDE starts fetching data from FIFO and outputting steps. There is no software-related variations in this process, it is all pure hardware so the threading pass is started at exactly same spot each and every time no matter what software is doing or how busy the PC is. Maximum variation possible is 1 PCI clock i.e. 30 NANOseconds. Each and every Timing (or Index if there is no Timing Sensor) pulse resets an internal HARDWARE counter that starts counting PCI clock pulses (~33MHz or 30nS). At the same time previous value is transferred to a software accessible register and an interrupt is generated. On that interrupt driver reads that value and makes a simple computation by multiplying kernel clock divisor value (kernel frequency is PCI clock, usually 33.333MHz, divided by that divisor) by this timing value and dividing it by reference value used for thread planning. The result is written to base divisor register thus adjusting feed rate to match actual Spindle RPM. This is repeated on each and every Timing (or Index) pulse as long as Mach is in threading mode. Actual RPM are compared to a reference value, not to a previous sample that makes this process as close to actual physical threading gears on manual lathe as it is possible. There is no pulse-to-pulse error accumulation :) CENTIPEDE can compensate for ~70% spindle speedup at 100KHz kernel frequency. That is limited by Mach ability to fill its step data queue fast enough and ~170KHz seems to be a limit for 2.93GHz CPU frequency. The range is wider at lower kernel frequencies. There is practically no limit for Spindle slowdown compensation. CENTIPEDE will easily compensate for e.g. 5x spindle slowdown. There is probably something wrong with your machine if it slows down THAT much but it will be compensated anyways. o CENTIPEDE Driver does not assume PCI clock is 33.333MHz any more. Actual frequency is measured on driver startup so it always uses the actual value specific for the PC it runs on. That means actual kernel frequency is at least 10e-4 accurate regardless of individual PC variations :) Please note that it makes Windows bootup to stop for ~2 seconds on driver load and Mach startup (after showing initial logo.) o A Homing bug is fixed that sometimes made the machine stop 1 step off of zero position. That was properly reported to Mach so actual position was correct but it was affecting Slaved Axes Homing. Slaved Axes are hooked to their Masters almost all time thus mirroring their movements. The only exception is final Dereferencing move when Homing. That moves Master and Slave Axes to their own Home positions thus squaring the gantry (or whatever.) This bug sometimes made them 1 step off square when one of the axes stopped 1 step off its Home position. o Some small fixes, enhancements, code cleanup etc. o Driver version bumped to 601. o PCI Device ID is changed to 0002 so old driver won't be loaded or installed with the new firmware.