On Thursday 30 June 2016 08:26:43 Eric H. Johnson wrote: > Ok, next problem. The Z is a two position air cylinder, where I use > M64 / M65 to lift and lower. That seems to be generating the error > "Cannot set auxiliary digital output with cutter radius compensation > on". > > Is there any way around this. Do I have to turn radius compensation > off before each head lift / drop. > > Thanks, > Eric
Thats odd. I cannot read anything like that into the very sparsely described M62-M65 in the docs. What I do read is: 3.4.15 M62 - M65 Digital Output Control • M62 P- - turn on digital output synchronized with motion. The P- word specifies the digital output number. • M63 P- - turn off digital output synchronized with motion. The P- word specifies the digital output number. • M64 P- - turn on digital output immediately. The P- word specifies the digital output number. • M65 P- - turn off digital output immediately. The P- word specifies the digital output number. The P-word ranges from 0 to a default value of 3. If needed the the number of I/O can be increased by using the num_dio parameter when loading the motion controller. See the Motion Section for more information. The M62 & M63 commands will be queued. Subsequent commands referring to the same output number will overwrite the older settings. More than one output change can be specified by issuing more than one M62/M63 command. The actual change of the specified outputs will happen at the beginning of the next motion command. If there is no subsequent motion command, the queued output changes won’t happen. It’s best to always program a motion G code (G0, G1, etc) right after the M62/63. M64 & M65 happen immediately as they are received by the motion controller. They are not synchronized with movement, and they will break blending. ======================== I read that as the M64-M65, since the motion controller is reading ahead in order to do blending, the M64-M65 will be executed immediately, possibly when in the middle of actually doing the XY cut motion several lines above the M64 or M65 in your code. I can't think of a reason that I would want that to happen. Since the M62-M63 are synchronized with motion, and take effect at the beginning of the next motion, It seems to me like you would want that command in the code flow at the end of that cut, issue a very small motion after the end of the cut, perhaps .0001" then a g64p.05 after that very small motion to give the cutter time to actuate, and then direct it to the starting position of the next cut sequence. But it is something (M62-M63) I would try based on the undesirability of actuating the lift or drop in the middle of a cut. The P value shouldn't change. One further note but I believe you have that covered in your hal file; Note: M62-65 will not function unless the appropriate motion.digital-out-nn pins are connected in your hal file to outputs. ====================== Thats a bit of a duh, but thats the end of that subject in the docs. Verbose, no, overly concise, yes. I am in favor of an example line and a short explanation of what that line actually does. And I totally fail to see why the presence of cutter compensation in effect, or not, should have a thing to do with it since this is a Z only motion. OTOH I am not one of the LinuxCNC coders. I may hack something in my hal file to scratch a particular itch in a particular machine, or I might play with a module to be compiled with hal_compile, but its been much of a decade since I waded around in C deep enough to drown. However , in the docs on G41-G49, there is mention of TLO, tool length offset, which would/could effect Z, and likely is the cause of the error. Can I assume that the Z entry in the tool table for that tool is 0.0000? In which case it should be a never mind, but its a special case so 0.0000 may not be being checked for. But I am still bumfuzzled as to why motion would somehow connect any of the M62-65 commands with the execution of the tool offsets. Its a separate, output0 to output3 as specified by the P word. Not being totally aware of those motion outputs, when I needed to do something like flip a jigs location bar in and out of position, or start a vacuum to help clean up the mess, I high jacked the M7-8-9 outputs for those functions. Never saw such an error, but I also do not make any great use of tool compensation either, doing it in the code I write instead. If switching to the use of M62-M63 with the motion sequence I described above doesn't fix it, I'd say in the vernacular that this one needs kicked upstairs. Possibly to the developers list. So, I'll send this to both lists. And I'll snip the previous exchange to help get this down to a readable size. 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> ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
