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 <ghesk...@shentel.net> 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 > > <reinha...@schwarzrot-design.de> > > > > 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 <http://geneslinuxbox.net:6309/gene> > > > _______________________________________________ > 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
