Re: [Emc-developers] State Tags and Hal_port pins

[Reinhard]

Hi Rod,

On Samstag, 16. Mai 2020, 08:01:41 CEST Rod Webster wrote:
> Now we have both State tags and the hal_port pin type in master branch, 
>... 
>, it would allow easy access to the state tags from a custom component
> instead of letting state tags sulk in the EMC folder.

don't know, if I got you right - to me it sounds as if you oppose the state 
tags.

>From my point of view, state tags are for communication with frontend / UI, 
whereas hal is the communication with hardware / drivers. 
So state tags are far from being complete. But I don't think, that they are 
equivalent or should be. No. There might be information, that will be 
important for the hardware-side and be of little interest for the frontend 
side.
I think, if NML is the communication portal of linuxcnc to other software, 
than an UI should not have to bother with hal. 
An UI may do that to give the users another taste of UI, but tools for hal 
exists and work, why reinvent the wheel?
So I appreciate state tags and would like them to become more complete to be 
able to offer all informations around machine state ...

May be, my point of view does not reflect the state of linuxcnc. 
But that's what I think and would like to become true one day :)


cheers Reinhard




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

Re: [Emc-developers] State Tags and Hal_port pins

[Gene Heskett]

On Saturday 16 May 2020 02:01:41 Rod Webster wrote:

> Now we have both State tags and the hal_port pin type in master
> branch, it occurred to me that it might be possible to publish the
> state tags structure to a hal_port pin and a component could check
> motion.motion_type or the tag type to determine the data contained in
> hal_port.
>
> A cursory read indicated that different classes of tags had different
> structures.
>
> I'm particularly interested in being able to retrieve the arc radius
> when the current segment is an arc.
>
> Is this feasible? Could  somebody explain how to go about doing
> something like this?
>
> If we could pull this off, it would allow easy access to the state
> tags from a custom component instead of letting state tags sulk in the
> EMC folder.
>
> Any help and advice would be appreciated.
>
We've had some parts of that for a while, Rod. I have a bit of hal that 
looks at motions state, and if not =5, disables response to a probe 
input, so I can use that same wire for a home switch. I've since put a 
5i25 and another bob in that machine, but that code is still there.

Nice to see this added. It expands what hal can do.
>
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> VMN®
> www.vmn.com.au
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


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-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] State Tags and Hal_port pins

[Rod Webster]

Gene, thanks, I've played around with motion_type like that for various
things too.

Reinhard,
I'm not interested in a UI  running in user space here at all. State tags
is in the real time code section of Linuxcnc  but I don't see its available
via any pins. The state tags structure is contained in the
emcmotCommand structure
created in motion.c using the structures defined in statetags.h and motion.h

The hal_port is a new "string" pin available in hal.

So what I propose is a "marriage" between them.  Copy the statetags as an
untyped "blob" in a hal_port  pin so that an interested hal component could
read the blob, determine how to decode it from motion_type and overlay the
typed structure over the top. What  I want to access is the radius of an
arc so I can make adjustments to the plasma cutting process  in real time.

An alternative (simpler) approach would be to create a new motion pin for
the arc radius, but I thought the hal_port marriage might allow anybody to
access all of the state_tags data from a component. I just don't quite know
where to start. But it would be a powerful enhancement to our awesome
platform.

Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au



On Sat, 16 May 2020 at 16:53, Reinhard 
wrote:

> Hi Rod,
>
> On Samstag, 16. Mai 2020, 08:01:41 CEST Rod Webster wrote:
> > Now we have both State tags and the hal_port pin type in master branch,
> >...
> >, it would allow easy access to the state tags from a custom component
> > instead of letting state tags sulk in the EMC folder.
>
> don't know, if I got you right - to me it sounds as if you oppose the
> state
> tags.
>
> From my point of view, state tags are for communication with frontend /
> UI,
> whereas hal is the communication with hardware / drivers.
> So state tags are far from being complete. But I don't think, that they
> are
> equivalent or should be. No. There might be information, that will be
> important for the hardware-side and be of little interest for the frontend
> side.
> I think, if NML is the communication portal of linuxcnc to other software,
> than an UI should not have to bother with hal.
> An UI may do that to give the users another taste of UI, but tools for hal
> exists and work, why reinvent the wheel?
> So I appreciate state tags and would like them to become more complete to
> be
> able to offer all informations around machine state ...
>
> May be, my point of view does not reflect the state of linuxcnc.
> But that's what I think and would like to become true one day :)
>
>
> cheers Reinhard
>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] State Tags and Hal_port pins

[Gene Heskett]

On Saturday 16 May 2020 03:47:20 Rod Webster wrote:

> Gene, thanks, I've played around with motion_type like that for
> various things too.
>
> Reinhard,
> I'm not interested in a UI  running in user space here at all. State
> tags is in the real time code section of Linuxcnc  but I don't see its
> available via any pins. The state tags structure is contained in the
> emcmotCommand structure
> created in motion.c using the structures defined in statetags.h and
> motion.h
>
> The hal_port is a new "string" pin available in hal.
>
> So what I propose is a "marriage" between them.  Copy the statetags as
> an untyped "blob" in a hal_port  pin so that an interested hal
> component could read the blob, determine how to decode it from
> motion_type and overlay the typed structure over the top. What  I want
> to access is the radius of an arc so I can make adjustments to the
> plasma cutting process  in real time.
>
> An alternative (simpler) approach would be to create a new motion pin
> for the arc radius, but I thought the hal_port marriage might allow
> anybody to access all of the state_tags data from a component. I just
> don't quite know where to start. But it would be a powerful
> enhancement to our awesome platform.
>
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> VMN®
> www.vmn.com.au

My imagination is on strike this time of the morning here, but in the 
longer view, it certainly would seem to be a worthwhile, usable control 
enhancement. Particularly if it unplugged the 1 byte wide connection 
between ones gcode and hal. I made that work recently, but when doing a 
loop, its untested as to whether or not its is bulletproof for all 
possible loop conditions but its promising enough that I just bought two 
more big bar holders, one to hold a hole depth probe, and one to hold a 
tap hat, and rig for peck tapping a hole without running into the bottom 
of the hole and breaking off a tap in the hole because the spindle 
overtravels dependent on revs and chuck mass when doing that on a bigger 
lathe.  Mainly because EDM'ing the tap back out of the hole to salvage 
the part is such a PITA.

I need to build a bigger psu for such bailouts.  My code isn't exactly 
complete just yet, but the autocomp part works. And once the tool 
holding is under control, it should be a piece of cake to calibrate and 
make it work with any tap in the drawer.

>
>
> On Sat, 16 May 2020 at 16:53, Reinhard
> 
>
> wrote:
> > Hi Rod,
> >
> > On Samstag, 16. Mai 2020, 08:01:41 CEST Rod Webster wrote:
> > > Now we have both State tags and the hal_port pin type in master
> > > branch, ...
> > >, it would allow easy access to the state tags from a custom
> > > component instead of letting state tags sulk in the EMC folder.
> >
> > don't know, if I got you right - to me it sounds as if you oppose
> > the state
> > tags.
> >
> > From my point of view, state tags are for communication with
> > frontend / UI,
> > whereas hal is the communication with hardware / drivers.
> > So state tags are far from being complete. But I don't think, that
> > they are
> > equivalent or should be. No. There might be information, that will
> > be important for the hardware-side and be of little interest for the
> > frontend side.
> > I think, if NML is the communication portal of linuxcnc to other
> > software, than an UI should not have to bother with hal.
> > An UI may do that to give the users another taste of UI, but tools
> > for hal exists and work, why reinvent the wheel?
> > So I appreciate state tags and would like them to become more
> > complete to be
> > able to offer all informations around machine state ...
> >
> > May be, my point of view does not reflect the state of linuxcnc.
> > But that's what I think and would like to become true one day :)
> >
> >
> > cheers Reinhard
> >
> >
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


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-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] State Tags and Hal_port pins

[Rod Webster]

Thanks for seeing the potential Gene.
You are lucky its morning there. 7:30 pm here. I've been up since 4:00 cos
I've been working with a US associate.  I said good night to him about
lunch time so its been a long day  and my imagination is really worn out
about now.!

Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au



On Sat, 16 May 2020 at 18:48, Gene Heskett  wrote:

> On Saturday 16 May 2020 03:47:20 Rod Webster wrote:
>
> > Gene, thanks, I've played around with motion_type like that for
> > various things too.
> >
> > Reinhard,
> > I'm not interested in a UI  running in user space here at all. State
> > tags is in the real time code section of Linuxcnc  but I don't see its
> > available via any pins. The state tags structure is contained in the
> > emcmotCommand structure
> > created in motion.c using the structures defined in statetags.h and
> > motion.h
> >
> > The hal_port is a new "string" pin available in hal.
> >
> > So what I propose is a "marriage" between them.  Copy the statetags as
> > an untyped "blob" in a hal_port  pin so that an interested hal
> > component could read the blob, determine how to decode it from
> > motion_type and overlay the typed structure over the top. What  I want
> > to access is the radius of an arc so I can make adjustments to the
> > plasma cutting process  in real time.
> >
> > An alternative (simpler) approach would be to create a new motion pin
> > for the arc radius, but I thought the hal_port marriage might allow
> > anybody to access all of the state_tags data from a component. I just
> > don't quite know where to start. But it would be a powerful
> > enhancement to our awesome platform.
> >
> > Rod Webster
> > *1300 896 832*
> > +61 435 765 611
> > VMN®
> > www.vmn.com.au
>
> My imagination is on strike this time of the morning here, but in the
> longer view, it certainly would seem to be a worthwhile, usable control
> enhancement. Particularly if it unplugged the 1 byte wide connection
> between ones gcode and hal. I made that work recently, but when doing a
> loop, its untested as to whether or not its is bulletproof for all
> possible loop conditions but its promising enough that I just bought two
> more big bar holders, one to hold a hole depth probe, and one to hold a
> tap hat, and rig for peck tapping a hole without running into the bottom
> of the hole and breaking off a tap in the hole because the spindle
> overtravels dependent on revs and chuck mass when doing that on a bigger
> lathe.  Mainly because EDM'ing the tap back out of the hole to salvage
> the part is such a PITA.
>
> I need to build a bigger psu for such bailouts.  My code isn't exactly
> complete just yet, but the autocomp part works. And once the tool
> holding is under control, it should be a piece of cake to calibrate and
> make it work with any tap in the drawer.
>
> >
> >
> > On Sat, 16 May 2020 at 16:53, Reinhard
> > 
> >
> > wrote:
> > > Hi Rod,
> > >
> > > On Samstag, 16. Mai 2020, 08:01:41 CEST Rod Webster wrote:
> > > > Now we have both State tags and the hal_port pin type in master
> > > > branch, ...
> > > >, it would allow easy access to the state tags from a custom
> > > > component instead of letting state tags sulk in the EMC folder.
> > >
> > > don't know, if I got you right - to me it sounds as if you oppose
> > > the state
> > > tags.
> > >
> > > From my point of view, state tags are for communication with
> > > frontend / UI,
> > > whereas hal is the communication with hardware / drivers.
> > > So state tags are far from being complete. But I don't think, that
> > > they are
> > > equivalent or should be. No. There might be information, that will
> > > be important for the hardware-side and be of little interest for the
> > > frontend side.
> > > I think, if NML is the communication portal of linuxcnc to other
> > > software, than an UI should not have to bother with hal.
> > > An UI may do that to give the users another taste of UI, but tools
> > > for hal exists and work, why reinvent the wheel?
> > > So I appreciate state tags and would like them to become more
> > > complete to be
> > > able to offer all informations around machine state ...
> > >
> > > May be, my point of view does not reflect the state of linuxcnc.
> > > But that's what I think and would like to become true one day :)
> > >
> > >
> > > cheers Reinhard
> > >
> > >
> > >
> > >
> > > ___
> > > Emc-developers mailing list
> > > Emc-developers@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> 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 fi