Auto Calibrating Metal Delta issues

[Andrew]

I got my Metal Delta running, but I am having problems auto calibrating.

I am following the instructions from http://smoothieware.org/delta

(With the Z-Probe on in case that matters)

First home the machine :

G28

Then move to the point the machine currently thinks is Z 0 :

G0 Z0

Then move the head to the bed by jogging, using Pronterface's arrows, the panel, the web interface or whatever other method is adequate in your case.

Finally issue the M306 Z0 command which will use the current Z position as a homing offset : 

M306 Z0

Then save to the SD card with M500 :

M500

Next time you home, the machine will know how high above the bed it is.

 This works great, doing this, I home it again and run G0 Z0 and it finds the bottom perfectly.

Next I try the auto-calibration G32 and that is where problems happen. Not at first, it passes the first and second probes, but the 3rd where it checks X-axis the probe doesn't touch or trigger

http://smoothieware.org/zprobe

Example use :

    G28 (Home XYZ)
    (Move Z at least 30mm away from the bed if it's not, and attach probe if you have a removable probe)
    G32 ( Calibrate the machine )
    (Remove probe if you have a removable probe)
    M500 (to save probe results)
    G28 (Home XYZ)
    (Manually: jog down to touch the plate)
    M306 Z0
    M500 (to save homing offset)
    G28
    (Machine is now calibrated and knows it's correct height above the bed)

Not sure what I am doing wrong or how to fix it. maybe a screw at the end of the switch to give it more area to press against the bed?

[Blue Eagle Labs]

andrew,

1st check the probe status using M114. check each endstop one by one

then home the printer

Run the autocalibration routine with G32

After calibration, save settings with M500

remove calibration probe and set it aside

use M665 to adjust the Z height such that the paper test is set to 0 (home every time you adjust)

Once you have the final Z height adjusted, save it with M500 again

lead the override file with M501 every time you turn on the printer. 

[Shane]

@Andrew

Disconnect your mag-arms from the effector and rotate the assembly one ball joint clockwise OR counterclockwise.  It is merely connected incorrectly.  

A properly connected effector will have perfectly parallel arms extending out to each tower.  I briefly made this mistake the first time I connected mine as well, but luckily I found the error quickly.

[Andrew]

Shane you are right! Just looked at the build photos and that is what is different

[Blue Eagle Labs]

nice catch shane, i didnt notice that :)

--
You received this message because you are subscribed to the Google Groups "Blue Eagle Labs Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to BlueEagleLabs+unsubscribe@googlegroups.com.
To post to this group, send email to BlueEa...@googlegroups.com.
Visit this group at https://groups.google.com/group/BlueEagleLabs.
To view this discussion on the web visit https://groups.google.com/d/msgid/BlueEagleLabs/2dec64b4-ca20-4ef0-9f63-04a7928d207b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Andrew]

Today I was getting the error:

Calibrating Endstops: target 0.030000mm, radius 115.000000mm

set trim to X:0.000000 Y:0.000000 Z:0.000000

initial Bed ht is 592.949951 mm

center probe: 0.4125

Probe was not repeatable to 0.030000 mm, (0.412506)

Calibration failed to complete, check the initial probe height and/or initial_height settings

 Uploaded a video: https://drive.google.com/open?id=0BwfKxaOw3Z_fNlppQTBtb1ZTcFU

[Shane]

I am not too familiar with the software you are using, but it appears to me that the printer thinks the bed is substantially closer than it actually is.  In other word, the "initial_height" setting is way out of whack.

Notice it goes down very quickly until it is about  ~80mm above the bed, then goes VERY slowly down the rest of the way?   I'm assuming if the "initial_height" setting was correct, it would go very quickly until it was just a few mm away from the bed, and only the last tiny bit would be slow.

Do this:  Run the calibration again, wait until it drops to the slow descent point, and then quickly shut the printer off.  Measure how far it is away from the bed.  Change the "initial_height" setting by just a little less than this amount.

I wish I knew your firmware more.  Maybe someone that does can chime in.

[Shane]

I'm reading up on it a little now, and I suspect you might have a different issue.  Go to this link, and follow the instructions for "Height calibration".

http://smoothieware.org/delta

[Blue Eagle Labs]

I think the board thinks that the bed is closer than it actually is. send M665, and share the response so we can take a look at it. 

[Haydn Huntley]

You might want to post the output from M501, because that will tell all of the settings.

Your bed is about 300mm in diameter, so the radius should be around 150 to 160mm, and not 115mm.

There is no way your bed height is 592mm.  Typically is is more like 200-300mm.

Perhaps you have your firmware configured for 1.8° stepper motors, but you are actually using 0.9° ones?

Perhaps someone else who has already calibrated their printer can post their parameters?

[Andrew]

>>> M665

SENDING:M665
L: 304.0200 R: 152.0000 Max Z  235.000

>>> M501

SENDING:M501
Loading config override file: /sd/config-override...
  ; DO NOT EDIT THIS FILE
  ;Steps per unit:
  M92 X80.00000 Y80.00000 Z80.00000
  ;Acceleration mm/sec^2:
  M204 S3000.00000
  ;X- Junction Deviation, Z- Z junction deviation, S - Minimum Planner speed mm/sec:
  M205 X0.05000 Z-1.00000 S0.00000
  ;Max cartesian feedrates in mm/sec:
  M203 X500.00000 Y500.00000 Z500.00000
  ;Max actuator feedrates in mm/sec:
  M203.1 X500.00000 Y500.00000 Z500.00000
  ;Optional arm solution specific settings:
  M665 L304.0200 R152.0000
  ;WCS settings
  G54
  ;Digipot Motor currents:
  M907 X1.00000 Y1.00000 Z1.00000 A1.00000 B1.00000
  ;Home offset (mm):
  M206 X0.00 Y0.00 Z370.00
  ;Trim (mm):
  M666 X0.000 Y0.000 Z0.000
  ;Max Z
  M665 Z235.000
  ;E Steps per mm:
  M92 E96.4600 P57988
  ;E Filament diameter:
  M200 D0.0000 P57988
  ;E retract length, feedrate:
  M207 S3.0000 F2700.0000 Z0.0000 Q6000.0000 P57988
  ;E retract recover length, feedrate:
  M208 S0.0000 F480.0000 P57988
  ;E acceleration mm/sec²:
  M204 E500.0000 P57988
  ;E max feed rate mm/sec:
  M203 E50.0000 P57988
  ;E Steps per mm:
  M92 E90.0000 P39350
  ;E Filament diameter:
  M200 D0.0000 P39350
  ;E retract length, feedrate:
  M207 S3.0000 F2700.0000 Z0.0000 Q6000.0000 P39350
  ;E retract recover length, feedrate:
  M208 S0.0000 F480.0000 P39350
  ;E acceleration mm/sec²:
  M204 E500.0000 P39350
  ;E max feed rate mm/sec:
  M203 E50.0000 P39350
  ;PID settings:
  M301 S0 P10.0000 I0.3000 D200.0000 X255.0000 Y255
  ;Max temperature setting:
  M143 S0 P300.0000
  ;PID settings:
  M301 S1 P10.0000 I0.3000 D200.0000 X255.0000 Y255
  ;Max temperature setting:
  M143 S1 P300.0000
  ;Probe feedrates Slow/fast(K)/Return (mm/sec) max_z (mm) height (mm):
  M670 S5.00 K100.00 R0.00 Z235.00 H5.00
config override file executed

[Haydn Huntley]

  ;Steps per unit:

  M92 X80.00000 Y80.00000 Z80.00000

The values for M92, steps per mm for each of your X, Y and Z motors is probably incorrect.

80 steps/mm is for 1.8 degree/step motors with 20-tooth pulleys and 1/16 stepping.

You should count the number of teeth on one pulley.  It will probably be 20, 16 or 15.  (I use a Sharpie to mark one tooth, to make counting easier.)

The MKS SBASE board you're using uses DRV8825 drivers, which use 1/32 stepping, which will double the above numbers from 80 to 160.

If you're using 16-tooth pulleys instead of 20-tooth ones (with 1/32 stepping), then the values should be increased by 1.25 from 160 to 200.

If you're using 0.9 degree motors, then the values should be doubled again.

You can use the command "M92 X160 Y160 Z160" to see if that helps.

 ;Home offset (mm):

  M206 X0.00 Y0.00 Z370.00

  

On my printer, it is using "M206 X0.00 Y0.00 Z0.00"

Also, this controls how many steps per mm of 1.75mm filament is extruded: M92 E96.4600

You should probably change it to double that, because you're using 1/32 stepping:  M92 E192.92

[Andrew]

You can use the command "M92 X160 Y160 Z160" to see if that helps.

I set M92 to 160

SENDING:M92

X:160.000000 Y:160.000000 Z:160.000000 E:96.459999

That seemed to work better, but when I home, the motors seem to bind.

On my printer, it is using "M206 X0.00 Y0.00 Z0.00"

 SENDING:M206

X: 0.000 Y: 0.000 Z: 0.000  will take effect next home

I didn't notice any changes with this one

[Haydn Huntley]

@Andrew, Did you already verify that all three of the endstop switches work properly?

Could you post a short video which shows what you mean by "the motors seem to bind"?

After doing "G28" to home your printer, then you can use these instructions to set the maximum z-height:  http://smoothieware.org/delta#configuring-z-height
Then I'd recommend using a ruler or tape measure to verify that the maximum z-height agrees with reality.

[Andrew]

Here is a video. Sound doesn't seem to be working, but you can see where it binds and the motors continue to go until I type the M999

https://drive.google.com/open?id=0BwfKxaOw3Z_fVXNLUkg4XzhIWWM

[Haydn Huntley]

After sending any command which changes the printer's settings, then you have to do G28 (home all) to make the new changes take effect, and then you can start using them.

The first thing you must do is make sure that your printer knows how many steps per mm the motors will move.

You need to follow the instructions at this link:  http://smoothieware.org/delta#configuring-z-height

And then check it with a tape measure afterwards to make sure the answer is accurate.

I'd recommend doing it without the z-probe attached, so that you can do it more accurately with the tip of the hotend.

BTW, when you do "G32" it still says the radius is 115.

Where does that number come from?  Is it in your config.txt file?

It should be around 150 instead of 115.  This is also likely to cause problems and should be fixed.

After changing anything in config.txt, then eject the drive from the OS and reset your MKS SBASE board, so that it will take effect.

G32 can do auto-calibration, but it requires that the steps/mm for the motors are correct, and it helps to have the maximum height and horizontal radius set close to their correct values.

Isn't there some sort of guide which BEL has written up on how to do this?

 

Haydn Huntley
cell: 808-283-5173

On Fri, Jun 2, 2017 at 4:12 PM, Andrew <seam...@gmail.com> wrote:

Here is a video. Sound doesn't seem to be working, but you can see where it binds and the motors continue to go until I type the M999

https://drive.google.com/open?id=0BwfKxaOw3Z_fVXNLUkg4XzhIWWM

--
You received this message because you are subscribed to a topic in the Google Groups "Blue Eagle Labs Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/BlueEagleLabs/5nCQXnr4U9g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to BlueEagleLabs+unsubscribe@googlegroups.com.

To post to this group, send email to BlueEa...@googlegroups.com.
Visit this group at https://groups.google.com/group/BlueEagleLabs.

To view this discussion on the web visit https://groups.google.com/d/msgid/BlueEagleLabs/01eccea7-2280-4f37-9338-7028dd8348d0%40googlegroups.com.

[Haydn Huntley]

I still wasn't able to understand what you mean by the "motors binding" by watching the video.

One other thing you can try (when you get everything prepared properly) is instead of using "G32" which defaults to requiring a precision of 0.03mm, which your printer currently is unable to meet, would be to use "G32 I0.05" to try calibrating with a precision of 0.05mm, which might work better.  Even 0.1mm might produce acceptable results.

[Andrew]

The 115 comes from the config file.

leveling-strategy.delta-calibration.radius   115             #BEL the probe radius (originally 100) 

I'll try the z-height calibration. I was attempting the Finding gamma_max with a probe method, but it didn't work before. 

I just did it and it worked. Z:296.6938 probe is 18, so gamma_max is 314.69mm. This is way off from what I measure (242mm). Config file has 235.

This makes me think the steps are off? They are 15-tooth pulleys, 0.9-degree motors, the belt pitch is 2mm, Micro-stepping jumper is 1/16. Should the steps be at 213.33?

I'll try to get the sound working on the video and try again. Not used to this video software.

As of right now, there is no guide (video files are still being worked on), but i thought I'd try anyway. 

Right now, after changing the config file, i unplug the power and the USB from the printer and plug it back in. I want to be sure it updates. 

On Friday, June 2, 2017 at 7:53:53 PM UTC-7, Haydn Huntley wrote:

After sending any command which changes the printer's settings, then you have to do G28 (home all) to make the new changes take effect, and then you can start using them.

The first thing you must do is make sure that your printer knows how many steps per mm the motors will move.

You need to follow the instructions at this link:  http://smoothieware.org/delta#configuring-z-height

And then check it with a tape measure afterwards to make sure the answer is accurate.

I'd recommend doing it without the z-probe attached, so that you can do it more accurately with the tip of the hotend.

BTW, when you do "G32" it still says the radius is 115.

Where does that number come from?  Is it in your config.txt file?

It should be around 150 instead of 115.  This is also likely to cause problems and should be fixed.

After changing anything in config.txt, then eject the drive from the OS and reset your MKS SBASE board, so that it will take effect.

G32 can do auto-calibration, but it requires that the steps/mm for the motors are correct, and it helps to have the maximum height and horizontal radius set close to their correct values.

Isn't there some sort of guide which BEL has written up on how to do this?

 

Haydn Huntley
cell: 808-283-5173

On Fri, Jun 2, 2017 at 4:12 PM, Andrew <seam...@gmail.com> wrote:

Here is a video. Sound doesn't seem to be working, but you can see where it binds and the motors continue to go until I type the M999

https://drive.google.com/open?id=0BwfKxaOw3Z_fVXNLUkg4XzhIWWM

--
You received this message because you are subscribed to a topic in the Google Groups "Blue Eagle Labs Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/BlueEagleLabs/5nCQXnr4U9g/unsubscribe.

To unsubscribe from this group and all its topics, send an email to BlueEagleLab...@googlegroups.com.

[Haydn Huntley]

Yes, the steps are off.

Yes, 213.33 is the correct value for 15-tooth pulleys, 0.9 degree motors and 1/16 stepping.  I'm surprised that you don't set your drivers to use 1/32 stepping, and use 426.67 steps/mm -- it will be slightly smoother and quieter.

In config.txt I'd recommend updating:

leveling-strategy.delta-calibration.radius   115

To:

leveling-strategy.delta-calibration.radius   151

I'm guessing it was a transposition typo.

Give it another whirl and see what happens!  :-)

If it makes you feel any better, I thought I knew how to calibrate Delta printers with Smoothieware, and spent a few weeks unsuccessfully wrestling with my Metal Delta, because I miscounted the number of teeth on the pulleys, and I'd assumed it had to be either 20 or 16!

[Andrew]

I'll power down the printer and move the jumper to 1/32. 1/16 was the default.

I'll try the 151 as well.

When setting to 426.67 with the M92 command, I get:

SENDING:M92 X426.67 Y426.67 Z426.67

X:426.670013 Y:426.670013 Z:426.670013 WARNING: actuator 0 rate exceeds base_stepping_frequency * ..._steps_per_mm: 213335.000000, setting to 234.000000
WARNING: actuator 1 rate exceeds base_stepping_frequency * ..._steps_per_mm: 213335.000000, setting to 234.000000
WARNING: actuator 2 rate exceeds base_stepping_frequency * ..._steps_per_mm: 213335.000000, setting to 234.000000

[Andrew]

I've started hosting a stream. It might make it easier to diagnose the printer issues 

https://mixer.com/KingSplaty

[Haydn Huntley]

Hi Andrew, 

I get that same warning on my printer, but it works just fine.

By good luck I just got a look at your stream.

It looked like you're still trying to use M92 with 160 steps/mm.  You should switch to using 426.67 steps/mm (with 1/32 stepping), because you have counted the number of teeth on your pulleys and know for fact there are 15 of them.

Just try it and see if it when you have the printer determine its maximum height, if that also agrees with what your ruler says.

This would be a step forward (and worth saving with M500).

Once this is done, then you can do auto-calibration with "G32 I0.05" or "G32 I0.1".  The I-parameter specifies the accuracy.

Question:  On your printer, if you used small pliers to remove the little metal spring arms on the microswitches used for the ends stops and the z-min probe, would they still get triggered properly?  On my printers I've done this modification, because it improves the accuracy by about a factor of two.

[Andrew]

Hi Hayden, thanks for checking it out. I was probably playing with the steps when you were watching. 

When I was talking with Blue Eagle went with the 1/16 and 213.33 steps.

The printer seems to have a problem homing right now. (this might be part of the overall problem)

The motors slip(?) when trying to home. They go about 1/2 way before the carriages stop moving, the motors are still making noise, but the shafts aren't moving. I can move the carriages (the motors are no longer gripping the shafts). When I move all carriages and trigger their end-stops, the motors re-engage and do their bumps against them. 

[Randy Smyth]

I've set my board jumper to the 1/32 setting as i have the upgraded motors,  

http://www.prusaprinters.org/calculator/#stepspermmbelt

using 0.9 degree motors, 15 tooth gears which i counted, 2mm pitch GT2 belts i get the 426.67 steps/mm, so I've changed this in my config file. 

I have my printer mechanical working, Goes to home correctly, motion across various travel appears correct using Ponterface through the usb interface.

Have not done a complete calibration as the build plate is a real bugger to assemble down and needs to be removed to change any wiring, so waiting for wiring questions answered prior to final

[Andrew]

Randy, how far away from the top are you before you start homing with the 426.67 steps/mm? Did you use the firmware Blue Eagle supplied? Can you please post the results of @version and M501. 

When testing, you might want to flip the build plate over so it doesn't scratch the surface. I found that out the hard way.

[Randy Smyth]

I stand corrected, the settings i am using in the config file are not updating the firmware. When i do a M501 command, or view using the LCD, the settings are back to the 80steps/mm as in the default config file.

I need to figure out why its not saving.

[Andrew]

You can check by sending an M92 command

[Randy Smyth]

Deleting the config override file to force it to use the config.txt only, and changing the config file to be 426.67 steps/mm as i believe its supposed to be, causes the printer to go erratic, move sideways, and jam? when issuing a home command.

Deleting the config override, and using the original config file BEL sent, where the steps are 80 and has comments for a 20 tooth wheel which it isn't, causes it to behave normally on a home command.

So im a tad confused. Maybe one of the listed 0.9 degree motors is actually a 1.8 degree and mislabeled?

[Andrew]

Good news/Bad news: 

Bad news:

You are having the same problems as me.

Good News:

Blue Eagle is aware of the issue and looking into it

 

I looked up the stepper motor product number and they are the 0.9.

Did you count your pulley teeth? I counted mine and it was 15, the parts list also said 15, but another confirmation would be great.

Two of us with the same problem makes me think its not hardware, which was the direction we were leaning yesterday.

[Randy Smyth]

15 teeth per gear.

[Andrew]

Thanks for verifying. Makes me feel better about my counting abilities :)

[Randy Smyth]

I can change the config to be the 426 steps, and jog through all motion and all appears smooth and correct. Its the G28 home command that makes it go crazy.

[Andrew]

Same problems here. I can jog up, down, 360, but as soon as I home, it jams. When I force the homing routine to complete by making the carriages hit the end stops, the motors reverse and the routine completes.

[Randy Smyth]

Thinking a upgraded firmware may be the answer as ours is dated Dec 26 2014. I went to the MKS repository on GitHub, downloaded their firmware dated Nov 2016, flashed the board but its the same Dec 2014 version.

[Andrew]

It uses the same firmware as smoothieboard. I was using it for a bit, but changed back when troubleshooting with Blue Eagle.
Here is a link to the github: https://github.com/Smoothieware/Smoothieware

[Randy Smyth]

I upgraded to newest smoothieware firmware with no change in homeing issue.

I then figured since  everything goes to crap when just the stepping motion changes, so reducing the speed of "homeing" might fix it since we doubled the steps per mm, its halve the homing speed.

cutting values in half appears to fix it.

alpha_fast_homing_rate_mm_s                  100              # homing feedrates in mm/second

beta_fast_homing_rate_mm_s                   100              #

gamma_fast_homing_rate_mm_s                  100              #

alpha_slow_homing_rate_mm_s                  10               #

beta_slow_homing_rate_mm_s                   10               #

gamma_slow_homing_rate_mm_s                  10

There may be a more optimal fix, but this at least allows me to proceed.

[Andrew]

Randy, Looks like Blue Eagle posted a new config file in the Wiring Diagram thread. I haven't had a chance to look at it yet, but from the description, they came to the same conclusion as you.

[Andrew]

Hey Randy and Blue Eagle, 

Those changes to the config file worked for auto calibration!

I had to set the z-probe max z to be about 30mm shorter than the distance to the bed. Once I did that, calibration worked the first time!

Now, I seem to be having an issue with moving X and Y. It doesn't seem to know how long its arms are? I can move X or Y to a point where the carriages are below the effector just by telling it to move X or Y. 

I thought it was a similar issue to a homing, so I slowed down the max_travel, max_rate, max_speed, default_seek_rate, and default_feed_rate to 100. I also changed acceleration to 300. 

This did not help.

Here are the results of a M501:

SENDING:M501
Loading config override file: /sd/config-override...
  ; DO NOT EDIT THIS FILE
  ;Steps per unit:
  M92 X426.67001 Y426.67001 Z426.67001
  ;Acceleration mm/sec^2:
  M204 S3000.00000
  ;X- Junction Deviation, Z- Z junction deviation, S - Minimum Planner speed mm/sec:
  M205 X0.05000 Z-1.00000 S0.00000
  ;Max cartesian feedrates in mm/sec:
  M203 X500.00000 Y500.00000 Z500.00000
  ;Max actuator feedrates in mm/sec:
  M203.1 X234.00000 Y234.00000 Z234.00000
  ;Optional arm solution specific settings:
  M665 L304.0200 R151.1601
  ;WCS settings
  G54
  ;Digipot Motor currents:
  M907 X1.00000 Y1.00000 Z1.00000 A1.00000 B1.00000
  ;Home offset (mm):
  M206 X0.00 Y0.00 Z29.60
  ;Trim (mm):
  M666 X-2.606 Y0.000 Z-1.051
  ;Max Z
  M665 Z213.860
  ;E Steps per mm:
  M92 E216.3300 P57988
  ;E Filament diameter:
  M200 D0.0000 P57988
  ;E retract length, feedrate:
  M207 S3.0000 F2700.0000 Z0.0000 Q6000.0000 P57988
  ;E retract recover length, feedrate:
  M208 S0.0000 F480.0000 P57988
  ;E acceleration mm/sec²:
  M204 E500.0000 P57988
  ;E max feed rate mm/sec:
  M203 E50.0000 P57988
  ;E Steps per mm:
  M92 E90.0000 P39350
  ;E Filament diameter:
  M200 D0.0000 P39350
  ;E retract length, feedrate:
  M207 S3.0000 F2700.0000 Z0.0000 Q6000.0000 P39350
  ;E retract recover length, feedrate:
  M208 S0.0000 F480.0000 P39350
  ;E acceleration mm/sec²:
  M204 E500.0000 P39350
  ;E max feed rate mm/sec:
  M203 E50.0000 P39350
  ;PID settings:
  M301 S0 P10.0000 I0.3000 D200.0000 X255.0000 Y255
  ;Max temperature setting:
  M143 S0 P300.0000
  ;PID settings:
  M301 S1 P10.0000 I0.3000 D200.0000 X255.0000 Y255
  ;Max temperature setting:
  M143 S1 P300.0000
  ;Probe feedrates Slow/fast(K)/Return (mm/sec) max_z (mm) height (mm):
  M670 S5.00 K100.00 R0.00 Z213.86 H5.00
config override file executed

[Blue Eagle Labs]

how far to + or - X are you trying to go? this will happen if you are beyond the bounds of the xy diameter. you have to set the diameter. 

if the diameter is not set, it will keep doing that. remember that ll the delta geometry is doing is converting the cartesian moves to delta moves, so this will happen if you don't establish the limits. the easiest way is to tell it its limits on pronterfacre (or whichever one you're using)

[Haydn Huntley]

The printable area on the bed should be a circle with a radius of approximately 125-130mm.

[Randy Smyth]

A radius of 120mm has my fans just touching the belts.

[Brian T]

^ Same, radius of 120 has autocalibrate hit the belts and sometimes it tries to probe just barely off the build plate.

[Andrew]

In ponterface, I set my Width and Depth to 240.0. I left height at 100 (for now).

I'm getting pretty good results right now with the Monoprice black pla

https://drive.google.com/open?id=0BwfKxaOw3Z_faUF3RVI5a18xZ0k

https://drive.google.com/open?id=0BwfKxaOw3Z_fZ0kxczE4d25hWVE

[Andrew]

Printed a calibration cube and was vary very close for X, Y, and Z at 20mm. Printed at 0 infill. Top needs some help

[Randy Smyth]

I did the same cube. My results are much worse :)

What settings are you using for temp, speed, etc?

Mine got 3/4 of the way though, with a honeycomb infill then my laptop went to sleep and broke the connection heh.

[Andrew]

Hotend temp is 200

Bed temp is 65

Filament is Monoprice PLA

Speed is default at what I set M92 E275.0000

I didn't use any infill which is why Z looks bad. I don't have the proper settings for bridging.

[Randy Smyth]

My extruder hack with washers is sufficeint for testing, but it can't keep up with the actual print demand. It skips a lot, spins and grinds the filament into a pile of filings below.

I need to get some correct sized bearings or a different hack to make it work. images below show how it stopped extruding in areas, couldn't keep up in other areas, then the laptop went to sleep .......

but its progress.

[Andrew]

Here is what my extruder looks like:

I had an extra large bearing. Not sure if it was supposed to be a large one, or small, but its working

[Randy Smyth]

interesting, mine feeds the other way, tubing out the other side but the supplied bearing as you show is too big. it seems to work with yours as the tube is far enough away from the pinch point

[Andrew]

That might be why you had to reverse yours. Seems like it could go either way.

[Haydn Huntley]

I never let my computers spool the G-code to the printer.

Instead I always copy the G-code files onto the SD card and print off of the SD card.

Spooling is fraught with problems and will typically decrease the quality of the printing, especially with 8-bit controllers and/or Windows.

[David Bates]

Interesting, I've always spooled since printing from SD Card was fraught with problems like read errors and I typically had issues getting good print quality...

[Haydn Huntley]

@David, Are you sure you had read errors from an SD card?

I've never heard of that, but if I had an SD card which wasn't working correctly, I'd replace it with another one.

Windows has a hard time keeping the buffer full when spooling G-code to the printer, so if you have a reasonably fast printer (60+mm/sec) the buffer on the printer can get emptied, which will cause the print to pause, which will leave zit-like marks in the plastic.

I've heard that Mac OS and Linux don't showcase this problem nearly as much as Windows does.

Either way (spooling the G-code or copying it to SD and then printing from the SD card), the same G-code gets used, so I'm very puzzled that you implied that your print quality was worse.

Could you have confounded other factors, such as not printing the exact same G-code in your side-by-side testing?

[David Bates]

Yeah I think it was more to do with parts failing and my makerbot experience than the actual quality of my kossel clear. I’ve worked solely from macs and octoprint since I had so many failures early on. When first starting with the clear I had many problems Printing from sd but none when connected straight to the Mac.

[Haydn Huntley]

Apparently Macs are much better than Windows at USB communications.

I've heard that Octoprint is very nice to use!

I've also been benchmarking and seeking the ultimate performance from my machines, which is part of the reason I gave up on spooling.

Plus, once Windows decided to do a reboot in the middle of a long, overnight print.  It just isn't my favorite operating system.

[David Bates]

For me it’s simplify 3d right to the printer from my Mac. Octoprint is great but I haven’t adjusted to it yet. (Bout two months) I think it will be more useful on the metal delta where I get to start from scratch.

[Shane]

I agree with Haydn, I always use SD card for print.  I had way too many failures using USB.

[John Gelnaw]

On Saturday, June 10, 2017 at 6:10:05 AM UTC-4, Shane wrote:

I agree with Haydn, I always use SD card for print.  I had way too many failures using USB.

I printed with my Kossel Clear for nearly a year via USB before I discovered that due to a misalignment when I built it, the SD card slot is inaccessible.

However-- I also print from Linux  (via Repetier Host) over USB @ 115200.

[Andrew]

I've been printing off the SD card. I can queue up what I want to print by saving the G Code to the SD card then print from the printer directly using the lcd.
I printed a few things this week without turning on the computer.

[Shane]

John, I had the same issue, but I noticed it when I was building and used a file to fix the slot alignment.

Andrew, that's exactly what I do.

[Randy Smyth]

Similar to the issues Andrew and myself had at the beginning of this thread, I still have occasional erratic behaviour.

Some parts print perfect. Auto calibrate works fine, even doing a grid calibration works.

Last night I tried doing 2 parts side by side on the bed, somewhere about the 5th layer it drove itself into the bed repeatedly as it moved diagonally hitting the bed 4 times before I could react and end it. Since that was sliced with Cura's newest beta I thought maybe it was putting in some odd gcode. Cura also doesn't have a "smoothie" gcode flavor and so maybe using riprap was getting a wrong code also.

So I used Slic3r to do the same model, and it sliced differently. Upload to SD card, and print. This time during the first layer at about 80% done (in a completely different area) while executing a move from one area to another it again drove itself into the bed and moved at different 45 angle......You can see in this pic where it was just finishing one section at upper left and was moving to the other incomplete area .....Yes its bunny ears :)

Im tired of destroying the nice silk screened gecko bed. I now have about 4 large gouges from erratic behaviour.

Heres a link to the gcode file if someone can tell me what command was making it go crazy. 

https://www.dropbox.com/s/m92slkpdaxcxxxe/Badge-bunny.gcode?dl=0

Since the previous erratic behaviour was fixed by slowing seek rates. Can someone with better knowledge than me figure out if a settings in BEL config.txt file need changing to Lower values to prevent this ?

[Andrew]

I was having similar issues. I lowered the speed of the print and the speed between parts.
When I get home I'll share my slicer settings.

[Johan Pettersson]

I was having huge problems with the motors jamming ect in the beginning but that was only because they tried to move to fast so that they used more amps than they could get DUE TO that pesky little bridger i did not know about that vhanges between the 1/16 and 1/32 microstepping setting. But maybe everyone else knows about that except me xD

[Johan Pettersson]

Oh yes, forgot to say. I also had where it did some erratic movements due to this when it didn't get enough juice i guess. When i changed that setting i never noticed it again. I think atleast. But i too have had some accidents that wasn't so nice...

[Randy Smyth]

Ya, hard to watch when the machine beats itself up and ruins the coated bed.

My stepping is set to 1/32 and motors stepping of 426.67 steps/mm. The home seek speeds were identified as too fast earlier so those are already lowered.

I've increased the amps for the extruders which solved my extruding issues but have left the movement steppers at 1.0 A. Did you change those also ?

@Andrew yes please let me know what settings you changed. Ive changed all my speeds and accelerations to half what they were in the config. From 4000 down to 2k, 1500 aceleration etc. 

[Andrew]

I hate finding out I did something to damage the bad. I assure you, mine is in worse case (gouged ridges between X and Z towers when printing calibration rings) and the GeckoTec plate is still preforming well. 

In my config file, acceleration is still at 3000. My x_axis_max_speed: 100 (same for y and z). I think after the homing speed decrease (alpha_max_travel: 1000 (same for beta and gamma)), I left the other settings the same.

I enabled Expert Mode in Slic3r (File > Prefrences > Mode > Expert)

My Speed settings in Slic3r (Print Settings > Speed) are as follows:

Speed for print moves:

Perimeters: 60 mm/s

Small Perimeters: 15 mm/s

External Perimeters: 50%

Infill: 60 mm/s

Solid Infill: 20 mm/s

Top Infill: 15 mm/s

Support Material: 60 mm/s

Bridges: 20 mm/s

Gap Fill: 30 mm/s

Speed for non-print moves:

Travel: 100 mm/s (I noticed it wasn't during the printing that the problem was happening, but when moving)

Modifiers:

First later speed: 30 mm/s

Acceleration control: All 0 mm/s

Autospeed:

Max print speed: 80 mm/s

Max volumetric speed: 0 mm³/s

While you are at it, change retraction settings (Printer Settings > Exctruder) to get rid of the strings between parts if you have this issue.

Retraction:

Length: 6mm

Lift Z: 0.1 mm

Speed: 100 mm/s

Extra length on restart: 0

Minimum travel after retraction: 2mm

Retract on layer change: Checked

Wipe while retractions: Un-Checked

Hopefully this works for you. Let me know!

[Johan Pettersson]

No i actually left my settings like they were in the new config that BEL put up for the high def motors in the Metal Delta Circuit diagram thread. There they had already lowered the speed in there. Only thing i had to change in there was the zprobe settings and yes, also the homing speed. How tight is your belts?

I guess it should be said that i gave up on slic3r and that i'm using the Cura nightly aswell.

[Randy Smyth]

Andrew

I set my speeds to the same as you have listed but the motion of the machine was very slow. Trying to do a G32 calibration routine took forever and i finally cancelled it.  Ive since put the speeds back up except the axis_max_speed ones.

x_axis_max_speed                             3000.0            # BEL 30000

The axis max speeds seem to be the ones which cause the issues. I changed them from 30,000 to 3000 which i believe is 500 mm/s down to 50mm/s. Changing from 30,000 to 100 as you have listed I think it moves at 1.7 mm/s. I might doubt them so the max it can move is 100mm/s. More testing, or someone with better knowledge needed. 

What i find interesting/disappointing is the inability of this system to go at speeds in excess of 100mm/s. Delta's main touted benefits are speed, with new and well constructed printers boasting 200mm/s and some as high as 300mm/s. If this is limited to under 100mm/s its a an interesting bottleneck. So is the issue the board itself? Is the MKS SBase board being a knockoff of a smoothie board unable to match the speeds? Is it a firmware issue? Or are there just some conflicting settings that cause the erratic behaviour?

Some input from BEL would be appreciated.

On Saturday, June 17, 2017 at 9:56:25 PM UTC-7, Andrew wrote:

In my config file, acceleration is still at 3000. My x_axis_max_speed: 100 (same for y and z). I think after the homing speed decrease (alpha_max_travel: 1000 (same for beta and gamma)), I left the other settings the same.

[Haydn Huntley]

Hi Randy,

Have you examined the Smoothieware documentation website?

I have found the answers to many of my own questions there -- it is well organized, illustrated, and clearly written.

Here is the link:  http://smoothieware.org/delta

Usually speeds are specified in mm/sec, so 3000 is very fast.  200-300mm/sec would be more reasonable.

On the printers I've built with controllers just like this one, they can easily move the effector at 200mm/sec for travel moves.  For actual printing, I usually print at 60-80mm/sec, because that produces higher quality results.  There are limits to how fast different filaments can be melted and printed.  With a normal (non-Volcano) E3D hotend and 1.75mm PLA, I've heard that the limit is around 9mm^3/sec.  With a 0.5mm nozzle with 0.2mm layers, then 80mm/sec = 8mm^3/sec.

Your issues are probably the result of user error or misconfiguration.

As it turns out, since 3D printers usually spend most of their time printing instead of doing non-printing moves, then it doesn't really matter that much how fast they can do the non-printing moves -- typically they're less than 10% of the production time.

If you really want to push the speed limits of your new printer, then first find out what works well, and slowly increase the speeds and accelerations by something like 1.2x to 1.5x at a time to find out what the limits are.

[Randy Smyth]

Haydn

Thanks for the reply. I do believe you have misunderstood my post.

I am printing at 50 or 60 mm/s, with non-print travel times that were at 130mm/sec as the default in slicer apps and that was causing the issue. 130mm/sec was too fast. I am only able to succeed when speeds are under 100mm/sec for any form of travel. I have not tried printing above 60mm/sec.

The 3000 I posted is mm/min not per sec.

I agree with you that 200mm/sec when not printing is a realistic expectation. Unfortunately anytime I run this over 100mm/sec travel speed it goes erratic and drives into the bed or heads off to space.

Im new, so operator error is quite easily an issue. But in the speeds I believe my expectations of 200 mm/sec when traveling are not unrealistic.

[Haydn Huntley]

Hi Randy,

Could you post your config.txt and config-override files?

Maybe I can look through them and suggest some things to try changing.

By the way, when you do a print which lasts 30 minutes or more, how warm do you X, Y, and Z tower motors get?  Are they at around body temperature, hot to the touch, or too hot to touch?

How about your extruder motor?

(The reason I'm asking this is that it is possible that your motors aren't getting enough voltage or current, which might be why they cannot move your effector at 200mm/sec.)

When you try to do non-printing moves at 200mm/s does it fail reliably?  It is very useful to have a test case which fails reliably!  :-)

[Randy Smyth]

Haydn

I'll post the files when I get home tonight, but the config.txt is what BEL has posted in the other thread. I used it un modified.

Well originally I used it in modified and that's when I discovered the homing speed was wrong and causing mine and others to go crazy. They have since found the same conclusion and posted a new one with the home seek speeds at half.

As for repeatability, thats unsure as any time it's gone crazy I've changed something in the slicing, used different slicer, tried a different part, etc.

So far the only common denominator is any travel speed over 100 mm/s.

[Randy Smyth]

Here are the two files

 

The motors get hot, but not too hot to touch, perhaps 40C ? 

When I had the original "as supplied" extruder setup with the wrong bearing size, etc, the routing of the pathway was not straight and the extruder was unable to supply filament. I increased the extruder motor current to 1.5A and that worked. I have since purchased a MK8 metal extrusion setup that allows a less restrictive filament path until BEL supplies the correct parts. With this mod I have put the extruder motor back to 1.0A.

I have not tried the axis motors at anything other than the 1.0A 

[Haydn Huntley]

Hi Randy,

40C is a pleasant temperature for stepper motors and 1A is the same amount of current I set my axis motors for.  Though I often have to use 1.2A or so for the extruder motors.

I used a "diff" tool to compare your files with mine and found some differences.

In your config.txt:

I'm surprised that your alpha/beta/gamma_steps_per_mm are "419.95" instead of "426.67"  Note: it is also that way in your config-override file.  I'm sure this should not be this way!

Your arm_radius is set to "R151.3678".  You should remove that leading "R" and possibly change it to "151.5503", which is what is in your config-override has for it.

I found out (the hard way) that Smoothie doesn't seem to use the alpha/beta/gamma_trim values in config.txt.  Only the ones in config-override have any effect, so in config.txt I just set them to "0.0".

You could probably change zprobe.fast_feedrate from "50" to "100".

In mine, I changed network.enable from "true" to "false" to help conserve RAM.  Apparently there is very little to spare.

In your config-override:

I believe you should change your M92 values from 419.95 to 426.67:

    ;Steps per unit:

    M92 X426.67 Y426.67 Z426.67

You could raise these values from 50 to 250 mm/sec:

    ;Max cartesian feedrates in mm/sec:

    M203 X250 Y250 Z250

    ;Max actuator feedrates in mm/sec:

    M203.1 X250 Y250 Z250

I believe this limits the speeds of your carriages and effector to moving at a maximum speed of only 50mm/sec.

On my printers, I have to give the extruder motors 1.2A instead of 1.0A, so I'd use:

    ;Digipot Motor currents:

    M907 X1 Y1 Z1 A1.2 B1.2

I think the Z-axis home offset should be 0 instead of 35.26.

I'm guessing that your Z height is 235.26 (instead of 200.00), and this is not the right way to correct for it.

 ;Home offset (mm):

 M206 X0.00 Y0.00 Z35.26

Should be changed to:

 M206 X0.00 Y0.00 Z0.00

I don't have these lines:

    ;Probe feedrates Slow/fast(K)/Return (mm/sec) max_z (mm) height (mm):

    M670 S5.00 K50.00 R0.00 Z200.00 H5.00

I wonder if the value for R should be 50, just like the value for K is?

I'm not sure about this though, so if it works OK as-is, then you can leave it be.

Is the printable height of your machine exactly 200mm?

That is difficult for me to believe, thus this line is very suspicious:

    ;Max Z

    M665 Z200.000

I'd guess it might be 235.26?

Once you've changed your steps per mm to 426.67, then use "G28" to home your printer and user a metric measuring stick to estimate the distance from the tip of your nozzle to the bed.

Once you get an estimate, then update that value with "M665 Zxxx.xx", do "G28" again, and then use "G0 Z10" and then keep on trying smaller Z values until you get to the point where the tip of your nozzle is just barely touching the bed.

On my printers, I use a sheet of paper as a feeler gauge, and I try to get it so that when the printer is at Z=0.1, the nozzle barely pinches the paper, and there is a moderate amount of drag as I attempt to slide the paper.

Once you have it at Z=0 and the nozzle is just barely touching the bed (note this is different from Z=0.1 and the nozzle is pinching a sheet of paper), then you can do "M306 Z0" to set that, and then "M500" to save it.

I'm guessing it will set the value for M665.

Here is a link:  http://smoothieware.org/delta#automated-calibration

In your config.txt file, you have these lines:

    leveling-strategy.delta-grid.do_home true

    leveling-strategy.delta-grid.enable true

    leveling-strategy.delta-grid.initial_height 35

    leveling-strategy.delta-grid.radius 115

    leveling-strategy.delta-grid.save true

    leveling-strategy.delta-grid.size 7

I didn't have any luck getting my MKS SBASE board to do automatic calibration, but I've had success with an AZSMZ and also an Azteeg X5 with the following:

    leveling-strategy.delta-calibration.enable   true            # basic delta calibration

    leveling-strategy.delta-calibration.radius   100             # the probe radius

    leveling-strategy.delta-calibration.initial_height 10        # height above bed to stop initial move

These came from this link:  http://smoothieware.org/zprobe#delta-calibration

I was able to use the "G32" command to quickly calibrate my printers.

I hope this proves useful!

At least I think I've figured out why your printer wouldn't go faster than 50mm/sec.

[Randy Smyth]

Haydn

Thanks for the review.

-No idea how the 426.67 got changed to 419.95. I looked at my calculations and earlier config.txt backups and I had them all at 426.67. I'll chalk it up to a seniors moment or IT savy gremlins.

- The Cartesian max feedrates may have gotten changed down when I had issues at speeds over 100mm/s. The supplied 30,000 mm/min converted to 500 mm/s which i thought may be causing issues so changed down to 3000 or 50mm/s, but only changed the config.txt file. I never edited the override. Only thing i can think of where it could have been changed to a 50.

- The height of the build is 237 but i left it at 200 and added the Z offset, that was back when trying to do the original calibration and it kept crashing the bed. The 200 and an offset fixed it and i haven't changed it back. I'll put it back to as you have listed. thanks for the lesson.

- The grid calibration appears to work fine for mine as I have listed. it uses a 9x9 grid (ive changed it from 7) and stores it to disk

The speed above 50mm/s is the interesting bit. It actually was going faster, it just went erratic behavior when it tried. Wouldn't the too low Cartesian rates prevent it from trying?
I'll adjust as suggested and see if the crashes continue.

I'm surprised that your alpha/beta/gamma_steps_per_mm are "419.95" instead of "426.67"  Note: it is also that way in your config-override file.  I'm sure this should not be this way!

You could raise these values from 50 to 250 mm/sec:

    ;Max cartesian feedrates in mm/sec:

    M203 X250 Y250 Z250

    ;Max actuator feedrates in mm/sec:

    M203.1 X250 Y250 Z250

I believe this limits the speeds of your carriages and effector to moving at a maximum speed of only 50mm/sec.

I didn't have any luck getting my MKS SBASE board to do automatic calibration, but I've had success with an AZSMZ and also an Azteeg X5 with the following:

[Haydn Huntley]

I'm surprised that it was going faster than 50mm/s when the max actuator feedrates were set to 50mm/s.

One question I'd ask is what is the evidence that it was going faster?

There are many times when I've been surprised by how 3D printers (and printer controllers) have behaved.

Sometimes it has been due to my own errors, and other times due to misunderstandings and/or bugs.

The things I know of which limit the printer's speed are:

1)  The various speed limits (for the carriages and effector).

2)  The acceleration limits for the above.

3)  The G-code instructions which have the "F" feedrate parameter.

One of the best tools I've found in Smoothieware for debugging/understanding is using the "M501" command to print the current settings.

Then I can modify them, and if I like my modifications, save them with "M500" in config-override.

[Randy Smyth]

Through lots of trial and error, and many crashes into the bed, i've determined the Mks Sboard V1.3 also has issues with the Z probe section.

Putting the Gamma_max to the actual height of 227.9 and putting Z offset to zero has the head crash into the bed whenever I tried a G31 or G32 calibration.

I added the following line from the smoothie sites config file

"zprobe.z_max     190         # maximum default travel for the probe command, will use gamma_max if not defined"
This never was used by the board. I could change the value to anything and it made no change when it was in the config.txt file. 

Oddly, If I added it it manually by issuing a "M60 Z190" it would work, but only on the G32 calibration routine not a G31 as that would again crash the bed. I also made sure there was no config-overrides file stepping it from working and still no success.

I resorted to adding the following two lines to the relevant sections. Both of these are missing in our BEL supplied config.txt file and as far as I can tell are needed for proper calibration.

leveling-strategy.delta-calibration.initial_height 50  

leveling-strategy.delta-grid.initial_height  50

I gave up with the Chinese in the supplied config file, and edited a new config.txt from smoothiboard site. Enclosed for anyone who wants.

Additionally, I added the section for controlling the hotend fan on a switch that comes on when the hotend is above 50C and turns off when below instead of staying on 100% of the time when the printer is plugged in. I used the 2.6 connection (green connector between fan and extruder heat cartridge) on the assumption our dual head hotend still only uses 1 heat cartridge.

[Randy Smyth]

Haydn

Update on how the stepper motors were set to 419.95 instead of the calculated 426.67.

- BEL supplied file had them as 80

- it was found this was wrong by yourself and others at beginning of this thread, and that 426.67 is correct value with upgraded motors and 1/32 stepping.

- I changed mine to 426.67

- following calibration tutorials I printed a 20x20x20 block and it measured at 20.3mm, the instructions state to then give a M92 code to correct the values for each axis. 

So this is how the values changed from calculated. Turns out It wasn't a seniors moment :)

I've since set them back to the 426.67 calculated and believe the initial 20.3mm measurement may have been by using 1.75mm as filament size instead of the actual 1.70 after measurement and was over extruding.

I assume keeping the motors at the theoretical calculated value is best instead of changing them to make up measured differences. 

As for evidence it was going faster...,

- original supplied files had federates at 500mm/sec max. (set as 30,000 mm/min) All the crashes happened with this original value not the slowed down 50mm/s

- Home command caused crashing and was fixed by slowing home seek speeds to 100 (down from 200)

- slicer programs seem to default to 130mm/sec travel time

- myself and others in this thread who have assembled so far had crashing and other erratic movements using supplied config files.

- Since setting all values in both config files and slicer apps to be 100mm/s or less for any style movement I've not had any more issues.

So I came to the conclusion, right or wrong, that the system can't go over 100mm/sec. 

- Ive also since moved my config files back up to the original values, but have kept my slicing apps to max travel speeds less than 100mm/s and with only a couple prints done have not had issues.

It will take some testing to see if I can put slicing apps travel speed above 100 again to the advertised 150mm/s and not cause issues.

You are correct, I have no idea what its actual speed was going when it went erratic. It was just a conclusion based on the above. All my print speeds were under 100 being 80 for infill, 30 or 50 for perimeters. It was only non print travel that caused issues and only when set to above 100.

[Haydn Huntley]

Hi Randy,

Thank you for publishing this update!

I'm sorry that BEL wasn't able to initially publish configuration settings for the MKS SBASE which worked properly.

I hope they're following this and updating theirs, or you might share yours with with them to help them.

Which program are you using for slicing?  I'm used to using Slic3r, though I've also used KISS and Cura (both a long time ago).

Sometimes slicers have bugs...

When I'm trying to get a printer calibrated, one of the question I consider is how certain am I about the accuracy of certain measurements?

Three pieces of information are at the root of getting it calibrated reasonably well:

1)  The length of the arms.

2)  The number of steps per mm.

3)  The horizontal radius.

I measure the arms with micrometers, so that is a pretty accurate number.

The number of steps per mm is also pretty well known, because it depends on the number of steps per revolution of the stepper motors, the number of teeth on the pulleys, and the pitch of the GT2 belts.  As long as one doesn't stretch the belts too much, it should also be pretty accurate.

The horizontal radius can be deduced by the G32 auto-calibration function, so that is relatively easy to figure out.

Once you've got the above three, then the printer should be pretty well calibrated.

My reasoning for the above is also why I would recommend against altering the number of steps/mm in order to make a test object print correctly.

When I print test objects to verify that the printer will make things with the right scale, I print something fairly large in comparison to the size of the bed.

I use a square which is 100mm on a side.  If the printer can print it with an accuracy of +/-1%, then I figure it is good enough.

Note: three small sources of inaccuracy with this technique are:

1)  The printer slows down for the corners, so it may extrude more thickly there, so I measure the square while it is still sticking to the glass, and I measure away from the corners.

2)  The first layer can sometimes be squished, making it fatter.  If I were more patient, I could print something 1-2mm tall, and measure the upper layers.

3)  My slicer defaults to printing the outside layer last, so if the printer is over extruding, all of that extra plastic will tend to make the outside larger.  I could change the default to printing outside perimeters first to help overcome this.

That's part of why I settle for 1% measured accuracy.

Now with all of that said, there are some simple tests you could try to see if your printer can do travel moves at 100+mm/sec.

M203 X250 Y250 Z250   ; set max cartesian feedrates in mm/s

M203.1 X250 Y250 Z250 ; set max actuator feedrates in mm/s

G28                   ; home

G0 Z10 F6000          ; rapidly move to Z=10 at 6000mm/minute (100mm/s)

G28                   ; home

G0 Z10 F7500          ; rapidly move to Z=10 at 7500mm/minute (125mm/s)

G28                   ; home

G0 Z10 F9000          ; rapidly move to Z=10 at 9000mm/minute (150mm/s)

G28                   ; home

G0 Z10 F10500         ; rapidly move to Z=10 at 10500mm/minute (175mm/s)

G28                   ; home

G0 Z10 F12000         ; rapidly move to Z=10 at 12000mm/minute (200mm/s)

When it is performing the above travels, do the motors make sounds at a different pitch when moving at different rates?  To your senses, does it seem to be moving at different speeds?

The above commands are the easiest case.  All three motors are moving the effector equally, and there is nothing nearby to bump into, but they might demonstrate that the printer can travel faster than 100mm/s.  I wouldn't be surprised if it can do 200mm/s.

In practice, the acceleration is very important.  Also, in practice, the speed at which the printer can do travels usually has very little influence on print time.

[Randy Smyth]

Haydn, thanks for the reply and sharing knowledge.

I agree that changing the steps per mm was not correct way to calibrate.

On my learning curve, I've set everything back to "theoretical values" and have spent much more time at calibration of everything else.

Ive managed to get my system calibrated using G32  I0.05 for accuracy, and then adding a G31 grid calibration with 9x9 grid which seems to have made a difference. 

Now when I print the 230mm calibration circle at 1 layer high it is very even all the way around the bed and measures correctly, The 180mm circle is 179.3 so 0.4% error, don't have callipers big enough for the 230mm.

Ive also been printing some filament roll holders, which have press to fit parts, and the fit has been perfect so I assume the time calibrating has paid off.

Ive supplied my version of the config.txt file earlier in the thread so hopefully it helps others.

Slicing apps, I've tried Slic3r, then Slic3r Prusa edition, and now trying Cura 2.6 which was just released, then sent to a Pi3 running octopi and printing from there.

The speed issues happened prior to using octoprint on both Cura 2.5, and on Slic3r as I originally thought it may have been a slicer issue and tried a few.

Now that I actually have some prints working, I'll wait till I try to the speed tests, or let some others experiment. I've damaged mine enough :)

[Randy Smyth]

An update on the erratic behaviour and travel speed with the metal delta.

After a lot of recalibration, etc, I've been happily printing parts, about 40 or so without issues. Print speed up to 60, infill up to 80, travel up to 120.

The prints were all fairly small, many calibration tower prints zeroing in E steps, temperature, etc.nothing big.

Today I ventured into a large multi part print covering the majority of the print bed. The travel speed was at 120mm,s and since the parts were several and spanning much of the bed (but still well within the limits, 40mm from max limits) some of the travel distances were much larger than I've done to date.

Once again the head while traversing a large travel distance decided to drive itself into the bed multiple times and trying to destroy itself.

I'm pretty much convinced the Mksbase board is a piece of crap and not able to keep up with calculations at 120mm. The acceleration speeds are all still set by BEL which also maybe are too high.

Ive already replaced many of the components such as extruders, springs, hotend, fans, etc, Guess the board is next. 

[Randy Smyth]

An update on the erratic behavior and travel speed with the metal delta.

Update #2:
After the unit tried to destroy itself I re-ran the print with travel reduced in slicer to 100mm/sec
This allowed it to get past where it previously crashed so after 20 or so layers I left the printer.

Came back to the pic at the bottom, again its destroyed itself, came off the rails, damaged the bed in multiple areas, etc. I have not examined it in detail to see if anything is broken.

So travel speed reduction is not working at stopping this.
Acceleration is the only thing left before I write this off as an expensive lesson and purchase from a legitimate source.

[Andrew]

I am planning on adjusting the acceleration when I have a chance. I've been testing with the 3DBenchy scaled to 250% and noticed the print skips.
My main issue is the print bed has a giant hole in the middle of the GeckoTek finish down to the metal that is keeping the prints from sticking.

[far beh]

BEL,

Hi I am having similar calibration issues with the following difference:

G28 homes well.

Z0 is set to within 5 mm off the plate

M306, Z0 registers

{SENDING:M306 Z0

Homing Offset: X 0.000 Y 0.000 Z 887.910

}

M500 saves OK

{SENDING:M500

Settings Stored to /sd/config-override

}

G32 command results in the following message with the effector stopping 

{SENDING:G32

Calibrating Endstops: target 0.030000mm, radius 115.000000mm

set trim to X:0.000000 Y:0.000000 Z:0.000000

Calibration failed to complete, probe not triggered

}

The probe switch toggles fine as do the endstops switches.

THank you for any help..

Farshad

On Wednesday, May 31, 2017 at 8:28:31 PM UTC-6, Blue Eagle Labs wrote:

andrew,

1st check the probe status using M114. check each endstop one by one

then home the printer

Run the autocalibration routine with G32

After calibration, save settings with M500

remove calibration probe and set it aside

use M665 to adjust the Z height such that the paper test is set to 0 (home every time you adjust)

Once you have the final Z height adjusted, save it with M500 again

lead the override file with M501 every time you turn on the printer. 

On Wednesday, May 31, 2017 at 6:57:44 PM UTC-7, Andrew wrote:

I got my Metal Delta running, but I am having problems auto calibrating.

I am following the instructions from http://smoothieware.org/delta

(With the Z-Probe on in case that matters)

First home the machine :

G28

Then move to the point the machine currently thinks is Z 0 :

G0 Z0

Then move the head to the bed by jogging, using Pronterface's arrows, the panel, the web interface or whatever other method is adequate in your case.

Finally issue the M306 Z0 command which will use the current Z position as a homing offset : 

M306 Z0

Then save to the SD card with M500 :

M500

Next time you home, the machine will know how high above the bed it is.

 This works great, doing this, I home it again and run G0 Z0 and it finds the bottom perfectly.

Next I try the auto-calibration G32 and that is where problems happen. Not at first, it passes the first and second probes, but the 3rd where it checks X-axis the probe doesn't touch or trigger

http://smoothieware.org/zprobe

Example use :

    G28 (Home XYZ)
    (Move Z at least 30mm away from the bed if it's not, and attach probe if you have a removable probe)
    G32 ( Calibrate the machine )
    (Remove probe if you have a removable probe)
    M500 (to save probe results)
    G28 (Home XYZ)
    (Manually: jog down to touch the plate)
    M306 Z0
    M500 (to save homing offset)
    G28
    (Machine is now calibrated and knows it's correct height above the bed)

Not sure what I am doing wrong or how to fix it. maybe a screw at the end of the switch to give it more area to press against the bed?

[Blue Eagle Labs]

hi farshad, 

the printer probably thinks the bed is farther than it actually is. Please adjust the z height in the calibration settings. reduce whatever value you have on there by 100mm. that should solve the problem. 

also, if you have a video of whats going ont, that would be more helpful. It's hard to diagnose with just looking at the pics, but from what you have given, that would be my guess. 

[far beh]

Thanks  I will try that. However which configuration files do I copy on the SD card? :smoothiware or smoothiware 2 from the download sites? Thanks.

--
You received this message because you are subscribed to a topic in the Google Groups "Blue Eagle Labs Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/BlueEagleLabs/5nCQXnr4U9g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to BlueEagleLab...@googlegroups.com.
To post to this group, send email to BlueEa...@googlegroups.com.
Visit this group at https://groups.google.com/group/BlueEagleLabs.
To view this discussion on the web visit https://groups.google.com/d/msgid/BlueEagleLabs/db252995-3641-45b7-a6b5-452ed24f0f2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Blue Eagle Labs]

hi randy, 

it could be a number of things.  it could be the acceleration settings, but might also have to do with the gcode file and the infill settings and the area in the bed that the effector is positioned (when the magnets got dislodged). i suspect that the arms get knocked off if there was a sudden accelleration, and if the direction of movement is opposite the previous movement. this will probably be worse if the effector is extended towards the outer limits of the bed, because the carriages will be at an angle that makes it more susceptible to being dislodged. 

another possible scenario is that the bed may have shifted (from looking at the pic), and that caused the effector to come in contact with other parts of the print, causing the arm to get knocked off. (Or it's also possible that the arm fell off and then caused the effector to crash into the print, thus moving the magnetic bed.)

some of my personal suggestions are:

reduce speed especially if printing overnight (I also installed a camera just to be able to check in on the print from my phone)

reduce acceleration (also check if your acceleration settings are being overridden by the controller you're using)

in your slicer settings, try to have as few speed settings as possible. for example, i only have 1 speed for the outer perimeter, and 1 speed for the infills and bridges. if something goes wrong, i'll be able to figure out which one of them is causing it. 

[Haydn Huntley]

Hi Randy,

I'm not currently using an MKS SBASE board, but I don't think the board is the problem.

The most common scenario when have trouble with the balls getting knocked loose is when I'm printing an object which does a pretty good job of adhering to the base, but is long, and has one end or the other which begins to warp upwards during the printing process (and come free from the bed).  Typically you'll begin to hear the hotend dragging along already printed material, instead of silently gliding a tiny distance above it.

If you were printing a smaller part, then the part would simply get knocked loose.

Six things you can do to ameliorate this are:

1)  Find a better way to stick the part down.  For warp-prone parts, I print on 3M blue painter's tape, and clean the top surface of the tape with isopropyl alcohol and a paper towel.

2)  Instead of using rectilinear infill, which is the most warp prone, use hexagonal infill.  It is less prone to causing warping.  3d honeycomb (octohedral) infill is less strong, but perhaps even less prone to warping.

3)  Use a lower percentage of infill.  25% is less prone to warping than 50%.

4)  Use a different brand/color of filament.  Some brands/colors are worse than others.  PLA warps quite a bit less than ABS.

5)  Use a lower temperature for the hotend and a higher temperature for the bed.  Shrinkage is what causes warping, and the difference in hotend vs. cooled plastic temperatures is directly proportional the the amount of warping stress which will occur.  If you can decrease that difference by 10%, that might help a little.

6)  Redesign the parts.  Often there is more than one way to skin a cat.  (With apologies to my feline friends.)

[Randy Smyth]

@BEL

Since it happened several times while i was watching the print where it went erratic, tried to drive itself outside the print volume until the arms fall off, or into the bed itself, I'm almost positive it drove into the bed and moving it, then the arms came off.

Slowing everything down to a print of 30mm, travel of 70mm, etc let the print finish.

I also moved the print as far away from Z tower as possible,

Eventually it printed, but only at a speed that is far what what this should be doing.

@Hayden

None of the parts were lifted and caught the nozzle, all parts were still stuck well. The one part in the pic that is lifted was me starting to clear the plate then deciding to take a pic, 

Print was printing petg with no fans and a heated bed.

Other tips i'll use on future prints, thanks.

On Monday, August 7, 2017 at 12:53:08 PM UTC-7, Blue Eagle Labs wrote:

hi randy, 

[blueeaglelabs]

Not sure im following, so did the arms fall off because it was outside the print volume? Or did it fall off because of shaking during print? 

Sent from my Samsung device

--
You received this message because you are subscribed to the Google Groups "Blue Eagle Labs Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to BlueEagleLab...@googlegroups.com.

To post to this group, send email to BlueEa...@googlegroups.com.
Visit this group at https://groups.google.com/group/BlueEagleLabs.

To view this discussion on the web visit https://groups.google.com/d/msgid/BlueEagleLabs/9a92adc2-160d-41d6-a419-631756294f91%40googlegroups.com.

[Randy Smyth]

Shaking ? Ive never mentioned shaking, why would that suddenly confuse you ?

The effector at a certain point during a print, during a travel move is when I've observed it, decides to suddenly veer off and go at a tangent that takes the effector well outside the print bed area. Like upwards and outwards at a 45 degree angle away from the print till the arms hit the towers and it all falls apart.

Or half way across a travel move it decides to suddenly turn 90 degree and drive into the bed at full speed.,

Its not the slicer, I've tried several.

[Blue Eagle Labs]

i meant shaking during infill. I'm trying to figure out if the arms fall off because of movement itself, or if it's because it hits something or goes beyond range. But nevermind, your response already answered that. 

if it takes the effector well outside the print area, or if the effectors hit the belts or the towers, then you need to set your limits on the slicer program that you're using. when you set the limit, the slicer will never create gcode outside your set limit. it will instead wall off right at the maximum area.

[Zach Moore]

Hey Randy,

I'm coming to this discussion pretty late. My understanding at this point:

While printing, during a travel move, your print head will randomly move outside of the build envelope and "crash". 

That is completely abnormal behavior if true, and almost sounds like a buffering/processing error. 

[Randy Smyth]

Zach

Yes my conclusions also. I have all settings I'm pretty sure correct, my build radius is set to 110mm, etc.

In talking with BEL outside of this forum it may be from trying to run 0.9 motors at 1/32 stepping and the mks sbase board can't keep up and looses it.

[Haydn Huntley]

BTW, I have been using 0.9 degree motors with 1/32 stepping with other Smoothieware controllers on four machines I've built, and none of them had any problems whatsoever.  It could be that there are bugs in the version of Smoothieware which the MKS SBASE is using.  I've been using versions of Smoothieware from 2016 and 2017.

[Randy Smyth]

Quite possible. I had issues both with the supplied firmware from MKS, and with the current firmware from smoothieware.

[Haydn Huntley]

Yes, the MKS would not auto-calibrate with the current version of Smoothieware.

Haydn Huntley
cell: 808-283-5173

--

You received this message because you are subscribed to a topic in the Google Groups "Blue Eagle Labs Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/BlueEagleLabs/5nCQXnr4U9g/unsubscribe.

To unsubscribe from this group and all its topics, send an email to BlueEagleLabs+unsubscribe@googlegroups.com.

To post to this group, send email to BlueEa...@googlegroups.com.
Visit this group at https://groups.google.com/group/BlueEagleLabs.

To view this discussion on the web visit https://groups.google.com/d/msgid/BlueEagleLabs/1de0ef56-6b5d-4822-8993-17278c303b6b%40googlegroups.com.

[far beh]

Hi ,

I tried adjusting the height, but then then I copied the config from <smoothieware> folder on to the SD card instead of the config from <smoothieware2> folder.  That took care of the Z height but now I cannot get it to go through the calibration.  I tried rotating the effector plate but with no improvement.

Any ideas?

Farshad

[Blue Eagle Labs]

farshad, is this resolved? I assume the autocalibration is crashing into the plate? try to reduce the z max in the config and in the override file,. reduce it to 100, that should tell the machine to slow down at a higher position instead of ramming into the bed.