Thanks for the explanation, that makes sense for your setup.

When I mentioned cost, I wasn’t really thinking only about the price of the drives themselves. The hardware can indeed be quite cheap nowadays, especially the Chinese EtherCAT kits. What I had more in mind was the total cost: time spent integrating, debugging, dealing with CiA402 states, homing behavior, synchronization issues, and so on. In LinuxCNC, that complexity is very real, as I’m sure you know.

For my own projects, I’m not looking at EtherCAT as something that would “upgrade” my machine in a practical sense. If I end up buying an EtherCAT drive, it would be purely to learn and experiment with the technology, not because it necessarily adds value compared to a Mesa + step/dir or ±10V setup, which are already very robust and proven.

Also, just to be clear, at this point in my life (I’m 50), I’m not chasing résumé points or planning to change jobs — this is purely technical curiosity and personal interest in understanding the trade-offs better.

Out of curiosity: when you compared step/dir, were you thinking about software step generation / parallel port, or FPGA-based solutions like Mesa? In my experience, that distinction makes a huge difference in terms of performance and PC load.

posting for good luck:

The main motion control signals between the press brake state machine and the hardware interface should be a unified standard within this family of LinuxCNC press brake components.

The idea is to have a standard GUI and press-brake state-machine component, then separate customized hardware interface components for specific machine makes/models. There will also be a simulation "hardware interface component".

The redundant analog velocity and discrete velocity/direction commands are necessary due to some presses use both spool valves and servo valves to set velocity and direction. A press using only a servo valve might not need this component and could likely be connected to a PID just like a servo driven axis. A press using only discrete spool valves (no variable speed control) would allow leaving the velocity command disconnected.

This allows a straightforward command from the state machine to the hardware.

The main control command between the press brake state machine and the hardware interface will be like:
(additional feedback and home-offset pins not listed here)

Type: float    y_cmd_pos "Y Position command";
Direction:    press_state_comp    =>    hardware_interface

Type: float    y_cmd_vel "Y Velocity command";
Direction:    press_state_comp    =>    hardware_interface

Type: float    y_cmd_tonnage     "Y Tonnage command";
Direction:    press_state_comp    =>    hardware_interface

Type: bit    pedal_is_dn "decoded foot-pedal status from state machine";
Direction:    press_state_comp    =>    hardware_interface

Type: s32    motion_type_cmd
Values:        -99 = homing slow up
        -31 = up fast 1
        -21 = up med 1
        -11 = up slow 1
        -1 = pressure dump
        0 = halt
        1 = dwell
        11 = down slow 1
        21 = down med 1
        31 = down fast 1
        99 = homing slow down

This allows easily adding speed states for presses with additional speed selection spools. For example, a press with an additional med-fast down speed would also support motion_type_cmd = 22 “down med 2” On the pullmax_optima hardware interface component I delete the med velocities entirely, as the spool valves on this press do only “fast” and “slow”.

We will need to pass a “list of valid values” for the selected hardware_decoder, to the press brake state machine, ideally via the ini file.

file.ini:
[AXIS_Y]
valid_states = -99 -31 -11 -1 0 1 11 31 99

Something like that. I’ll see what I can do.

The pc is a HP Z400; workstation (quad core xeon with 8 gb memory and ssd). The interface is parallel port with step/dir. G28 moves all axis to machine zero.
I will upload the hal and ini files tomorrow (it's night time overhere). But I don't think that's the problem because it was working perfectly for the last couple of years.

Finally I made a successfull connection of the mesa 7i97t.
When I turn the motor still standing on the table i can see the X Dro increase in numbers to what could be expected in relation to the counts/rev.
Now two things are still beyond my understanding.
1. When I try to jog the axis the DRO only moves 0,18mm when pressing and releasing the < or > key. Same result if I use arrows in AXIS. Jog mode is set to continuous. 
2. When I release Estop and enable the drive F1 & F2 the motor starts rotating at a speed which looks like something that could be1v. 
Any explanations?
HAL file attached 

No, no other errors. Only joint following error.

I don't think LinuxCNC has changed anything basic like this
it's more likely a hardware, wiring, hal, or ini file change.

  thank you for the response, i have an older Dell 980 optiplex with onboard parallel port. the output of lspci shows no parallel port controller and under communications controller is has no i/o ports line in between "flags" and "memory at".
in bios its set to epp and address 378h.
i ran the command cat /proc/ioports grep parports and it showed 0000-0000 : parport0 (twice, one above the next)
so i ran the command sudo cat /proc/ioports grep parports and after enter my password it showed 0378-37a : parport0 and 037b-037f : parport0.
i tested every pin of my parallel cable and its good. im not sure if i need to do something with enable amplifier on pin 1 because i tried it unused, enabled, and enabled active low and i still got no movement. i read somewhere that the kernel may not be reading my parallel port but i am not that savy at this, its been a week or two since i started dabbling in this..
i will attach my .ini and .hal files

I’ve updated and replaced all the Probe Basic Lathe files and copied my configuration into the folder (HAL file, INI, and postgui). Everything is still the same. The bottom part of the screen is cut off (in PB Mill it displays correctly), the on-screen movement arrows don’t work unless I perform a home after referencing the machine, The conversational section doesn’t work, and the default RPM isn’t shown (for example, S500 in the INI file). It’s the same in simulation mode.

I changed the prefix today, and now the machine no longer moves automatically.

I'd like to know why this is happening. The Debian version and the Linux CNC version have changed. I haven't made any changes to the INI file itself.