v092: "use_advance" in combination with "drive_system 2"

Comments

• andin

  March 2015

  Correct:

  In my previous post, I made a mistake:

  It should say EXT0_ADVANCE_L, not EXT0_ADVANCE_K obviously.
• Repetier

  March 2015

  Advance has no direct connection with movement in xyz. Moreover it is completely independent of the drive system. So I guess it is not really software related. What I think is that it is an other instance of crosstalk. Maybe to endstops causing moves to stop early (disable always checking endstops to validate) or even influencing of xy somehow, also I haven't seen this happen so far. Normally it is a endstop triggering from stepper signals. Activating advance causes faster stepper rates inducting more current. Something like that.
• andin

  March 2015 edited March 2015

  I was confused as well - there should be no relation between both. always checking endstops is disabled.

  
  

  However, there is no such problem with version 0.91.7. 

  There must be something in 0.92 which creates such problems.

  
  

  Configurations I used for testing both firmware versions were absolutely identical with new features of 0.92 disabled.
• Repetier

  March 2015

  0.92 now has PDM instead of PWM enabled by default. That gives different frequencies on the extruder heater line (more frequent). Yesterday I had a user where this made the difference between crrosstalking and not crosstalking.

  
  

  On the other side, if endstop checking was disabled it should not be crosstalk to endstops creating the problem. But without knowing your printer and knowing how and where all the cables are it is hard to say what is influencing what.
• andin

  March 2015

  Thanks for your quick responses, repetier!
  

  
  The heater was disabled during the test. I also take specific cautions to EMI-related issues by making sure that cables do not radiate and the signals are robust. Crosstalk is minimal on all lines - checked with my oscilloscope...

  
  

  There is this interesting phenomena which seems like a bug in the firmware (or maybe I am missing something):

  
  

  This settings works good:

  #define DRIVE_SYSTEM 2
  

  #define USE_ADVANCE 1

  #define EXT0_ADVANCE_L 0 <--- set using EEPROM

  
  

  Causes erratic movements of X-Y and high motor noise:

  #define DRIVE_SYSTEM 2
  

  #define USE_ADVANCE 0

  #define EXT0_ADVANCE_L 0 <--- not available in EEPROM

  
  

  Ceteris paribus, all other settings remain equal.

  
  

  What other differences there are 0.91.7 vs. 0.92.2 that could cause these issue?
• andin

  March 2015

  Ok, problem found:

  
  

  Repetier Host does not load the EXT0_ADVANCE_L to EEPROM correctly. I assume the parameter is loaded as int and not as float as it is supposed to be, but not sure...

  
  

  Anyway, I have tested saving EXT0_ADVANCE_L 40 to EEPROM using my LCD controller and it works without any problems in X-Y movement thereafter. The act of saving was verified by checking the EEPROM settings from the host. 

  
  

  On the other hand, saving EXT0_ADVANCE_L 40 to EEPROM from the Repetier Host causes problems.

  
  

  :-)

  
  

  
  

  
  
• andin

  March 2015

  Follow-up:

  
  

  The problem persists and is definitely a bug in the firmware:

  
  

  The issues with X-Y movements appear with DRIVE_SYSTEM 2 and after the function setAdvanceActivated() is called.

  
  

  Hardware related problems are out of the question: everything works wonderfully if DRIVE_SYSTEM is set to 1 and/or EXT0_ADVANCE_L=0. Crosstalk problems were excluded after checking with an oscilloscope - besides my hardware setup is very EMI-robust.

  
  

  It would be great if you could verify the firmware. Many thanks!
• Repetier

  March 2015

  I rechecked the firmware. Drive system 1 and 2 are nearly identical and only differ in 2 routines: startXStep and startYStep. See here startXStep for axample

  
  

  #if DRIVE_SYSTEM == XY_GANTRY || DRIVE_SYSTEM == XZ_GANTRY

          if(isXPositiveMove())

          {

              Printer::motorX++;

              Printer::motorYorZ++;

          }

          else

          {

              Printer::motorX--;

              Printer::motorYorZ--;

          }

  #endif

  #if DRIVE_SYSTEM == YX_GANTRY || DRIVE_SYSTEM == ZX_GANTRY

          if(isXPositiveMove())

          {

              Printer::motorX++;

              Printer::motorYorZ--;

          }

          else

          {

              Printer::motorX--;

              Printer::motorYorZ++;

          }

  #endif

  
  

  As you see there is really no difference that could explain it. Only difference is direction of motors.

  
  

  Also does it happen with L = 30 or only with 40? You might be right that you have no crosstalk but I have seen strange things like power units switching of at special extruder PWM frequencies, Y axis loosing some steps for no apparent reason  on Rumba boards and more. Also it is very unlikely that a software problem like this appears only for some very special extruder speed settings. So I still think it is a electronic issue. Maybe you should switch XY with extruder 0/1 sockets and see if it goes away.