› ›

Debug trick?

greybeardgreybeard
in Questions & Answers
My firmware works in ping pong mode, but still has problems otherwise.  I am trying to figure out what the problem is.
Looking at the uart_rx buffer it looks like it did the last command and the head and tail pointers are the same so that it finished all commands to that point. What I am not sure about is whether the acknowledge "ok" from the firmware is truly in response to the last command that was performed before it halted.  I am wondering if I could add a Delay by using Dwell time G4 command that would allow the previous commands to finish and catch up.  If there is a mismatch in the acknowledge and in fact I lost a command acknowledge causing the host to halt and wait, then perhaps the halt would ensure this didnt happen??  Another possibility would be to add the line number to "ok" if I can figure out a way and if this additional number didn't cause a problem with the Host? It would be simpler to echo back the command being performed with the OK, but its unlikely that this would be displayed by the host?? Does any of this make sense?

Comments

  • RepetierRepetier
    You should always return ok linenumber with linenumber & 65535 to reduce space. That is what host and server expect and also use to fix missed line numbers in non ping pong mode. G4 is done on firmware so using that to debug is not helpfull here. In repetier firmware you can also enable echo denug option with M111 so it writes echo: command so you see what was last.
  • greybeardgreybeard
    That should be quite helpful, thanks.  I have tried adding a G4 command and found that it goes further but stops again.  It seems that G1 commands are too slow and perhaps exceed the timeout and that could be the reason for the halts.  In ping pong mode it doesn't halt but runs to the finish. I wonder why that works.
  • greybeardgreybeard
    The speed and time to completion of an earlier G1 was quite large but that did not halt the machine, so I dont know it that is the real problem. I will add the Line numbers because that will be a better indication. 


  • greybeardgreybeard
    I have added the line numbers to OK and it was very helpful in seeing what is happening.  It indicated that the last command's acknowledge wasn't received, yet the move which follows the OK for G1 commands did take place. Perhaps, I cant understand how,  the acknowledge was clobbered and never wasn't output or received by the host. The second situation is very unlikely. 
  • RepetierRepetier
    Are you still in ping-pong mode? In the normal mode it would send several commands and correct missing ok from line number.
  • greybeardgreybeard
    NO ping pong works. I am not in ping-pong mode. I am running out of ideas about why I have this problem and am considering the possibility that perhaps my interrupt driver is too long and cant keep up when the transmit and receive buffers are both active.  Is the only way to slow the transfer is by slowing the baud rate?  No way to program the time between updates?
  • greybeardgreybeard
    Perhaps the UART should not be sending a message while in the receive interrupt, but wait till it finishes to send??
  • RepetierRepetier
    Not sur what you mean with sending while in receive interrupt. Receive interrupt must be a very short code part just buffering input and do nothing else. Send interrupt does the same. Just sending bytes in send buffer. If you parse in receive interrupt you are lost anyway. Interrupts always must be very short to not miss one. 
Sign In or Register to comment.