HE280 Crashes right into the build plate durring setup

[GadgetTech]

Hello all,
I hate to make a post about this but I can't seam to find this exact issue to go off of. I have a v2 with trick-laser arms, molded cheapskates and of course the HE280. Everything got wired up with the per-assembled whip and I have check continuity on all wires and confirmed proper placement in the diagrams. Everything is groovy until I try to calibrate and it goes down like it should, hits the bed and just keeps on truckin down without stop. I have to estop it. I know there have been some that say you have to run it a few times when it does that to get it to work but this seams extreme. I did confirm in the firmware I have it set to 2 for a v2 with my ATX power supply and all that. Is there a way to see the output from the accelerometer to see if it getting a signal back to the rambo? Thank you in advance.

[Mac The Knife]

I was under the impression that if you put the new hotend on a V@, and wanted to do autocalibration, that you had to select V3 in the updated firmware, and reverse the direction of the Y steppermotor.

[GadgetTech]

Really? I followed the guide for installing the HE280 and it specified that I needed to just select v2... I don't suppose you have the reference for that? Maybe I followed the wrong guide.

[bruceg]

Here are the mods i made to Repetier 0.92.2 (2016 12 27) - configuration.h for my v2 HE280 upgrade (molded carriages, SeeMeCNC ballcup arms).

Code: Select all

10   #define PRINTER 2 // used v2 as starting point as v3 contains extra line defining a pin for the fan board
19   #define POWER_SUPPLY 1 // old school ATX supply
59   #define MIN_DEFECT_TEMPERATURE 15  // chilly basement

192  #define MAXTEMP 290 // increase from 245 to match v3 setting
194  #define INVERT_Y_DIR 0 // required if POWER_SUPPLY 1
196  #define DELTA_DIAGONAL_ROD 291.06  // ball cup arms
199  #define Z_MAX_LENGTH 350 // starting point for calibration note that v3 distance of 395 will be problematic
201  #define CARRIAGE_HORIZONTAL_OFFSET 26.5  // molded cheapskates
227  #define Z_PROBE_SPEED 60 // note that v3 speed is 90 -  not sure of significance

When you first connect to your printer, do you get a listing in the terminal something like this? (presumably indicating good communication with accelerometer).

Code: Select all

->Communication State: AttemptingToConnect

->M105
<-start
->Communication State: Connected
->M115
<-Info:Autoleveling enabled
<-Transformation matrix: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000
<-Free RAM:830
<-Autoretract:0
<-X:0.00 Y:0.00 Z:0.000 E:0.0000
<-SpeedMultiply:100
<-iis2dh accelerometer initializing...
<-read reg 15 value: 51
<-read reg 49 value: 21
<-read reg 32 value: 156
<- etc.....

What is the material of your print surface?

What are you using for a calibration script?, are you following the SeeMeCNC Wizard?

Are BOTH the Bed and HotEnd Off during calibration?

[GadgetTech]

Hello and thank you.
I actually followed your settings from another post. so they should be the same

Code: Select all

define MOTOR_CURRENT {140,140,140,130,0}
#define EXT0_PID_INTEGRAL_DRIVE_MAX 180
#define EXT0_PID_INTEGRAL_DRIVE_MIN 80
#define EXT0_PID_PGAIN_OR_DEAD_TIME 14.50
#define EXT0_PID_I 0.73
#define EXT0_PID_D 53.41
#define EXT0_PID_MAX 235
#define HAVE_HEATED_BED 1
#define MIN_EXTRUDER_TEMP 150  //  this is the minimum temperature that will allow the extruder to drive filament, lower and it will ignore extruder commands
#define MAXTEMP 290            //  this is the max allowable temp the hotend can be set at, any higher will trigger safety's
#define UI_SET_MAX_EXTRUDER_TEMP   290
#define INVERT_X_DIR 1
#define INVERT_Y_DIR 0
#define INVERT_Z_DIR 1
#define DELTA_DIAGONAL_ROD 291.06  // ball cup arms
#define DELTA_MAX_RADIUS 145.0
#define PRINTER_RADIUS 200.0
#define Z_MAX_LENGTH 350
#define END_EFFECTOR_HORIZONTAL_OFFSET 30.22
#define CARRIAGE_HORIZONTAL_OFFSET 26.5  // molded cheapskates
#define DELTASEGMENTS_PER_PRINTLINE 22
#define STEPPER_INACTIVE_TIME 600L
#define MAX_INACTIVE_TIME 900L
#define MAX_FEEDRATE_X 250
#define MAX_FEEDRATE_Y 250
#define MAX_FEEDRATE_Z 250

For the console output I get something similar

Yes both the heaters are off and yes I am using the script and guide. Something I did notice when I was just having the Z travel down using the control panel it hit zero way before the bottom of the build plate, which is just the glass one, and it stated it did start at 350 so maybe steps per mm is off or something?

[GadgetTech]

[youtube]https://www.youtube.com/watch?v=7DyJN0CELXo[/youtube]
That's what it does when I issue a G69 S2 like in the first part of the script

[bruceg]

Does it recover from that point and continue, or just try to keep going?

Can you export your EEPROM settings to a file and attach them?

Have you measured (or know) your arm length precisely?

Can you see exactly where the nozzle is striking the bed - to the inside or outside of the white line?

[GadgetTech]

It just sits there and tries to go lower, eventually it tries to go to another position but I'm afraid to let it keep going and break something. Yes, it is the 291 that is in the eprom that I have attached. It's inside the line, I attached a youtube link as well above. Thank you for your help.

[crocky]

This is ALL I changed in mine...

Select printer type as 2

Define the MOTHERBOARD 301

Define the POWER_SUPPLY 1

PRINTER == 2

Define INVERT_Y_DIR 0

Define Z_MAX_LENGTH 350

Define MAXTEMP 290

Define Z_PROBE_SPEED 90 <---------- Important

[GadgetTech]

to the inside or outside of the white line?

I stand corrected, after changing the z probe speed and confirming the arm length because it was off a bit it is hitting outside the white line, not inside. Sadly those two changes did not help.

[bruceg]

Nothing jumps out (to me) from the EEROM settings. It is interesting that crocky is using 90 for Z probe speed on a v2 as tuning speed is mentioned in some other threads re triggering the accelerometer and as a component in the quest for better calibration results.

Have you been through the machine to ensure there are no sources of mechanical and alignment problems - belts evenly tensioned, bed not loose, play in u-joints (not sure if u-joints vs ball cups is significant), end stop switches tight, manual alignment to minimize tower end stop offset, towers aligned etc?

How far outside of the white line? - does the effector tilt over or stay flat?

Maybe attach an export of your terminal session.

[bruceg]

Provided no mechanical problems, you might consider lengthening your Diagonal Rod Length a little. After the alignment dust had settles, mine (ball cup - see below) come in at ~294.8/9

If my understanding is correct, a shorter rod setting will cause a greater amount of carriage travel to get to a particular target location for a given physical geometry and hence more radial excursion of the nozzle. It may be that the probe point is too close to the x-tower and the resulting nearly vertical x and more horizontal y & z-arm angles are impairing the trigger response from the accelerometer.

Also, I vaguely recall reading something about the molded carriage adapter for u-joints being such that the geometry would be the same as for ball cups but you might be well advised to clarify that. At the effector end, a quick visual comparison of the ball cup vs u-joint effectors would seem to suggest that the pivot centre of the u-joint as about 2-3mm outboard (closer to the towers) than the centre of the balls...

Nozzle is completely clean, no plastic poking out?

8-pin connector is snug, not being displaced by the Bowden tube over at the x-tower?

Acclerometer board is sitting completely level on its mount pillars?

[GadgetTech]

Nothing jumps out (to me) from the EEROM settings. It is interesting that crocky is using 90 for Z probe speed on a v2 as tuning speed is mentioned in some other threads re triggering the accelerometer and as a component in the quest for better calibration results.

Have you been through the machine to ensure there are no sources of mechanical and alignment problems - belts evenly tensioned, bed not loose, play in u-joints (not sure if u-joints vs ball cups is significant), end stop switches tight, manual alignment to minimize tower end stop offset, towers aligned etc?

How far outside of the white line? - does the effector tilt over or stay flat?

Maybe attach an export of your terminal session.

Yes, I have gone through top to bottom and everything is within spec, it was printing just fine before the... upgrade but I rechecked it all anyway. This is what I get when I run the first command. The platform stays level, until it hits the bed and tries to keep going. I've just experimented and changed the rod length dramatically. While that does bring it inside the line, it still hits the bed and doesn't stop. I've highlighted where I hit the estop

[GadgetTech]

Provided no mechanical problems, you might consider lengthening your Diagonal Rod Length a little. After the alignment dust had settles, mine (ball cup - see below) come in at ~294.8/9

If my understanding is correct, a shorter rod setting will cause a greater amount of carriage travel to get to a particular target location for a given physical geometry and hence more radial excursion of the nozzle. It may be that the probe point is too close to the x-tower and the resulting nearly vertical x and more horizontal y & z-arm angles are impairing the trigger response from the accelerometer.

Also, I vaguely recall reading something about the molded carriage adapter for u-joints being such that the geometry would be the same as for ball cups but you might be well advised to clarify that. At the effector end, a quick visual comparison of the ball cup vs u-joint effectors would seem to suggest that the pivot centre of the u-joint as about 2-3mm outboard (closer to the towers) than the centre of the balls...

Nozzle is completely clean, no plastic poking out?

8-pin connector is snug, not being displaced by the Bowden tube over at the x-tower?

Acclerometer board is sitting completely level on its mount pillars?

I had it quite a bit longer then it should have been because of a conversion error on my part to no effect, exact same behavior. I've never even turned this hotend on so no, no plastic. No bowden tube either as I cut it too short so I just haven't installed it yet, 8 pin is very snug and I have allowed all the slack I can. Acclerometer is completely level too. Thank you for your help BTW.

[Dale Eason]

What is happening is that the machine is going down to about 20 mm above the bed and then it will try to find the bed by a probe. That probe is when yours is crashing because it never detects the bed and so just continues trying to push the head lower. Mechanically it can not go lower and so as the other two arms go down that pushes it over and out toward the side. The ratcheting sound you hear is the belt slipping on the X stepper.

I think your accelerometer may not be working. There is a command to check it. M261. It will print out a bunch of reg values. Reg 49 is the important one for this. After reset it should be 21 or very close to that. Then thump/flick the hot end with you finger. That number should change when next you send M261. When I push the hot end down onto the surface with my hand to make it click a little I get 101 as the value. The next M261 will reset it and it should go back to 21.

I had similar response to your bed crash video when my initial eeprom settings where wrong or left over from the previous V2 build. After clearing them it worked the next time. So eeprom settings could be the problem but I don't see anything out of range. So maybe it is a problem with the Z probe.

I ended up using the V3 config and changing the max Z height, y-dir like an earlier poster did. That seemed to work better than using V2 as a starting point.

Dale

[GadgetTech]

What is happening is that the machine is going down to about 20 mm above the bed and then it will try to find the bed by a probe. That probe is when yours is crashing because it never detects the bed and so just continues trying to push the head lower. Mechanically it can not go lower and so as the other two arms go down that pushes it over and out toward the side. The ratcheting sound you hear is the belt slipping on the X stepper.

I think your accelerometer may not be working. There is a command to check it. M261. It will print out a bunch of reg values. Reg 49 is the important one for this. After reset it should be 21 or very close to that. Then thump/flick the hot end with you finger. That number should change when next you send M261. When I push the hot end down onto the surface with my hand to make it click a little I get 101 as the value. The next M261 will reset it and it should go back to 21.

I had similar response to your bed crash video when my initial eeprom settings where wrong or left over from the previous V2 build. After clearing them it worked the next time. So eeprom settings could be the problem but I don't see anything out of range. So maybe it is a problem with the Z probe.

I ended up using the V3 config and changing the max Z height, y-dir like an earlier poster did. That seemed to work better than using V2 as a starting point.

Dale

Thank you for your insight. I was able to check the sensor and it responded just like you described. I will try the V3 and report back.

[GadgetTech]

Changed to the v3 with the changes indicated earlier, attempted a calibration and the exact same thing happened. I've attached the output.

[geneb]

The ONLY command you should be sending for calibration is G29. The calibration script is deprecated and has been removed from the docs.

g.

[bruceg]

Did you clear your EEPROM before uploading the different Repetier configuration?

For what it is worth, at least in 0.92.2 21061227, a search for the variable PRINTER does not yield any differences (aside from some printer identification messages) for PRINTER == 2 vs PRINTER == 5 outside of configuration.h Within configuration.h, the differences to my eye are:

PRINTER == 2 - vs - PRINTER == 5

no statement - vs - #define FAN_BOARD_PIN 6 // ERIS Case Fan pin
#define MAXTEMP 245 - vs - #define MAXTEMP 290
#define Z_MAX_LENGTH 350 - vs - #define Z_MAX_LENGTH 395
#define Z_PROBE_SPEED 60 - vs - #define Z_PROBE_SPEED 90
#define UI_PRINTER_NAME "RostockMAXv2" - vs - #define UI_PRINTER_NAME "RostockMAXv3"

There may well be differences beyond my ken (which does not reach very far) and those illuminated by a simple variable search in the firmware.

A couple of other observations,

In the EEPROM settings you posted, you have Autolevel active (1/0)|0 as compared to Autolevel active (1/0)|1 in my EEPROM (unfortunately i did not save my EEPROM settings after the initial upload of 0.92.2 for comparison). My first thought is that this is a consequence of the G29 command not successfully running through to completion on your machine and unlikely related to your problem.... You will have noticed that Autolevel active gets turned on and off by various g-codes.

The motor current settings (#define MOTOR_CURRENT {140,140,140,130,0}) in 0.92.2 20161227 are lower than those recommended in the v2 Assembly Guide 2nd Edition which were #define MOTOR_CURRENT {175,175,175,200,0} for "stock motors" and #define MOTOR_CURRENT {155,155,155,165,0} for Kysan or Automation technology motors. To my understanding, this should mainly only affect the torque sustainable before stall and amount heat generated and not the speed of the motor which should mainly just depend on voltage. So one would think that motor current should not affect the presumably primarily speed dependent response of the accelerometer. However, there is more complexity to the motor behavior and certainly the accelerometer response/processing than that. On the other hand, my n=1 experience with my v2 is that there is reliable accelerometer triggering with Kysan motors @ the 140 current settings on both glass and ~2mm thick PEI.

It would seem as Dale pointed out, that the accelerometer is simply not triggering.

Am i correct in understanding that the effector stays level after the nozzle contacts the bed?

[GadgetTech]

Did you clear your EEPROM before uploading the different Repetier configuration?

For what it is worth, at least in 0.92.2 21061227, a search for the variable PRINTER does not yield any differences (aside from some printer identification messages) for PRINTER == 2 vs PRINTER == 5 outside of configuration.h Within configuration.h, the differences to my eye are:

PRINTER == 2 - vs - PRINTER == 5

no statement - vs - #define FAN_BOARD_PIN 6 // ERIS Case Fan pin
#define MAXTEMP 245 - vs - #define MAXTEMP 290
#define Z_MAX_LENGTH 350 - vs - #define Z_MAX_LENGTH 395
#define Z_PROBE_SPEED 60 - vs - #define Z_PROBE_SPEED 90
#define UI_PRINTER_NAME "RostockMAXv2" - vs - #define UI_PRINTER_NAME "RostockMAXv3"

There may well be differences beyond my ken (which does not reach very far) and those illuminated by a simple variable search in the firmware.

A couple of other observations,

In the EEPROM settings you posted, you have Autolevel active (1/0)|0 as compared to Autolevel active (1/0)|1 in my EEPROM (unfortunately i did not save my EEPROM settings after the initial upload of 0.92.2 for comparison). My first thought is that this is a consequence of the G29 command not successfully running through to completion on your machine and unlikely related to your problem.... You will have noticed that Autolevel active gets turned on and off by various g-codes.

The motor current settings (#define MOTOR_CURRENT {140,140,140,130,0}) in 0.92.2 20161227 are lower than those recommended in the v2 Assembly Guide 2nd Edition which were #define MOTOR_CURRENT {175,175,175,200,0} for "stock motors" and #define MOTOR_CURRENT {155,155,155,165,0} for Kysan or Automation technology motors. To my understanding, this should mainly only affect the torque sustainable before stall and amount heat generated and not the speed of the motor which should mainly just depend on voltage. So one would think that motor current should not affect the presumably primarily speed dependent response of the accelerometer. However, there is more complexity to the motor behavior and certainly the accelerometer response/processing than that. On the other hand, my n=1 experience with my v2 is that there is reliable accelerometer triggering with Kysan motors @ the 140 current settings on both glass and ~2mm thick PEI.

It would seem as Dale pointed out, that the accelerometer is simply not triggering.

Am i correct in understanding that the effector stays level after the nozzle contacts the bed?

Here is what I get when sending the g29. The first auto-leveling enabled was me setting the value to 1 manually in the eeprom settings. It seams to turn off during the probe which I suppose makes sense. For the effector no, when it contacts the bed if just tried to keep going. And yes, I did clear it after every change.

[Dale Eason]

Maybe try a little experiment. Send it a g28 (home) and then G0 Z20 (move to x 0 y 0 Z 20mm) That should send the head to about 20 mm from the bed surface and in the center of the bed. If it is there then try G30. That should probe the bed twice at the center. If that works you can try various combinations of G0 Xsomething Ysomething Z20. Where something is replaced by values in mm. Then at each of those you can try a G30. A G30 all by iteself is a probe command from the current position. It will not change any values in the eeprom but you can use it to prove out the probe works.

Dale

[GadgetTech]

Maybe try a little experiment. Send it a g28 (home) and then G0 Z20 (move to x 0 y 0 Z 20mm) That should send the head to about 20 mm from the bed surface and in the center of the bed. If it is there then try G30. That should probe the bed twice at the center. If that works you can try various combinations of G0 Xsomething Ysomething Z20. Where something is replaced by values in mm. Then at each of those you can try a G30. A G30 all by iteself is a probe command from the current position. It will not change any values in the eeprom but you can use it to prove out the probe works.

Dale

Just tried it and no joy, also when I tell it to go 20mm above on the z it ends up at 60+. Sending the command just crashes it into the bed and it keeps trying to go down, but we have shown that the accel data is getting to the board and it registers movement so I am really lost.

[Dale Eason]

You said "Sending the command just crashes it into the bed" I assume you mean that happens on the G30 command.

I would first try to figure out why G0 Z20 does not send it to 20 mm above the bed. Without looking at your eeprom settings I would have guessed you have the steps per mm wrong or something is fishy with the end stop switches that the home command uses.

The process for the G0 Z20 command inside the machine is pretty simple. It just moves the steppers (max Z height - 20 mm ) * steps per mm down.

Dale

[GadgetTech]

You said "Sending the command just crashes it into the bed" I assume you mean that happens on the G30 command.

I would first try to figure out why G0 Z20 does not send it to 20 mm above the bed. Without looking at your eeprom settings I would have guessed you have the steps per mm wrong or something is fishy with the end stop switches that the home command uses.

The process for the G0 Z20 command inside the machine is pretty simple. It just moves the steppers (max Z height - 20 mm ) * steps per mm down.

Dale

Yes, sorry for not being specific. Nothing has changed with the end stops and it all worked fine before so I would guess steps per mm as well. I don't suppose anyone knows offhand what the standard steps per mm would be for the stock stepper motors that came with the v2 at first?

[GadgetTech]

I was able to tweak the steps until it went to 20, still doesn't help.