Tweaked Probe Basic UI fails to launch

msrdiesel post=255074 userid=28393

spumco post=255057 userid=28776Nice job with the named parameters.

Does that stop you from loading a tool number that's already in the carousel?
 
No it did not, Had to revamp it. If a picture is worth a thousand words, this must be worth much more...

from this video, depending on how you are using the unload spindle button, in stock form it is just an MDI Button issuing the following command:

M61 Q0 G49 #5210 = 0 #5231 = 0

M61 Q0 (standard linuxcnc mcode for change current tool without tool change to Q##)
G49 Remove current tool offset
#5210 = 0 (remove G52 or G92 offsets)
#5231 = 0 (save tool 0 in var file persistent parameter 5231 so it shows tool 0 at startup)

this should work unless it has been changed in your customizations in the ui.  you may need to manually add parameter 5231 to the var file and save it.

you are correct about what splash screen shows up on startup, you must save the screen that you want in the active state in qtpyvcp designer.  it will become the screen you see on startup every time.

the atc routines are just an example, there is no way to account for all the various atc types and styles and configurations.  the one attached in the sim is simply the one that runs the sim atc, it is there as a guide but nothing more.  it looks like you have it pretty well sorted though!

probing is already setup and ready to run, you just need to assign a probe tool and fill in the on screen parameters and be sure the probe is setup in hal correctly, after that it is very simple to use.  there is a help section in the probing screen to define what the parameter entries are.

adding tool touch off is a bit trickier and requires some hal magic to use two inputs on the single linuxcnc probe input pin.  but that info is written out a few places in the forum already and is hal related.

what else are you having trouble with?

Chris

Lcvette wrote:

 

what else are you having trouble with?

Chris

Any idea how to set the Gremlin default view zoom level, is there a FIT ALL setting that can be implemented when a file is loaded?

And this, slipped my mind. My 16 tool carousel is BT, I also have CT tool holders. Would it be possible to setup the CT tools as tools 17 and up, and have the ui treat those as a manual toolchange, by pausing the G code to allow a manual toolchange?

I'm not sure what you mean by gremlin. probe basic uses VTK for the gcode backplotter display.  it is open source and the files are available to look at in your qtpyvcp/probe basic folder under widgets.  i think we had on the list to fix and get working the mch ext and pgm ext buttons working, but it was proving difficult and causing other issues, so for the time since it was non critical we put it back on the to do list.  once 2.9 officially releases I am sure it will get looked at again, until then I'm avoiding work on probe basic 2.9 py3 as i have already gotten inundated with help requests on installation of linuxcnc more than help with probe basic issues.  I created probe basic and even i only run 2.8 on my shop machines and since all my machines run on 2.8, because there is no official easy installation for a user version on 2.9 and i like my work horses using something steady and reliable. 

as for it automatically opening, once those buttons get sorted out, i think it can be setup as a user config in the yaml file in the user config folder.  but that will need to be setup to work.

"And this, slipped my mind. My 16 tool carousel is BT, I also have CT tool holders. Would it be possible to setup the CT tools as tools 17
and up, and have the ui treat those as a manual toolchange, by pausing the G code to allow a manual toolchange?"

if you are using the remap macros for your atc, you should be able to write in a rule in the sequence section after storing the current tool in the platter and it does the tool number check.  when it does the tool number check, the following is just an off the top of my head basic idea, I would look at the toolchange.ngc at this point and maybe adjust the "if" expression to look for tool #'s greater than 16 (in your case 17 and up are cat40 and require manual insertion etc) and add some expressions on what to do if they are.  you would want to store the current tool providing it was less than 17 in the carousel, then configure what message you wanted prompted and action to take.

you can do about anything in the macros, just have to dig in a bit on the rules and expressions.  luckily there are many examples already in the macros to study and get a feel for the flow.  this is a great resource for learning RS274NGC language. it helped me immensely while learning how to write and edit macros.

tsapps.nist.gov/publication/get_pdf.cfm?pub_id=823374

Lcvette wrote:

I'm not sure what you mean by gremlin.
 

FYI - 'gremlin' is the name of the backplotter used in Axis, gmoccapy, and various QTvcp screens.  I think it's sort of become a generic term for the backplot in any of the LCNC gui's.  Of course, PB and most (all?) of the qtpyvcp gui's use VTK.

andypugh wrote:

My feeling is that current_pocket and selected_pocket have been left as-is for compatibility with existing (presumably random, if they are working) toolchanger implementations, but that in a remap routine the #<pocket> param should return the tool-table pocket entry. 

Andy,

Thank you.

I had a look at the rack toolchange sim and I'm confused.  The stdglue "T" remap appears to be what's creating(?) the #<pocket> parameter to be used or made available for a remapped tool change.

However, the rackchange.ngc file still refers to global parmeters #<_current_pocket and #<_selected_pocket>... and doesn't include #<pocket> anywhere.

I guess I don't understand how it all fits together.  You've demonstrated it works to pass the pocket number value through to an .ngc file, but how does this work if rackchange.ngc never refers to #<pocket>?

And the rackchange sim readme still has this right on the front page:This assumes tool number == pocket number; the pocket number in the tool.tbl is currently ignored.

Again, thanks for digging.

So does this mean that for a nonrandom toolchanger the tool-to-pocket dance can be vastly simplified over the 'parameters as placeholders' scheme used by Probe Basic and other GUI's or setups?

More to the point, if M6 is remapped in INI and a simple toolchange.ngc is created, lcnc will pass the intended tool's pocket number (from the tool table) as  #<_selected_pocket>?

Thus:
Tool table - tool #5 is in pocket 8
"M6T5" will result in #<_selected_pocket> = 8?

That would simplify things greatly if it works like that.  Carousel could be given the value of #<_selected_pocket> and it just goes there with no fussing or macro gymnastics.