incorrect operation of the menu

[AnatoliyKube]

1 all versions: if you enter the menu -MOVE AXIS -and set the movement (1 mm) let 100mm , displacement will be larger (say 120 mm). When working with Repetier-Host the movement of the target value -the menu must be provided the opportunity to set the first and then perform, because when setting the movement already starting to happen, and because of this is an accumulation of errors when you move (в меню нужно предусмотреть возможность сперва установить значение а потом выполнить , потому что при установки значения уже начинает происходить перемещение, и из за этого происходит накопление ошибки при перемещении)

[AnatoliyKube]

2 RC version а if you set the temperature NOZLLE ,let's say 240 degrees,and then (after a while) to set the temperature BED ,let's say 90 degrees, or change it , temperature NOZLLE It sets itself in 210 в if you select the heating mode, for example ABS , and after heating to select the file from the SDcard printing , and then try to change the temperature of the menu TUNE - after the change of temperature can not exit from the menu, the unit hangs completely, withdraw can only be with the button RESET

[Blue-Marlin]

No. I don't think so. When working in the move-axis-menus on the display we display a absolute position. With turning the knob we change the absolute position in steps determined by the menu we are in (10/1/0.1). If we want to use the one or the other is a matter of, if we want to change the value fast or precise. Marlins reaction to the changed, displayed value is a absolute move to the new position. There is no accumulation of errors.

When using a host, the buttons work in relative mode. They are sending G91 G0 ?-10 G90. Here a accumulation of errors is possible, but that's not Marlins fault. The hosts could have an internal position, in/decrement that, send a absolute G0, ask Marlin about its new position with M114 and update the internal position.

The errors in your second message are supposed to be already fixed in RCBugFix.

[AnatoliyKube]

thanks for the answer Post 1 why did this happen? I exhibited a size between the extruder nozzle and the table, and asked to shift the axis of the axis ns to 100 mm (from the menu) and then shifted to 100 mm back, and I worked on the endstop 92 mm

The essence is that while I scroll encoder, exposing the value, the movement has already begun, and the value of the counter of steps begins to change, but probably change the variable is a little on the true test, with lateness engine has already made a step and engine variable has not changed (not increased), and is obtained by adding to the already made steps. I noticed that the more I twist the encoder - the greater the error I do not know how to explain it to you (I do not know English perfectly), but similar cases in the development of the programs I have come across, and it 's called - the human factor (I did a design engineer of radio equipment and a lot of work with the AVR, but the assembler)

[Blue-Marlin]

That looks a bit as if your DEFAULT_AXIS_STEPS_PER_UNIT could be wrong. Is you EEPROM activated? Gives M503 the same values as in your configuration. Recalculate them. (http://calculator.josefprusa.cz)

[AnatoliyKube]

Steps for the motor are correct when operating in repetier-host everything is fine, it's only when I use the encoder and the menu on the display

[Blue-Marlin]

Are the moves from the menu faster than from RepetierHost? Could you move too fast? Are you losing steps? Has MANUAL_FEEDRATE a reasonable value?

[AnatoliyKube]

Thank you . Edition RCBugFix these are no problems , questions 1 Why encoder works in reverse ? to the right -decreases ,to the left - increases in ergonomics to the right - MAX , to the left - MIN how to fix ? 2I do not like how the car park must: 1 up Z 2 then parking how to fix ?

[Blue-Marlin]

1 Why encoder works in reverse ? to the right -decreases ,to the left - increases in ergonomics to the right - MAX , to the left - MIN how to fix ?

//#define SD_CHECK_AND_RETRY // Use CRC checks and retries on the SD communication
- //#define ENCODER_PULSES_PER_STEP 1 // Increase if you have a high resolution encoder
+ #define ENCODER_PULSES_PER_STEP -1 // Increase if you have a high resolution encoder
//#define ENCODER_STEPS_PER_MENU_ITEM 5 // Set according to ENCODER_PULSES_PER_STEP or your liking

[AnatoliyKube]

It works, thanks

[AnatoliyKube]

Edition RCBugFix command G29 not working properly , RC version ok.

[Blue-Marlin]

Edition RCBugFix command G29 not working properly

What is the problem?

[AnatoliyKube]

I give a command G29 - There is no movement (Version RC100 works)

//===========================================================================

// @section bedlevel
#define AUTO_BED_LEVELING_FEATURE // Delete the comment to enable (remove // at the start of the line)
//#define DEBUG_LEVELING_FEATURE
#define Z_MIN_PROBE_REPEATABILITY_TEST  // If not commented out, Z-Probe Repeatability test will be included if Auto Bed Leveling is Enabled.

#if ENABLED(AUTO_BED_LEVELING_FEATURE)

  // There are 2 different ways to specify probing locations:
  //
  // - "grid" mode
  //   Probe several points in a rectangular grid.
  //   You specify the rectangle and the density of sample points.
  //   This mode is preferred because there are more measurements.
  //
  // - "3-point" mode
  //   Probe 3 arbitrary points on the bed (that aren't colinear)
  //   You specify the XY coordinates of all 3 points.

  // Enable this to sample the bed in a grid (least squares solution).
  // Note: this feature generates 10KB extra code size.
  #define AUTO_BED_LEVELING_GRID

  #if ENABLED(AUTO_BED_LEVELING_GRID)

    #define LEFT_PROBE_BED_POSITION 15
    #define RIGHT_PROBE_BED_POSITION 170
    #define FRONT_PROBE_BED_POSITION 20
    #define BACK_PROBE_BED_POSITION 170

    #define MIN_PROBE_EDGE 10 // The Z probe minimum square sides can be no smaller than this.

    // Set the number of grid points per dimension.
    // You probably don't need more than 3 (squared=9).
    #define AUTO_BED_LEVELING_GRID_POINTS 2

  #else  // !AUTO_BED_LEVELING_GRID

    // Arbitrary points to probe.
    // A simple cross-product is used to estimate the plane of the bed.
    #define ABL_PROBE_PT_1_X 15
    #define ABL_PROBE_PT_1_Y 180
    #define ABL_PROBE_PT_2_X 15
    #define ABL_PROBE_PT_2_Y 20
    #define ABL_PROBE_PT_3_X 170
    #define ABL_PROBE_PT_3_Y 20

  #endif // AUTO_BED_LEVELING_GRID

  // Offsets to the Z probe relative to the nozzle tip.
  // X and Y offsets must be integers.
  #define X_PROBE_OFFSET_FROM_EXTRUDER -0//25     // Z probe to nozzle X offset: -left  +right
  #define Y_PROBE_OFFSET_FROM_EXTRUDER -0//29     // Z probe to nozzle Y offset: -front +behind
  #define Z_PROBE_OFFSET_FROM_EXTRUDER -4//12.35  // Z probe to nozzle Z offset: -below (always!)

  #define Z_RAISE_BEFORE_HOMING 4       // (in mm) Raise Z axis before homing (G28) for Z probe clearance.
                                        // Be sure you have this distance over your Z_MAX_POS in case.

  #define XY_TRAVEL_SPEED 8000         // X and Y axis travel speed between probes, in mm/min.

  #define Z_RAISE_BEFORE_PROBING 15   // How much the Z axis will be raised before traveling to the first probing point.
  #define Z_RAISE_BETWEEN_PROBINGS 5  // How much the Z axis will be raised when traveling from between next probing points.
  #define Z_RAISE_AFTER_PROBING 15    // How much the Z axis will be raised after the last probing point.

 // #define Z_PROBE_END_SCRIPT "G1 Z10 F12000\nG1 X15 Y330\nG1 Z0.5\nG1 Z10" // These commands will be executed in the end of G29 routine.
                                                                             // Useful to retract a deployable Z probe.

 // #define Z_PROBE_SLED // Turn on if you have a Z probe mounted on a sled like those designed by Charles Bell.
  //#define SLED_DOCKING_OFFSET 5 // The extra distance the X axis must travel to pickup the sled. 0 should be fine but you can push it further if you'd like.

  //If you have enabled the Bed Auto Leveling and are using the same Z Probe for Z Homing,
  //it is highly recommended you let this Z_SAFE_HOMING enabled!!!

  #define Z_SAFE_HOMING   // This feature is meant to avoid Z homing with Z probe outside the bed area.
                          // When defined, it will:
                          // - Allow Z homing only after X and Y homing AND stepper drivers still enabled.
                          // - If stepper drivers timeout, it will need X and Y homing again before Z homing.
                          // - Position the Z probe in a defined XY point before Z Homing when homing all axis (G28).
                          // - Block Z homing only when the Z probe is outside bed area.

  #if ENABLED(Z_SAFE_HOMING)
// at G28  not be carrying out !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    #define Z_SAFE_HOMING_X_POINT ((X_MIN_POS + X_MAX_POS) / 2)    // X point for Z homing when homing all axis (G28).
    #define Z_SAFE_HOMING_Y_POINT ((Y_MIN_POS + Y_MAX_POS) / 2)    // Y point for Z homing when homing all axis (G28).

  #endif

  // Support for a dedicated Z probe endstop separate from the Z min endstop.
  // If you would like to use both a Z probe and a Z min endstop together,
  // uncomment #define Z_MIN_PROBE_ENDSTOP and read the instructions below.
  // If you still want to use the Z min endstop for homing, disable Z_SAFE_HOMING above.
  // Example: To park the head outside the bed area when homing with G28.
  //
  // WARNING:
  // The Z min endstop will need to set properly as it would without a Z probe
  // to prevent head crashes and premature stopping during a print.
  //
  // To use a separate Z probe endstop, you must have a Z_MIN_PROBE_PIN
  // defined in the pins_XXXXX.h file for your control board.
  // If you are using a servo based Z probe, you will need to enable NUM_SERVOS,
  // Z_ENDSTOP_SERVO_NR and SERVO_ENDSTOP_ANGLES in the R/C SERVO support below.
  // RAMPS 1.3/1.4 boards may be able to use the 5V, Ground and the D32 pin
  // in the Aux 4 section of the RAMPS board. Use 5V for powered sensors,
  // otherwise connect to ground and D32 for normally closed configuration
  // and 5V and D32 for normally open configurations.
  // Normally closed configuration is advised and assumed.
  // The D32 pin in Aux 4 on RAMPS maps to the Arduino D32 pin.
  // Z_MIN_PROBE_PIN is setting the pin to use on the Arduino.
  // Since the D32 pin on the RAMPS maps to D32 on Arduino, this works.
  // D32 is currently selected in the RAMPS 1.3/1.4 pin file.
  // All other boards will need changes to the respective pins_XXXXX.h file.
  //
  // WARNING:
  // Setting the wrong pin may have unexpected and potentially disastrous outcomes.
  // Use with caution and do your homework.
  //
  //#define Z_MIN_PROBE_ENDSTOP

#endif // AUTO_BED_LEVELING_FEATURE

// @section homing

// The position of the homing switches
//#define MANUAL_HOME_POSITIONS  // If defined, MANUAL_*_HOME_POS below will be used
//#define BED_CENTER_AT_0_0  // If defined, the center of the bed is at (X=0, Y=0)

// Manual homing switch locations:
// For deltabots this means top and center of the Cartesian print volume.
#if ENABLED(MANUAL_HOME_POSITIONS)
  #define MANUAL_X_HOME_POS 0
  #define MANUAL_Y_HOME_POS 0
  #define MANUAL_Z_HOME_POS 0
  //#define MANUAL_Z_HOME_POS 402 // For delta: Distance between nozzle and print surface after homing.
#endif

[Blue-Marlin]

Any messages on the display/console? What does a M119 show in mid air?

[AnatoliyKube]

OLL TRIGGERED

[AnatoliyKube]

G28 - in lcd x100 y100 z 4 g29 -not so if:

define Z_SAFE_HOMING_X_POINT 0 //(X_MAX_POS / 2)

define Z_SAFE_HOMING_Y_POINT 0 //(Y_MAX_POS / 2)

g29 working ????????????

[AnatoliyKube]

.https://github.com/MarlinFirmware/Marlin/tree/RCBugFix -problem home end G29 in https://github.com/MarlinFirmware/Marlin - problem work in the temperature menu apparently there is a problem with the files in where to download the operating firmware????

[dmummert]

No. I don't think so. When working in the move-axis-menus on the display we display a absolute position. With turning the knob we change the absolute position in steps determined by the menu we are in (10/1/0.1). If we want to use the one or the other is a matter of, if we want to change the value fast or precise. Marlins reaction to the changed, displayed value is a absolute move to the new position. There is no accumulation of errors.

That's not true. At least here, if I scan the head across the build platform several times using the Move Axis menu, I end up with an axis value that bears no relationship to the system. It doesn't reset if it hits a limit switch, it just keeps adding and subtracting encoder clicks. This seems to have an impact on autolevelling as well, as the numbers coming out of this routine don't look right either. So far, I haven't trusted it enough to turn it over to a host program.

Electronically, though, it looks like it's using my z-probe instead of the z axis limit switch during some operations and I didn't thing that was possible.

[Blue-Marlin]

@dmummert Your printers behaviour requires, not to have homed the printer before, or an incorrect setup. The very first thing you should do with your printer after switching on, is homing. Before that any display is invalid, the software endstops clueless, every move potentially unsafe. If that wouldn't also be unsafe, the printer would home alone when switched on. It is discussed if we should lock the printer until homed, like GBRL does.

[Blue-Marlin]

Noise on the hardware endstops could be an other source.

[AnatoliyKube]

all settings are done correctly on all versions except the working temperature control (temperature during installation of the table changed extruder temperature of 210) version 1.1.0-rc3 https://github.com/MarlinFirmware/Marlin~~pobj I went on the advice of a version RCBugFix - all with temperature OK with encoder understood - OK teams G28 G29 work at all because it is not in the version 1.1.0-rc3 G28 HOME -the carriage comes to ENDSTOP Y , X (0.0) ,LATER Z -0(ENDSTOP) lcd x=125 y=129 z=12,35 but the carriage is near ENDSTOP Y ,X (version 1.1.0-rc3 CAR GO X0 Y0 , next go

define Z_SAFE_HOMING_X_POINT 0 //(X_MAX_POS / 2)

define Z_SAFE_HOMING_Y_POINT 0 //(Y_MAX_POS / 2)

Z - ENDSTOP)

[Blue-Marlin]

@AnatoliyKube

OLL TRIGGERED

I hoped you could see that this can't be correct. No ensdstop shall be triggered in mid air. No unconnected endstop shall ever be triggered.

[AnatoliyKube]

Blue-Marlin all settings are done correctly on all versions except the working temperature control (temperature during installation of the table changed extruder temperature of 210) version 1.1.0-rc3 https://github.com/MarlinFirmware/Marlin~~pobj I went on the advice of a version RCBugFix - all with temperature OK with encoder understood - OK teams G28 G29 work at all because it is not in the version 1.1.0-rc3 G28 HOME -the carriage comes to ENDSTOP Y , X (0.0) ,LATER Z -0(ENDSTOP) lcd x=125 y=129 z=12,35 but the carriage is near ENDSTOP Y ,X (version 1.1.0-rc3 CAR GO X0 Y0 , next go

define Z_SAFE_HOMING_X_POINT 0 //(X_MAX_POS / 2)

define Z_SAFE_HOMING_Y_POINT 0 //(Y_MAX_POS / 2)

Z - ENDSTOP)

G 29 - LCD X=170 Y=170 BUT CAR IN X=0 Y=0 TND CAR NOT GO

[dmummert]

I won't rule out the possibility of an incorrect setup, but I just ran a series of tests. AFTER an autohome, the behaviour is identical. All encoder clicks are counted both during a move and after an endstop has been triggered. I'm using the RepRapdiscount Full Graphic Smart Controller.

On 2/26/2016 2:26 PM, Makaira wrote:

@dmummert https://github.com/dmummert Your printers behaviour requires, not to have homed the printer before, or an incorrect setup. The very first thing you should do with your printer after switching on, is homing. Before that any display is invalid, the software endstops clueless, every move potentially unsafe. If that wouldn't also be unsafe, the printer would home alone when switched on. It is discussed if we should lock the printer until homed, like GBRL does.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/3030#issuecomment-189441665.

[Blue-Marlin]

@dmummert Do you send a G91 before moving with the menu? Are you in relative mode? That could be the hole you are slipping through.

[Blue-Marlin]

@dmummert No. Relative mode is completely bypassed by the menu moves.

[AnatoliyKube]

in general , It was tested two versions downloaded from the repository : 1 version 1.1.0-rc3 https://github.com/MarlinFirmware/Marlin (error when installing the temperature BED tuning - T NOZZEL 210) parking and AUTO_BED_LEVELING_FEATURE work fine
end 2 version RCBugFix https://github.com/MarlinFirmware/Marlin/tree/RCBugFix ( not error when installing the temperature BED tuning - T NOZZEL 210) but not work parking and AUTO_BED_LEVELING_FEATURE after hours of torment and dancing with a tambourine while the file correction CONFIGURATION.H it was decided not engineering solution , replace the file from the firmware 1 in firmware 2 - (files were compared to the letter -the same ,the only difference SD -#define SDSLOW end #define SDEXTRASLOW ) , IMAGINE - all earned , not error temperature parking and AUTO_BED_LEVELING_FEATURE work fine
BUT a problem with the movement -remained if you rotate the encoder when moving -distance is increased by a few mm - in lcd 100 мм -Travel 109 мм , if the movement set to 1 mm -Travel 1 мм , next - if you change the encoder value from 0 to 200 - ok if you change the value of the encoder after that from 200 to 0 the value will change to 100 and then jumps back to 200 . After several such activities ahluino reseting !!! It was tested on the axis z step 1 end 0,1 mm - is clearly an error in the program when you change numeral

[Blue-Marlin]

Ah. Now i understand your problem with the menu moves. It's a rather old problem (#1166). Recently talked with thinkyhead about that, but have not tested that in detail..

You could try:

static void _lcd_move(const char* name, AxisEnum axis, int min, int max) {
+  if (movesplanned() > 3) return;
  if (encoderPosition != 0) {
    refresh_cmd_timeout();
    current_position[axis] += float((int)encoderPosition) * move_menu_scale;

around line 826 in ultralcd.cpp

I'd love to read your feedback abut that, because i never have been able to reproduce this error.

[AnatoliyKube]

Today I tried to repeat the operation with the axis Z - YES error occurs axis only Z , both at 1 mm and 0.1 mm in at 1 mm - count - ok ,movement - ok , when reaching 200 mm (encoder) - arduino - reset at 0,1 mm -count 0-200 -ok 200-90 -rearranged to 200 end reset

[AnatoliyKube]

static void _lcd_move(const char* name, AxisEnum axis, int min, int max) {

• if (movesplanned() > 3) return; if (encoderPosition != 0) { refresh_cmd_timeout(); current_position[axis] += float((int)encoderPosition) * move_menu_scale;}

this is not the way out Yes - reset, and the number of stop jump but did hang indicator on the motion picture disappears,end only odd values become 1, 3, 5, 7, 9

problem encoder library , rather its interaction with the main program , just not enough time to perform the procedure, and the variable responsible for the input of numbers, it is not working properly , All error associated only with the axis Z !!!!!!!!!!!!!!!!!! axis X end Y work fine the proposed code, we slowed down the work but did not solve the problem This eternal contradiction of high-level languages and the ability of the processor for a given algorithm

[AnatoliyKube]

the way it is at all firmwares, even older , when it reaches 100 or more, a failure occurs along the axis Z

[Blue-Marlin]

Sorry for my bad English. I do not understand most of your writing. I just guess what you could have meant.

For the 1,3,5 problem you can increase ENCODER_PULSES_PER_STEP. (In your case with a negative number decrease.) The 100 problem can be caused by the accelerator algorithm in combination with the negative ENCODER_PULSES_PER_STEP. Instead of this you could use the official was to change the encoder direction. In your pin file, for your display change the pin numbers for BTN_EN1 and BTN_EN2

Did i correctly understood that with my addition (if (movesplanned() > 3) return; ) the resets are away?

[AnatoliyKube]

what language you speak? I well know Russian Ukrainian ,English - Machine Translation proposed function 1 - slows down lcd 2 - It shows only the odd numbers It is not an option with the position

[Blue-Marlin]

@AnatoliyKube I'm German. Sorry, I give up.

[AnatoliyKube]

if the increase ENCODER_PULSES_PER_STEP -very difficult to manage in other sections of the menu negative meaning - does not affect as the organized movement of the input values axis z ?

[AnatoliyKube]

give early !es ist notwendig, dieses Problem zu lösen

[dmummert]

For my tests, I specifically did not exercise the Z axis, and cannot say that those routines aren't functional or not.

But;

From a cold boot, that is power-up reset and after the splash-screen disappears on the RepRap Full Graphic Smart Display, from the Prepare screen (and as someone suggested, execution of an Autohome),

Move Axis 10mm, or 1mm, X axis;

spinning the encoder shaft while against an activated end-stop accumulates position value, either negative or positive depending on which stop the carriage has hit.

While not specifically tested for in any exhaustive manner, the other two axes appear to be affected this way as well.

I do have the system set as;

define min_software_endstops false // If true, axis won't move to

coordinates less than HOME_POS.

define max_software_endstops false // If true, axis won't move to

coordinates greater than the defined lengths below.

On 2/27/2016 5:04 AM, AnatoliyKube wrote:

static void _lcd_move(const char* name, AxisEnum axis, int min, int max) {

• if (movesplanned() > 3) return; if (encoderPosition != 0) { refresh_cmd_timeout(); current_position[axis] += float((int)encoderPosition) * move_menu_scale;}

this is not the way out Yes - reset, and the number of stop jump but did hang indicator on the motion picture disappears,end only odd values become 1, 3, 5, 7, 9

problem encoder library , rather its interaction with the main program , just not enough time to perform the procedure, and the variable responsible for the input of numbers, it is not working properly , All error associated only with the axis Z !!!!!!!!!!!!!!!!!! axis X end Y work fine the proposed code, we slowed down the work but did not solve the problem This eternal contradiction of high-level languages and the ability of the processor for a given algorithm

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/3030#issuecomment-189615318.

[AnatoliyKube]

topic CLOSED

static void _lcd_move(const char* name, AxisEnum axis, int min, int max) {
  if (encoderPosition != 0) {
    refresh_cmd_timeout();
    current_position[axis] += float((int)encoderPosition) * move_menu_scale;
    if (min_software_endstops && current_position[axis] < min) current_position[axis] = min;
    if (max_software_endstops && current_position[axis] > max) current_position[axis] = max;
    encoderPosition = 0;
    if (movesplanned() <= 3)
      line_to_current(axis);
    lcdDrawUpdate = 1;
  }
  if (lcdDrawUpdate) lcd_implementation_drawedit(name, ftostr31(current_position[axis]));
  if (LCD_CLICKED) {
      line_to_current(axis);
      lcd_goto_menu(lcd_move_menu_axis);
  }
}

[thinkyhead]

What is the topic here? What issues need to be resolved?

[Blue-Marlin]

@thinkyhead I guess the most difficult problem to solve, was language here. I talked about, reversing encoder direction, what to do against omitting values ( ENCODER_PULSES_PER_STEP) and the z-axis crash problem.

I think with merging #3050 everyone is happy here.

[thinkyhead]

I think with merging #3050 everyone is happy here.

Except me, of course! I will try to implement a better solution tomorrow.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.