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

[RaySuave]

I don't know off hand if this change is folded into the DACB fork. But if it isn't you might want to give it a try.

Left, Right, Front and Back were the result of a long discussion on what the names should be. The problem is people have their origin in different places on the bed. This was an attempt to not confuse things by saying things like X_MAX or Y_MIN. It remains to be seen if this was a good choice of names. But if you imagine your part on the bed, the Front would be the lowest Y coordinate, Back would be the largest Y coordinate. Left and Right would be the lowest and largest X coordinate of the part.

Thanks for the tips. It turns out that the code changes recommended were already in the fork so what I ended up doing was take a dremel and rounded off the micro switch case edge where it was contacting the bed since the interference was pretty small. Problem Solved!! Can post a pic if needed.

Regarding the probe position orientation, it would probably be helpful to put in some short descriptive comments after each probe position on the next fork update. Your explanation was clear and made complete sense, now I have the probe area area perfectly adjusted.

[BgHurt]

I too have the issue of the Z axis not raising after the G28 before retractions. I put some debug code into the G28 to see if it was indeed running the do_blocking_move(blah, blah, +Z_RAISE_BETWEEN_PROBINGS)

It does run the command, but it never actually does the move on my arduino. Not sure if it is already in the middle of something so the function never runs. or if the move is no good. Not sure, but regardless it never lifts the Z before it retracts.

Stock dacb, just compiled and pushed to my RAMPS. Didnt work, so I put some SERIALPGM's in to get where it was in the program loops.

[dacb]

Hi all,
I have just tested a bunch of the changes people have posted including Roxy's. I'll get them into the fork in the next couple of days after a few more prints. Stay tuned!

[Roxy]

Hi all,
I have just tested a bunch of the changes people have posted including Roxy's. I'll get them into the fork in the next couple of days after a few more prints. Stay tuned!

Darn! I wish I knew you were going to do that... I fixed a bug in the Bed Level Topology Report for the Front-Right case:

#ifdef ORIGIN_FRONT_RIGHT
for(yy=0; yy<n_points; yy++ {
for(xx=0; xx<n_points; xx++) {
SERIAL_PROTOCOLPGM(" ");
if ( eqnBVector[ (n_points*n_points)-yy-(xx*n_points)-1 ]-mean >= 0.0)
SERIAL_PROTOCOLPGM("+");
else
SERIAL_PROTOCOLPGM("-"); // we need this extra - because Proterface uses a preportional
// font and it causes the columns to not line up nice without it.
SERIAL_PROTOCOL_F( eqnBVector[ (n_points*n_points)-yy-(xx*n_points)-1 ]-mean, 5);
}
SERIAL_PROTOCOLPGM(" \n");
}
SERIAL_PROTOCOLPGM(" \n");
#endif // ORIGIN_FRONT_RIGHT

[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