Re: [Emc-users] Probe cycle switches to MDI

[Gene Heskett]

On Saturday 08 October 2016 13:46:12 Danny Miller wrote:

And I copied to the developers list as you bring up a point that I too 
would like to see fixed. It will not fix my instant problem of the G38 
contact not getting to motion.probe-input, that  signal lost failure 
will still crush the probe or the workpiece.  See below when I grokked 
what is happening to you.

> On 10/8/2016 12:13 PM, Gene Heskett wrote:
> > On Saturday 08 October 2016 12:25:57 Danny Miller wrote:
> >> I have the wireless pendant button triggering a probe cycle in an
> >> .ngc.
> >>
> >> Problem is, IF the cycle ends without tripping the probe (user
> >> error), Axis UI ends up switching to MDI tab, and all the pendant
> >> function is for Manual Control tab.  So it disables the pendant
> >> until you can get back to the PC and fix it by clicking back to
> >> Manual Control tab.  Why does it end up in MDI tab, and how can
> >> make LinuxCNC end up back in the Manual Control tab?
> >>
> >> .ngc code below:
> >>
> >> 
> >> o100 sub
> >>
> >> #1 = #[5203 + [20 * #5220] ]
> >>
> >> G38.3 F50 Z[-6.5-#1]
> >
> > Coding style. did you mean -6.5 - #1? I always use a space around a
> > math function char, reducing the ambiguity when I go back and read
> > it months/years later.
> >
> >> G10 L2 P0 Z1.826
> >
> > This also is a coding style preference, but I have gotten out of the
> > habit of adjusting the G54 map.  It reduces the hunting while
> > looking for a map that matches the one originally homed to mapping,
> > for me at least.  So I wind up using the next 2 or 3 maps in most of
> > my coding.
> >
> > This also is a disadvantage because, realizing the machine is going
> > to hit a fixture or something I didn't intend, hitting the esc key
> > restores G54, and unless you know what map was in use, you lost the
> > data that would tell me my math was funkity or THAT map was funkity
> > because my math was.
>
> Yeah I wanted to refer to a .ini parameter.  Wasn't sure how, on my
> to-do list.  So I can refer to .ini parameters inside g-code?

No, but .hal code can.

> Z#<_probing.probethickness>  or what?

If its truly a fixed value, how about

#<_probe_len>

These are not cleared when you load a different bit of gcode, so one 
could add it to one normal preamble, ran once as the lcnc machine has 
been rebooted, I don't 100% trust that it would survive a cold reboot.  
With hot reboots, the actual survival rate of stuff like that was quite 
good, amazing me at the time I discovered it, several years ago.

Mine however is a piece of 10 gauge copper wire, buried in a 3/4" 
diameter teflon rod, which has no stop collar.  I use it far more often 
in finding and establishing the exact center of a hole so everything 
else can then be calculated from there.  If I need to find a Z position, 
I put a .0625" thick pcb on the work, use the real cutting tool, usually 
rotating backwards, and add that pcb thickness to get the tool at 
contact=0..

I have yet, when the probe circuit is working, to put a visible mark on 
the piece of pcb, the contact is that gentle, and I usually have a .2 uf 
cap across the contact so a momentary contact is saved long enough for 
lcnc to register it.  That improved its repeatability quite a bit.

> Point is, probe tool is 1.826 inches thick, so once it touches off it
> needs to fix the z-offset for that point to be 1.826 so z=0 is the
> bottom of the probe, i.e. the surface it's sitting on.
>
> >> o101 if [#5070 EQ 1]
> >>   G10 L20 P0 Z1.826
> >>   G1 Z1.93 F3
> >>   G38.3 F3 Z[1.6] (<- useless brackets. what effect? if any)
> >>   G10 L20 P0 Z1.826
> >>   G0 Z2.5
> >> o101  else
> >>   G53 G0 Z0
> >>   (debug, FAILED TO FIND PROBE)
> >> o101 endif
> >>
> >> o100 endsub
> >> 
> >>
> >>
> >> Thanks,
> >>
> >> Danny
> >
> > I don't see anything above that would put you in the mdi mode unless
> > the math equates to an F5 character somehow. Not seeing the rest of
> > the code, I've no clue if the scope of #1 thru #30 has been
> > violated.
>
> It's if the probe cycle fails to trip.  If the probe gets found in the
> acceptable travel, all is well.

Ahh, yes, the miss is reported. Now the light of comprehension comes on.

I don't know of a way around that, and IMO the miss should not be an 
error, but a return value so far out of range that ones software can use 
it for an error flag as you tried to do with the 'else' above. But the 
error catcher in the g38 code won't let it work.

Perhaps something can be added to the G38 call that would make that the 
g-code writers choice?  I'd be very happy with that option. The stopper 
error in the g38 miss condition as it exists now is a PIMA. It should be 
our choice.
 
> If the probe travel limit is reached, the error condition dumps out of
> the .ngc code and for some odd reason the Axis UI ends up with the MDI
> tab selected.  Well it's not incomprehensible, Axis tried to run
> g-code and got an exception condition.  But it's a problem, not a
> 

Re: [Emc-users] Probe cycle switches to MDI

[Danny Miller]

On 10/8/2016 12:13 PM, Gene Heskett wrote:
> On Saturday 08 October 2016 12:25:57 Danny Miller wrote:
>
>> I have the wireless pendant button triggering a probe cycle in an
>> .ngc.
>>
>> Problem is, IF the cycle ends without tripping the probe (user error),
>> Axis UI ends up switching to MDI tab, and all the pendant function is
>> for Manual Control tab.  So it disables the pendant until you can get
>> back to the PC and fix it by clicking back to Manual Control tab.  Why
>> does it end up in MDI tab, and how can make LinuxCNC end up back in
>> the Manual Control tab?
>>
>> .ngc code below:
>>
>> 
>> o100 sub
>>
>> #1 = #[5203 + [20 * #5220] ]
>>
>> G38.3 F50 Z[-6.5-#1]
> Coding style. did you mean -6.5 - #1? I always use a space around a math
> function char, reducing the ambiguity when I go back and read it
> months/years later.
>
>> G10 L2 P0 Z1.826
> This also is a coding style preference, but I have gotten out of the
> habit of adjusting the G54 map.  It reduces the hunting while looking
> for a map that matches the one originally homed to mapping, for me at
> least.  So I wind up using the next 2 or 3 maps in most of my coding.
>
> This also is a disadvantage because, realizing the machine is going to
> hit a fixture or something I didn't intend, hitting the esc key restores
> G54, and unless you know what map was in use, you lost the data that
> would tell me my math was funkity or THAT map was funkity because my
> math was.
Yeah I wanted to refer to a .ini parameter.  Wasn't sure how, on my 
to-do list.  So I can refer to .ini parameters inside g-code? 
Z#<_probing.probethickness>  or what?
Point is, probe tool is 1.826 inches thick, so once it touches off it 
needs to fix the z-offset for that point to be 1.826 so z=0 is the 
bottom of the probe, i.e. the surface it's sitting on.
>
>> o101 if [#5070 EQ 1]
>>   G10 L20 P0 Z1.826
>>   G1 Z1.93 F3
>>   G38.3 F3 Z[1.6] (<- useless brackets. what effect? if any)
>>   G10 L20 P0 Z1.826
>>   G0 Z2.5
>> o101  else
>>   G53 G0 Z0
>>   (debug, FAILED TO FIND PROBE)
>> o101 endif
>>
>> o100 endsub
>> 
>>
>>
>> Thanks,
>>
>> Danny
>>
> I don't see anything above that would put you in the mdi mode unless the
> math equates to an F5 character somehow. Not seeing the rest of the
> code, I've no clue if the scope of #1 thru #30 has been violated.
It's if the probe cycle fails to trip.  If the probe gets found in the 
acceptable travel, all is well.
If the probe travel limit is reached, the error condition dumps out of 
the .ngc code and for some odd reason the Axis UI ends up with the MDI 
tab selected.  Well it's not incomprehensible, Axis tried to run g-code 
and got an exception condition.  But it's a problem, not a show-stopper 
but I did aim to make the pendant control essentially everything but 
file selection with minimal need to use the terminal.
>
> This to me is a very strong argument in favor of separating global data
> from local data by the use of #<_name> (note the underscore) for global
> variables, and # for local to this subroutine data.  In my own
> coding I find that results in far fewer surprises.  Either way works if
> you pay attention but I find that the leading underscore is a reminder
> that this is global data, and its lack as an indicator that this was
> intended to be local, vanishing with the end of the subroutine rather
> handy when I am reading it again later.
>
> Named data to me is at least as handy as sliced bread. :)
>
> I've no clue if this helps but I hope it does Danny.
>
> Cheers, Gene Heskett


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Probe cycle switches to MDI

[John Alexander Stewart]

Danny - not an answer, but I do find sometimes that my USB MPG will cause
that to happen.

It is on an older version of LinuxCNC that I should update sometime, hoping
that a bug fix has cured it.

Sorry for no answer, but at least you know you are not the only one. ;-)

John.
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Probe cycle switches to MDI

[Gene Heskett]

On Saturday 08 October 2016 12:25:57 Danny Miller wrote:

> I have the wireless pendant button triggering a probe cycle in an
> .ngc.
>
> Problem is, IF the cycle ends without tripping the probe (user error),
> Axis UI ends up switching to MDI tab, and all the pendant function is
> for Manual Control tab.  So it disables the pendant until you can get
> back to the PC and fix it by clicking back to Manual Control tab.  Why
> does it end up in MDI tab, and how can make LinuxCNC end up back in
> the Manual Control tab?
>
> .ngc code below:
>
> 
> o100 sub
>
> #1 = #[5203 + [20 * #5220] ]
>
> G38.3 F50 Z[-6.5-#1]

Coding style. did you mean -6.5 - #1? I always use a space around a math 
function char, reducing the ambiguity when I go back and read it 
months/years later.

> G10 L2 P0 Z1.826

This also is a coding style preference, but I have gotten out of the 
habit of adjusting the G54 map.  It reduces the hunting while looking 
for a map that matches the one originally homed to mapping, for me at 
least.  So I wind up using the next 2 or 3 maps in most of my coding.

This also is a disadvantage because, realizing the machine is going to 
hit a fixture or something I didn't intend, hitting the esc key restores 
G54, and unless you know what map was in use, you lost the data that 
would tell me my math was funkity or THAT map was funkity because my 
math was.

>
> o101 if [#5070 EQ 1]
>  G10 L20 P0 Z1.826
>  G1 Z1.93 F3

>  G38.3 F3 Z[1.6] (<- useless brackets. what effect? if any)

>  G10 L20 P0 Z1.826
>  G0 Z2.5
> o101  else
>  G53 G0 Z0
>  (debug, FAILED TO FIND PROBE)
> o101 endif
>
> o100 endsub
> 
>
>
> Thanks,
>
> Danny
>
I don't see anything above that would put you in the mdi mode unless the 
math equates to an F5 character somehow. Not seeing the rest of the 
code, I've no clue if the scope of #1 thru #30 has been violated.

This to me is a very strong argument in favor of separating global data 
from local data by the use of #<_name> (note the underscore) for global 
variables, and # for local to this subroutine data.  In my own 
coding I find that results in far fewer surprises.  Either way works if 
you pay attention but I find that the leading underscore is a reminder 
that this is global data, and its lack as an indicator that this was 
intended to be local, vanishing with the end of the subroutine rather 
handy when I am reading it again later.

Named data to me is at least as handy as sliced bread. :)

I've no clue if this helps but I hope it does Danny.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Probe cycle switches to MDI

[andy pugh]

On 8 October 2016 at 17:25, Danny Miller  wrote:
> Why
> does it end up in MDI tab, and how can make LinuxCNC end up back in the
> Manual Control tab?

I imagine that you have the pendant connected to one of the
MDI_COMMAND HAL pins? Those use MDI, and switch to the MDI window.

How doe the pendant interface to LinuxCNC? wheel-jogging appears to
work regardless of manual/mdi mode

You could toggle the halui.mode.manual pin to return to manual mode.
However that doesn't switch tabs in the Axis GUI, so I am not sure if
it has the required effect.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Probe cycle switches to MDI

[Danny Miller]

I have the wireless pendant button triggering a probe cycle in an .ngc.

Problem is, IF the cycle ends without tripping the probe (user error), 
Axis UI ends up switching to MDI tab, and all the pendant function is 
for Manual Control tab.  So it disables the pendant until you can get 
back to the PC and fix it by clicking back to Manual Control tab.  Why 
does it end up in MDI tab, and how can make LinuxCNC end up back in the 
Manual Control tab?

.ngc code below:


o100 sub

#1 = #[5203 + [20 * #5220] ]

G38.3 F50 Z[-6.5-#1]
G10 L2 P0 Z1.826

o101 if [#5070 EQ 1]
 G10 L20 P0 Z1.826
 G1 Z1.93 F3
 G38.3 F3 Z[1.6]
 G10 L20 P0 Z1.826
 G0 Z2.5
o101  else
 G53 G0 Z0
 (debug, FAILED TO FIND PROBE)
o101 endif

o100 endsub



Thanks,

Danny


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users