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

Mihara wrote:

Thank you. I expect there's no other documented work of similar nature anywhere?

The Hostmot2 stepgen driver does much the same thing.
git.linuxcnc.org/gitweb?p=emc2.git;a=blo...e3f5aaaddfb4;hb=HEAD
But that is written in C and is a little harder to read.

Basically your module would need to accept position commands and feedback where it thinks it has got to. It could optionally take timing parameters. That basically involves an internal count of current position, to be compared to the newly-commanded position. That is then converted to a step frequency request based on the assumed time that the function will next run. I guess there is then some correction applied for the actual time that the function next runs.
If you write the realtime module in comp then you can just use the predefined variable "period" for the calculations (it returns the time in nS since the function last run). The fact that EMC2 works in nS and the existing driver works in 20mS slices might tell you something...

The drives really aren't that bad by themselves, I expect, it's the software and the stock controller.

My impression is that they run at constant speed? That is very bad, as it means you can't cut curves.
If the drives can run at variable speed then I withdraw some of my criticism.

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

We seem to have a fair number of Russian users, and at least one developer/contributor. There may be more equipment available than you think.

Mihara wrote:

Upon further meditation, it appears to me that the simplest possible way to do it would be to connect my userspace python script to software step generator pins, pretend it's a type 2 stepper, and expose "up" and "down" pins for every motor, translating them into a command sent to the FTDI to do pretty much the same thing,.

It's an interesting idea, but I don't think the timing will work. Your userspace module would have to "watch" the step pulses all the time, and if it misses one (as a userspace program is almost certain to do) every few seconds then the machine will drift away from where you think it is.

I think a realtime component that has 3 "position-command" pins is a better idea. That can stop and start all three sets of drivers as required. Typical update rate with EMC2 in the servo thread is every mS, which should give you acceptable dither.
Starting the motors from stopped straight to a fixed speed seems like a really bad idea, though. I am amazed it works at all. EMC has careful rate-shaping that this driving scheme will throw away.
Actually, perhaps not. At 1kHz servo thread, the commands are more likely to be "move this time, not this time, nor this time, ok this time" aren't they?

Mihara wrote:

I think a userspace driver has a good chance,

I still think that bit-banging USB on a P-Port pin in a reatime thread might be better. A servo-thread function could assemble the bytes to be sent into a buffer and a base-thread function could squirt the bits out as USB signals on a P-Port pin straight to the drive.

psha wrote:

disclimer: My view may be too optimistic and far from reality

It seem that FTDI chips are affordable soultion to low-speed bitbanging. I've digged Linux USB documentation a bit and it seem possible to create simple "realtime" component (yes, I hear voices about USB and realtime ) using async communication with FTDI chip (so we won't stuck in rt thread for a long time even if communcation is long).
I hope that 1ms latency is enough for transmitting single byte.

I have spent the last week or so working on an EMC2 realtime component that runs once a millisecond and copes with handshaking/timeout that can take 500mS. The way I am doing it is with a state machine that checks inputs/outputs, changes state if it needs to, and then exits. Something similar might work here.

I suspect that the FTDI hardware is effectively realtime. The bit of wire between the computer and the drive is. If you can do realtime USB at the EMC2 end then the "USB isn't realtime" argument isn't true.

A 1ms Servo thread and a 20uS base thread can send 50 bits per motion cycle with reasonably good timing. Do you know what the actual bit pattern on the physical wires needs to look like?

(Edit)

I have just realised that the post above was from psha (all you Russians look the same from here).

Also, p-port bit-banging can't handle even the slowest USB speed so is a non-starter unless the FTDI chip can be pesuaded to work at a different rate to standard.

psha wrote:

Bears, vodka and balalayka? :-P

CNC-machined, nested, wooden dolls
Actually, I wonder just how many levels you could get with a CNC lathe and the right wood?