Re: [Machinekit] Re: M62/M63 and education about the planner

2016-12-01 Thread schoone...@btinternet.com

  
  

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
 

Re: [Machinekit] Re: M62/M63 and education about the planner

2016-09-08 Thread schoone...@btinternet.com

  
  
Hi Devin

Just so you don't feel your email is broken, thought I would give
you one reply at least  :-P 

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

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.
  Y-0.1000 (OUTPUT
GOES OFF HERE)
G3 X0.2000 Y0.2000 I0. J0.2000
G3 X0. Y0. I-0.7510 J0.
M63P1
G3 X-0.2000 Y0.2000 I-0.2000
  J0.
G1 X0. Y-0.1000
M05
...
  M62 P1 (OUTPUT
  COMES ON HERE)
  G1 G41.1D#<_kerf_rad>
X0. Y-0.1000 
  G3 X0.2000 Y0.2000 I0.
J0.2000
  G3 X0. Y0. I-0.7510
J0.
  M63P1 (OUTPUT
  GOES OFF HERE)
  G3 X-0.2000 Y0.2000 I-0.2000
J0.
  G1 X0. Y-0.1000
  M05