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... -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
