Dev branch status - 2015.5.30 - 2728dc06063aa2240c8c766cbaf4586e028bd8ec [2728dc0]

[fmalpartida]

Test setup:

• SAV MkI
• SAV 3D LCD
• CoreXY mechanics
• Inductive sensor + Autobed leveling
• SD Card
• Host interface: CURA

  Status:

• Outbid leveling - PASS/FAIL (with observation)
• Thermals - PASS
• Movement and print - PASS
• SD printing - PASS
• LCD updates - FAIL (print position shows as ----)
• Host printing - FAIL (fail to print from host - "CURA", other hosts, not tested.

  Observations

Auto bed levelling: Performing travel movements between objects while printing, the hotend tip, keeps bumping onto the travelled to object. Is a if prints movements and travel movements are not on the same plane.

Current development branch status

• Fit for integration branch - NO, host printer regressions.
• Fit for release branch - NO.

  Defects found:

• Host printing failure with Cura
• During printing the current print coordinates are not refreshed and remain as "---"
• Autobed levelling - Print surfaces are being hit by the hotend; travel and print movements seem to happen on different planes.

[Wackerbarth]

Performing travel movements between objects while printing, the hotend tip, keeps bumping onto the travelled to object.

Can you give the G-Code sequence involved? And a more complete description of the observed movement. From your description, this could be the fault of either the printer or the slicer.

[fmalpartida]

Printing the same object without autoleveling turned on, the hotend doesn't touch the print at all. With old version neither (1.0.2). Sliced with cura. I will find try to find a place to upload. I am testing with a print the involves movements from side to side of the print without extruding. Moves from place to place do seem to hit the printed object.

[MagoKimbra]

With Cura it does not work and the reason is the new control system gcode:

void process_next_command() { current_command = command_queue[cmd_queue_index_r];

if ((marlin_debug_flags & DEBUG_ECHO)) { SERIAL_ECHO_START; SERIAL_ECHOLN(current_command); }

// Sanitize the current command: // - Skip leading spaces // - Bypass N... // - Overwrite * with nul to mark the end while (_current_command == ' ') ++current_command; if (_current_command == 'N' && current_command[1] >= '0' && current_command[1] <= '9') { while (_current_command != ' ') ++current_command; while (_current_command == ' ') ++current_command; } char _starpos = strchr(currentcommand, ''); // * should always be the last parameter if (starpos) *starpos = '\0';

// Get the command code, which must be G, M, or T char command_code = *current_command;

// The code must have a numeric value bool code_is_good = (current_command[1] >= '0' && current_command[1] <= '9');

int codenum; // define ahead of goto

// Bail early if there's no code if (!code_is_good) goto ExitUnknownCommand;

// Args pointer optimizes code_seen, especially those taking XYZEF // This wastes a little cpu on commands that expect no arguments. current_command_args = current_command; while (_current_command_args != ' ') ++current_command_args; while (_current_command_args == ' ') ++current_command_args;

// Interpret the code int seen_pointer = current_command; codenum = code_value_short();

// Handle a known G, M, or T switch(command_code) {

Returned to the old system code, Cura works perfectly ...

Cura sends the entire gcode as if the printer was answering ok to all controls, while the printer remains stationary.

[AnHardt]

@fmalpartida The "---" in the display is shown as long we don't know where we are. You have to "home" the printer to see the coordinates. If you have defined DISABLE_? true you may lose the position and the coordinate display during print. The "---" is done per axis so, if you send a G28 X, you'll see a 000.0 only for the X-axis.

Investigated a bit further. https://github.com/MarlinFirmware/Marlin/blob/Development/Marlin/Marlin_main.cpp#L6256

if (stepper_inactive_time && ms > previous_cmd_ms + stepper_inactive_time && !ignore_stepper_queue && !blocks_queued()) disable_all_steppers();

gets currently true, for example during a M190, and disables all steppers regardless off the DISABLE_axis settings and regardless of printing from serial or sd-card. stepper_inactive_time is set by DEFAULT_STEPPER_DEACTIVE_TIME what is non zero for the most configurations. Until now i haven't dug in the deeps of ignore_stepper_queue and blocks_queued().

[fmalpartida]

Then it is not working. I currently have DISABLE_XYZ as false and do a G28 to home everything before printing,followed by a G29.

[AnHardt]

@fmalpartida What do you see directly after a G28? If G29 lasts longer then DEFAULT_STEPPER_DEACTIVE_TIME the display may be reset to "---". For M190 i know this for sure. That's an error i can reproduce. I'm investigating this.

[fmalpartida]

That may be just it. I have a very short time configured for disabling. I'll try that out.

[fmalpartida]

I tried increasing the inactivity timer and it looks good.

I think that as soon as the Cura defect is sorted out, we can move this code base into integration.

[MagoKimbra]

I found the problem width CURA... Cura send this format. NxxxG1 Fxxx Xxx Yyy etc etc The problem that there is not the space between the line number and the command.

The new system for sanitize the command do:

while (*current_command == ' ') ++current_command;
  if (*current_command == 'N' && current_command[1] >= '0' && current_command[1] <= '9') {
    while (*current_command != ' ') ++current_command;
    while (*current_command == ' ') ++current_command;
  }
char command_code = *current_command;

And the command_code isn't G but F

And at switch(command_code) go to ok_to_send()...

[MagoKimbra]

Ok i correct it width

while (*current_command == ' ') ++current_command;
  if (*current_command == 'N' && current_command[1] >= '0' && current_command[1] <= '9') {
    while (*current_command != ' ' && *current_command != 'G' && *current_command != 'M' && *current_command != 'T') ++current_command;
    while (*current_command == ' ') ++current_command;
  }

[AnHardt]

A very short test with Cura, Pronterface, Repetier, Octoprint gives me hope.

[fmalpartida]

Great job here!

Closing this defect and creating new update with todays build.

[thinkyhead]

Instead of this…

while (*current_command != ' ' && *current_command != 'G' && *current_command != 'M' && *current_command != 'T') ++current_command;

…the better and more general solution is this…

while (*current_command >= '0' && *current_command <= '9') ++current_command;

[MagoKimbra]

It is better. I did not think about it ...

[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.