Re: [Emc-developers] Changes in trunk - Was: New home requirement in trunk

[Eric H. J. <ejo...@ca...>]

Sebastian, et al, 

Ok, made some progress, but something is definitely working differently here
than in previous versions. The short version is that there is a timeout for
the length of time to wait for an NML command to complete (i.e. detect an
appropriate change in status). I had the timeout set to 0.0, which indicates
wait forever. In all previous versions, setting the timeout to 0 always
returned from every command, but using the code in trunk, the NML abort
command in certain instances never completes, at least based on checking for
the appropriate change in status.

If I set the timeout to some small value (1/10th to 1/4 second for example),
then it will drop through after timing out. This mostly works, except I will
get an error:
"Can't do that (EMC_TRAJ_SET_TELEOP_ENABLE) in auto mode with the
interpreter idle."

I thought that was the result of following the abort command with commanding
the mode to change to mdi, and then issuing G0 Z0 to turn the laser off on
an abort, since it is tied to the Z value. I eliminated that, and instead
drop the hostmot2 pwm enable for the laser on an abort.

However I still occasionally get that error. It is fairly minor, because I
can just swallow the error and go on. What I don't understand is why TkEMC
never encounters this error. I can see how it can work by setting timeout to
a non zero value, but not sure why it does not get the "SET_TELEOP" error
somewhere along the way. I have also not figured out whether this error
occurs from the abort, or as a consequence of a command issued immediately
after the abort. I can't reproduce it by entering commands manually, and
while the client side program does have a logging feature, the log is
inconclusive as to exactly when the error occurs.

All this was done to try to track down the other problem I reported, the one
where the CNC would occasionally do a controlled move to relative
coordinates X0, Y0 in the middle of a program. That problem has either gone
away, or worse, just moved someplace else. At any rate, the g-code file in
which I was able to reliably reproduce that problem, now runs flawlessly. 

Here is some more detail on the specific functions involved.

The function emcCommandWaitReceived does the following:

int emcCommandWaitReceived(int serial_number)
{
  double end = 0.0;

  while (emcTimeout <= 0.0 || end < emcTimeout) {
    updateStatus();

    if (emcStatus->echo_serial_number == serial_number) {
      return 0;
    }

    Esleep(EMC_COMMAND_DELAY);
    End += EMC_COMMAND_DELAY;
  }

  Return -1;
}

With emcTimeout set to 0.0, this function would sometimes never return after
issuing an abort. If I set emcTimeout to 0.100 or 0.250 (1/10th second or
1/4 second respectively), it will return, but with a value of -1, indicating
that it returned due to timing out. The test for
emcStatus->echo_serial_number == serial_number never resolves to true.

Further, the call to updateStatus does the following:

int updateStatus()
{
  NMLTYPE type;

  if (0 == emcStatus) || 0 == emcStatusBuffer
    || !emcStatusBuffer->Valid()) {
      return -1;
  }

  switch (type = emcStatusBuffer->peek()) {
    case -1:
      return -1;
      break;
    case 0:
    case EMC_STAT_TYPE:
      break;
    default:
      return -1;
      break;
    }
  return 0;
}

Flow drops through the if statement, and "type" has a value of 1999. I have
not searched through the header files to see what a type of 1999 as of yet.

Regards,
Eric


Try running the client under strace (with -o and -s 1024) and see what it's
getting from the network, to see if it's the sender or the receiver (or
both) that's confused.

I dont know how NML does its network I/O, but there are a bunch of racy ways
to do it that might make it look like messages occasionally getting lost ;-)

Also, if possible, join #emc-devel on irc and we might be able to work
through this quicker than email.


-- 
Sebastian Kuzminsky
"Okay, people. Now is the time to start discussing the rules of war for
autonomous robots. Now, when it's still theoretical." --  Bruce Schneier

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