Subroutine GUI

12 Oct 2010 21:30 - 12 Oct 2010 21:35 #4653 by BigJohnT
BigJohnT replied the topic: Re:Subroutine GUI
I just noticed with ngcgui you can load several different subfiles to create a complete program... Dam that is neat.

Load a subfile, set the parameters then "Create Feature" then load the next subfile and continue until done then "Finalize"

Last Edit: 12 Oct 2010 21:35 by BigJohnT.
27 Oct 2010 10:18 #4890 by Rick G
Rick G replied the topic: Re:Subroutine GUI
Hello John,

Just wanted to let you know I have started using your lathe subroutines on my lathe, just the ticket when you need to knock out something quickly. Thanks for posting them.

I noticed on Dewey Garrett's site that ngcgui can be embedded in an axis tab. Have you tried that?

27 Oct 2010 11:02 #4891 by BigJohnT
BigJohnT replied the topic: Re:Subroutine GUI
Hi Rick,

No, but I intend to this weekend. Much better to have a tab in Axis than all those icons on my desktop for each op.

21 Nov 2010 21:07 #5501 by cwmk577
cwmk577 replied the topic: Re:Subroutine GUI
I haven't had a chance to test this yet but the concept is absolutely awesome. One of the things I liked most about Mach was the Wizard facility, and this goes a long way to making subroutines as nice for end-users as the Mach wizards.

To that end, I have a few ideas for ways to make this friendlier or more powerful:

1. As someone said earlier, it would be a nice option to be able to populate an input based on "Current Machine Position." Maybe you need three buttons for Machine X, Y, Z, etc.

2. Tool parameters: I'd like to set things like feed rate, plunge rate, RPM, and depth of cut on a per-tool basis and use them as defaults when populating a subroutine. Ideally I could either set these directly and see what they equate to in SFM, feed per tooth, etc. or vice-versa.

3. Graphic legend: Allow the subroutine programmer to attach an image which visually explains the parameters. Sometimes it's easier to put labels on a picture than explain things with words, especially as the number of params grows. Mach lets the wizard designer place the inputs directly on top of a graphic, but I think that's superfluous.

4. Saving parameters in a single part file: This one might be a bit complicated but I think it could be really powerful. Let's say you have a bracket which consists of a surfacing op, four drilled holes, and a rectangular pocket. You make one, but find that the pocket needs to be shifted 0.050" to the right and milled 0.050" deeper.

Right now, I could go into the gcode program, delete the pocketing routine, run the pocket sub with the new parameters, and paste the output. It's not bad, really, but it requires switching to an editor and it's easy to miss a line of code and ruin the program. I think it can be made much better:
  1. When the user first opens NGCGUI, allow them to select or create a new "Part File." I could see doing this as its own file, e.g. an XML file, or embedding the information in G-code comment blocks in the final program.
  2. The part file would contain a definition block for each part feature. A feature would be an instance of a particular subrotuine, i.e., if I run the "drill a hole" subroutine four times to define four drilled holes, my part program would have four feature definitions, with user-defined labels like Hole 1, Hole 2... Hole 4.
  3. If I chose an existing part file, the gui would have a dropdown with all the features of that type. I.e., if I choose the rectangular pocket sub, then open a part file, it would show me all the rectangular pockets on that part, plus the option to create a new one
  4. If I choose an existing pocket, it would load all the parameters, and then I could modify the specific ones I want, and save them.
  5. At some level, the user would get the option to "run all" which would run all the individual subroutines (of all types) based on their saved parameters, and spool the outputs into a single program file

When you combine this with the full toolpath preview in Axis, I think it would make for an extremely awesome user experience. And I don't know if my description makes it sound really complex to implement, but the way I'm seeing it I think it should be--mostly--pretty straightforward.
21 Nov 2010 21:15 #5505 by BigJohnT
BigJohnT replied the topic: Re:Subroutine GUI
Sounds like a good idea, you should give it a go.

21 Nov 2010 21:47 #5509 by cwmk577
cwmk577 replied the topic: Re:Subroutine GUI
Yeah, I'm willing to give it a swing but I need to finish my other EMC project first:
21 Nov 2010 21:52 - 21 Nov 2010 21:52 #5510 by BigJohnT
BigJohnT replied the topic: Re:Subroutine GUI
Yea, I looked at that right after you registered and it looks pretty cool.

and welcome to the forum.

Last Edit: 21 Nov 2010 21:52 by BigJohnT.
01 Feb 2011 00:12 #6907 by otto_pjm
otto_pjm replied the topic: Re:Subroutine GUI
Very nice, I played with an earlier version, but the added functionality and the in-tab feature is awesome.

I can't say I've ever written anything in TCL, but I'm going to take a crack at creating a subroutine. Is there a repository for them either here or with Dewey?

I like the associated image idea and the caching of parameters, I think I'll start simple though.

Also great work on the custom controller / aux display project, very cool.

01 Feb 2011 13:29 #6922 by BigJohnT
BigJohnT replied the topic: Re:Subroutine GUI
The subroutines are simply g code subroutines with a few extra things on top for Dewey's TCL to work the magic.

As far as I know this is the only place that has examples related to Dewey's ngcgui program.

04 Mar 2011 15:53 #7579 by Pilotltd
Pilotltd replied the topic: Re:Subroutine GUI
Hi John - been having a look at this today, can get the gui tabs to show but on finalize I get the error

Near line 26 of home/steve/emc2/configs/sb-lathe1/auto.ngc :

Unable to open file <od>

or id or taper-od depending on which tab I selected.

Any ideas?

Moderators: Rick G
Time to create page: 0.098 seconds
Powered by Kunena Forum