› ›

Uart RxBuffer terminal sign

greybeardgreybeard
in Questions & Answers
I am having occasional problems when running in a non ping pong mode of just hanging at certain places.  My question is the following: When the interrupt server for the Uart stores the receive message, after stripping of the Line Number,  should it also strip off all of the LineEnd terminator?  Currently I still keep   \n   from \r\n.  If I am wrong the buffer may overflow at certain times.  I dont have this problem in ping-pong mode when the buffer only has one command at a time. The line end could be still detected when a new new G or M is detected. 

Comments

  • RepetierRepetier
    Treat \n and \r as line end. If you get both the line is empty and you just start over with next command. Host takes all chars it sends into account. The ok causes host to remove send part including \r\n. So could in deed cause the counter to add one byte more then actually freed on first char. Reducing buffer to 126 in host would solve that problem. 
  • greybeardgreybeard
    I am not sure I followed your comments.  Maybe my example will help.  This is all about the printer reception.

    The input message may looks like:   N123 G0 X876.876  Y986.986\n\r    saved as G0 X876.876  Y986.986\n
    I was just wondering if this is what is the normal format.  Do I need to strip of even the last line end \n indicator for the printer receive buffer or is there expected to be a line end indicator.   Because it is possible to remove that and work around it, however it would be a bit more messy.  I am using a 128byte Circular Receive Buffer.

  • RepetierRepetier
    What do you mean with saved? What you do internally is up to you. I would strip the \n but you can also keep it.
  • greybeardgreybeard
    What I mean by  "saved" is that the input message from the host gets stripped of unnecessary headers, check sum, *,  and endings and placed (i.e. saved) into a Serial UART input circular buffer so that it can be used later by the parser to set up various commands for implementation. As far as what I do internally in the printer firmware is naturally up to me, but the input serial  buffer size of 128 bytes must never be exceeded. Therefore the Host has to keep an eye on how many outstanding command lines times their size is accumulated in the Receive Buffer at all times. Otherwise it can overflow in non ping-ponged modes and loose data. However I don't know that the Host uses the same sizing of the message that the Printer firmware uses. I assume it also doesnt count the Line No header or the check sum header "*" and  check sum value but I don't know if it counts the line terminator as  \n\r   or \n   or nothing.  Since all of this is possible. As long as I know these limitations I can implement a safe means to store the incoming data.
  • RepetierRepetier
    Host does not do or care what you do in firmware. One line is until last \r\n and it counts all bytes including these and with the ok to that message it assumes you have removed these bytes from input buffer and can send new lines. On arduino the 128byte ring buffer stores only 127 byte correctly. To be totally save set host buffer to 120.
  • greybeardgreybeard
    G0, G1 and G28  plus a few more output OK before they parse and perform these tasks, so that the buffer isn't really emptied of these commands yet. All other G and M commands output OK after the command line is completely finished. Is this wrong?
  • RepetierRepetier
    Yes that is wrong. ok means send me more I freed buffer already. If a command takes longer then 2 seconds it should additionaly send every 2 seconds

    busy:homing

    or some other message what it is doing. This is to prevent timeout on host side which causes even more commands getting send.
    Simply send ok after the buffer is not needed any more. Either copy it so you send ok faster or delay ok until handled, that is up to you. Handle all commands the same. Host does the same.
  • greybeardgreybeard
    OK then that means that move type commands should output OK after they have been parsed which frees up the receive buffer and other commands after they have been implemented.   Thanks. Actually I've tried all sorts of combinations before and this is the last one.

    I still have a weird problem with commands from the host.
    The host sends commands before I send "start" but these aren't causing interrupts until after "start"  is output . The start is preceeded by a message "Printer reset detected -initializing" .   I guess this is in response to the start?
    So after I output start, I receive N1 and N2 command lines followed by 2 ok then it restarts with N1 again and continues with four M codes, but does not wait for the "ok"  signals after each M code. That just seems wrong. 


  • RepetierRepetier
    "start" causes to resend initalization. At connection we reset board and wait a while for start. If no start comes we assume a board that does not reset and send the stuff without seing a start as that only happens with reset. So I guess you manage to extend initialization period so long that this happens. Normally you should send start in the first second after reset. After that you can add some delays for lcd banner or whereever you want to waste some time:-)
  • greybeardgreybeard
    Why am I geting new commands type M when I dont output ok?

  • RepetierRepetier
    There is this thing that happen - communication error. So if firmware does not respond for a while hosts assume there is a problem and they have just missed the "ok" and send next command. Otherwise we get much more aborted prints.
Sign In or Register to comment.