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

andypugh wrote:

I still think that bit-banging USB on a P-Port pin in a reatime thread might be better.

It probably would be, but... Turns out it's actually irrelevant. Inside the controller, connected across the FTDI chip, is an ATMEGAsomething microcontroller, which controls the whole mess of L293DD drivers, six of them. (turns out the motors are actually bipolar, so it needs one per motor) What the bizarre program inside says, goes. Making a controller from scratch even for running it directly from parallel port pins involves more trouble than I'm up for right now.

Nevertheless, hey, I got it working as described above. EMC actually moves the head of the machine by exposing fake up-down pins to stepgen and limiting stepgen to the speed the move commands actually get executed at. The problem is now to get it to correctly handle cases where EMC wants to move two axes at once. My python pseudo-driver actually blocks while sending commands to FTDI, which means that unless I halve the speed from the already slow 1mm/s, when moving two axes at once, steps get lost. Nope, there's no way to tell it to move more than one axis in one command, even though there's enough bits in the byte it takes per command to handle that.

I wonder if compiling FTDI with async writes will help, as it may in fact be that the controller does execute them faster than 500Hz and I'm just being stupid. No idea about the actual latency I end up having in this manner.

P.S. I wonder, is there a way to tell stepgen to never, ever move more than one axis at the same time?...

Mihara wrote:

My python pseudo-driver actually blocks while sending commands to FTDI, which means that unless I halve the speed from the already slow 1mm/s, when moving two axes at once, steps get lost.

Blocking is not big problem since you may create internal command queue inside component. You'll loose context switch time which is pretty small (for threads it's less then for regular processes).

I wonder if compiling FTDI with async writes will help, as it may in fact be that the controller does execute them faster than 500Hz and I'm just being stupid. No idea about the actual latency I end up having in this manner.

You have USB limit of 1kHz. ftdi chips may work in two modes: bulk (default) and isochronous.
Bulk mode guarantees delivery but may require retransmission (internally) and don't promise you how long data will travel to endpoint.
Isochronous mode guarantees you that data will be transmitted on next USB timeframe (1ms for Low/Full speed devices, 125us for High speed) but don't provide reliable transmission.
In isoch mode you may get up to 1kHz transmission rate but with possible losses. I don't know what is better - losses or delays in the middle of the transmission.

andypugh wrote:

Can you not just buy a proper controller from eBay?

You'd think I would, however, trusting Russian Mail with parcels is not an exercise I want to repeat unless really, really hard pressed, thank you.

However, now I do have a parallel port, a set of six L293 driver chips, and I'm wondering if I can just connect an input from two different L293 (two motors per axis, you see, and the parallel port only allows me 12 outputs, not 24) to the same parallel port pin and expect both drivers to trigger simultaneously with no ill effects, or do I need more complex circuitry...

andypugh wrote:

Are the ICs socketed? If they are then you could make stand-off sockets to test with. (Or you could just bend up the step and direction legs, but if they break off then there is a problem)

Actually, I'm building a controller from scratch, (thankfully, I can just replace the controller unit without messing with the rest, and go back to the stock controller and software if that fails without actually burning a drive out) and this is the most obvious method available. So now I have a new board with 6 drive connectors (bipolar steppers, each of them, Coil A, Coil A, Coil B, Coil , 6 ICs (to be wired as the datasheet directs, 4 inputs each for a total of 24 inputs), a parallel port connector (which would total 12 outputs, so I need to make one output drive two ICs), and no wires ...yet.

I'm only wondering how to split the output pins properly, now, I'm generally better with software than hardware.

andypugh wrote:

Just wire the two step pins together, connect to +5V with a 1k resistor and connect to the the p-port pin.
Connect p-port 0V / gnd to the 0V of the 5v (you could even use the USB port as the 5V source).

Unless you want to opto-isolate the p-port. If you do then the pins can either share an opto-isolator as described above, or you could run two opto-isolators in series from a single p-port pin. Again use 5V to the opto-high side, and connect the p-port to the low side. P-ports work a lot better with current flowing in than out. That does mean that the optos are active when the port is low, but that doesn't matter at all with step signals, and has a 50% probability of being what you want anyway for direction.

Don't have opto-isolators at the moment, or I'd probably prefer to use them.

The drives want 12V though, which complicates the circuit. The stock controller gets it's 5V from USB and 12V from an external power supply. I'm currently thinking of adding a voltage regulator (looking through my trash for a 7805 right now) to procure 5V from that and use it to power the L293s and also to set their enable pins high.

I'm probably looking extremely noobish right now, but if I am correct, I need resistors to do this too, right?

Here's the schematics I'm ending up with in the end:

i077.radikal.ru/1011/00/8868f77795e6.png

Any disparaging comments?