On Thursday, December 1, 2016 at 12:27:29 PM UTC-5, Schooner wrote: > > > On 01/12/16 16:23, Devin Hughes wrote: > > 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. > > > In a hal file you can access with [SECTION](VALUENAME) - even > [SECTION]VALUENAME seems to work too > eg > the motmod line at the start of most hal files > 'loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD > num_joints=[TRAJ]AXES kins=trivkins tp=tp' > and > 'addf hm2_[HOSTMOT2](BOARD).0.read servo-thread' > etc >
I knew about this one, and I use it pretty heavily. > > In gcode you access with #<_hal[pinname]> if the access level is set > properly > http://www.machinekit.io/docs/remap/structure/ > > You can also access ini vars from gcode with > > #<_ini[SECTION]VALUENAME> > But this one! Awesome! I think I missed the docs because that page seems broken after a remap statement (it switches to an uncompiled source view?). I will search more, thanks for your guidance. > > > That is covered in the remap doc too, heavy reading but the info is in > there somewhere :) > > Best way to test is execute DEBUG commands in MDI > > regards > > > >> >> 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]. >> 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] <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.
