Re: [Emc-users] another wild hare idea.

2020-03-30 Thread Gene Heskett
On Sunday 29 March 2020 09:40:38 andy pugh wrote:

> On Sun, 29 Mar 2020 at 08:15, Gene Heskett  
wrote:
> > > And there is no need to add a tiny move to M66.
> >
> > Somebody should fix the docs, it say it needs a move to activate it.
>
> No it doesn't. That is for M67 (and the requirement can be avoided by
> using M68)
> http://linuxcnc.org/docs/2.7/html/gcode/m-code.html#mcode:m66

Ok, its getting clearer. But I have at least one digital-out I haven't 
coded yet, and I need two analog-in-nn's but thats disabled because M68 
uses #5399 regardless of the E0/E1/E3 etc. We get around that by reading 
#5399 as the next op, storing it in a gcode var.

To make that 100% usefull, we really need as many memory locations as 
there are num_aio specified if the default 4 is not enough. Either that 
or a way to synchronize the writes with the M68 read function, making 
sure its been read by an m66 before overwriting it with a different 
value.

And now it appears my Z home switch mount has failed, again, 3rd time 
TBE.  Gr.  Put it back on with jbweld this time, And drill/tap a 4mm 
cap screw for insurance once the jbweld is cured. Belt and suspenders 
insurance. :( I've found that while goop and its locktite ilk have more 
resilence than superglues, they also fall apart in 2 years if way oil is 
nearby. The only tension against that mount is the spring in the 
mini-microswitches roller lever.

Thanks Andy. Stay safe and away from crowds.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-29 Thread andy pugh
On Sun, 29 Mar 2020 at 08:15, Gene Heskett  wrote:

> > And there is no need to add a tiny move to M66.
>
> Somebody should fix the docs, it say it needs a move to activate it.

No it doesn't. That is for M67 (and the requirement can be avoided by using M68)
http://linuxcnc.org/docs/2.7/html/gcode/m-code.html#mcode:m66

-- 
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, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-29 Thread Gene Heskett
On Saturday 28 March 2020 23:03:59 andy pugh wrote:

> On Sun, 29 Mar 2020 at 03:08, Gene Heskett  
wrote:
> > Is the analog-in-00 and and analog-out-00 two separate circuits
> > independent of each other?
>
> Yes.
>
That will help clarify my thinking, a bunch. So I can use 00 for 
independent vars.

> And there is no need to add a tiny move to M66.

Somebody should fix the docs, it say it needs a move to activate it.  The 
way the peck is written the next move is the next g33.1 and thats too 
late. Thats why I added the .002 moves, so motion would have something 
to do.

> M67 takes effect on the next move, but that's for output, not input.

Its also too late.

> M66 ENN  transfers the value of the hal pin motion.analog-in-NN
> straight to #5399.

Ok, but what about the docs saying its waiting for input, which I'd 
normally assume will be zero before the first peck, aka no 
data=0.000 until the measurement arrives shortly after the bottom of 
the pecks turnaround? And is held valid until the next peck updates it.


> That is all there is to it.

Ok, I should be able to get this part working in the morning.

But I just thought of another roadblock, units.py, I need its output to 
make things imperial that started imperial. units.py is apparently 
called from the system as it is not in a loadrt or addf statement 
anywhere. It used like this in postgui.hal
net display-mode<= units.G21 => ovrtrvl-scaler-mux.sel
However, a bit of conditional gcode in the ngc file can make a substitute 
for that I think. I was amazed that there is no units loadable module 
when I started this project over a year ago.

Good night & stay safe.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-28 Thread andy pugh
On Sun, 29 Mar 2020 at 03:08, Gene Heskett  wrote:

> Is the analog-in-00 and and analog-out-00 two separate circuits independent of
> each other?

Yes.

And there is no need to add a tiny move to M66.
M67 takes effect on the next move, but that's for output, not input.

M66 ENN  transfers the value of the hal pin motion.analog-in-NN
straight to #5399.

That is all there is to it.

-- 
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, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-28 Thread Gene Heskett
On Saturday 28 March 2020 15:51:02 Gene Heskett wrote:

> On Saturday 28 March 2020 13:55:28 andy pugh wrote:
> > On Sat, 28 Mar 2020 at 17:50, Gene Heskett  wrote:
> > > mornings git pull so it might not be page 812 any more. Is now on
> > > page 814 according to evince:
> > >
> > Section 14.15 is "14.15 Creating Userspace Python Components"
> >
> > So, this is a Python function for use in custom userspace
> > components. It has no place in your G-code.

I guess I don't have a grasp on the relationshit of
motion.analog-in and out vs m68 and m66. Is there a doc that explains how this 
works? wrapping an m66 
e1 l0 in a two thou g1 movements so there is motion seems to get me nothing yet 
halshow shows .05 at 
motion.analog-in-01. Is the analog-in-00 and and analog-out-00 two separate 
circuits independent of 
each other?

I currently have a "net showdist => motion.analog-in-01" but cannot get 
anything for the gcode out of 
M66 E1 L0 to #5399 with this hal code:
net showdist<= mult2distance.out # should feed pyvcp.ovrtvldist does 
and works
net showdist=> motion.analog-in-01
 and this gcode:
g33.1 z#<_z_tmp> k0.050 # its a 20 tpi thread

g1 f30 z[#<_z_tmp> + 0.002] # movements to enable the M66 and is an error at 
gcode load time.
m66 E1 L0
g1f30  z#<_z_tmp> #put it back. Humm, z-tmp is the wrong var, s/b #<_z_start
#<_z_correction> = #5299
And #<_z_correction> remains at 0.
Theres a flubbergasket blown here someplace, need more tutorial.
Reading the docs again it looks as if I should be using M67 E1 L0 followed by a 
small g1 move.
But its getting late here too.

Thanks

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-28 Thread Gene Heskett
On Saturday 28 March 2020 13:55:28 andy pugh wrote:

> On Sat, 28 Mar 2020 at 17:50, Gene Heskett  wrote:
> > mornings git pull so it might not be page 812 any more. Is now on
> > page 814 according to evince:
> >
> > 14.15.6.6
>
> Section 14.15 is "14.15 Creating Userspace Python Components"
>
> So, this is a Python function for use in custom userspace components.
> It has no place in your G-code.

So while I have used M68 to give the counts to pyvcp for massaging and display, 
I'll have to do all the 
rest in the gcode if I want to get it done.  Thats a bummer.

Thanks Andy, I'll see what I can do from that side of the wall. First I have to 
use a different means 
of getting the counter output, which is a different signal name in the main 
hal, I can I hope retrieve 
that somehow. Here is what I have, from the main hal:

# calculate spindle reversal overshoot
setpsum2.ovrtrvl.gain0  -1.0 # make sub2 out of sum2
# feed accumulated counts to both sample-holds
net ovrtrvl1<=  hm2_[HOSTMOT2](BOARD).0.encoder.00.count
# Feed both sample-holds
net ovrtrvl1=>  sample-dirchg.in   #checks
net ovrtrvl1=>  sample-spndlchg.in #checks

net spindle-is-reversed <=  abs_encdir.is-negative  =>  
sample-spndlchg.hold # checks
# that takes care of measuring reversal rotation distance, HOWEVER, it also 
measures the other end
# of the travel, so the halmeter jumps to a higher value at the end of the 
retract move as it
# reverses to fwd again. SO KEEP THAT IN MIND! Better yet, make it a held value 
thats updated
net ovrtrvl2   <=   sample-dirchg.out=>   s32_float_cmd.in # checks
net ovrtrvl3   <=   s32_float_cmd.out=>   sum2.ovrtrvl.in0 # checks
net ovrtrvl4   <=   sample-spndlchg.out  =>   s32_float_spndl.in # checks
net ovrtrvl5   <=   s32_float_spndl.out  =>   sum2.ovrtrvl.in1 # checks
# make a sample-hold out of a mux2
net ovrtrvl6   <=   sum2.ovrtrvl.out =>   ovrtvl-frz.in1
net ovrtrvl6a  <=   ovrtvl-frz.out   =>   ovrtvl-frz.in0
# now we need a ovrtvl-frz.sel <= trig.frz signal
net spindle-is-reversed=> trig-frz.in
setptrig-frz.width  0.25
net holdovrtvl <= trig-frz.out ovrtvl-frz.sel

# ovrtvl-frz.out can be watched with a halmeter, is in encoder counts, works
# next we need a mult2 to make turns of spindle out of this
# first, feed reciprical of encoder counts to in0, which is 240/turn
# this is hard coded reciprical of encoder's scale
setpmult2turns.in0 0.0041667
net ovrtrvl6a => mult2turns.in1
# now mult2turns.out s/b spindle turns
net makedist0<= motion.analog-out-00 => mult2distance.in0
net makedist1<= mult2turns.out mult2distance.in1
net showdist <= mult2distance.out # which feed to pyvcp.ovrtvldist
net showdist => motion.analog.in-01

So to feed gcode, I need mult2distance.out delivered to a named gcode var.

At least to this point its all hal. So I'm confused, can I do that with 
a feed to motion.analog.in-01 as above, retrieve in gcode with an 
M66 E1 L0, and  get it back from #599? the M66 uses?  And is that 
instant enough to use for some math in gcode, done above the g33.1 and 
applied to the next peck cycle. It should be available to the M68 E1 L0
at the end of the g33.1 in each peck cycle. But the header of M66, Wait 
for input bothers me

Does excedrin have a number for this headache? :)

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-28 Thread andy pugh
On Sat, 28 Mar 2020 at 17:50, Gene Heskett  wrote:

> mornings git pull so it might not be page 812 any more. Is now on page
> 814 according to evince:
>
> 14.15.6.6

Section 14.15 is "14.15 Creating Userspace Python Components"

So, this is a Python function for use in custom userspace components.
It has no place in your G-code.

-- 
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, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-28 Thread Gene Heskett
On Saturday 28 March 2020 10:01:51 andy pugh wrote:

> On Sat, 28 Mar 2020 at 13:45, Gene Heskett  
wrote:
> > > Where did you find that format? Is it in the docs somewhere?
> >
> > page 812, /usr/share/doc/linuxcnc/Documentation.pdf
>
> The 2.7 docs don't even have a page 812, and in 2.9 and 2.8 that page
> is discussing kinematics.
>
> Searching the PDF for the string "hal." doesn't help either, so I
> really have no idea where you got that string from, but it certainly
> isn't G-code.

Get it from my web page. You should know that I am pulling and rebuilding 
master for the rpi4 at some point every weekend. Goto the link in my 
sig, then add lathe-stf/ to the address bar, and you will see a dir 
listing, click on linuxcnc4rpi4, and get 
linuxcnc-doc-en_2.9.0~pre0_all.deb. But I see a gfx add during this 
mornings git pull so it might not be page 812 any more. Is now on page 
814 according to evince:

14.15.6.6
get_value
read a pin, param or signal directly.
example:
value = hal.get_value("iocontrol.0.emc-enable-in"):

Thats copy/pasted from the docs I built this morning on the rpi4.
Just installed it on mine, appears to work, so in 15 minutes or less you 
should see todays date on that stuff at the link described above.
 
All done, ready for your downloading pleasure.  Be my guest.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-28 Thread andy pugh
On Sat, 28 Mar 2020 at 13:45, Gene Heskett  wrote:

> > Where did you find that format? Is it in the docs somewhere?
>
> page 812, /usr/share/doc/linuxcnc/Documentation.pdf

The 2.7 docs don't even have a page 812, and in 2.9 and 2.8 that page
is discussing kinematics.

Searching the PDF for the string "hal." doesn't help either, so I
really have no idea where you got that string from, but it certainly
isn't G-code.

-- 
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, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-28 Thread Gene Heskett
On Saturday 28 March 2020 07:16:49 andy pugh wrote:

> On Sat, 28 Mar 2020 at 07:45, Gene Heskett  
wrote:
> > Now, the actual line from the gcode which should be good
> > #<_Z_dist>=hal.get_value("ovrtrvl-scaler-mux.out")
>
> Where did you find that format? Is it in the docs somewhere?

page 812, /usr/share/doc/linuxcnc/Documentation.pdf

> If so, can you say which file and which page?
>
> You seem to be trying to put Python code in G-code.
> http://linuxcnc.org/docs/2.8/html/hal/halmodule.html

Is not answering the phone this morning.

> You can read HAL pins at the _beginning_ of a G-code routine, but the
> format is quite different.
> #<_Z_dist>=#<_hal[ovrtrvl-scaler-mux.out])

Not usefull here.

> http://linuxcnc.org/docs/2.7/html/remap/remap.html#remap:referto-hal-i
>tems
>
> But that won't work here, as the G-code gets the interpreter value,
> not the run-time value.
>
> What you need to do is
>
> net G-code-input ovrtrvl-scaler-mux.out => motion.analog-in-00

The in-00 is already in use so I'll have to use in-01, in-00 is supplying 
the tpmm or tpi to hal, which then runs it thru a short chain that 
converts the overtravel counts into turns(float) and if tp* is non-zero, 
distance(float) according to the value passed as tpi/tpmm from the 
gcode, to turns*tpi|tpmm and converts it back to imperial based on the 
outputs of a units module so I get the same "physical" answer for both 
g20 and g21.

Section 5.4.16 of that same doc says wait on input, but in this case the 
input is there, and what I want it to do is pass the new value the hal 
modules have caught during he peck just performed, updated during every 
g33.1 pass and held in a sample-hold. Updated at the bottom of each peck 
and available even if tp** is zero. I still get the # of counts, 
displayed as turns.

What I want to do now is ship that "turns" back to the gcode, massage it 
by tpmm or tpi and subtract it from the depth commanded as it runs the 
next loop of the peck. Eventually I want to incorporate the tools tlo 
from the tool table. (that, with my tray of taps, might need a bigger 
tool table).

That however will probably wait until I've bored out a big bar holder so 
it mates with my tray of top-hatted taps. They are all 7/8" OD and keyed 
so they cannot turn in the holder. There is a 4mm cap screw in the side 
of each hat that mates with a notch cut in an R8, or will be cut into 
this custom toolholder.

> Then in the g-code
> M66 E0 L0
> # = #5399

M66 E1 L0, but is the #number(#5399) the same? The docs would seem to say 
so, so in the gcode I should capture that immediately after the g33.1 
peck is done.

And this is synchronized? Coding it up and testing will answer that..

My method is always, if I'm pecking, one peck stale.  And if I don't peck 
it still works for the display of turns in FPoint. So then I just loop 
once. All this gives me, after the 1st peck, a display of both turns and 
distance traveled while its slowing and turning around to back out of 
the hole. Even if one is carefull, this is where you break taps, and 
I've broken quite a few already. :( 

At some point I want to add a #<_var> to hold the in-## so it can be 
edited to fit other installs that may already be using different 
num_aio's for other things.

Stay safe everybody.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-28 Thread andy pugh
On Sat, 28 Mar 2020 at 07:45, Gene Heskett  wrote:

> Now, the actual line from the gcode which should be good
> #<_Z_dist>=hal.get_value("ovrtrvl-scaler-mux.out")

Where did you find that format? Is it in the docs somewhere?

If so, can you say which file and which page?

You seem to be trying to put Python code in G-code.
http://linuxcnc.org/docs/2.8/html/hal/halmodule.html

You can read HAL pins at the _beginning_ of a G-code routine, but the
format is quite different.
#<_Z_dist>=#<_hal[ovrtrvl-scaler-mux.out])
http://linuxcnc.org/docs/2.7/html/remap/remap.html#remap:referto-hal-items

But that won't work here, as the G-code gets the interpreter value,
not the run-time value.

What you need to do is

net G-code-input ovrtrvl-scaler-mux.out => motion.analog-in-00

Then in the g-code
M66 E0 L0
# = #5399


--
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, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-28 Thread Gene Heskett
On Friday 27 March 2020 16:04:21 Gene Heskett wrote:

> On Friday 27 March 2020 14:39:39 Gene Heskett wrote:
> > On Friday 27 March 2020 07:20:33 Gene Heskett wrote:
> > > On Friday 27 March 2020 02:53:03 theman whosoldtheworld wrote:
> > > > Hi
> > > >
> > > > They are read only.
> > > >
> > > > The FEATURES=12 or whatever gives you access to the values, but
> > > > you cannot change them, that would be the Holy Grail.
> > > >
> > > > If the pin can be written to, you can do it from a user M code
> > > >
> > > > halcmd setp  value type thing
> > > >
> > > > Whether it is linked and what type of pin it is is going to
> > > > determine if it can be written
> > > >
> > > > regards
> > > >
> > > > (by ArcHye   with AndyPugh some years ago teach me about
> > > > thse)
> > > >
> > > > plus on g code #<_hal[pinname]>
>
> Apparently has been modified, see snip below from page 812 of the
> current docs, I finally found it with zero help from the index.
>
> > > Great minds, I just thought of adding a module, putting it in the
> > > correct place in the addf order & feeding it from hal but using
> > > its output in the gcode. That syntax '#<_hal[pinname]>' may be the
> > > key to the backwards path I need to actually make it work.
>
> Nope.
>
> > > And a debug statement is all it will take to prove its working. 
> > > But that also means the loading of the module will have to be
> > > moved out of the postgui.hal to the initial loadrt's and addf's so
> > > that the modules output exists at the hal scan time, else the
> > > error is that the pin doesn't exist. I can sort that I think as
> > > geany's copy/paste is I think, global.  I think I may have already
> > > done that as postgui.hal is all 'net' statements:
> > >
> > > net   showdist1   <= scale-ovrtrvl.out => ovrtrvl-scaler-mux.in1
> > > net   display-mode<= units.G21 => ovrtrvl-scaler-mux.sel
> > > setp  scale-ovrtrvl.gain 25.40
> > > # here, use a scale and a mux2 to select the scale.in for inches,
> > > or the scale.out
> > > # for a mm's conversion.
> > >
> > > So in the gcode:
> > > #<_z_depth> = [#<_hole_depth> - #<_hal[ovrtrvl-scaler-mux.out]>]
>
> And on page 812, I find this example:
> value = hal.get_value("iocontrol.0.emc-enable-in")
> So I'll use that syntax just for S
> Then I noted the dblquotes around the hal-pinname, but now it is an
> unk where a unary could be.  Gonna take more figuring I think.

Now, the actual line from the gcode which should be good
#<_Z_dist>=hal.get_value("ovrtrvl-scaler-mux.out")
That pin is there in hal-showconfig, but lcnc spits it out.

Where have I made a mistake?

I have also noted that the copyright date this freshly pulled and 
compiled Documentation.pdf is in June 2019, so it stands to be nearly 9 
months out of date.

Thanks again.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-27 Thread Gene Heskett
On Friday 27 March 2020 14:39:39 Gene Heskett wrote:

> On Friday 27 March 2020 07:20:33 Gene Heskett wrote:
> > On Friday 27 March 2020 02:53:03 theman whosoldtheworld wrote:
> > > Hi
> > >
> > > They are read only.
> > >
> > > The FEATURES=12 or whatever gives you access to the values, but
> > > you cannot change them, that would be the Holy Grail.
> > >
> > > If the pin can be written to, you can do it from a user M code
> > >
> > > halcmd setp  value type thing
> > >
> > > Whether it is linked and what type of pin it is is going to
> > > determine if it can be written
> > >
> > > regards
> > >
> > > (by ArcHye   with AndyPugh some years ago teach me about thse)
> > >
> > > plus on g code #<_hal[pinname]>

Apparently has been modified, see snip below from page 812 of the current 
docs, I finally found it with zero help from the index.

> > Great minds, I just thought of adding a module, putting it in the
> > correct place in the addf order & feeding it from hal but using its
> > output in the gcode. That syntax '#<_hal[pinname]>' may be the key
> > to the backwards path I need to actually make it work.
> >
Nope.

> > And a debug statement is all it will take to prove its working.  But
> > that also means the loading of the module will have to be moved out
> > of the postgui.hal to the initial loadrt's and addf's so that the
> > modules output exists at the hal scan time, else the error is that
> > the pin doesn't exist. I can sort that I think as geany's copy/paste
> > is I think, global.  I think I may have already done that as
> > postgui.hal is all 'net' statements:

> > net showdist1   <= scale-ovrtrvl.out => ovrtrvl-scaler-mux.in1
> > net display-mode<= units.G21 => ovrtrvl-scaler-mux.sel
> > setpscale-ovrtrvl.gain 25.40
> > # here, use a scale and a mux2 to select the scale.in for inches, or
> > the scale.out
> > # for a mm's conversion.

> > So in the gcode:
> > #<_z_depth> = [#<_hole_depth> - #<_hal[ovrtrvl-scaler-mux.out]>]

And on page 812, I find this example:
value = hal.get_value("iocontrol.0.emc-enable-in")
So I'll use that syntax just for S
Then I noted the dblquotes around the hal-pinname, but now it is an unk 
where a unary could be.  Gonna take more figuring I think.

Thanks again.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-27 Thread Gene Heskett
On Friday 27 March 2020 07:20:33 Gene Heskett wrote:

> On Friday 27 March 2020 02:53:03 theman whosoldtheworld wrote:
> > Hi
> >
> > They are read only.
> >
> > The FEATURES=12 or whatever gives you access to the values, but you
> > cannot change them, that would be the Holy Grail.
> >
> > If the pin can be written to, you can do it from a user M code
> >
> > halcmd setp  value type thing
> >
> > Whether it is linked and what type of pin it is is going to
> > determine if it can be written
> >
> > regards
> >
> > (by ArcHye   with AndyPugh some years ago teach me about thse)
> >
> > plus on g code #<_hal[pinname]>
>
> Great minds, I just thought of adding a module, putting it in the
> correct place in the addf order & feeding it from hal but using its
> output in the gcode. That syntax '#<_hal[pinname]>' may be the key to
> the backwards path I need to actually make it work.
>
> And a debug statement is all it will take to prove its working.  But
> that also means the loading of the module will have to be moved out of
> the postgui.hal to the initial loadrt's and addf's so that the modules
> output exists at the hal scan time, else the error is that the pin
> doesn't exist. I can sort that I think as geany's copy/paste is I
> think, global.  I think I may have already done that as postgui.hal is
> all 'net' statements:
> net   showdist1   <= scale-ovrtrvl.out => ovrtrvl-scaler-mux.in1
> net   display-mode<= units.G21 => ovrtrvl-scaler-mux.sel
> setp  scale-ovrtrvl.gain 25.40
> # here, use a scale and a mux2 to select the scale.in for inches, or
> the scale.out
> # for a mm's conversion.
>
> So in the gcode:
> #<_z_depth> = [#<_hole_depth> - #<_hal[ovrtrvl-scaler-mux.out]>]

unfortunately that source of data is undefined^^
after I fixed the copy/paste error. There was a typu in the first varname 
and an extra space in the 2nd, fixed above.  I have read the docs around 
page 812 and the sugar must be getting to my eyes, or the docs need 
help. That pin name does exist in postgui.hal.

> Which will subtract the overtravel from the gcode var that sets the
> ultimate depth of the hole.  And it should  be a value less for the
> peck increment than this.  And I could warn if the peck increment was
> greater than the over travel, which would setup a crash anyway
> situation.
>
> Thank you very much.
>
> Once I get both eyes open for the day. I'll test it. At 07:17 and only
> two sips of cold coffee, no bets.
>
> > *is this what you need? did I get it right? *
> >
> > regards and good luck with your work
> >
> >
> > Il giorno gio 26 mar 2020 alle ore 22:47 Gene Heskett
> > 
> >
> > ha scritto:
> > > Greetings all;
> > >
> > > I have some code in my Sheldon's hal file that accepts a value
> > > from gcode, #<_tpmm> or #<_tpi> that twiddles that value shipped
> > > across motion and then shows me via a pyvcp text box, the
> > > numerical distance value of the overshoot from inertia between the
> > > initiance of the reverse at the bottom of the g33.1 and the actual
> > > maximum overshoot before it gets stopped, which with an 8" 40 lb
> > > chuck mounted can exceed 3 turns at 300 rpms to slow and get the
> > > first 1.5 degrees of the reverse done.
> > >
> > > Works good but atm doesn't autoconvert metric/imperial. Thats a
> > > relatively minor detail involving the units module. and a sum2.
> > >
> > > Now what I want to do is ship that derived value back from hal to
> > > the gcode side of motion, so I can decrease the g33.1 depth and
> > > automatically adjust it to prevent the taps breakage from hitting
> > > the bottom of the hole.
> > >
> > > How can I do that backwards data transfer? The M6# codes don't
> > > seem to fit this.
> > >
> > > Thanks all.
> > > .
> > > 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)
> > > If we desire respect for the law, we must first make the law
> > > respectable. - Louis D. Brandeis
> > > Genes Web page 
> > >
> > >
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> Cheers, Gene Heskett


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-27 Thread theman whosoldtheworld
Fine!

Il giorno ven 27 mar 2020 alle ore 12:23 Gene Heskett 
ha scritto:

> On Friday 27 March 2020 02:53:03 theman whosoldtheworld wrote:
>
> > Hi
> >
> > They are read only.
> >
> > The FEATURES=12 or whatever gives you access to the values, but you
> > cannot change them, that would be the Holy Grail.
> >
> > If the pin can be written to, you can do it from a user M code
> >
> > halcmd setp  value type thing
> >
> > Whether it is linked and what type of pin it is is going to determine
> > if it can be written
> >
> > regards
> >
> > (by ArcHye   with AndyPugh some years ago teach me about thse)
> >
> > plus on g code #<_hal[pinname]>
>
> Great minds, I just thought of adding a module, putting it in the correct
> place in the addf order & feeding it from hal but using its output in
> the gcode. That syntax '#<_hal[pinname]>' may be the key to the
> backwards path I need to actually make it work.
>
> And a debug statement is all it will take to prove its working.  But that
> also means the loading of the module will have to be moved out of the
> postgui.hal to the initial loadrt's and addf's so that the modules
> output exists at the hal scan time, else the error is that the pin
> doesn't exist. I can sort that I think as geany's copy/paste is I think,
> global.  I think I may have already done that as postgui.hal is
> all 'net' statements:
> net showdist1   <= scale-ovrtrvl.out => ovrtrvl-scaler-mux.in1
> net display-mode<= units.G21 => ovrtrvl-scaler-mux.sel
> setpscale-ovrtrvl.gain 25.40
> # here, use a scale and a mux2 to select the scale.in for inches, or the
> scale.out
> # for a mm's conversion.
>
> So in the gcode:
> #<-z_depth> = [#< _hole_depth> - #<_hal[ovrtrvl-scaler-mux.out]>]
>
> Which will subtract the overtravel from the gcode var that sets the
> ultimate depth of the hole.  And it should  be a value less for the peck
> increment than this.  And I could warn if the peck increment was greater
> than the over travel, which would setup a crash anyway situation.
>
> Thank you very much.
>
> Once I get both eyes open for the day. I'll test it. At 07:17 and only
> two sips of cold coffee, no bets.
> >
> >
> > *is this what you need? did I get it right? *
> >
> > regards and good luck with your work
> >
> >
> > Il giorno gio 26 mar 2020 alle ore 22:47 Gene Heskett
> > 
> >
> > ha scritto:
> > > Greetings all;
> > >
> > > I have some code in my Sheldon's hal file that accepts a value from
> > > gcode, #<_tpmm> or #<_tpi> that twiddles that value shipped across
> > > motion and then shows me via a pyvcp text box, the numerical
> > > distance value of the overshoot from inertia between the initiance
> > > of the reverse at the bottom of the g33.1 and the actual maximum
> > > overshoot before it gets stopped, which with an 8" 40 lb chuck
> > > mounted can exceed 3 turns at 300 rpms to slow and get the first 1.5
> > > degrees of the reverse done.
> > >
> > > Works good but atm doesn't autoconvert metric/imperial. Thats a
> > > relatively minor detail involving the units module. and a sum2.
> > >
> > > Now what I want to do is ship that derived value back from hal to
> > > the gcode side of motion, so I can decrease the g33.1 depth and
> > > automatically adjust it to prevent the taps breakage from hitting
> > > the bottom of the hole.
> > >
> > > How can I do that backwards data transfer? The M6# codes don't seem
> > > to fit this.
> > >
> > > Thanks all.
> > > .
> > > 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)
> > > If we desire respect for the law, we must first make the law
> > > respectable. - Louis D. Brandeis
> > > Genes Web page 
> > >
> > >
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> 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)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-27 Thread Gene Heskett
On Friday 27 March 2020 02:53:03 theman whosoldtheworld wrote:

> Hi
>
> They are read only.
>
> The FEATURES=12 or whatever gives you access to the values, but you
> cannot change them, that would be the Holy Grail.
>
> If the pin can be written to, you can do it from a user M code
>
> halcmd setp  value type thing
>
> Whether it is linked and what type of pin it is is going to determine
> if it can be written
>
> regards
>
> (by ArcHye   with AndyPugh some years ago teach me about thse)
>
> plus on g code #<_hal[pinname]>

Great minds, I just thought of adding a module, putting it in the correct 
place in the addf order & feeding it from hal but using its output in 
the gcode. That syntax '#<_hal[pinname]>' may be the key to the 
backwards path I need to actually make it work. 

And a debug statement is all it will take to prove its working.  But that 
also means the loading of the module will have to be moved out of the 
postgui.hal to the initial loadrt's and addf's so that the modules 
output exists at the hal scan time, else the error is that the pin 
doesn't exist. I can sort that I think as geany's copy/paste is I think, 
global.  I think I may have already done that as postgui.hal is 
all 'net' statements:
net showdist1   <= scale-ovrtrvl.out => ovrtrvl-scaler-mux.in1
net display-mode<= units.G21 => ovrtrvl-scaler-mux.sel
setpscale-ovrtrvl.gain 25.40
# here, use a scale and a mux2 to select the scale.in for inches, or the 
scale.out
# for a mm's conversion.

So in the gcode:
#<-z_depth> = [#< _hole_depth> - #<_hal[ovrtrvl-scaler-mux.out]>]

Which will subtract the overtravel from the gcode var that sets the 
ultimate depth of the hole.  And it should  be a value less for the peck 
increment than this.  And I could warn if the peck increment was greater 
than the over travel, which would setup a crash anyway situation.

Thank you very much.

Once I get both eyes open for the day. I'll test it. At 07:17 and only 
two sips of cold coffee, no bets.
>
>
> *is this what you need? did I get it right? *
>
> regards and good luck with your work
>
>
> Il giorno gio 26 mar 2020 alle ore 22:47 Gene Heskett
> 
>
> ha scritto:
> > Greetings all;
> >
> > I have some code in my Sheldon's hal file that accepts a value from
> > gcode, #<_tpmm> or #<_tpi> that twiddles that value shipped across
> > motion and then shows me via a pyvcp text box, the numerical
> > distance value of the overshoot from inertia between the initiance
> > of the reverse at the bottom of the g33.1 and the actual maximum
> > overshoot before it gets stopped, which with an 8" 40 lb chuck
> > mounted can exceed 3 turns at 300 rpms to slow and get the first 1.5
> > degrees of the reverse done.
> >
> > Works good but atm doesn't autoconvert metric/imperial. Thats a
> > relatively minor detail involving the units module. and a sum2.
> >
> > Now what I want to do is ship that derived value back from hal to
> > the gcode side of motion, so I can decrease the g33.1 depth and
> > automatically adjust it to prevent the taps breakage from hitting
> > the bottom of the hole.
> >
> > How can I do that backwards data transfer? The M6# codes don't seem
> > to fit this.
> >
> > Thanks all.
> > .
> > 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)
> > If we desire respect for the law, we must first make the law
> > respectable. - Louis D. Brandeis
> > Genes Web page 
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] another wild hare idea.

2020-03-27 Thread theman whosoldtheworld
Hi

They are read only.

The FEATURES=12 or whatever gives you access to the values, but you cannot
change them, that would be the Holy Grail.

If the pin can be written to, you can do it from a user M code

halcmd setp  value type thing

Whether it is linked and what type of pin it is is going to determine if it
can be written

regards

(by ArcHye   with AndyPugh some years ago teach me about thse)

plus on g code #<_hal[pinname]>


*is this what you need? did I get it right? *

regards and good luck with your work


Il giorno gio 26 mar 2020 alle ore 22:47 Gene Heskett 
ha scritto:

> Greetings all;
>
> I have some code in my Sheldon's hal file that accepts a value from
> gcode, #<_tpmm> or #<_tpi> that twiddles that value shipped across
> motion and then shows me via a pyvcp text box, the numerical distance
> value of the overshoot from inertia between the initiance of the reverse
> at the bottom of the g33.1 and the actual maximum overshoot before it
> gets stopped, which with an 8" 40 lb chuck mounted can exceed 3 turns at
> 300 rpms to slow and get the first 1.5 degrees of the reverse done.
>
> Works good but atm doesn't autoconvert metric/imperial. Thats a
> relatively minor detail involving the units module. and a sum2.
>
> Now what I want to do is ship that derived value back from hal to the
> gcode side of motion, so I can decrease the g33.1 depth and
> automatically adjust it to prevent the taps breakage from hitting the
> bottom of the hole.
>
> How can I do that backwards data transfer? The M6# codes don't seem to
> fit this.
>
> Thanks all.
> .
> 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)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


[Emc-users] another wild hare idea.

2020-03-26 Thread Gene Heskett
Greetings all;

I have some code in my Sheldon's hal file that accepts a value from 
gcode, #<_tpmm> or #<_tpi> that twiddles that value shipped across 
motion and then shows me via a pyvcp text box, the numerical distance 
value of the overshoot from inertia between the initiance of the reverse 
at the bottom of the g33.1 and the actual maximum overshoot before it 
gets stopped, which with an 8" 40 lb chuck mounted can exceed 3 turns at 
300 rpms to slow and get the first 1.5 degrees of the reverse done.

Works good but atm doesn't autoconvert metric/imperial. Thats a 
relatively minor detail involving the units module. and a sum2.

Now what I want to do is ship that derived value back from hal to the 
gcode side of motion, so I can decrease the g33.1 depth and 
automatically adjust it to prevent the taps breakage from hitting the 
bottom of the hole.

How can I do that backwards data transfer? The M6# codes don't seem to 
fit this.

Thanks all.
. 
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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users