Mesa Card Basics

It'd be ok for driving the steppers and some extra outputs and 5 inputs. Really depends on how inputs you need.

That's the common "Mach 5 axis" breakout board (BOB)
that's compatible with 7I92t_5abob.bin firmware.
It does have 5 inputs

 

quite new to mesa and llinuxcnc myself, few doubts retrofitting an older machine
all 3 axis + spindle are all AC servos that use resolvers for feedback, does this mean I can use 7i49? and can I use its 10v analog to control the motors respective drives?
moreover, I've seen it elsewhere paired with 6i24 fpga, but online ive seen variants of that with 16, 24 and 50 pins, how does this affect my usage? are these related to I/O pins?

If the resolvers go to the drives(and this would be expected for AC servos),
the drives themselves have the resolver interface, so a 7I49 is not needed.
What hardware is needed to interface to the drives themselves depends
on what interface modes the drives themselves support.
 

Hi,
some more questions from me:
Assuming using a 3D probe with one signal to use (NC or NO does not matter to me). How is this handled inside a Mesa Card? Is it just read and then put through to linuxCNC and then LinuxCNC is reacting on this saying "stop"? How does LinuxCNC knows where it is? Or is there some kind of interrupt going on and the fpa itself is stopping the movement and "sending" back some information to LinuxCNC how much steps it did to reach this position?
How fast is the Data Transfer through ethernet? And isn't it a problem for the probe process itself when the Card does all the stepping stuff? How does LinuxCNC knows how much steps have been done?
regards Han

Things like probe inputs are sampled at the servo thread rate ( typically 1 KHz )
by LinuxCNC's motion component. Typically probing ( and homing ) is done in
two steps with a higher velocity search motion followed by a lower velocity latch
motion. You would normally choose a latch velocity low enough that the 1 ms
(max) sampling uncertainty causes a minimal position error when probing.

Mesa hardware does have the capability of latching encoder or stepgen counts
at probe activation, but this is currently not supported by LinuxCNC.

HI PCW,
thank you for your Answer!
But for a better understanding. How is the communication between LinuxCNC and the Card done? With the LPT "communication" the LinuxCNC software gets a command to go 3mm in X direction, so "itself" sends the pulses on the LPT in the (hopefully) correct speed.
Does LinuxCNC still sends "pulses" when it has a mesa card and the card only corrects the jitters? Or is there some kind of communication so that LinuxCNC just sends go 3mm in that speed and the card does the pulses? LinuxCNC then know how long it takes for that movement and after this time it send the next command.
With the second approach it would probably be really hard to do something like probing.
Thanks !

All LinuxCNC motion hardware is real time so as I said the only limitation is that the accuracy
of some operations like probing and homing without using index is limited to velocity *
servo thread period (usually 1 ms). This is typically not an issue because the final velocity can be quite low
as the distance covered by the final latch move is small.

On Mesa hardware, the stepgen is a digitally controlled rate generator. At ever servo thread
invocation (typically 1000 times a second),  LinuxCNC reads the current stepgen position
from the hardware and compares it to the actual commanded position and makes corrections in the rate 
to keep the step generation in sync with LinuxCNCs commanded position. This typically
keeps the external step generation within a small fraction of a step of the commanded position.
 

Thank you for the explanation.
Just for a short conclusion in other words. LinxCNC "works" together with mesa HW like a "closed loop regulator". Linux "controlles" the executed steps donbe by mesa in the servo thread and corrects if necassary?
If this is the case I can estimate the error during milling and probing.