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 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