Generating G Code from MDI history log

Nice one Dewey,

The #<x1> = #<_move:x> threw me at first until I realised that #<_move:x> was a global declared in move.ngc and not a referencing notation I was unaware of !!

I think you might have prompted a 'build a better mousetrap' competition.
I'll have to give this some serious thought.

regards

An example of how to do something similar with axis, ngcgui, and a simple subroutine:

O.K. Dewey that is cool, everytime I turn around that ngcgui makes things faster and easier!
I will try that this weekend.
Thanks for sharing.

Rick G

Dewey, That is Neat! I can't wait to get my BP converted to EMC...

John

"The #<x1> = #<_move:x> threw me at first until I realised that #<_move:x> was a global declared in move.ngc and not a referencing notation I was unaware of !!"

Yes, the general pattern for returning values from subroutines called by ngcgui subfiles is to return them as globals with a colon somewhere in the name. It is convenient to format the names as:

#<_nameofsubroutine:item_value>

as in:

#<_move:x>

It is good practice to immediately localize the return value, as in:
#<x1>=#<_move:x>

The only way to return multiple items from a subroutine is with globals. (I think the git-master version supports a return statement that can return a single item).

Using the colon in the name is important, it prevents ngcgui from interpreting the variable as a user input -- using globals as inputs to ngcgui is deprecated.

Hi,

'To build a better mousetrap' ( or just do the same thing differently for the sake of it! )

I decided to take a different tack and added some functionality which hopefully will come in useful for other things too.

In the unknown but definitely irregularly spaced holes, each requiring multiple drilling operations, scenario, it works thus.

Manually jog to each hole position in turn and when aligned press pyvcp button [Mark Co-ordinates].
This will save the current co-ords to a file /tmp/cords.txt. Repeat for each hole.

Clear the MDI history and enter the g code commands necessary to drill a single hole (either for real or in fresh air).
Last command needs to be a movement to a Safe Z height.

In ~/emc2/ngc there should be 2 files header.ngc and footer.ngc. These contain the standard preparatory and terminating g code for your operations.
The header can contain the spindle start up, speed and coolant commands followed by a move to Safe Z, to save having this all in MDI history and repeating each hole.

Pressing the pyvcp [Generate] button creates a file consisting of header, move to first co-ords, mdi commands for operation, move to next co-ords, operation ... etc until all co-ords used and finally footer.

The engine behind the file creation is a C++ QT3 program I called 'splice' which takes all the file names as command line arguments and splices them together to make the final g code file. (this could be a bash script or python prog. I just find it easier to think in C / C++)

[Mark Co-ordinates] button is linked to halui.mdi-command.0 ,which calls <writecords> a g code subroutine to get co-ords, then calls M152 to write them to file.

[Generate] button is linked to halui.mdi-command.1, which calls M153, which calls splice with all the relevant file names as arguments

Screen capture 1 shows MDI window with code for one hole and trace where hole co-ords have been captured.

image missing http://www.linuxcnc.org/media/kunena/attachments/legacy/images/splice1.png

Screen capture 2 (next post) shows resulting plot from generated file.

Overall just demonstrates the power and flexibility of both LinuxCNC and Linux itself, using a combination of HAL, g code, user M codes and a binary to achieve a degree of automation.

I think I may be building upon the co-ordinate capture at some point in the future to do basic 'teach' routines.

Feel free to 'borrow with pride' if any of it appeals.

regards

Screenshot 2 image missing http://www.linuxcnc.org/media/kunena/attachments/legacy/images/splice2.png