#Marlin 336 rc serial number date software
#Marlin 336 rc serial number date code

#Marlin 336 rc serial number date code

But I optimized the code since theese day. I did this already as I saw the errors when I started the advance coding, without success. To proof this, I set the baud rate to 115200 again. Maybe not much, but 40µs are not much too. That there are even more errors with RC6 means that the stepper ISR is a tad slower than in RC4. So the answer why I get much more errors with enabled advance is clear: I'm doing a few more calculations inside stepper ISR. But if this loop takes more than 40µs, the char is gone - my error messages are triggered now. That may be the reason why there is another checkpoint inside the stepper ISR, which tries to store a char at every loop. The interrupt triggered when a new char is recieved - but this one has nearly the lowest possible priority available on the Atmega so it may be 'postponed' by timer0 interrupts used by the steppers, it get's even worse with the timer1 used by the advance stepper ISR. ) There are two ways of storing a new char: If the char is not read, it gets replaced by the next one sent by the host. ) At a baud rate of 250000, there is a new char every 40µs. The serials RX-interrupt is executed too late - the RX-registers content was replaced by the next char.Īnd looking how Marlin handles available chars, I would sum up as followed. Missing chars -> an ISR takes too long, or a CRITICAL_SECTION is not closed properly. I will build AnHardt#32 into my code and run some tests with it, but it will take some time to get results as my printer is blocked for the next 9h. Than it should be more likely that a ISR is 'hitting' the transfer of the 0.5s long slow 115200 baud than it's hitting a only 0.25s long transfer?įor me as a hobby-programmer I would say higher rate should be better to not influence with stepper ISR. I might be wrong, but do you think so? If we need to transfer 10 commands for a print, say each one takes 0.5s (I know, only for easy calculation) at 115200 baud and 0.25 at 250000 baud and the ISR is running at a fixed rate. otherwise we would need to be really screwing it up to still affect 115.2bps. This for me somehow clears the ISR delay errors.

#Marlin 336 rc serial number date software

RC4 runs 'smooth' even with advance (maybe 4-5 errors per hour), RCBugFix on the other side is flooding the pronterface status window with error messages and 1-2 times per hour the printer is even doing wrong 'print' moves to one edge of the print bed (only limited by software end limits I guess). I'm in the process of printing 70 identical parts, so all tests are done with the exact same gcode. Maybe little input debug helpers can give a hint. 'Strange' pointer from somewhere? Wrong array indices in a near by array? Likelihood increases with the amount of buffer content - unlikely with ping-pong. Is unlikely with 8bit buffer indices and interrupt protection. But more likely with increased frequency of high current lines near the serial lines. That's unlikely to change with release versions. That makes missing to fetch a char from the register unlikely.Įrrors on the USB between host and AT32U2 (used as the USB chip) is unlikely because of the USB block checksum.Įrrors on the serial line between AT32U2 and AT2560 (hardware problem). No improvement with 115200bd means doublet time between arriving chars. Using Promterface translates to me as using ping-pong, That makes overfilling the RX-buffer unlikely. I'm not using speed ranges where double stepping would occur in the last days, I went up to 80% of single step mode. I'm using pronterface with 250000 baud, changed it to 115200 with no sucess. If there are already ideas to test in some branches or forks, I would be happy to test them. There are more errors as the ISR rate or duration is increased because the probability increases that an ISR happens at the time where something with the communication is done. I guess the main ISR can interrupt something in the USB communication, if that happens the transfer gets corrupted. I have not the skill to track this down in detail without help. It was better in RC4, I get significant more errors in current RCBugFix.At high speed, especialy high speed combined with high needed command transfer rate due to short line segments, the error rate increases. It scales with print speed (higher ISR rate): At normal speeds (say up to 50-60mm/s) there is nearly no error, maybe one in some print hours.It's not the USB cable or the USB port.This is not related to my advance patch, but enabling it makes the problem worse as the main isr takes more time.I'm also writing for others from the Lulzbot forum, where we have threads from time to time that are also based on communication problems.

Error:Line Number is not Last Line Number+1, Last Line: 412