Melzi v2 and ?zonestar? on Tronxy X3

Comments

• Repetier

  January 2017

  Maybe the chip is a bit slower then others. There is a macro UI_DELAYPERCHAR  that defines how long to wait after a 4 bit nibble is send. Search for it and increase the value and see if it works. If it helps let us know what you needed to get it working so we can adjust the default value.
• Tsoukan

  January 2017

  Thanks, I just did a search in the factory firmware that the seller supplied and found that UI_DELAYPERCHAR was set to 320 everywhere.  I'll try changing the value to that as a starting point and I'll let you know how it goes.  If it works at 320 is there any benefit to seeing how low I can go before the problem returns?
  
• Tsoukan

  January 2017 edited January 2017

  So I tried 320, 500 and 1500 with not significant changes to the phenomenon.
  
  Here is a link to a video of the issue...
  https://1drv.ms/v/s!Ao5MY57jQx33iPcdORaLZwBShKBTng
  
  
  
  Staring at it while printing the phenomenon is much worse - seems to be more frequent and the characters shift more positions
  https://1drv.ms/v/s!Ao5MY57jQx33iPcg3LO2tp4DPPYuZg
  
  Everything else seems to work fine.
  
• Repetier

  January 2017

  It really seems like the display does get a bit wrong from time to time. Since display updates every second it fixes itself after a second until it goes wrong again. So since it works with older versions the timings seem to tight at some point. Maybe not the delay you used or it got overwritten in DisplayList.h/ui.h (depending on version). The problem is therefore in ui.cpp in this code:

  
  

  void lcdWriteNibble(uint8_t value)

  {

      WRITE(UI_DISPLAY_D4_PIN,value & 1);

      WRITE(UI_DISPLAY_D5_PIN,value & 2);

      WRITE(UI_DISPLAY_D6_PIN,value & 4);

      WRITE(UI_DISPLAY_D7_PIN,value & 8);

      DELAY1MICROSECOND;

      WRITE(UI_DISPLAY_ENABLE_PIN, HIGH);// enable pulse must be >450ns

      HAL::delayMicroseconds(2);

      WRITE(UI_DISPLAY_ENABLE_PIN, LOW);

      HAL::delayMicroseconds(UI_DELAYPERCHAR);

  }

  
  

  you see there are 2 more delays 1MS and 2ms. So maybe increase them by 1 and retest.
• Tsoukan

  January 2017

  No dice...
  
  I tried changing the first HAL::delayMicroseconds to 2, 10, 500 - no noticeable change
  I tried changing the second HAL::delayMicroseconds to 2, 10, 50, 320, 500 - no noticeable change
  I tried changing the DELAY1MICROSECOND to DELAY2MICROSECOND and since there is not 3 defined I added repeats up to 10.  - no significant change
  I tried multiple combinations with no significant change.
  
  Thanks for the help so far, any other suggestions?
  
• Repetier

  January 2017

  Not at the moment. My bet was on timings there since we know we are sending correct data as we normally see anything. But now I have no idea where that bit gets changed for you.
• Tsoukan

  January 2017

  I am working on muddling my way through the original firmware to see if I can track down how it was configured there.  As this is my first adventure into Arduino the learning curve is vertical.  I work in IT and have some scripting knowledge (VB and Powershell) but no development experience so your patients and assistance so far is appreciated.
  
  In the lcdWriteByte function in ui.h what is the interpretation of the first if statement in particular the "false" -
  #if false && UI_DISPLAY_RW_PIN >= 0 // not really needed
  
  The reason I ask is because in the original firmware has the following instead of the single if statement.
  #if UI_DISPLAY_RW_PIN<0
      HAL::delayMicroseconds(UI_DELAYPERCHAR);
  #else
  
  
  The remaining code in the function appears identical if I assume that
  #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(1);
  #endif
  is functionally equal to
  DELAY1MICROSECOND;
• Repetier

  January 2017

  #if false && UI_DISPLAY_RW_PIN >= 0 // not really needed

  
  

  means do not execute that section. No one is using rw pin for displays anyway so we do not ask display if byte is received and just wait long enough.

  
  

  #if CPU_ARCH == ARCH_AVR is just a test which cu is used and uses simple no operation assembler to delay 1us while for due we use the function.
  

  
  

  I rechecked the code and you are right that lcdWriteByte is more important as it is used to send complete bytes. So you should change timings there instead.

  
  

  The difference is between sending the first 4 bit and the second 4 bit. If that is too fast the display might read wrong values. So yes, try longer delays there. As you see in current version for radds display we already had increased it to 10 but normally use 2. Maybe 3-10 works better. You want as low as possible since that stops your computations making firmware react slower. But of course long enough to work.

  
  
• Tsoukan

  January 2017

  So after tweaking timings everywhere, even adding delays between setting the RS pin.  Increasing delays anywhere only seems to make things worse, and completely removing them leads to complete corruption.  I even cut and paste the nibble and byte code from the original firmware, replacing those sections in the 0.92 without any improvement.  Issue still goes away with the complete 0.91 compiled code so I know the display "can" work...
  
  This did give me lots of time to observe the phenomenon.  The characters always toggle to the character where the least significant bit of a nibble is a 0 and not a 1, never the other way.  For example a "u" 01110101 will become an "e" 01100101 or sometimes a "t" 01110100 but the bit will never flip the other way so the "u" will never become a "v" 01110110 and a "B" 01000010 never seems to be affected.  Also the u is more likely to become an e over the t.  I did increase the delay between the nibbles in the byte function without any imporvement, things seemed worse in fact.  Don't know if this sheds any light on it.
  
  For now I am content with a slightly wonky display since it seems to be purely and esthetic problem that is not affecting a lot of users - a least searching the forum and the google doesn't turn up anyone else with this issue.  If you have any other suggestions to try let me know.
  
  All this talk of nibbles and bytes is making me hungry....after I solve that issue it is onto getting a BLtouch working.
  
• e_things4you

  January 2017

  Hi, can you please post the .91 and .92 firmware so I can download it. I have the tronxy x3, and want to enable auto level, but am having a hard time compiling the firmware from scratch. Thank you.
• Tsoukan

  January 2017

  Someone was nice enough to post the factory firmware here https://github.com/worder/tronxy-x3-repetier-firmware
  
  For the .92 firmware the configuration tool works well.  Use the Zonestar option for the display and pin1 for the ADC.  If look at your eeprom values  should be able to find all the values you need to complete the configuration tool.  I won't be near my printer until Sunday or Monday, if you don't get things working let me know and I'll be able to share my configuration file.
  
  You will need to be able to run Arduino 1.0.x to compile the .91 and the latest arduino version for .92.  The solution that I have that works on Windows is to install the 1.0 Arduino and use the "portable" option for the 1.8 (https://www.arduino.cc/en/Guide/PortableIDE).  If you have not already done so you will need the sanguino hardware files from https://github.com/Lauszus/Sanguino.   BTW, I had to re-flash my bootloader to get things working initially so if you don't get complile errors and avrdude errors out a the start of the upload you may be in the same boat.
  
  When you get .92 installed on yours I would be really interested to know if you have the same glitch on the LCD. 
  
• e_things4you

  January 2017

  Thank you for all the info, I'm very new to Arduino, but am a quick learner. I will post my results when I get the time to fiddle with it. I was able to get the marlin firmware from here https://github.com/erikkallen/Marlin_tronxy installed and working with auto level. But I prefer the reptier .91 that was originally on it. And I'm sure .92 will be that much better.
• boughman

  October 2017

  Hallo,
  Is there anybody who can post an actual firmware for the x3s?
  I crashed my board and I really have no experiences.
  Boughman