On Thursday 08 September 2016 12:45:56 Kirk Wallace wrote: > On 09/07/2016 04:49 PM, Jeff Epler wrote: > > At least three things fall in the category "It is an error if ...": > > > > * The part program is invalid, and LinuxCNC rejects it with a > > message. > > > > * The part program is invalid, but LinuxCNC may not detect it. > > Undesired motion (or other action) may ensue. This could > > reflect a case that the developer knows she did not correctly define > > during the design of the interpreter. > > > > * The part program is invalid, and a future version of LinuxCNC > > is free to assign a different meaning to the part program in > > a future release, with or without notice in the documentation. > > > > Some of the things listed as an error for G76 clearly fall into the > > second two categories. > > > > Jeff > > I'm not following the above well. Let's take the first item in the > manual's G76 error list. > http://linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g76 > > "... > It is an error if: > > The active plane is not the ZX plane > ..." > > Currently, the interp_convert.cc code contents for G76 doesn't seem to > check for the active plane. In running g-code I can set any plane and > G76 runs normally, (although the active g-codes box always switches to > indicate G17 when the cycle starts). > > So, should the line about the active plane be removed from the G76 > manual entry because it's not really an error. > > Or, am I missing something and interp_convert needs to be edited to > add a check for the active plane? If so, what am I missing that makes > this check necessary? > > The goal is to bring the source code, performance, and the > documentation into agreement. > > I am also assuming that "It is an error if" means that if an error > occurs, somewhere along the line an error message will be presented > and running the code will be prevented, rather than implying "this is > a mistake so don't do this". Either way could be valid, but I know > what I usually prefer. > > At this point since G76 seems to function well enough in this regard, > it would be best to remove this item from the manual.
No Kirk, but edit it to indicate that A: shallow tapers are possible by using an E argument that is one P short of the z thread-length. If indeed you want an error check and die, die on an E >= "total z motion". That would be because if e=thread-length, it goes in to the cut depth, and it then moves, at cutting depth, one P to the right before it does the normal motion. This could either break tooling, or at best carve an entry groove that will be total thread depth and one P wide. Of course if cutting air off the end of the workpiece, its wasted time. I have not checked to see if that effects the carved angle, and while I did get the 74ACT245N's today, which combined with finding a teeny little ground bridge on the C1G breakout board that was used for a fuse & sticking a short piece of 30 ga kynar across it, I can now move the X & Z motors, but it appears the opto's on the encoder board are history, and the only signal I can see at the spindle interface is I believe, the enable, a gpio on pin 9. Thats a 3 signal control, enable, pwm (p3-14) and dir (p3-16) speed, and I don't see any dir or pwm on the leds. The opto's I have, but replacing them on that ultra thin copper rat shack pcb I made it on will redefine my personal hell. At this point, the question is what blew all that, so the next thing is uncover enough of that motor to see if its thrown a winding, causing a short. I have another motor in that event but it doesn't mount exactly the same. "Good" luck I could use some of. And I can't blame it on Murphy, I think he got tired of the near beer I drink, I've not missed any of mine in weeks now. 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 <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
