My alternative approach...
rodw wrote:
There are a few reasons I think like this
1. That is consistent with the LinuxCNC component approach. Many standard components are < 10 lines of code.
The idea here is to keep as much as possible in one place as long as the thread time is not exceeded.
[hr]
2. I was always taught that if you could not see a procedure on a single screen or page, it is too long and it needs to be broken up.
Although technically this is one procedure, in reality it is many different procedures, each of which (mostly) follows the above criteria. They are then joined together in a reasonably easy to follow sequence in one place. I could (should) have split the 'CUTTING' procedure into the two differing types.
[hr]
3. I was adding pieces of the puzzle on a progressive basis.
That is how I originally built this component, one procedure at a time. First probing then going to pierce height and so on. Get a procedure working then go on to the next one.
[hr]
4. Many of the pieces are totally unrelated. Eg corner lock/velocity anti-dive and torch sampling have nothing in common.
If these are separate components then one has to know how to connect them together and in the correct order which I think complicates the setup for a new user.
[hr]
5. A small component is much easier to debug where we don't have access to a debugger to step through code in an interrupt service routine environment.
The original debugging was easy as only one procedure at a time was added. However that may prove be different when (if) I actually get to try it to my table.
