Hi all,

I am trying to track down a problem and need to make sense of the debug
output. What is happening is in a very small number of G-Code programs,
instead of doing the commanded vector, it does a move, at the current feed
rate to relative coordinates 0, 0, then picks up at the next vector. It
always occurs at the same vector, but at a probability of about 1 in 8.
Searching the debug output, I can find no instance of issuing a move to 0,
0, other than those I can explain (issuing MDI commands). Shouldn't that
have to show up some place?

This is what I am seeing, starting with the section of g-code where the
problem occurs:

N06670 G01 Z0.0
N06680 G00 X1.6476 Y10.7028
N06690 G01 Z0.1250
N06700 G01 X1.4242 Y10.7165
N06710 G01 X1.2461 Y10.7598  <== This +/- 1 line is where the problem occurs
N06720 G01 X1.1486 Y10.8189
N06730 G01 X1.1152 Y10.9016
N06740 G01 X1.1575 Y10.9941
N06750 G01 X1.3002 Y11.0679
N06760 G01 X1.7264 Y11.1053
N06770 G01 X2.0659 Y11.0659
N06780 G01 X2.2087 Y10.9882
N06790 G01 X2.2372 Y10.9065
N06800 G01 X2.1841 Y10.8061
N06810 G01 X2.0906 Y10.7559
N06820 G01 X1.9547 Y10.7244
N06830 G01 X1.6476 Y10.7028
N06840 G01 Z0.0

The end of the debug output looks like this. The last line is from entering
pause as the X and Y axes start heading for 0, 0:

Motion id 666 took 0.179898 seconds.
Outgoing motion id is 2837.
emcTaskPlanRead() returned 0
emcTaskPlanLine() returned 3952
emcTaskPlanCommand(N39520 G01 Z0.1250) called. (line_number=3952)
emcTaskPlanExecute(0) return 0
emcTaskPlanRead() returned 0
emcTaskPlanLine() returned 3953
emcTaskPlanCommand(N39530 G01 X10.3671 Y7.5640) called. (line_number=3953)
NML_INTERP_LIST::append(nml_msg{size=116,type=220}) : list_size=1001,
line_number = 3952
emcTaskPlanExecute(0) return 0
Issuing EMC_TRAJ_LINEAR_MOVE --          (+220,+116,
+0,11.033500,9.049200,0.125000,0.000000,0.000000,0.000000,0.000000,0.000000,
0.000000,    +2,1.666667,10.004224,35.014785,    +0,)
Motion id 667 took 0.089905 seconds.
Outgoing motion id is 2838.
emcTaskPlanRead() returned 0
emcTaskPlanLine() returned 3954
emcTaskPlanCommand(N39540 G01 Z0.0) called. (line_number=3954)
NML_INTERP_LIST::append(nml_msg{size=116,type=220}) : list_size=1001,
line_number = 3953
emcTaskPlanExecute(0) return 0
Issuing EMC_TRAJ_LINEAR_MOVE --          (+220,+116,
+0,11.033500,9.049200,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,
0.000000,    +2,1.666667,1000.000000,1000.000000,    +0,)
Motion id 668 took 0.179904 seconds.
Outgoing motion id is 2840.
emcTaskPlanRead() returned 0
emcTaskPlanLine() returned 3955
emcTaskPlanCommand(N39550 G00 X10.2884 Y7.4970) called. (line_number=3955)
NML_INTERP_LIST::append(nml_msg{size=116,type=220}) : list_size=1001,
line_number = 3954
NML_INTERP_LIST::append(nml_msg{size=116,type=220}) : list_size=1002,
line_number = 3955
emcTaskPlanExecute(0) return 0
Issuing EMC_TRAJ_LINEAR_MOVE --          (+220,+116,
+0,11.033500,9.049200,0.125000,0.000000,0.000000,0.000000,0.000000,0.000000,
0.000000,    +2,1.666667,1000.000000,1000.000000,    +0,)
Issuing EMC_TASK_PLAN_PAUSE --   (+510,+12,  +105,)

It looks to me what is going on is that lines 3952 through 3955 are being
added to the execution queue, while lines 666 through 668 are actually being
executed. So looking back to the point where line 668 is added to the queue
I find the following debug information:

emcTaskPlanCommand(N06670 G01 Z0.0) called. (line_number=667)
NML_INTERP_LIST::append(nml_msg{size=116,type=220}) : list_size=665,
line_number = 666
emcTaskPlanExecute(0) return 0
emcTaskPlanRead() returned 0
emcTaskPlanLine() returned 668
emcTaskPlanCommand(N06680 G00 X1.6476 Y10.7028) called. (line_number=668)
NML_INTERP_LIST::append(nml_msg{size=116,type=220}) : list_size=666,
line_number = 667
NML_INTERP_LIST::append(nml_msg{size=116,type=220}) : list_size=667,
line_number = 668
emcTaskPlanExecute(0) return 0
Issuing EMC_TASK_PLAN_SYNCH --   (+516,+12,    +0,)
emcTaskPlanSynch() returned 0
emcTaskPlanRead() returned 0
emcTaskPlanLine() returned 669
emcTaskPlanCommand(N06690 G01 Z0.1250) called. (line_number=669)
emcTaskPlanExecute(0) return 0
Outgoing motion id is 2.
emcTaskPlanRead() returned 0
emcTaskPlanLine() returned 670
emcTaskPlanCommand(N06700 G01 X1.4242 Y10.7165) called. (line_number=670)
NML_INTERP_LIST::append(nml_msg{size=116,type=220}) : list_size=667,
line_number = 669
emcTaskPlanExecute(0) return 0
emcTaskPlanRead() returned 0
emcTaskPlanLine() returned 671
emcTaskPlanCommand(N06710 G01 X1.2461 Y10.7598) called. (line_number=671)
NML_INTERP_LIST::append(nml_msg{size=116,type=220}) : list_size=668,
line_number = 670
emcTaskPlanExecute(0) return 0
Issuing EMC_TRAJ_SET_ORIGIN --   (+224,+84,
+0,-0.000000,-0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
,0.000000,)
emcTaskPlanRead() returned 0


The interesting part is where it issues EMC_TRAJ_SET_ORIGIN in line 671.
This is the only point in the execution of the g-code (from auto mode) where
this call is made. However the same call appears in the same place on all
the instances that worked too. I point this out only because it seems
awfully coincidental that a set origin call is very close to the point where
it does the move to 0,0.

Is there another way, or better way to trap for this condition, other than
the debug output?

Additional information:

What I suspect is happening is that it is related to running my network
interface (emcrsh) on an isolated network (i.e. no valid gateway address).
That seems to be the common element, because if I run any local user
interface, the problem does not occur, and if I run on a network with a
valid (resolvable) gateway address, then it also runs without error. To
prove this I need to pick up a dumb hub, as I have been unsuccessful it
getting my second identically configured box to exhibit the same error.
However it is going through a smart switch with the uplink port
disconnected, rather than an ordinary hub. So that may be what is allowing
it to work.

If it turns out to be the case, then I have to figure out how my interface
can affect the commanded position even though the system is in auto mode.

Regards,
Eric




------------------------------------------------------------------------------
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to