The Problem:
This memory in this control is measured in meters, meters of punched paper tape. Mine holds 80 meters or roughly 32kb, which is a serious limitation on the size of program I can store on it. Luckily it also came with a tape reader and has a BTR (behind the tape reader) device that interfaces with a PC serial port and emulates the tape reader; this allows you to “drip-feed” a program from the computer through the tape interface. This works around the memory limitation and lets you run any length of program, but it has a major drawback: it’s really slow. This can make a situation where the control can’t read in the next line of a program before the current one has completed, resulting in jerky movement as the machine will pause until the next command is ready. This is like driving with GPS navigation that is so bad that you have to stop after every turn to get the next one. You’ll know it when it happens, you can hear it, see it, your surfaces will show it, and your cutters hate it.
Identifying the bottleneck
There process starts on the computer. I’m using DNC4U to send programs through a USB serial adapter to the BTR, which is connected directly to the tape reader port on the control board. The control reads each character and line, calculates the motion, then tells the servo drives to execute it. Here’s what I’ve got:
- Computer: some old laptop, plenty fast
- USB-Serial adapter: cheapest one on amazon, seems great
- BTR: “Gateway V4”. Running at 4800 Baud on the serial side, don’t think this is the bottleneck
- Control tape interface: This is the problem, it seems that it runs at the speed of a paper tape reader (slow). This post suggests 300 characters per second
- Control processing: capable of running the same program without issues at high feed rates, so this isn’t the issue
The key problem here is the relationship between the speed that a line can be read by the control to the feed rate and length of the previous line. Long moves or canned cycles where the physical motion takes longer than reading the next line are no problem, but short movements are a problem. This is particularly bad if you have surfaces or curves that are composed of tiny line segments.
Example
I did an experiment using two short programs of .005″ moves: the first program had very short lines like this: “X.005; X.010; X.015;” and so on; the second had relatively long lines like this: “G01 X0.0050 Y0.000 Z0.000 F100.;”. I set up a dial indicator so I could easily see the motion and used the feed rate override knob to find the point at which it went from jerky to smooth. What I found was that the program with short lines could run smoothly at about 1.6 inches per minute, and the longer lines only ran at .5. Since the only variable is the character count on the lines, I am able to determine the relationship between the line length and read time.
Strategies
- Reduce the feed rate: this works, but has a serious drawback. If your program has a mix of long and short moves, decreasing all moves to a feed that is safe for the short ones means that all of your longer moves will be unnecessarily slow, potentially adding a huge amount of time. In the graphic above, you would be sacrificing a ton of time (light green) areas in exchange for not starving the control
- Feed rate override: stand in front of the machine, slow it down for the short parts and back up for the long ones. The drawback is that you have to pay attention.
- Reduce the file size: this is a good practice, and the best place to start.
- Remove line numbers
- Remove spaces
- Remove trailing zeroes
- Remove comments
- Remove blank lines
- Use arcs instead of lines: configure your CAM software and post processor to output arcs where possible instead of line segments. The point is to have longer moves in each line, which gives the control longer to read the next one and also can shrink the file size.
- Use the perfect feed rate: using the known read-speed of your control, set the feed rate on every line to the perfect amount so that the control is never starved for the next one. I don’t know if this is a feature anyone has in their CAM/POST, but I haven’t really looked.
So… Finding the perfect feed rate?
Actually this is pretty straightforward. First, figure out how fast the control can read lines and characters. Next calculate the distance traveled for each line in the program, and finally do some math to determine the minimum time required for the control to read that next line and set the speed accordingly. Mission accomplished.
I’m using this as an excuse to try python and create a standalone application for the first time. The project can be found here on Github. I would describe it as a “working prototype” at this stage, and I’ll post again as I get further along. Here’s what it looks like so far:
