Centroid CNC control sales, service, training and support
The following are summaries of various tech support issues I have been called upon to solve in recent years. It is my hope that these may help others more quickly resolve related problems. Be aware, however, that many different problems can have superficially similar symptoms.
A customer using (Linux-based) Intercon version 2.64 reported that Intercon was not automatically reloading their conversational programs when they returned to Intercon after Posting.
Normally, when you create a new program, or load an existing one, and press F10/Post, Intercon includes comments in the G code file which allow it to locate the source ICN (conversational) file in the future. Thus if you have an Intercon-generated CNC program loaded, and you return to Intercon (e.g. F5/CAM, F1/ICN), Intercon will load the conversational file for that program and present it for editing.
It turns out that this feature fails if your part program name includes space characters (e.g. "My Part" instead of "MyPart").
In general, your life will be easier if you do not include space characters in your program names. You can use underscores or hyphens if needed (e.g. "My_Part" or "My-Part").
A customer with a small lathe called. His control is a T15 with the Aaeon PCM6890 (PC104-bus) motherboard and DOS-based control software version 8.23.
He had begun getting increasingly frequent startup failures. The motherboard would boot up and start the CNC7 software; CNC7 attempt to initialize the CPU7 board and would fail with the message "Timeout: 64180 not responding".
That message generally means that the PC-based CNC7 software was unable to get a response from the main processor on the CPU7 board (across the card bus: PC104 in this case, ISA or PCI in other cases).
I had him unplug the wired devices from the CPU7 (jog panel and encoders) to see whether an external device might have been interfering with CPU operation. That did not appear to be the case, which left the CPU7 and the motherboard itself as possible causes. I lent him a different CPU7 board; with that board in place the problem continued. He then obtained a used motherboard assembly from Centroid. Even with the replacement motherboard and CPU7 in place he still had startup problems.
Finally, he decided that the pin engagement in the PC104 bus looked too shallow, and trimmed about 1/16" off of each of the 1" hex standoffs that separate the CPU7 from the motherboard. With the shortened standoffs the control started up and ran fine, even with his original CPU7 (he did not report whether he tried swapping the motherboard back).
This was a new one to me. There are between 1200 and 1500 PC104-based Centroid controls in the field, generally with the same pin dimensions. This is the first I have seen startup problems positively attributed to pin engagement. There has been some variation in the use of plastic washers over and under the 1" standoffs; it is possible that this customer's control was assembled with thicker washers in both positions.
A customer with the TT1 tool detector called to report that his TT1 was intermittently failing to detect the tool tip on contact. In all cases he had stopped the move before overtravel damaged the TT1.
He had an older TT1 which had been damaged by overtravel several years previously (failure to plug the unit in). He tried using that unit on the same cord, and it seemed to detect okay. Thus we suspected the problem was internal to the newer TT1.
Centroid was skeptical of that. The TT1 is a simple continuity device, with direct contact between the plunger and the inside end of the cord plug (both isolated from the base). There are no wire connections inside. It would be very unusual for it to fail to make contact, short of major mechanical damage (e.g. due to a crash).
Further testing and inspection proved Centroid right. The problem was in the cord, which had been stressed and had broken at the back of the plug pin. This connection is covered by heat shrink. The heat shrink was holding the wire together so that it made intermittent contact.
In order for the TT1 to detect the tool there must be continuity from the socket on the side of the TT1 to its plunger; and there must be continuity through the cord from pin 5 of the black AMP connector to the single pin which plugs into the side of the TT1. These components can be tested independently with a multi- meter. The cord can also be tested using the PLC Diagnostic display on the control (Alt-I). The probe input (often INP15, but see Machine Parameter 11) should close (turn green) whenever the cord is plugged in and its tip is touched to the machine table or frame.
A dealer called to report that one of his customers, after replacing a failed motherboard in a ca. 2005 M400S console, had gotten the "This demo control has expired" screen on startup.
That message normally means that the time-limited demo mode on a new control has run out, and the permanent software unlock codes (specifically the overall unlock in Parameter 298) have not yet been entered. It can also appear if the Centroid CPU board is swapped out, because the unlock codes are keyed to each individual CPU board.
In this case, however, the customer still had the permament unlock codes in place (as they had been for several years) and had not changed the CPU board. He had replaced the PC motherboard in the console, but had reinstalled his original Centroid CPU10 board.
In order to verify that there had not been an unreported CPU10 change, I asked the customer to check his system key by pressing F2 at the "demo expired" screen. This should ordinarily display the 9-10 letter code for the system key on the CPU board. In his case, it just said "error - press a key", indicating that the control software was unable to retrieve the system key from the CPU board.
To make a long story short, it was ultimately found that the customer had plugged the IDC connector from his jog panel into the CPU10 board's "JOG" header backwards. Most such IDC connectors are keyed to prevent this, but evidently he received one with no key. The crossed connections between the CPU10 and the jog panel evidently suppressed the section of the CPU10 which holds and reports the system key, among other functions. Fortunately it appears that no permanent damage was done. He reconnected the jog panel correctly and everything resumed proper operation.
Customer e-mailed to report intermittent "436 servo drive shutdown" errors, also intermittent "410 _ axis position error" and "411 _ axis full power w/o motion" stalls. The stalls could occur on any axis. Sometimes the machine would run for a while without errors; other times they could not even home the machine after power-up.
The first thing to try in this situation should always be cleaning the servo logic power supply connections (see http://www.cncsnw.com/ServoLogicPM.htm). In this case, the customer had already cleaned the connections, but the problems continued.
Next he inspected the supply itself (a Toko supply with the alternate Revolution AC connector: see http://www.cncsnw.com/Drives.htm#SERVO1) and wrote:
"It looks like the Toko logic card on the back of the servo drive is cooked. The center of the card is black and a couple of the solder points are melted and floating. Can we replace this card?"
I supplied a replacement power supply, with the appropriate plugs. Since the replacement supply (a MeanWell PT45B) had a different mounting hole pattern, I provided some wire ties and 1" self-adhesive anchors to secure it to the back of the drive. An adapter plate with both hole patterns would have been better, but there was not time to fabricate one. Four 1" wire tie anchors should be sufficient to hold the supply board in place for many years, as long as the surface is cleaned with alcohol before the anchors are applied.
With the new logic power supply in place, the machine homed and ran with no further errors.
I agreed to upgrade a 2003 M400S control (originally DOS-based) to the newer Linux-based CNC10 software.
The console originally had an MSI MS-6368 motherboard, 1.2GHz Celeron processor, and 64MB memory (http://www.cncsnw.com/motherboards.htm#MS6368). The motherboard and processor were sufficient for running the current Linux and CNC10 software (v2.64 at the time of this upgrade), but the 64MB memory was inadequate.
I plugged a 512MB PC133 DIMM into the second DIMM slot, leaving the original 64MB PC133 DIMM in place.
I then removed the old flash card (solid state hard drive) and plugged in one containing CNC Linux and CNC10 v2.64. The boot process hung up at "booting the kernel...".
I then tried a flash card containing CNC Linux and CNC10 v2.38 (which uses an earlier Linux kernel). This time it proceeded further, but hung up randomly at several different points in the process: once after "freeing unused kernel memory...", once while starting up the X Window system, once while initializing USB support, etc..
I then removed the 64MB DIMM and moved the 512MB DIMM into the first slot. Both Linux versions booted up and ran fine. I completed the upgrade with version 2.64, and had no further problems.
I had thought that PC133 DIMMs of different capacities would be compatible with each other. That turned out not to be the case.
Customer with 2007-model Uniconsole M400 (see http://www.cncsnw.com/Fieldguide.htm#M400_2002) called: machine was running normally, then quit abruptly. The machine stopped and the screen went blank.
They cycled the power and got a "no signal, going to sleep" message on the LCD display. This indicates that the LCD monitor has power (and therefore that the MATX supply in the console is turning on and putting out 12VDC) but that the PC motherboard is not booting.
The original console motherboard was an MSI MS-7253 (http://www.cncsnw.com/motherboards.htm#MS7253). I stopped by Fry's on the way down and purchased a Gigabyte GA- M61PME-S2P motherboard, Athlon 64 X2 processor, and a pair of 1GB DDR2/800 DIMMs.
On site I powered up the control and found that it initially booted okay. However, the CPU temperature reported on the CMOS Setup screen rose steadily every time I rebooted and checked it. Initially it was 115øF to 120øF, which is normal for these consoles. After 10 or 15 minutes of power-on time, though, the temperature had risen to 150øF. The CPU cooling fan was running, but evidently not keeping up. I tried reseating the fan, but the temperature continued to rise beyond acceptable limits. The console then locked up, and when I cycled the power it refused to boot at all.
I installed the new motherboard with new CPU and memory, powered back up, and tested the system. The new CPU stabilized at around 50øC (122øF). While a little higher than I would like, it showed no signs of rising farther and so should not cause any problems.
I reminded the customer to check and clean the console cooling fan filters frequently.
A customer with an original style M39 pendant (as shown in the first picture on http://www.cncsnw.com/FieldGuide.htm#M39) wrote to report the following:
"The M39 Pendant on our Milling Machine is starting to give some trouble with a few of the buttons. The Y-axis positive jog button and the X-axis negative jog button do not always move the table. Also the .0001" increment button for the pendant hand wheel is also not activating when pushed. Pushing the buttons either lightly or with some force does not work. The only way the three buttons will work is the "squeeze" and hold the pendant with the fingers of your hand just to the left and below the X-axis negative jog button."
I was not available to look at it on site, so I had him ship the pendant to Centroid for evaluation and repair. Not unexpectedly, they found that the inner circuit board had started to separate from the jog keypad board, causing intermittent contact for some of the keys. They plugged the boards securely together and put adhesive on the plugs to keep them there.
This one could have been fixed in the field, but if it were it would ideally have required a new overlay. In this style pendant, it is only the overlay (the self-adhesive plastic sheet with the keys printed on it) that keeps the keypad in place and seals out contaminants. If you peel it up to access the boards (or the emergency stop pushbutton) then you need to clean the mating surfaces thoroughly and either apply a new overlay, or reinstall the old overlay with suitably strong and thin adhesive.
The machine is a 2006 Atrump E320, with a 16-station umbrella- type tool changer, M400 AC-servo control, and Linux CNC10 control software v2.61.
Customer reported that tool change sequence stopped with carousel in, gripping the old tool. The fault message was "9015 ATC UNCLAMP TIMEOUT".
After clearing the carousel using the manual override button on the pneumatic solenoid valve, I had him try removing and inserting a tool using the manual tool release pushbutton. This worked normally, showing that the tool release cylinder was working fine. I had him press Alt-I for the PLC Diagnostic display and highlight INP23, the tool-unclamped switch. We found that INP23 remained Red (open) even as he removed and inserted tools with the manual pushbutton.
Further investigation showed that the tool-unclamped switch had physically come loose: one of its two mounting screws had fallen out, and the switch was hanging down at an angle. As a result, the trip tab on the drawbar cylinder never closed the switch even after moving full stroke.
One the switch was secured back in its correct location the machine once again changed tools without error or incident.
Customer had two Revolution mills: a 1997 model with the old M40-style console, and a 1998 model with Revolution's console and the updated jog panel. Both were still running CNC7 version 5.27 software.
The hard drive failed in the older machine, and they had no backups. Their IT person copied the contents of the newer machine's hard drive onto a new drive and installed it in the older machine, in place of the failed drive. The computer booted up okay, but reported "Spindle drive fault detected", and of course would not home. There was no fault code displayed on the spindle drive.
The spindle drive fault message was due to differences in PLC logic. The older machine with the M40 console used the PLC program "MX0-I3.SRC", suitable for a machine with an RTK2 PLC, spindle inverter, three axes, and the M40-style jog panel. The newer machine used the PLC program "M400.SRC", suitable for a machine with an RTK2 PLC, three or four axes, spindle inverter or reversing contactors, and original M400-style jog panel. Because M400.SRC was intended to work with reversing contactors as well as an inverter, it required a normally-open spindle fault signal (the only auxiliary contacts available on the contactor overload, after the normally-closed contacts are used to interrupt the coil).
Even if the customer had changed the inverter's fault wiring over to normally-open contacts, there would have been several other problems with the PLC program because of the different jog panel key layouts. There also would have been numerous problems with Control Configuration and Parameters, as in general configuration and parameter values are machine-specific.
I e-mailed backups I had taken from the failed machine in 1998, plus an updated PLC program and a few supporting files. These got the machine back up and running correctly.
The customer did well to get a replacement hard drive working with a copy of the software from the other machine. However, that was only half the job. The other half is to have on hand a configuration backup from the target machine, so that correct PLC programming, configuration and parameters can be restored.
Note that the Utility -> Backup -> CFG feature in version 5.27 and earlier does not do a very complete job. It picks up Configuration and Parameter settings, but it does not back up several other important files. If you are still using v5.27 and want to make complete backups, you should copy the following files from the CNC7 directory, using a DOS command prompt (Ctrl- Alt-X):
You should also copy any *.SRC files from the C:\PLC directory. One of these will be the source file from which your PLC program was compiled, and so will be valuable if you ever need to modify the PLC programming.
Control is a 2005 M400S, with the DC3IO servo drive/PLC unit.
Local technician called:
This appears to be a fairly cut-and-dried case of a blown output on the DC3IO. The main concern is whether it was caused by an intermittent short in the servo motor or motor power cable. The last several tests indicate that the motor and cable are okay. We will send the drive to the Centroid factory for repair and return.
It would be nice to have a clear indication of why the Y axis may have blown, but there is no smoking gun here. The machine is a Series II Bridgeport with quill drive, so Y is the most heavily-loaded axis.
Once the repaired drive is in place I will have him re-run the Drag test on that axis (and preferably on all three axes) to see if something is binding or dragging to cause excessive motor load.
Three months later, with a replacement DC3IO unit in place, the customer has had no further problems. He has not yet found motivation to re-run the drag test.
Copyright © 2010 Marc Leonard
Last updated 18-Apr-2010 MBL