On Thursday, September 8, 2016 at 12:28:30 PM UTC-4, Schooner wrote: > > Hi Devin > > Just so you don't feel your email is broken, thought I would give you one > reply at least :-P >
Thanks for the response! For some reason I wasn't notified back when you answered, and when I searched for remapping today this thread was a top result. > > > You are not the first to discover or wonder about this. > > > https://forum.linuxcnc.org/forum/38-general-linuxcnc-questions/9802-cannot-set-auxiliary-digital-output-with-cutter > http://emc-developers.narkive.com/zSqCKpkO/emc-users-tool-offset > just for 2 > > M64/65 are easier to understand the case for, since they are queue > blockers, but M62/63 less so > > I have looked at interp_convert_m() in interp_convert.cc previously, where > the rules for M codes are enforced, but did not gain enlightenment. > > In the past I have side stepped the issue, by never bothering with DIO, > since I found it easier to work at HAL level and write a rt component > to do the work and check a pin value as part of a conditional loop in the > gcode, if it is actually necessary to do it there at all. > > ie. by setting > > [RS274NGC] > FEATURES = 8 (or higher I think, seem to recall it is a bitmap of OR'd > values, not an absolute number) > in the ini file > > and using the parameter addressing brought in with the remap code AFAIR > > #<_hal[name_of_pin]> > Can you elaborate a little on this? I can't seem to find any docs and I'm not sure what I'm looking for in the code base. As a test, I wanted to read an ini pin exposed in the hal, something trivial like a max limit for axis 0. > > I think the pin has to be referenced in the hal files, for it to work, > but it is not likely you are going to want to check the value of one that > isn't. > > I you achieve M62 enlightenment, do let us know! > > regards > > > > On 07/09/16 14:09, Devin Hughes wrote: > > On Wednesday, September 7, 2016 at 1:47:39 AM UTC-4, Devin Hughes wrote: >> >> Sorry for the noise if you're not interested, but I've seen a lot of >> unanswered questions about this on the internet so I thought I'd look into >> it deeper. >> >> On Tuesday, September 6, 2016 at 10:46:07 PM UTC-4, Devin Hughes wrote: >>> >>> On Tuesday, September 6, 2016 at 9:19:26 PM UTC-4, Devin Hughes wrote: >>>> >>>> >>>> >>>> On Tuesday, September 6, 2016 at 11:17:11 AM UTC-4, Devin Hughes wrote: >>>>> >>>>> Hi Everyone, >>>>> >>>>> I was hoping someone a little more experienced with the planner could >>>>> explain some behavior to me. In the code, there are specific error checks >>>>> that do not allow digital outputs to change state if cutter compensation >>>>> is >>>>> turned on. First question, why? What cutter comp logic is broken by a >>>>> motion synchronized digital output? M64/M65 look like they could be queue >>>>> busters, and maybe the logic get's complex to replan, but I don't >>>>> understand the restriction on M62/M63. >>>>> >>>>> As a test, I commented out the guard checking for cutter comp and used >>>>> the following snippet of code: >>>>> >>>>> M62 P1 (OUTPUT COMES ON HERE) >>>>> G1 G41.1D#<_kerf_rad> X0.0000 Y-0.1000 (OUTPUT GOES OFF HERE) >>>>> G3 X0.2000 Y0.2000 I0.0000 J0.2000 >>>>> G3 X0.0000 Y0.0000 I-0.7510 J0.0000 >>>>> M63P1 >>>>> G3 X-0.2000 Y0.2000 I-0.2000 J0.0000 >>>>> G1 X0.0000 Y-0.1000 >>>>> M05 >>>>> ... >>>>> M62 P1 (OUTPUT COMES ON HERE) >>>>> G1 G41.1D#<_kerf_rad> X0.0000 Y-0.1000 >>>>> G3 X0.2000 Y0.2000 I0.0000 J0.2000 >>>>> G3 X0.0000 Y0.0000 I-0.7510 J0.0000 >>>>> M63P1 (OUTPUT GOES OFF HERE) >>>>> G3 X-0.2000 Y0.2000 I-0.2000 J0.0000 >>>>> G1 X0.0000 Y-0.1000 >>>>> M05 >>>>> >>>>> >>>>> I commented above about the side effects I'm seeing. The first call to >>>>> turn on the ouput works, but the state is immediately cleared in the next >>>>> line. Then, the second time the code is encountered, it works as >>>>> expected. >>>>> There are no hiccups in motion though, it is perfectly smooth. >>>>> >>>>> To test if I broke something elsewhere, I used the below snippet >>>>> (which is above, but without cutter comp, and only the first >>>>> nonfunctional >>>>> hole): >>>>> >>>>> M62 P1 (OUTPUT COMES ON HERE) >>>>> G91 G1 X0.0000 Y-0.1000 >>>>> G3 X0.2000 Y0.2000 I0.0000 J0.2000 >>>>> G3 X0.0000 Y0.0000 I-0.7511 J0.0000 >>>>> M63 P1 (OUTPUT GOES OFF HERE) >>>>> G3 X-0.2000 Y0.2000 I-0.2000 J0.0000 >>>>> G1 X0.0000 Y-0.1000 >>>>> M05 >>>>> ... >>>>> >>>>> This version works as expected, the output remains in the requested >>>>> state. >>>>> >>>>> I'm a little stumped, why does cutter comp enable/disable affect gpio? >>>>> >>>>> Thanks for any guidance, >>>>> Devin >>>>> >>>>> >>>> Digging further, it seems that all roads lead to emctaskmain.cc. There, >>>> the plan function emits the command to control a digital output provided >>>> the mode is manual or mdi. Auto mode only handles the case for an >>>> auxiliary >>>> input. I must be missing something because the spindle / coolant commands >>>> all appear in the planner under auto mode cases as well. I would think the >>>> auxiliary motion digital outputs would be treated similarly, but they do >>>> not appear in the places I'd expect to see them (all the places coolant >>>> controls appear, for instance). I still haven't found the cutter comp >>>> interaction though - still searching. >>>> >>> >>> Looks like the spindle hal pins are directly updated by motion in the >>> output_to_hal() function, but the digital/analog io are passed off to be >>> handled by the trajectory planner. An example of which is tpToggleDIOs() in >>> tp.c. >>> >>> For M64/M65 especially, why does the tp need to know about the io? Why >>> wouldn't we want asynchronous aux digital outputs to be handled the same >>> way as the asynchronous spindle outputs? Any insight on the double standard? >>> >> >> I found the part that does the final handling of the asynchronous digital >> io. Now I understand that it does indeed parallel the handling of the >> spindle outputs and never hits the trajectory planner. To try and >> understand the problem initially posted with the inconsistent output, I >> decided to change to M64/M65. I know the manuals say that this will wreck >> the planner, but I'm not sure how this happens since it never gets posted >> to tp.c (or whichever planner is active), everything is done in motion >> before the tp gets involved. I think M62/M63 could force the tp to plan a >> full stop on a line based on the checks in tc.c. >> >> How cutter comp is involved (and different from a normal move) is a >> little hazy to me still. The major difference I can find is the involvement >> of convert_queues - non cutter comp moves skip this layer. Further, I can >> see the convert_straight and convert_arc functions calling two versions of >> cutter comp functions, 1st move and not 1st move. First moves never dequeue >> the added motions, which I imagine allows the following blocks (up until >> the first call to convert_xxx_comp2) to blend with the initial block when >> they call move_endpoint_and_flush(). >> >> This makes me wonder if the reason the gpio was not being set correctly >> in the example above is because of this skip in moves with the blocks - >> i.e., the M62 call had no linear move following immediately with it to sync >> the output with since the g1 move was trapped in the convert_queues qc() >> until the next block. Maybe the M62 was lost in the wind... >> > > Everything is clear to me with the exception of taskPlan in > emcTaskmain.cc. Why do the following only appear in mdi and manual mode, > and not auto? How do the M6x commands actually get emitted without a call > to emcTaskIssueCommand() during auto execution? > > case EMC_MOTION_SET_DOUT_TYPE: > case EMC_MOTION_SET_AOUT_TYPE: > case EMC_MOTION_ADAPTIVE_TYPE: > > > > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
