Reverse run on BeagleBone Black
17 Mar 2019 21:12 #128858
by andypugh
Replied by andypugh on topic Reverse run on BeagleBone Black
Maybe. But reverse-run seems better.
The BBB problem is easily addressed simply by using something else
The BBB problem is easily addressed simply by using something else
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
Less
More
- Posts: 17771
- Thank you received: 5907
17 Mar 2019 23:48 #128862
by tommylight
Replied by tommylight on topic Reverse run on BeagleBone Black
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
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
Please Log in or Create an account to join the conversation.
18 Mar 2019 09:28 #128879
by Tower
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).
Replied by Tower on topic Reverse run on BeagleBone Black
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).
Please Log in or Create an account to join the conversation.
18 Mar 2019 12:27 #128885
by andypugh
Components written with .comp look exactly the same, though. (Not that the BBB drivers fit into that class)
Replied by andypugh on topic Reverse run on BeagleBone Black
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)
Please Log in or Create an account to join the conversation.
18 Mar 2019 13:32 #128894
by andypugh
Replied by andypugh on topic Reverse run on BeagleBone Black
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."
"My guess is it would be dramatically easier to get the hal_pru_generic
driver running on LCNC vs. merging reverse-run into Machinekit."
Please Log in or Create an account to join the conversation.
18 Mar 2019 14:07 - 18 Mar 2019 14:08 #128898
by OT-CNC
Replied by OT-CNC on topic Reverse run on BeagleBone Black
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:
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:
Last edit: 18 Mar 2019 14:08 by OT-CNC. Reason: found on youtube
Please Log in or Create an account to join the conversation.
19 Mar 2019 12:17 #128963
by Tower
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).
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?
Replied by Tower on topic Reverse run on BeagleBone Black
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).
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?
Please Log in or Create an account to join the conversation.
19 Mar 2019 12:25 #128964
by andypugh
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.
Replied by andypugh on topic Reverse run on BeagleBone Black
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.
Please Log in or Create an account to join the conversation.
Time to create page: 0.122 seconds