Is EMC the software I need, or should I look for s

Hi. New guy here.

I happen to have a (pretty basic, but hard to modify further) CNC machine. It contains 6 stepper motors (2 per axis) and a controller board which presents an FTDI 2XX chip to the outside world, a USB device. The software it comes with is, pardon the term, a piece of feces, written in Visual Basic, which I simply don't find usable -- while it can do everything the machine can do, it's very crude. Looking around the net, I have found that EMC2 is the place to go for CNC in the open source world.

But EMC, as far as I can see, is the easiest to set up when it comes to driving motors from parallel port pins, which, in this particular case, is out of the question.

After a few hours of reverse engineering and some minor swearing, I have been able to write a Python script which uses libftdi to run the machine -- it moves nicely along each axis in 0.002mm increments by sending a byte into the port to move the motors one step per byte sent, and requires a few initialisation commands to get the FTDI chip to properly start up. It's now a problem of somehow patching that into EMC, so if anyone would be so kind as to answer a few questions for me, it would be very nice:

1. Is EMC the software for me, or should I look for something else entirely? After all, driving the machine in this manner is far from realtime. If EMC is not it, what would it be? A searchstring to google for would be quite helpful.
2. I have looked at the HAL documentation and it seems to deal mostly with directly driving motors anyway, while the access I have to the hardware limits me to telling it which axis should be stepped in which direction, and it will do the actual stepping of the motor by itself. Am I missing something? Is there an example of a HAL component for working with similar hardware anywhere that I could study?
3. For that matter, can I get away with writing the component in Python starting with the script I have, or will I have to use something else?

I don't know what's in it (yet) but I suspect that the controller board contains nothing but the FTDI chip itself and an L293 quadruple half-H driver (or possibly two of them, since every axis drives two motors in parallel... well, I'm not an engineer), so it's probably not impossible to rip it open and try to run the L293 directly from parallel port. However, I would prefer not to do it, because this is not a unique device, that's the way it comes from the manufacturer, (even though it's an obscure one, it's the only device readily available around these parts for hobbyist purposes) and I would rather write a driver people could just plug in and go.

Just how realtime does realtime need to be? The machine has no sensors, just steppers, which step at a fixed speed and can't really go faster, so as long as my driver reports where it thinks the motors are and ensures it doesn't send commands faster than they can be executed, why exactly should it be problematic?

Failing that, ok, if not EMC, what else?

According to my examination the native software does the following:

1. Finds the FTDI chip by directly addressing it's Windows driver with it's DLL, resets it and puts it into bitbanging mode. (For some reason, it doesn't start out in one even though it's supposed to have an EPROM in it) FTDI can actually report a latency timer of some kind, but the native software doesn't care.
2. Hooks a control function into the timer tick that fires every 50 milliseconds, i.e. at 20Hz.
3. When motion is commanded by the G-code interpreter or manually, the control function calls an interface function that sends data to the FTDI chip: 0b10000 for X, 0b100 for Y, 0b10100 for Z (huh?), ORs it with the 0b1 to invert direction. OR with 0b10 for every other step. Each step moves the axis 0.002mm. ...Once that command is sent, the interface function adds a delay by counting up to 200000. The drives appear to work completely identically without that delay, it's there for speed control -- as far as I can see if the timer tick doesn't interrupt it, the function will keep moving the drive in an infinite loop until it does. I might, of course, be horribly wrong, but...

When the command is received, drives move, which I've been able to replicate perfectly, so it's mostly a question of figuring out what sort of pins exactly does EMC expect from a HAL component that handles it's own stepping, and why, and whether I can provide it. I'm pretty sure I can do better than what is described above.

The native software doesn't know (or want to know) what state the drives are in and gets no input from them. (But I happen to have a Velleman K8000 which I might try to use for homing switches later...) It actually has a G-code interpreter and stuff, but it's extremely painful to use.

andypugh wrote:
Is an example of a python userspace component that creates HAL pins. You could do something equivalent in your script then hook the EMC movement commands to that.

Actually, that's what I've been reading up on for the past few hours, this seems like the way to go, at least initially, to see if I can get any practical result. What I don't quite understand is how should I interpret the EMC movement commands, which pins they go out on and whether I need to keep track of the coordinates internally.

I don't expect that it can make it into the tree, but nothing stops me from putting up a LiveCD pre-setup for the machine.

andypugh wrote:
The Pluto driver is a good example, and is written in "comp" which is the friendly way to write hal components. Just don't buy the actual Pluto hardware.

Thank you. I expect there's no other documented work of similar nature anywhere? Well, there's the Arduino USB driver in Python, but it doesn't expect to control any axes, so while it plainly shows how to expose pins to HAL in Python, it doesn't answer my question of what to do with the motion commands and what format to expect them in.

Your drives sound basically horrible. It is unfortunate that you have two motors per axis, as that will double the cost of changing the drives, but I would be looking hard at things like

The drives really aren't that bad by themselves, I expect, it's the software and the stock controller. But I'm not up to making a controller from scratch right now, and, there's people out there using the device as is with good results, might as well try helping them while helping myself. If I were up to building a machine from scratch, I'd be reading the RepRap instructions right now, but since this one ended up in my hands for a time, (actually, my father wanted it, and I'm the non-mainframe-IT guy in the family... so now I'm the one stuck getting it easy enough for him to use) I'm thinking of using it to make the component parts for one. Before I can do that, though, I need to make it work in a non-painful fashion.

You mentioned that there is not much to be found where you are. Might one ask where you are?

Russia. Which makes ebay really not a very good option because my local post office passionately hates me.