Marlin firmware fork for MakerFarm i3v w/ auto bed level & Roxy's enhancements

[dacb]

I'll bring this change in too.

I have noticed that Waiting for user... appears more frequently now. Almost every print.

[Roxy]

I'll bring this change in too.

I have noticed that Waiting for user... appears more frequently now. Almost every print.

I've never seen that message. But I think I know why. That message is only used in one place:

  else if(code_seen('M'))
  {
    switch( (int)code_value() )
    {
#ifdef ULTIPANEL
    case 0: // M0 - Unconditional stop - Wait for user button press on LCD
    case 1: // M1 - Conditional stop - Wait for user button press on LCD
    {
      LCD_MESSAGEPGM(MSG_USERWAIT);
      codenum = 0;
      if(code_seen('P')) codenum = code_value(); // milliseconds to wait
      if(code_seen('S')) codenum = code_value() * 1000; // seconds to wait

      st_synchronize()

I think this has something to do with your UltiPanel! I have a dedicated (ancient) laptop acting as my LCD Display. So I'm not going to see this message. And if you look at the code... You (or the panel) must be sending it an M1 command.

Right????

[printbus]

I think this has something to do with your UltiPanel! I have a dedicated (ancient) laptop acting as my LCD Display. So I'm not going to see this message. And if you look at the code... You (or the panel) must be sending it an M1 command.

To clarify, the smartpanels on at least the MakerFarm printers have no intelligence of their own. They're not capable of sending commands. They're really quite simple - a one-way data interface is used to send character information to an LCD display, and discrete lines from a push-button rotary encoder are sensed by Marlin to determine when any operator knob rotation or knob press input is present. When knob rotation or knob press is detected, Marlin decides how to act on it. It seems to me that the M0 or M1 would have to be in the gcode (as in a wait here for operator response), or there's some problem like an errant pointer clobbering variable or stack space within Marlin.

EDIT: And following all the auto bed leveling threads, I've been wondering about the data clobbering possibility for some time now.

[dacb]

There are no M0 or M1 in the Cura generated G-code. It always happens after the auto bed level and before the print begins. I'm leaning very strongly towards printbus's interpretation.

What was the bed topology report bug? Did it write off the end of a buffer or something like that?

[Roxy]

It seems to me that the M0 or M1 would have to be in the gcode (as in a wait here for operator response), or there's some problem like an errant pointer clobbering variable or stack space within Marlin.

EDIT: And following all the auto bed leveling threads, I've been wondering about the data clobbering possibility for some time now.

There are no M0 or M1 in the Cura generated G-code. It always happens after the auto bed level and before the print begins. I'm leaning very strongly towards printbus's interpretation.

What was the bed topology report bug? Did it write off the end of a buffer or something like that?

Well... You understand what I'm arguing, right? That M1 is the only place that message can get issued from. So some how the firmware thinks it got an M1 to process. I have also seen some strange behavior depending upon how the code got built. Some times just adding or taking out a little bit of code can make the firmware go from being stable to unstable.

If I was going to blame this on the Auto Bed Leveling code.... I would suspect it is tied to the Least Squares Fit code. That is getting passed some big arrays and it is manipulating them (and using a fair chunk of memory to do its calculations).

But anyway... The fact you have something (the M1 command) that you are not doing... Gives us a good place to check out this theory. I suggest we put some debug code in the M1 code that dumps the entire command buffer. From that, we will be able to see if it is getting corrupted when the M1 starts executing. It might also be good to dump the stack and see where (and what) it was executing just prior to getting into the M1 code. (Did the top of the stack get corrupted, and the return address sent the processor to the M1 code???)

Update: One more thought on this... If we were to put debug code to dump various things in memory to try to resolve this... We need to very early in the debug code say "We got into the debug code." The reason I'm saying this is because I've seen one build of the firmware be OK. And I've seen with a very small change that has nothing to do with the execution path the code become unstable. Just adding the debug code, might shift it from going into the M1 code????

[nefiwashere]

got this loaded up today. been using the regular zenmaster setup for ABL and so far so good printing at .3 layer height with good results. when i print at .1 layer height i get some issue see video



nozzle is pushing/dragging through the print. feed rate 20mms temp 200. using the Prometheus hot end .4 orifice. extrusion multiplier changed from 1 to .95 to .90 still had issues. not sure if it something with the auto bed leveling

thanks for any help

[AbuMaia]

Roxy, there's a new update to the EricZalm Marlin addressing something about the M0/M1. https://github.com/ErikZalm/Marlin/pull/1159 Think this might have something to do with the occasional "wait for user"?

[Roxy]

Roxy, there's a new update to the EricZalm Marlin addressing something about the M0/M1. https://github.com/ErikZalm/Marlin/pull/1159 Think this might have something to do with the occasional "wait for user"?

Thanks! I guess I better get these changes! I wonder which path I should go? I really should get DACB's fork ported to my machine. But I want the M0/M1 changes.

DACB, are you going to re-merge with the latest code soon? If so, I'll wait so I don't have to do the port twice. (I normally wouldn't be trying to get out of a merge / port, but I'm too busy with other things right now.)

[old man emu]

Please, Oh Wise ones, enlighten a moron groping in the dark.

Today, do I download and flash this:

https://github.com/beckdac/Marlin/co...29b5184dab6fd0

or this:

https://github.com/beckdac/Marlin/tr..._merge_11_2014

?

Old Man Emu

[clough42]

Has anyone else had any trouble with the auto-bed-level sometimes not running or not completing?

My custom start gcode in Slic3r heats the bed, starts the hot ends heating and then runs G28 followed by G29 to home and auto-level. After the G29, it moves the extruder tips just off the front edge of the bed (Y=215, Z=0), primes them and then wipes them onto the glass.

Sometimes, the G28 runs, and it homes in the center, but the G29 sequence doesn't run and the printer is left with the Z level off by about 6mm. Those first layers don't adhere to the bed real well when they're applied from 6mm up.

I haven't figured out how to reproduce it at will yet, but it seems to happen if I've already run one print job and haven't reset the printer. Or maybe it's just happening when the Z axis is high (90mm or more) and it takes a long time for the G28 Z probe.

Ideas?