bunch of noob questions

Reinhard wrote:

What affordable hardware is recommended to connect the stepper-drivers with pc?
I'd like Ethercat, but I'm quite sure, that it's too expensive. So what is recommended?
Smoothstepper, UC400ETH, Mesacards, others?

I believe that the Smoothstepper works well, but I have no experience with it, and it doesn't work with LinuxCNC. The ethernet version could probably be made to, with different firmware.
The UC400ETH looks like it might be able to work with LinuxCNC, but as far as I know there is no driver.
Reading between the lines, it sounds like you want to use an Ethernet connection?
The closest equivalent of the UC400ETH that I can see is the Mesa 7i92 . There are three versions, and I don't know what the differences are.
The 7i92 is likely to need a breakout board, so at that point the Mesa 7i76E might be a more sensible choice as it is Ethernet motion controller and breakout board in-one.

If you have an EPP parallel port available then the Pico USC might be worth a look.

If you have a PCI or PCIe port available then the Mesa 5i25 / 7i76 combo is very popular.

What is the fastest encoder resolution, that linuxcnc supports?

All Mesa cards (that support encoder counting) can count encoders at a few MHz. The Pico USC can count as 250kHz.

I have an evalboard for stm32 with ethernet. I'd like to try that as controller board.
Which parts of linuxcnc do I have to port into firmware to enable the game?

if you want a working CNC machine then I suggest buying one of the boards above which has an existing driver and sample configurations.

If you want a project, then the Pluto Stepper driver is a good example of a simple external step generator. it is EPP interfaced, but the principles are the same. The driver is written in the .comp preprocessing language , which makes things rather simpler. (note that much of that file is documentation)

Reinhard wrote:

The UC400ETH looks like it might be able to work with LinuxCNC, but as far as I know there is no driver.

Hm, may be I'm confused. I thought LiChuan is a driver.

Two different things with the same name...

I was referring to a software driver, the interface between LinuxCNC and the hardware, rather than a motor drive.

Reinhard wrote:

Is there some more documentation available for the Pluto-use-case?

We don't actually recommend the Pluto boards any more, they never worked very well. But they are a good example of a simple software driver of the type you will need.

linuxcnc.org/docs/2.7/html/drivers/pluto-p.html is the manual page, but very little of that would be relevant.

LinuxCNC works best with relatively dumb hardware. All the clever stuff like path-blending and acceleration limiting is done in the PC, the external hardware will normally just read a new step-rate every 1mS and write back the steps-made count and possibly the encoder counts.
The LinuxCNC step-generator components take a now position command every 1mS, calculate needed steps, and attempt to make them.

Interestingly it has been found that the Mesa stepgens are more jitter-tolerant in velocity mode, with a PID component in LinuxCNC HAL calculating the required step rate (sent as a linear velocity)

Not related to the post but i have to explain:
I just "thank you" Andy twice, as i read the posts and i admire his way of detailed and coherent explanations, something i lack, i tend to skip a lot.
Thanks, again
Tom

Reinhard wrote:

So the driver is the firmware, that handles protocol and generates the steps?

No, in this case the driver is the LinuxCNC HAL code that takes position updates from axis.0.motor-position-cmd and converts that into the data packets sent to the FPGA or similar external hardware.
If you look at the Pluto drive .comp file you will see that it creates HAL pins called (for example) stepgen.0.position-cmd (pin in float stepgen.#.position-cmd[4]
The values passed-in to the code from that HAL pin are converted to stepper counts and output to the EPP port using port read/write commands. (It might not be so clear, the ,comp file uses write16() which is part of pluto_common.h which includes EPP_WRITE (and friends) from rtapi_parport.h
None of this parport stuff matters much to you, but you might be able to use the read/write functions from hm2_eth

That could work using USB and should as well work for a slow ethernet-connection.

USB is unlikely to work. The USB specs allow multiple-mS response latencies.