If you use this, do have a close look at your output files and test carefully – there is always potential for disaster and I won’t be responsible for damage or injury.
Here’s a tool to write programs for a Hansvedt MS-4 Foreman CNC EDM. The control reads and writes programs in a .TXT file format. I believe there was a standalone console/computer you could have purchased for programming at one time… but I doubt you’d find one no matter how hard you looked. Programs can be input directly on the control using the keyboard and scroll wheel of course, but that’s no fun.
All of the same functions should be available here as they are on the control. Build your program line by line, then export it to a text file:
There are also a few nifty things included: existing files can be imported, edited, then output again, and there is also a sheet for saving power settings. The spec is based on these three pages from the manual:
Transfer the file using a floppy drive (hah!) or figure out the RS-232 connection. I made this for just one person, but if you happen to find this useful please let me know, that would make my day! Download it here:
Hope this helps somebody, there’s a serious shortage of info on these machines findable by google – not much on discussion boards either. I’m working on a excel utility to write programs for it that can be transferred on a floppy drive instead of programming on the control directly.
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:
Here’s a nifty way to keep track of tools. My machine doesn’t have a tool changer, so I need to remember which register I’ve loaded the offset in the control for each one – basically a fancy sticky note. These are laser cut from formica which makes them pretty durable. Permanent marker works great, but it can be erased if you try hard enough, so they are also reusable. The center punches out to fit over the tip of different size tools; the main exception to that is big stuff like face mills. SVG file is attached below if you want to try this yourself.
