On Thursday 02 April 2020 10:03:03 Ken Strauss wrote: > > -----Original Message----- > > From: Gene Heskett [mailto:[email protected]] > > Sent: Thursday, April 02, 2020 8:51 AM > > To: [email protected] > > Subject: Re: [Emc-users] wild hare continued. > > > > On Thursday 02 April 2020 07:23:28 Ken Strauss wrote: > > > > -----Original Message----- > > > > From: Gene Heskett [mailto:[email protected]] > > > > Sent: Thursday, April 02, 2020 6:42 AM > > > > To: Enhanced Machine Controller (EMC) > > > > Subject: [Emc-users] wild hare continued. > > > > > > > > Greetings Andy; > > > > > > > > I have some of the data transfers working, but I then recall you > > > > said G33.1 ran in metric internally. > > > > > > > > So if I am capturing data during the execution, but its in > > > > inches at the nc_file origin, the captured data being passed > > > > back needs to be *25.4000000 to be usefull, both as a display > > > > and as a correction to the Z stroke. > > > > > > > > The fact that m66 Enn uses #5399 regardless of the nn is being > > > > an obstacle. It means that I'll have to use some digital outputs > > > > to tally whether or not #5399 has been read and by whom. > > > > > > > > Could this use be expanded to a memory location dependent on > > > > ENN? That would greatly simplicate the gcode. > > > > > > > > Thanks Andy. > > > > > > > > Cheers, Gene Heskett > > > > -- > > > > > > I like the suggestion. I believe that the docs say that M66 Enn is > > > limited to nn=0 to 3. Tormach's PathPilot appears to allow nn=0 to > > > 7. If so, you need to allocate more than four cells to hold the > > > most recently read value. Just a consideration to avoid breaking > > > stuff. > > > > But thats expandable at load module time (top of your main hal file) > > by passing the num_dio=NN and num_aio=NN arguments. Up to 16 of each > > I've seen someplace. 4 is the default though. But, I need to pass 2 > > floats to make what I want to do, works right. And I'll need to make > > sure that variable 00 never gets mixed with variable 01 by the > > sharing of a single #5399 placeholder for the gcode to retrieve and > > use. I'm sure there is a reason for the #5399, but so far I don't > > recall hearing it. > > > > ??? > > > > Thanks. > > > > Cheers, Gene Heskett > > My point was that allowing expansion of the number at HAL load time > and allocating a numbered variable for each possible input is > problematic. You might as well always allocate 16 and dispense with > the parameter that changes the maximum Enn. Just a thought. > Not a bad one, but also wastefull of memory, for what I want to do, 2 each of numbered vars should be sufficient. Actually, anything that would guarantee their separation would work. hal code runs at a kilohertz, but gcode is throttled by how fast the machine moves with no real fixed time and delay between them. So hal may write var-B 1k+ times while gcode is getting to the m66 En. I think I can send stuff above or below the while/endwhile and send a differrent var-A during the while/endwhile of the peck loop. But that would be yet another whole rewrite. Doable, but discouraging as I always run into the lack of separation caused by using only a single double float buffer. Sigh.
> > > > _______________________________________________ > Emc-users mailing list > [email protected] > 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 <http://geneslinuxbox.net:6309/gene> _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
