Reverse run on BeagleBone Black

Maybe. But reverse-run seems better.

The BBB problem is easily addressed simply by using something else

Andy and the original poster are right as without reverse run EDM will not work, but this is true always for sinker EDM, wire EDM can make do (and they did for quite some time ) without it.
It is unreasonable not to have it, even if it can work without it, as it will save a lot of time and effort to make proper parts.
And as Andy said before, get a normal PC, usually it is cheaper than the BBB.
What type of signalling does the power supply provide ? A digital pin when there is a short or an analogue out depending on the current ?
The second version is much harder to configure properly, but after that it never needs reverse run during normal work.
The first version does not work without reverse run.
Etc....
Tired.... need sleep badly

Bosston88 wrote: I found where hal_init sits in LCNC: src/hal/hal_lib.c and hal_xinit in MK: src/hal/lib/hal_comp.c. I'll give it a try to add this function in hal_lib.c, but will it work...?

It's not going to be easy. The HAL engines in both Machinekit and LinuxCNC diverged quite a bit over the years after the fork and now the Machinekit one is quite reworked (with the multicore and instantiable components support, new HAL objects and whatnots). These Init functions are just tips on the icebergs and you will find yourself quickly in a rabbit hole.

The saner approach is to rewrite the actual PRU driver (however I think it uses constructs like ring buffers, so you probably will have to bend the logic).

Tower wrote: It's not going to be easy. The HAL engines in both Machinekit and LinuxCNC diverged quite a bit over the years after the fork and now the Machinekit one is quite reworked (with the multicore and instantiable components support, new HAL objects and whatnots). These Init functions are just tips on the icebergs and you will find yourself quickly in a rabbit hole.

Components written with .comp look exactly the same, though. (Not that the BBB drivers fit into that class)

I asked the hal_pru_generic author for his take on this:

"My guess is it would be dramatically easier to get the hal_pru_generic
driver running on LCNC vs. merging reverse-run into Machinekit."

Bosston88

What are you using as a power supply?

Where do we stand on reverse run if not using a beagle bone?
I found this on youtube:

andypugh wrote: Components written with .comp look exactly the same, though. (Not that the BBB drivers fit into that class)

That's true, but COMP is precompiled sublanguage. I think that it's there for backward compatibility reason as it was superseded by the ICOMP (instantiable components) and now is considered pretty much obsolete.

It probably has something to do with Michael Haberler's idea of not differentiating RT/USERSPACE components but RT/nonRT threads (which cannot be done under RTAI).

andypugh wrote: I asked the hal_pru_generic author for his take on this:

"My guess is it would be dramatically easier to get the hal_pru_generic
driver running on LCNC vs. merging reverse-run into Machinekit."

Well, that's it then. I would take Charles Steinkuehler opinion. He seems very competent.

BTW, is reverse run branch changing code run in RT threads or it is all in higher parts?

Tower wrote: BTW, is reverse run branch changing code run in RT threads or it is all in higher parts?

I don't know for sure, but I am pretty sure that reverse-run hooks in to the adaptive feed mechanism, and that is (necessarily) in the realtime layer.