*I have received quite a few emails from people requesting help with Anilam Crusader M machines. I no longer have this machine (replaced this one with a Deckel FP2NC Dynapath), so my ability to help others troubleshoot is now limited.
Last year (2010) I bought a CNC vertical knee mill, to help fill out the shop’s needs. It was a late 80′s, early 90′s era machine (as best as I could tell) with an Anilam Crusader M controller. The machine seemed to work fine, although once I got it home and started poking around, I realized it needed a new spindle. It took me some time to source a spindle, but removal of the old, and re-installation of the new spindle was relatively easy. Once that was taken care of, I discovered that the variable speed spindle was badly worn. I decided to face the VS varidiscs on the Monarch 10ee lathe, manufacture a new set of bushings from Delrin, and machine a new shaft for the bushing and lower varidisc to slide on. After that, I began learning to program the controller.
Not having had much prior experience with CNC equipment, I was surprised that the controller was relatively easy to program, using the conversational control. Later, I learned that there are some subtleties to programming which have great impact on the parts that are made on the machine. One of the biggest lessons was learning how important it is to properly ramp off of the part, when turning cutter compensation on and off. I don’t remember all the mistakes I made, but I do remember believing that I was performing the programming operation correctly, based on the manual, when in reality I was missing a few key steps. I had a variety of odd results, from little chunks milled unintentionally out of parts, to the machine table wandering all over kingdom come.
After gaining some functional skill in programming the mill, I designed some adjustable bicycle dropouts using Alibre 3D modelling software. From there, I wrote programs for the 5 different parts that went into making a set of dropouts using coordinates from Alibre Design, and writing/organizing programs in MS Excel. I hand entered the programs, and revised them on the machine. I asked my wonderful wife to come out to the shop and help me transcribe the programs once they were finalized. The process was pretty slow going, but I could produce the parts that my imagination developed, which was very satisfying. I used these parts to build a few bicycles, for myself and others.
Recently, I have been trying to establish communication between the Anilam Crusader M controller, and my HP laptop. The goal is to be able to transfer programs on and off the CNC machine, and to utilize CAM software to help make toolpaths. I know that this will help me make better parts, with shorter time between drawing the part to having the finished part in hand.
I initially began by purchasing a premade RS232 cable, supposedly specifically for this controller, to go from an expresscard/serial adapter at the laptop, to the db25 plug on the back of the Anilam controller. I followed the instructions that were supplied with the cable, cross-referencing the instructions with my Crudader manual, but nothing I did appeared to transmit data from the CNC machine to the laptop. In fact, there was so little happening that I didn’t have any idea where to start – I wasn’t sure what was working, and what wasn’t. There was very little information on the internet that clearly described the problem solving strategy, though I did find a page on the B&B Electronics website to be very handy for understanding RS232 cables.
So I decided to employ my own problem solving strategy: start with what you know and work down. I knew that the controller itself seemed to work, but I didn’t know if the controller’s RS232 communication from the CNC controller was functional. I called Jerry at Anilam technical support (which is actually now run by Heidenhain I believe) who described the self-testing procedure:
1)At the back of the controller, at the DB25 plug, jumper pins 2 to 3, 4 to 5, and 6 to 20. I jumpered them using some 14 gauge insulated wire I had around. I poked the ends of the insulation with a small brad first, so that there was a little pocket for the pin on the plug to sit in.
2)Turn on the machine
3)Pull out the E-stop.
4)Press the “Manual” button on the control panel.
5)Type “Aux 2740″, then press “Start”.
If the machine then says “Aux 0″ in the area where you initially entered “Aux 2740″, the machine’s RS232 communication is functional. If instead, in the right corner area of the display, it flashes “Dsr/dtr fail” or “duart fail”, then the CNC controller’s communications system is not operating correctly. Note: the test will fail if the plug is incorrectly jumpered.
In my case, the machine tested as working.
I then moved on to make sure that the PC laptop end of things was working correctly. I found a piece of great software, Terminal v1.9b. This software can be used to perform a loopback test on the computer. By jumping the same pins (on serial terminal) as on the CNC controller (or their functional equivalent on a DB9 plug – see the page on B&B electronics webpage listed above), you can send a message from the transmit field in Terminal v1.9b, and see it loopback into the receive field. This shows that communication is operating correctly at the PC.
So if the CNC machine’s RS232 port is working, and the PC’s RS232 port is working, then the only piece of hardware left that needs checking is the cable. In my case, the cable that I bought specifically for my machine, didn’t work. So I went to the local electronics supply store, Norvac Electronics, and bought a female db25 plug, a male db9 plug, 30 feet of insulated 10 wire cord, and the plug housings to go over the plugs/wire. I bought the nicest plugs and housings that they had, and still my 30′ cable cost around $20. The cable I initially bought for the machine was around $50, only contained 3 wires, and didn’t work! I definitely recommend building you own RS232 communication cables.
I invited over my friend Teryk, thinking that two heads were better than one. Teryk is a software guy (and a fabricator), but he’s also good to work with when troubleshooting things.
I initially wired the cable up based on the assumption that I was working with a DTE machine on the DB9 end (the computer) and a DTE device on the db25 end (the controller). This combination of devices should utilize a crossover cable (see B&B webpage). When I did this, and then set the parameters on the Crusader controller, and then tried to transfer data from the controller to the computer (viewing the data via Terminal v1.9b) I received some data, but very little in the receive field. I also noticed that green lights on the CTS, DSR, CD and RI buttons in Terminal were flashing. That gave Teryk and I the idea that perhaps the cable had been wired incorrectly. We decided to map out all the wires in the cable to their respective functions, and compare that to what was on the actual control board in the Crusader M.
We opened the controller up, and found what is known as the “green board” which is PCB523. On this board there are two plugs: one going to a ribbon cable, and one that goes to the RS232 cable. We pulled the board, and saw the labeled functions for the different wires. We wrote those down, the color of the wires that they were attributed to, and followed those out to the DB25 plug. From there we determined that what we had was essentially a crossover cable contained between the DB25 plug of the machine controller, and PCB523. So when we used a crossover cable from the laptop to the control, we were effectively “crossing over” a crossover cable. This meant that the actual wiring of the setup was all screwed up.
DB25 RS232 Plug configuration for Anilam Crusader M CNC Controller
We decided to rewire the cable from the computer to the controller. Teryk stated that it would also be possible to use a crossover cable, but then switch the wires to the plug on PCB523. The decision to just rewire the cable from computer to controller in a straight configuration was based on the concern that the plug at PCB523 might be brittle, and if we damaged it, it could be time consuming to fix. After rewiring the RS232 cable in a straight configuration, we tested sending data from the CNC control to the laptop, and sure enough, when Terminal (the program) was set to the same settings as the CNC control, and we clicked to see the data as “string” (not “hex”), G-code was clearly visible coming through to the laptop! High-fives were had. Having Teryk there to go over the situation was very helpful, and he was instrumental in working though the problem.