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

Reply via email to