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

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>

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+unsubscr...@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+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