LCD initialization/usage have high failure rate compare to 0.91 version

[luc-github]

At initialization the AiO boards have very high failure rate and get white screen or 2 lines visibles When printing screen become white randomly and need reboot on 1.0 old generation.

[garry572]

Ive been using 0.92 for more than a week on my 1.0 da Vinci. So far, it been performing well. Ive modified the extruder thermistor table to suit my machine. I have a calibrated thermocouple, so it was easy to get it right. I'm not concerned about the table temperature being off at low temperatures, as the only temperatures of interest are between 120C and 260C, Anything outside this range is either too hot or cold for either PLA, ABS or PET. Ive had a few random LCD failures, only a power up. Done a little investigating. Ive used the HD44780 before and I noticed a few inconsistencies. There is a requirement to have a wait between commands, unless you check the busy status of the LCD controller. Most commands have a delay, but I found a few that didn't. Also in the initialization of the LCD you use the OR function to turn bits on, but you use OR to turn then off as well.. This doesn't work you need to use the AND function to reset bits. This doesn't effect the operation of the display, just is confusing. Overall it been reliable , and the few odd issues haven't been a concern. I will continue testing and report my findings

[luc-github]

thanks a lot Garry, actually I did not do any modification for LCD in this 0.92 - it is original repetier code and they did several changes compare to 0.91 As I do not have any issue on my 2.0 I was waiting for feedback - I will check what you said

[garry572]

The good Luc. I'm not too concerned about the LCD issue only happen rarely, and only on power up. I will see how often the error occurs now that Ive done a few mods. Apart from the LCD, Ive had no real problems with the software, more issues with Repetier not doing what I think it should do.(or what I thought I wanted it to do )

[luc-github]

Feel free to push suggestions of improvement also - if FW can be improved it is good ^_^

[garry572]

I'm making up my own issues log, but it not very long. You've done a great job porting the code to the Da Vinci, I was thinking of doing that as some as I had issues with the XYZ software but fortunately some did it for me :)

[garry572]

oops excuse my spelling, English is my native language and I still cant get it right

[luc-github]

No worry - It is not my native language - so I cant get is right neither ;)

[garry572]

Hi Luc Been doing further testing of the LCD initialization, it determinately temperature related to the display. It our summer here so the lower temperature in the last two weeks was 20C so I never had a issue. Now its a little cooler, Ive had a few failures. Ive modified the LCD initialization to add a few delays to align it with the data sheets i have. This reduced the failures but I found that if i initialized the LCD twice, it always recovered form the error. It seems the LCD doesn't always initialize correctly the first time , but doing it twice, it recovers. Looking back at my past projects I found some notes I had, where some of the poorer quality displays take longer than the specified time, and it was recommended to initialize them twice.

[spaelectronics]

That actually sounds like a good fix. I would implement it to initialize the LCD Twice.

[luc-github]

Yes, looking at what we did on 0.91 https://github.com/luc-github/Repetier-Firmware/issues/37 we got same conclusion : cold boot increase failure rate. adding and increasing some timing reduce failure but do not solve all. Also failure seems high on 1.0 vs 2.0, on my side It is 16 on morning and no failure on my 2.0 with 0.92.

I have also tried the double initialization based on same idea that, if first start failed, second should succeed, because when we power up LCD initialization failed , just restart printer or do emergency stop make it passed. But actually it also bring failure, to be honest I did i once and it failed right away so I drop it and did not reported as tested - may be need more testing, so it worth to do it again.

Anyway I have also a doubt it will solve issue based on fact that: the 1.0A board owners can do 10 restart and they still have screen issue, when on 1.0 just restart it solve the problem.

I think have several factors generating the issue, and one of them is the nature of LCD itself - we are not sure we use correct initialization sequence, as we are not sure of what is the screen type, looks like a clone of HD HD44870, and I found several sheets on the net with some diference in sequences for the clones. Another factor I suspect for 1.0 vs 2.0, is the power supply, but this should only impact the first timing:

    // according to datasheet, we need at least 40ms after power rises above 2.7V      

    // before sending commands. Arduino can turn on way before 4.5V.      

    // is this delay long enough for all cases??     

    HAL::delayMilliseconds(400);       

I first plan to use same timing as 0.91 (https://github.com/luc-github/Repetier-Firmware/blob/davinci/src/ArduinoDUE/Repetier/ui.cpp#L407) so should solve most of 1.0 issues (I guess as I have no issue...), do you have any suggestion/correction about this timing modification ?

About double initialization, do you have an idea of what trigger we could check when LCD failed ? It would help a lot instead of doing a blind double or even triple init. If not I will just do a blind double call for this one:

    WRITE(UI_DISPLAY_RS_PIN, LOW);   
    WRITE(UI_DISPLAY_ENABLE_PIN, LOW);   
     HAL::delayMilliseconds(40);   
    //put the LCD into 4 bit mode   
    // this is according to the hitachi HD44780 datasheet   
    // figure 24, pg 46   

    // we start in 8bit mode, try to set 4 bit mode   
    // at this point we are in 8 bit mode but of course in this   
    // interface 4 pins are dangling unconnected and the values   
    // on them don't matter for these instructions.   
     WRITE(UI_DISPLAY_RS_PIN, LOW);   
    HAL::delayMilliseconds(40);   
    lcdWriteNibble(0x03);   
   HAL::delayMilliseconds(40); // I have one LCD for which 4500 here was not long enough.
    // second try  
    lcdWriteNibble(0x03);   
   HAL::delayMilliseconds(40); // wait   
    // third go!  
    lcdWriteNibble(0x03);   
    HAL::delayMilliseconds(40);   
    // finally, set to 4-bit interface   
    lcdWriteNibble(0x02);   
    HAL::delayMilliseconds(40);   
    // finally, set # lines, font size, etc.    
    lcdCommand(LCD_4BIT | LCD_2LINE | LCD_5X7);     
    HAL::delayMilliseconds(40);   
    lcdCommand(LCD_CLEAR);    //-   Clear Screen    
    HAL::delayMilliseconds(40); // clear is slow operation    
    lcdCommand(LCD_INCREASE | LCD_DISPLAYSHIFTOFF); //- Entrymode (Display Shift: off, Increment Address Counter)     
    HAL::delayMilliseconds(40);    
    lcdCommand(LCD_DISPLAYON | LCD_CURSOROFF | LCD_BLINKINGOFF);    //- Display on    
    HAL::delayMilliseconds(40);     

Any suggestion/correction for this ?

[garry572]

This is the LCD initialization I am current using on 0.92, it a small change from the original, just the Hitachi data sheet I had used a slightly different sequence.

on my 1.0 I have not had any unrecoverable failure by restating the display twice. I can tell if it had failed as there are random characters on the screen after the first initialization, but before the second. It always seems to recover this way, for me anyway.

I'm not sure what controller the LCD uses, it is close to a HD HD44870 but maybe it has some issues we don't know about

WRITE(UI_DISPLAY_RS_PIN, LOW); HAL::delayMicroseconds(5); WRITE(UI_DISPLAY_ENABLE_PIN, LOW);

//put the LCD into 4 bit mode
// this is according to the hitachi HD44780 datasheet
// figure 24, pg 46

// we start in 8bit mode, try to set 4 bit mode
// at this point we are in 8 bit mode but of course in this
// interface 4 pins are dangling unconnected and the values
// on them don't matter for these instructions.
WRITE(UI_DISPLAY_RS_PIN, LOW);
HAL::delayMicroseconds(5);
lcdWriteNibble(0x03);
HAL::delayMicroseconds(5500); // I have one LCD for which 4500 here was not long enough.
// second try
lcdWriteNibble(0x03);
HAL::delayMicroseconds(150); // wait
// third go!
lcdWriteNibble(0x03);
HAL::delayMicroseconds(150);
// finally, set to 4-bit interface
lcdWriteNibble(0x02);
HAL::delayMicroseconds(150);
// finally, set # lines, font size, etc.

lcdCommand(LCD_DISPLAYOFF); 
HAL::delayMicroseconds(120);

lcdCommand(LCD_CLEAR);                  //- Clear Screen
HAL::delayMilliseconds(10); // clear is slow operation

lcdCommand(LCD_4BIT | LCD_2LINE | LCD_5X7);
HAL::delayMicroseconds(120);

lcdCommand(LCD_DISPLAYON | LCD_CURSOROFF | LCD_BLINKINGOFF);    //- Display on
HAL::delayMicroseconds(150);

lcdCommand(LCD_INCREASE | LCD_DISPLAYSHIFTOFF); //- Entrymode (Display Shift: off, Increment Address Counter)
HAL::delayMicroseconds(150);

lcdCommand(LCD_CLEAR);                  //- Clear Screen
HAL::delayMilliseconds(10); // clear is slow operation

[luc-github]

Thanks a lot for sharing I will have a look at it

[luc-github]

Interresting, actually you reduced several timing when we increase them - your experienced improvement by decreasing timing ? I see also you send clear screen command before initialization is finished - any reason for this ?

I will try your sequence

[garry572]

yes according to the data sheets I have, most command complete in a max of 120 usec apart from the clear screen which is 4.0 msec The second clear screen was to see if the screen would recover with being initialized twice I have restarted my 1.0 quite a few time with a single failure, even on the first clear screen. I think part of the issue is that during initialization, the IO line goes from non programmed Io to a digital output, I think sometime the screen sees the Enable line toggled from high to low and take it as a beginning of a command

[luc-github]

I have applied your suggestion timing/sequence https://github.com/luc-github/Repetier-Firmware-0.92/commit/d653f5c80764a463a5b487ec7ecce7fb27e2fd7f

[garry572]

hi luc hope it helps the weather here has taken a turn for the worse, next week will not be under 30C Ive had not LCD initialization failure since I made the change and since it only show up at low temps I will have to wait a while

[luc-github]

I just got white screen just after applied your modifications and another modification present on 0.91 for the write function, so I removed the 0.91 write modification and was fine. I am not sure the other modification was the root cause of the problem, I did not double check by adding modification back to confirm, I may do later - anyway few change step by step is better thanks again for your help and suggestions

Now need to wait someone test on 1.0A to see if there is some improvement for them

[garry572]

that's interesting, i will try the write modification on my 1.0 to see it make any changes good or bad

[luc-github]

ok - I am doing some printing test now - need few hours before I can reflash printer

[garry572]

I'm not sure if im looking in the right place for the 0.91 changes if I'm looking correctly the changes effect the method of setting delays

[luc-github]

yes was a delay line 482 DELAY1MICROSECOND;

} void initializeLCD()

I changed to

if CPU_ARCH == ARCH_AVR

**asm**("nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t");

else

HAL::delayMicroseconds(100);

endif

} void initializeLCD()

then put DELAY1MICROSECOND; back

[garry572]

interesting I will look at it tomorrow, I have a arduino due i will do some testing/verification to see if the delays are generated as expected

[luc-github]

Ok thanks a lot for your help ^_^

[luc-github]

Interresting, Repetier did some change for " faster lcd timing" by ... increasing some timing actually (DELAY2MICROSECOND; and HAL::delayMicroseconds(40);) and reducing the UI_DELAYPERCHAR from 320 to 40 in lcdWriteNibble and lcdWriteByte

https://github.com/repetier/Repetier-Firmware/blob/bd45683f32aa4ba442d41f922f5da16a5e608a51/src/ArduinoDUE/Repetier/ui.cpp then increase timing again: https://github.com/repetier/Repetier-Firmware/commit/08d032adca47f0bde63f5bdc13d69eb78e64639d

What do you think ?

[garry572]

Thats kind of odd, I have a few data sheets comparing supposed compatible HD44870 and they are all different. I have on showing command delays as short as 32uSec and other as long as 150uSec. Ive also now found one from Hitachi that's a later version of the I have, and the initialization sequence for 4 bit display interfaces is long with 2 additional commands

[luc-github]

Yes that what I found also when working on 0.91 improvement - oscahie and I did several test increasing or adding timing, changing sequence, even using other library So I have requested some help to have more tester/feedback on change we could do - http://voltivo.com/forum/davinci-firmware/540-lcd-failure-on-1-0-1-0a-tester-feedback-needed Hope it could help to triger the solution - as unfortunatly I think it will be several try and error loops before we get accurate solution and may be solution will be different according the boards

[garry572]

That's so true so many possibilities of displays. Mine hasn't faulted since I did the mod so I cant verify more than saying is ok by me. I will add the latest info to test on my 1.0 but I think other might need to try it out also

[luc-github]

Yes you are in same situation as me now ^_^

[garry572]

I think it ok to change the UI_DELAYPERCHAR from 320 to 150 as this covers most of the controller variants I have found, anything lower ie 40 might be ok for a fast controller, but theses ones seem slow so it better to be safe

[superdavex]

Just saw your request for 1.0a users on voltivo. I am running .92 compiled from the latest master on a 1.0a. The two issues I have are the LCD initialization failure and the extruder temperature error. It usually takes me 2 to 3 times to get the LCD to initialize properly when powering on. Usually if I turn it on, wait a few seconds, and then turn it off/ on it works.

[luc-github]

Hi superdavex, welcome, thanks for your feedback, appreciate Ok so I will create a branch for testing some change for the LCD, so will be easy to switch to original if it is not working for the temperature we will adjust table to avoid the problem - what temperature the bed display and extruder display on repetier when you connect repetier host ? Also homing Z is working on your 1.0a ? ( I just saw someone raise issue on forum) What it your time zone ? (this is to know when I can do change to deliver test version to you)

[superdavex]

Np, thanks for all the work you have done. This firmware prints much better than stock. The extruder is -12 to -16 and the bed is 19.5 to 19.7. Homing Z works fine for me, I have done many prints with it and never seen an issue. I am in the US Eastern Standard (UTC−05:00). I have noticed the LCD issue only occurs when powering off/on from the switch. If i reboot using left arrow, down arrow, and ok it fixes it every time on the first try. (edit: I had the temps backwards)

[luc-github]

Sorry can you confirm the version of the FW ? it is in settings - version (1.1-201..... because you said "extruder temperature error" and now seems the bed is a problem

that is very interresting that the emergency stop is better than the switch because looks like the timing

    // SEE PAGE 45/46 FOR INITIALIZATION SPECIFICATION!
    // according to datasheet, we need at least 40ms after power rises above 2.7V
    // before sending commands. Arduino can turn on way before 4.5V.
    // is this delay long enough for all cases??
    HAL::delayMilliseconds(400);

is not enough

I will prepare a branch for testing after my breakfast ^_^

[superdavex]

I had those values backwards at first, not sure if you saw the edit. It is the extruder that is in negative values. Currently I have the MIN_DEFECT_TEMPERATURE set to -20 as a workaround.

The version is

define VERSION_MAJOR " 1"

define VERSION_MINOR_YEAR "15"

define VERSION_MINOR_MONTH "01"

define VERSION_MINOR_DAY "02"

define VERSION_BUILD "1"

The delay in the master branch was at 500 HAL::delayMilliseconds(500);

I will trying bumping that up.

[garry572]

I have had no issues with my LCD since the mods, it likely some boards power up differently. Perhaps someone can confirm what the display is ie what manufacturer and pert number so we can narrow down the roor cause of the failures

[luc-github]

I just created a testing branch and changed the value for rise power from 500 to 2000

Ho great - as bed should be OK, table is tweaked already, so I was worry ^_^ Extruder issue is consistent with the current table and my observation of the table data (https://github.com/luc-github/Repetier-Firmware/issues/83) - I will need ADC value - I will update the testing code to display it on screen so you can give it to me and the temperature displaying for the bed to match them

Garry - I already requested information to the guy who removed his screen when he modified his printer - he said he will check but never got any feedback - removing the screen is not easy on Davinci

[superdavex]

Still having the display issues with the 2000ms pause. I still corrects it every time when using emergency stop.

[luc-github]

we have 2 lead : Garry suggested to duplicate initialization Another lead is repetier did several update recently for LCD

I will apply the duplicate of initialization on testing branch first

for extruder temperature I created a new issue to avoid to mix the threads and already modifed the table in testing branch so you can test and feedback https://github.com/luc-github/Repetier-Firmware-0.92/issues/18

[luc-github]

branch updated https://github.com/luc-github/Repetier-Firmware-0.92/commit/c92b35590542625462a0fadc1f7ef9fb207b9d8f

[superdavex]

No change with second initialization.

[luc-github]

Ok - I will revert and prepare the second lead : implement all latest repetier update (https://github.com/repetier/Repetier-Firmware/blob/bd45683f32aa4ba442d41f922f5da16a5e608a51/src/ArduinoDUE/Repetier/ui.cpp and https://github.com/repetier/Repetier-Firmware/commit/08d032adca47f0bde63f5bdc13d69eb78e64639d ) I need 1h or more as I need to do something else first - will post when modification is ready

Thanks a lot for your help

[superdavex]

Ok,no problem. I'll be around

[luc-github]

https://github.com/luc-github/Repetier-Firmware-0.92/commit/e6784ade5a12397d65aeed007b03357da519aa1b ready for test - repetier timing but keep Garry sequence modification

[superdavex]

Still about the same frequency of initialization failures. The LCD has garbled characters on it now instead of black bars though. Emergency stop still fixes it every time.

[luc-github]

Ho before is not white screen but black bars ?

[superdavex]

A mix of that and missing text and random characters. Now its random blank screen and garbled text.

[luc-github]

so little bit better as black screen means no init at all I will put original sequence to see if there is a difference

[luc-github]

updated https://github.com/luc-github/Repetier-Firmware-0.92/commit/0a32ed68bd0def0853b08e94317db7185c98e944

[superdavex]

Still random garbled text and blank screens. But now it also has a normal text screen but constantly shifting the location of the text. The failures seem to be more often. Emergency stop does not fix it now.

[superdavex]

Just tried flashing master, definitely more failures compared to master. With master most failures are blank screens.