Welcome to the SeeMeCNC Community

Posted: **Fri Aug 16, 2013 3:48 pm**

Just to be clear I was not complaining about the stock arms so much as stating how much I really enjoy the performance of the magnetic and the ease of use and swapability of them.

Sanding/setrup/rigisity aside I prefer to use a magnetic arm machine over a stock arm machine even if both are fully finished and do not requir any effort or work from me.

I have no doubt that the machine will come prebuilt and run very nicely.

I just would have preferred magnetic personally. I imagine it would have been less time and work for you guys to mass produce as well since really all you do is hold the arm near the cup and "snap" there ya go done. No tools, no time, no effort required.

I did not intend any critic however in a negative way to the product.

Gord

Posted: **Fri Aug 16, 2013 5:28 pm**

johnoly99 wrote: Do you guys know you can jog the hotend down to the table, and when you're satisfied with the z, send M251 S2 in the gcode, and that will auto-update your z height setting and store it to the eeprom in the firmware??? if not, you should try it!

I'm similar to flateric about the stock arms. They served me great but my inability to fully trust my sanding job never left my mind when a print was slightly off.

Damnit... I just got done recalibrating my arms too... Nice tip though, future me will be more thankful

Posted: **Fri Aug 16, 2013 7:40 pm**

is that wonderful M-code a Repetier only feature? I prefer to roll with the Marlin side of things.....

Posted: **Sat Aug 17, 2013 6:30 pm**

Nylocke wrote:is that wonderful M-code a Repetier only feature? I prefer to roll with the Marlin side of things.....

ewww

Posted: **Sun Aug 18, 2013 12:35 am**

Nylocke wrote:is that wonderful M-code a Repetier only feature? I prefer to roll with the Marlin side of things.....

Marlin already has a WAY better code (I think Johann mapped it to M29, it's in his experimental branch, not stock I think) that uses a Hall effect sensor to probe the build surface in a dozen or more places to figure out its geometry. No jogging involved (or rather, the firmware does it for you.) Someone is supposedly working on porting it to Repetier, which a lot of us prefer because it seems to work better. (For example - try moving the head up or down 0.1mm in Repetier Host - with Marlin, it will move if it feels like it, and sometimes it doesn't. With Repetier it always moves 0.1mm.)

PS - if you SeeMe guys are reading this thread - the coolest Rostocks on Kickstarter have some kind of built-in autolevel. One has a regular endstop switch that flips down from the effector (the printer knocks it into something at the edge of the print envelope) and the other does the multi-sample test. It makes the printer a lot more civilized to deal with. We are trying to get autoleveling to work with Z-probes with the Hall-Θ board. If you guys sold this in a kit, made it an option, etc., it would sell like air on the Moon. Particularly if it does the multi-sample test, so we don't have to bother with those adjustment screws.

Posted: **Mon Aug 19, 2013 6:43 am**

send M251 S2 in the gcode, and that will auto-update your z height setting and store it to the eeprom in the firmware

I tried this M251 (repeater firmware, several months old) over the weekend. When I checked the eprom, it only updated Z max length and did not change max length for X or Y. I always thought all three of those had to be the same value. So I changed them myself before using the new value.

Posted: **Mon Aug 19, 2013 9:03 am**

FYI, Johann's G29 auto-level does not use a hall effect sensor. It uses a tiny microswitch (the same size that the Rostock MAX uses for the end-stops), a ballpoint pen spring and a small allen wrench for the probe itself.

Barnett, nudge your nozzle to the "lightly gripping paper" distance in the center of your bed and then re-run the M251 S2 command. Try a print. I think you'll be happy with the result.

g.

Posted: **Mon Aug 19, 2013 12:25 pm**

Hey flateric, no way man, never even considered you were complaining at all. No problems.

626pilot, btw, that would be me trying to port the autolevel into repetier, although my firmware-fu isn't quite as strong as it needs to be yet, i'm getting closer

And also, just an FYI, anyone seen any of the kickstarter machines in real-life yet? Are any of them shipping yet? Ahhh, right

lol

Also, take a look at this video from a while ago, wonder where they got the idears for the probe?
http://youtu.be/dyleBUd25wo

Posted: **Mon Aug 19, 2013 2:39 pm**

johnoly99 wrote:Hey flateric, no way man, never even considered you were complaining at all. No problems.

626pilot, btw, that would be me trying to port the autolevel into repetier, although my firmware-fu isn't quite as strong as it needs to be yet, i'm getting closer

And also, just an FYI, anyone seen any of the kickstarter machines in real-life yet? Are any of them shipping yet? Ahhh, right lol

Also, take a look at this video from a while ago, wonder where they got the idears for the probe?
http://youtu.be/dyleBUd25wo

John, that's great news! When you get the autolevel incorporated into Repetier that would be one of the best improvements you could have possible done.
Thank you for working on that and we all await with anticipation. Seriously, your work is appreciated and what are you doing sitting around reading emails
when you should be working on the auto level.

Posted: **Mon Aug 19, 2013 2:45 pm**

LOL eagle, well ya know, trollin' our own forum is a pass-time for us, hehe

Posted: **Mon Aug 19, 2013 3:27 pm**

johnoly99 wrote:LOL eagle, well ya know, trollin' our own forum is a pass-time for us, hehe

Troll away, John. Just picken on ya.

Posted: **Mon Aug 19, 2013 6:18 pm**

johnoly99 wrote: 626pilot, btw, that would be me trying to port the autolevel into repetier, although my firmware-fu isn't quite as strong as it needs to be yet, i'm getting closer

Send me a PM if you need any help. I've put some hours into working with the Arduino C++ "compiler."

Posted: **Mon Aug 19, 2013 11:55 pm**

I actually had said I was going to try to port the auto level from Marlin to Rep, but I guess if John beats me he beats me....

Posted: **Wed Aug 21, 2013 2:57 am**

johnoly99 wrote:Do you guys know you can jog the hotend down to the table, and when you're satisfied with the z, send M251 S2 in the gcode, and that will auto-update your z height setting and store it to the eeprom in the firmware??? if not, you should try it!

This works in Repetier, but the second time I did it the printer attempted to murder my build plate.

X max length = 361.32
Y max length = 361.32
Z max length = 417.56

Third run, X and Y are the same, Z is 360.83... no bueno

Posted: **Thu Aug 22, 2013 2:07 pm**

626pilot,

Make sure you HOME the machine first, so it has a fresh start at the step counter, and only jog straight down in Z, x/y moves are buggy with it ATM

Posted: **Thu Aug 22, 2013 5:26 pm**

It went something like this:

g28
g1 z5 f5000
(jog down until it gets the paper)
m251 s2

There were no x/y moves any of the 3 times I did it.

Edit: Tried it again with a new hot end - numbers were 360.8, 360.8, 298.13. The Z coordinate is almost right, the other two appear to be from the old hot end.

Posted: **Fri Aug 23, 2013 9:32 am**

I've noticed this as well on Blue Max, but I figure the firmware knows what the hell is going on a lot better than I do so I left it alone.

g.

Posted: **Fri Aug 23, 2013 10:02 am**

John, is the auto-level code you're porting in one of your github repos? I've also spent quite a bit of time around AVRs and have been digging through both the Marlin and Repetier code bases to consider adding a couple new features.

Maybe I can help here, too.

Edit: For those experiencing the non-updating X & Y max when using the M251 S2 command, I think I've found the reason why. The code only updates the zMaxSteps from what I can tell. AFAIK, the *MaxSteps value should be the same for all three axes.

Relevant code segment from Commands.cpp with some of my documentation (starting at line 1107):

Code: Select all

#if DRIVE_SYSTEM==3
  case 251:
    if(GCODE_HAS_S(com)) {
      if (com->S == 0) {
        printer_state.countZSteps = 0;
        out.println_P(PSTR("Measurement reset."));
      } else if (com->S == 1) {
        OUT_P_L_LN("Measure/delta (Steps) =",printer_state.countZSteps);
        OUT_P_F_LN("Measure/delta =",printer_state.countZSteps * inv_axis_steps_per_unit[2]);
      } else if (com->S = 2) {
        if (printer_state.countZSteps < 0)
          printer_state.countZSteps = -printer_state.countZSteps;
        printer_state.zMin = 0;
        printer_state.zLength = inv_axis_steps_per_unit[2] * printer_state.countZSteps; // convert to mm with the z-axis multiplier, which should be equal for all axes
>>>>printer_state.zMaxSteps = printer_state.countZSteps;<<<<< THIS IS THE ONLY *MaxSteps UPDATE IN THE COMMAND
        for (byte i=0; i<3; i++) {
          printer_state.currentPositionSteps[i] = 0;
        }
        calculate_delta(printer_state.currentPositionSteps, printer_state.currentDeltaPositionSteps); //update the delta positions
        OUT_P_LN("Measured origin set. Measurement reset.");
        #if EEPROM_MODE!=0
          epr_data_to_eeprom(false);
          OUT_P_LN("EEPROM updated");
        #endif
      }
    }
    break;
#endif

You should be able to fix this by adding two lines:

Code: Select all

       printer_state.xMaxSteps = printer_state.countZSteps;
       printer_state.yMaxSteps = printer_state.countZSteps;

I haven't tested any of this (as my machine is currently down for upgrades), but I would imagine that the xLength and yLength (in mm) parameters also need to be updated. So I would probably also add

Code: Select all

        printer_state.xLength = inv_axis_steps_per_unit[0] * printer_state.countZSteps;
        printer_state.yLength = inv_axis_steps_per_unit[1] * printer_state.countZSteps;

and possibly even relevent code to update the xMin and yMin to zero, just to be safe.

As John said, I wouldn't use any cartesian X/Y moves, as the routine only uses the Z-axis step count to determine the height. Once I can test this and verify that it does fix things, I'll submit a pull request.

BTW - I'm using RepetierFirmware 0.83.

Posted: **Fri Aug 23, 2013 11:27 am**

NICE catch!!! I think this is what will work:

After

Code: Select all

        if (printer_state.countZSteps < 0)
	  printer_state.countZSteps = -printer_state.countZSteps;

And before

Code: Select all

	for (byte i=0; i<3; i++) {
	  printer_state.currentPositionSteps[i] = 0;
	}

Try this:

Code: Select all

        printer_state.xMin = 0;
        printer_state.yMin = 0;
	printer_state.zMin = 0;

        printer_state.xLength = inv_axis_steps_per_unit[0] * printer_state.countZSteps;
        printer_state.xMaxSteps = printer_state.countZSteps;

        printer_state.yLength = inv_axis_steps_per_unit[1] * printer_state.countZSteps;
        printer_state.yMaxSteps = printer_state.countZSteps;

	printer_state.zLength = inv_axis_steps_per_unit[2] * printer_state.countZSteps;
	printer_state.zMaxSteps = printer_state.countZSteps;

It compiles. I can't test right now, but it looks logically correct, assuming inv_axis_steps_per_unit[0..1] are initialized.

Posted: **Fri Aug 23, 2013 12:36 pm**

You guys need to check the main Repetier firmware github repo to see if this has already been addressed - if not, please submit a patch so it can be fixed in the main branch.

tnx.

g.

Posted: **Fri Aug 23, 2013 7:18 pm**

Another change is necessary. There is some drift (number usually comes in .01 - .03 lower than it should be) caused by machine epsilon. inv_axis_steps_per_unit was defined as a float. I changed inv_axis_steps_per_unit from a float to a double (twice the accuracy) and where it was set to 1.0f / (something) I removed the f, so it would just do the math in double precision.

The following seems to reduce the drift to 0.01 every time. Ideally it should be zero, but it's still better than .03, which is enough to cause 1st layer printing issues with very fine layers (.01 and lower.) There's probably some more stuff that needs to be converted to double precision. I'm afraid to convert too many variables to that, in case it might take too much RAM or slow down some calculations, but I might try later.

In Repetier.h, find this:

Code: Select all

extern float inv_axis_steps_per_unit[];

Change float to double.

In Extruder.cpp, find this:

Code: Select all

   inv_axis_steps_per_unit[3] = 1.0f/axis_steps_per_unit[3];

Remove the f so that it does the math in double precision. (Bonus: that controls the extruder, not the movement axes, so maybe your extruder will run with a zillionth better accuracy.)

In Repetier.ino (main file), find this:

Code: Select all

inv_axis_steps_per_unit[i] = 1.0f/axis_steps_per_unit[i];

Remove the f here too.

I don't seem to have a .git directory, so I guess I got this source from John or something rather than pulling it off github. I need to figure out how to diff it against the main branch later.

Posted: **Sat Aug 24, 2013 2:26 am**

626Pilot wrote:Another change is necessary. There is some drift (number usually comes in .01 - .03 lower than it should be) caused by machine epsilon. inv_axis_steps_per_unit was defined as a float. I changed inv_axis_steps_per_unit from a float to a double (twice the accuracy) and where it was set to 1.0f / (something) I removed the f, so it would just do the math in double precision.

Good luck with that. avr-gcc, the compiler Arduino uses, defines float and double identically as 32 bits.

http://gcc.gnu.org/wiki/avr-gcc#Deviati ... e_Standard

Posted: **Sat Aug 24, 2013 11:04 am**

geneb wrote:You guys need to check the main Repetier firmware github repo to see if this has already been addressed - if not, please submit a patch so it can be fixed in the main branch.

tnx.

g.

I run the main repo already. Once I test these changes myself I intend to submit a pull request.

Edit (2013/08/24 16:36 EDT): Sitting here on the deck at the lake I've been going through the development branch, and as I expected, the M251 routine is identical. I've never tried running the development branch (it has Arduino Due support!), so maybe next week I'll be trying that, too.

I've forked the main repo into my github account, where the fixes I've made to the current stable version can be found in the 'm251_devel' branch. My github profile can be found here: https://github.com/edwardhughes

Posted: **Wed Sep 25, 2013 3:42 pm**

ORION's start shipping!

We're back from the New York World Maker Faire and assembling ORION printers. John Oly has put his signature "Oly's Performance" tune into the control and test prints are being performed on each ORION before final packaging. We'd like to thank our customers for patience and support during the launch of our first assembled delta 3D printer!!

Welcome to the SeeMeCNC Community

That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

M251 S2 bugfix

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!

Re: That's all for now!