Reverse run on BeagleBone Black

Hi,
I’m in process of building wire edm machine where I’d like to use LinuxCNC as an interpreter/controller. One of the features this kind of machine needs is a reverse run (possibility to do a step back in Gcode). The platform I’d like to use is a BeagleBone Black with a custom cape. I’m aware of branch “feature/reverserun_master2” of LinuxCNC, however, there’s no HAL libs for running on BBB. On the other hand, there’s a Machinekit which is crafted for BBB, but there’s no reverse run feature. My intention is to customize LinuxCNC reverse run branch to run BBB PRU’s GPIO or to add reverse run feature to Machinekit. A couple of last weeks I worked on both and I did some progress, however, things are not fully functional and that’s why I’d appreciate help from you guys. Here’s a summary of my work up to now:
- Machinekit with reverserun:
I compared work of Rob here:
github.com/LinuxCNC/linuxcnc/compare/mas...e/reverse-run-master
And implemented these differences in Machinekit build. Some of the things had to be changed because some of the functions/structures have changed compared to LinuxCNC. I can build from source, Machinekit runs, but when changing adaptive-feed pin value < 0 in Axis program freezes and even when pin value is changed back to a positive value nothing happens… There’s also an error in terminal: USRMOT: ERROR: command timeout.
Here’s the link to my fork of Machinekit with changes: github.com/bosston88/machinekit

- LinuxCNC reverse run with BBB drivers:
Using guidelines for RPI:
wiki.linuxcnc.org/cgi-bin/wiki.pl?RPi3BPreemptRT#buildhalgpio
I’ve built from source reverse run branch on BBB, added hal_bb_gpio libs to hal dir, changed Makefile in src dir and added a function in rtapi to be able to open /dev/mem with root privileges. After a few changes I was able to compile and with simple hal commands I’m able to blink with user leds. When it comes to running a demo gcode it seems that reverse run works – changing adaptive-feed < 0 changes direction and when changing back to > 0 program runs forward (ran in axis_mm.ini).
Here are files I changed and uploaded to BBB: github.com/bosston88/Linuxcnc.RR
Now I have a couple of questions/requests.
- Is there someone who could have a look at code for Machinekit reverse run? After many trials I simply have no idea what goes wrong…
- Is hal_bb_gpio fast/reliable to use it for the generation of steps signals? What step rate can be achieved?
- Looking at PRU files it seems that there will be a chunk of work to do to implement it to LinuxCNC reverse run. Does it make sense to start with that? Will it work with LCNC?
I hope that this work can help many other users who are wishing to implement a tiny SOC for their EDM, WEDM, plasma cutters etc.
Many thanks,
Pawel

EDM mashine uses the JOG.speed to get the feed stoed so the wire can move more efficent
you can control this by comp as the Voltige dropps like a THC component

as the Voltige goes up then the feed is enable or upspeed
you can drop the feedrate to zero and rise by given MUX numbers as on travel length

PhillC has a current master build with reverse run on this thread.
forum.linuxcnc.org/plasma-laser/35449-another-plasma-component
So just get his branch, compile from source and ignore his plasma component. Then fold back in you RPI components.

Wire EDM can most probably work without reverse run, it just needs to have the feed rate controlled by the current value, more current=less speed and vice-versa.
Lately been thinking of building a wire EDM as definitely when precision is required, nothing beats it.
Now i need to find a way to get some wire, to heavy so i can not order it through friends as usual, lugging 15 to 20 Kg is not something they do for fun !

Bosston88 wrote: - Is hal_bb_gpio fast/reliable to use it for the generation of steps signals? What step rate can be achieved?
- Looking at PRU files it seems that there will be a chunk of work to do to implement it to LinuxCNC reverse run. Does it make sense to start with that? Will it work with LCNC?

It is probably less work to make the BB_gpio and pru drivers work with LinuxCNC than to make reverse-run work with Machinekit. (But I might be wrong about that). The reason I think that is that the drivers interface at the HAL layer and that hasn't significantly changed. Drivers are inherently modular.

rodw wrote: PhillC has a current master build with reverse run on this thread.
forum.linuxcnc.org/plasma-laser/35449-another-plasma-component
So just get his branch, compile from source and ignore his plasma component. Then fold back in you RPI components.

Thanks for that! I'll definitely look at his build.

@tommylight
It's not even about current, but a voltage in the gap. The closer the electrode is to workpiece the lower the voltage. When short occurs controller needs to reverse at least a bit. In old controllers without a reverse run when short occurred and lasted e.g. 20s machine was shutting down. I still would like to reverse and continue work.

@andypugh
I have bb_gpio running - just copied a couple of files and modified Makefile to compile them. But after searching it turns out that max rate I can get from it is around 5kHz... For G0 movements it's really low, however, for WEDM cutting is enough. Today I played with pru drivers - copied *.so files from Machinekit build to my reverse run build, but it turns out that in the meantime they added at MK functions like hal_xinit (hal_init in LCNC), so when I try to run in halcmd "loadrt hal_pru_generic" I get "undefined symbol: hal_xinit"

I found this on MK github:
"A legacy component so far was initialized by hal_init("compname").

An instantiable component is initialized by the new hal_xinit() call, which takes several parameters besides the name. To be instantiable, a component MUST export a constructor function. It MAY export a destructor function. A component which uses hal_xinit() but does not export a constructor (NULL) behaves like a legacy component."

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...?