Strange behaviour while platform descending to printbed

[DeltaCon]

Hope someone recognizes this behaviour (can't seem to embed video here):
https://youtu.be/ZB8xwyCcOu8

I am trying to get the new repetier firmware 0.92.9 working and used the webtool. I had to change a lot in the Arduino IDE afterwards concerning PIN assigments en motor current, baudrates and more, so that was a real trial, error and google event. I am now in a state that homing goes normal and I can do Z calibration and moving the platform around without problems. But when I start a printjob from repetier, after the bed is almost warmed up (60 degrees Celcius) I notice a ticking sound. I believe it is coming from one of the steppers, and I can feel a little shake on the whole machine. Then when the bed temp reaches 60, the platform goes to Z 10, and that happens like the video shows. The platform moves bits towards the X tower in a few steps. Z 10 is not reached by far. This only seems to happen when the bed is warm.

My coniguration.h says:

Code: Select all

#define MICROSTEP_MODES { 16,16,16,16,16 } // [1,2,4,8,16]
#define MOTOR_CURRENT_PERCENT { 175,175,175,200,0 }

and I believe that to be correct since I have the Wantai steppers. All this occurs after reflashing, I come from the SeeMe supplied 0.91 firmware on which the machine worked fine.

Any Ideas?

[DeltaCon]

I thought to add the configuration.h here:

Code: Select all

[spoiler]#define NUM_EXTRUDER 1
#define MOTHERBOARD 301
#include "pins.h"

// ################## EDIT THESE SETTINGS MANUALLY ################
//  Microstepping mod eof your RAMO board
#define MICROSTEP_MODES { 16,16,16,16,16 } // [1,2,4,8,16]
// Motor Current setting (Only functional when motor driver current ref pins are connected to a digital trimpot on supported boards)
#define MOTOR_CURRENT_PERCENT { 175,175,175,200,0 }

// ################ END MANUAL SETTINGS ##########################

#undef FAN_PIN
#define FAN_PIN ORIG_FAN2_PIN
#undef FAN2_PIN
    #define FAN2_PIN ORIG_FAN_PIN
#undef FAN_BOARD_PIN
#define FAN_BOARD_PIN -1
#define BOARD_FAN_SPEED 255
#define FAN_THERMO_PIN -1
#define FAN_THERMO_MIN_PWM 128
#define FAN_THERMO_MAX_PWM 255
#define FAN_THERMO_MIN_TEMP 45
#define FAN_THERMO_MAX_TEMP 60
#define FAN_THERMO_THERMISTOR_PIN -1
#define FAN_THERMO_THERMISTOR_TYPE 1

//#define EXTERNALSERIAL  use Arduino serial library instead of build in. Requires more ram, has only 63 byte input buffer.
// Uncomment the following line if you are using Arduino compatible firmware made for Arduino version earlier then 1.0
// If it is incompatible you will get compiler errors about write functions not being compatible!
//#define COMPAT_PRE1
#define BLUETOOTH_SERIAL  -1
#define BLUETOOTH_BAUD  250000
#define MIXING_EXTRUDER 0

#define DRIVE_SYSTEM 3
#define XAXIS_STEPS_PER_MM 80
#define YAXIS_STEPS_PER_MM 80
#define ZAXIS_STEPS_PER_MM 80
#define EXTRUDER_FAN_COOL_TEMP 50
#define PDM_FOR_EXTRUDER 0
#define PDM_FOR_COOLER 0
#define DECOUPLING_TEST_MAX_HOLD_VARIANCE 20
#define DECOUPLING_TEST_MIN_TEMP_RISE 1
#define KILL_IF_SENSOR_DEFECT 0
#define RETRACT_ON_PAUSE 2
#define PAUSE_START_COMMANDS ""
#define PAUSE_END_COMMANDS ""
#define SHARED_EXTRUDER_HEATER 0
#define EXT0_X_OFFSET 0
#define EXT0_Y_OFFSET 0
#define EXT0_Z_OFFSET 0
#define EXT0_STEPS_PER_MM 90.542
#define EXT0_TEMPSENSOR_TYPE 97
#define EXT0_TEMPSENSOR_PIN TEMP_0_PIN
#define EXT0_HEATER_PIN HEATER_0_PIN
#define EXT0_STEP_PIN ORIG_E0_STEP_PIN
#define EXT0_DIR_PIN ORIG_E0_DIR_PIN
#define EXT0_INVERSE 1
#define EXT0_ENABLE_PIN ORIG_E0_ENABLE_PIN
#define EXT0_ENABLE_ON 0
#define EXT0_MIRROR_STEPPER 0
#define EXT0_STEP2_PIN ORIG_E0_STEP_PIN
#define EXT0_DIR2_PIN ORIG_E0_DIR_PIN
#define EXT0_INVERSE2 0
#define EXT0_ENABLE2_PIN ORIG_E0_ENABLE_PIN
#define EXT0_MAX_FEEDRATE 100
#define EXT0_MAX_START_FEEDRATE 45
#define EXT0_MAX_ACCELERATION 6500
#define EXT0_HEAT_MANAGER 1
#define EXT0_WATCHPERIOD 3
#define EXT0_PID_INTEGRAL_DRIVE_MAX 230
#define EXT0_PID_INTEGRAL_DRIVE_MIN 40
#define EXT0_PID_PGAIN_OR_DEAD_TIME 7
#define EXT0_PID_I 2
#define EXT0_PID_D 40
#define EXT0_PID_MAX 255
#define EXT0_ADVANCE_K 0
#define EXT0_ADVANCE_L 0
#define EXT0_ADVANCE_BACKLASH_STEPS 0
#define EXT0_WAIT_RETRACT_TEMP 20
#define EXT0_WAIT_RETRACT_UNITS 0
#define EXT0_SELECT_COMMANDS ""
#define EXT0_DESELECT_COMMANDS ""
#define EXT0_EXTRUDER_COOLER_PIN 7
#define EXT0_EXTRUDER_COOLER_SPEED 255
#define EXT0_DECOUPLE_TEST_PERIOD 12000
#define EXT0_JAM_PIN -1
#define EXT0_JAM_PULLUP 0

#define FEATURE_RETRACTION 1
#define AUTORETRACT_ENABLED 0
#define RETRACTION_LENGTH 3
#define RETRACTION_LONG_LENGTH 13
#define RETRACTION_SPEED 40
#define RETRACTION_Z_LIFT 1
#define RETRACTION_UNDO_EXTRA_LENGTH 0
#define RETRACTION_UNDO_EXTRA_LONG_LENGTH 0
#define RETRACTION_UNDO_SPEED 20
#define FILAMENTCHANGE_X_POS 0
#define FILAMENTCHANGE_Y_POS 0
#define FILAMENTCHANGE_Z_ADD  2
#define FILAMENTCHANGE_REHOME 1
#define FILAMENTCHANGE_SHORTRETRACT 5
#define FILAMENTCHANGE_LONGRETRACT 50
#define JAM_STEPS 220
#define JAM_SLOWDOWN_STEPS 320
#define JAM_SLOWDOWN_TO 70
#define JAM_ERROR_STEPS 500
#define JAM_MIN_STEPS 10
#define JAM_ACTION 0

#define RETRACT_DURING_HEATUP true
#define PID_CONTROL_RANGE 20
#define SKIP_M109_IF_WITHIN 2
#define SCALE_PID_TO_MAX 0
#define TEMP_HYSTERESIS 5
#define EXTRUDE_MAXLENGTH 100
#define NUM_TEMPS_USERTHERMISTOR0 0
#define USER_THERMISTORTABLE0 {}
#define NUM_TEMPS_USERTHERMISTOR1 0
#define USER_THERMISTORTABLE1 {}
#define NUM_TEMPS_USERTHERMISTOR2 0
#define USER_THERMISTORTABLE2 {}
#define USE_GENERIC_THERMISTORTABLE_1
#define GENERIC_THERM1_T0 25
#define GENERIC_THERM1_R0 100000
#define GENERIC_THERM1_BETA 4036
#define GENERIC_THERM1_MIN_TEMP -20
#define GENERIC_THERM1_MAX_TEMP 300
#define GENERIC_THERM1_R1 0
#define GENERIC_THERM1_R2 4700
#define USE_GENERIC_THERMISTORTABLE_2
#define GENERIC_THERM2_T0 25
#define GENERIC_THERM2_R0 100000
#define GENERIC_THERM2_BETA 4036
#define GENERIC_THERM2_MIN_TEMP -20
#define GENERIC_THERM2_MAX_TEMP 300
#define GENERIC_THERM2_R1 0
#define GENERIC_THERM2_R2 4700
#define GENERIC_THERM_VREF 5
#define GENERIC_THERM_NUM_ENTRIES 33
#define HEATER_PWM_SPEED 0

// ############# Heated bed configuration ########################

#define HAVE_HEATED_BED 1
#define HEATED_BED_MAX_TEMP 120
#define SKIP_M190_IF_WITHIN 5
#define HEATED_BED_SENSOR_TYPE 98
#define HEATED_BED_SENSOR_PIN TEMP_1_PIN
#define HEATED_BED_HEATER_PIN HEATER_1_PIN
#define HEATED_BED_SET_INTERVAL 5000
#define HEATED_BED_HEAT_MANAGER 1
#define HEATED_BED_PID_INTEGRAL_DRIVE_MAX 255
#define HEATED_BED_PID_INTEGRAL_DRIVE_MIN 80
#define HEATED_BED_PID_PGAIN_OR_DEAD_TIME   196
#define HEATED_BED_PID_IGAIN   33
#define HEATED_BED_PID_DGAIN 290
#define HEATED_BED_PID_MAX 255
#define HEATED_BED_DECOUPLE_TEST_PERIOD 300000
#define MIN_EXTRUDER_TEMP 0
#define MAXTEMP 275
#define MIN_DEFECT_TEMPERATURE 0
#define MAX_DEFECT_TEMPERATURE 290[/spoiler]

[DeltaCon]

Only other thing that does not seem te work is the layerfan. Something is wrong with the pin assignment most likely, but I would like the first problem solved first. Please take a look at

https://youtu.be/ZB8xwyCcOu8

I hope someone recognizes this, I am out of ideas. It seems linked to the bed heating. If the bed goes over let's say 55 degrees C the X tower stepper starts ticking in a certain frequency of about one tick every 2 seconds. Exactly at this moments the X-skate freezes for a moment, causing the platform to move in the X tower direction while traveling down, and reverse while traveling up. Without any heating the movement functions completely normal and accurate. I have nothing changed to the machine or it's wiring, and had a completely normal functioning machine before flashing the new firmware. But the symptoms don't give me any clue as where to look for in the firmware settings.

[Eaglezsoar]

Are you sure your belts are tight on all 3 steppers?

[Nylocke]

Check your endstop wires, they might be entangled or crossing the bedhead wires and the PWM signal might be triggering the X one via EMI. In your config search for "Always check endstops" and disable that (set it to 0) and see if it works then. If it does then be careful when in Z+ direction, if you move too high your carriages will crash (since they only check endstops when homing)

[teoman]

Also check voltage of psu at rambo inputs.

[DeltaCon]

Thanks, Will check all suggestions. Can't think of it being an EMI problem, since the machine has functioned before and I did not do any rewiring. Although the the LCD has been off, and I plugged the FSR controller on the Z-min... I'll be back!

[DeltaCon]

Are you sure your belts are tight on all 3 steppers?

Belt tensioning has been a concern for me, but at least they are all equally loose or tight. The "skipping" of the skate is always more or less equal in height, and in my opinion far to big to be slipping on the motorpulley.

Check your endstop wires, they might be entangled or crossing the bedhead wires and the PWM signal might be triggering the X one via EMI

That was my first thought also, but that would not explain why in the previous firmware that has not been a problem. I tidied up the wiring a bit some weeks ago and it has been printing fine all that time. In the picture you can see clearly that the bed wires are going straight ahead and above behind the controller, and the endstop wires are taking al left turn to the bottom on the left side of the controller. So I guess EMI is out of the question.

[img]http://hennekens.info/rostock/Wiring.jpg[/img]

I would have measured the voltage as teoman suggested, but in my impatience I flashed the original 9.91 firmware, and guess what... The problem is entirely gone... I have been printing for half an hour as I type. So I am pretty convinced that it must be some strange firmware setting, but cannot image where to go look for. I know I had some problematic pin assignments. I thought the last one was the disfunctioning layerfan. I really don't understand what I am missing.

What's the best method of upgrading firmware. I used a json file I found on this forum (think it was Nylockes but am not sure). Can I make my own json file from my current setup, that I can import in the repetier web tool? Maybe that would leave me with less undefined errors...

[Nylocke]

The file I uploaded was from .92.2, the current version is .92.9. I could run through again and update everything that was broken. I'm also building my MAX up and its pretty much stock electronics so I can share my config from that. Probably won't be right away though, I'm 30 miles away from my printer right now.

Check the .91 config and the .92 config and search for "always check endstops" and compare the values. I'm guessing that the .91 has it disabled and the .92 has it enabled. I'm pretty sure that this is your problem because it matches the symptoms almost exactly.

[DeltaCon]

Yes, why didn't I think of checking that... However, the malfunction was also visible during homing, but not so on the .91 firmware. I guess with "always check endstops" turned off it would at least be visible during manual homing with the bed powered and in temp. That's not the case. Also the endstop and bedwires are not touching by at least 10cm. If I have EMI, anyone would... Unless it is EMI between other pairs... Is there anything in this printer that would generate short pulses with, about once every second? I'll check the endstops value when I get back from work.

[Nylocke]

I'm not sure. I'll try checking out my config for .92.9 tonight and I'll upload the config file if you want to try it out (if you have any mods from stock just open it in the firmware builder tool and change what you need to)

[DeltaCon]

Check the .91 config and the .92 config and search for "always check endstops" and compare the values. I'm guessing that the .91 has it disabled and the .92 has it enabled. I'm pretty sure that this is your problem because it matches the symptoms almost exactly.

I hate to prove you're wrong but I just checked that value in the 0.91 ino I uploaded yesterday and it says:

Code: Select all

#define ALWAYS_CHECK_ENDSTOPS true

So it is identical to the problematic 0.92.9 value. Will check for other differences, but we will be off for short vacation until Sunday.

[DeltaCon]

I thought I solved the problem, but I hate to admit I didn't...
But I can shed some new light on the issue. In the video you can see what happens. It is not that something is wrong in the motion itself. Instead I found out that the X stepper is intermittently disabled for a short moment. But it is only the X stepper, and not the others.

https://youtu.be/1smIyYXvV0Q
(why can't I embed youtube video?!)

I am making an educated guess when I tell you the frequency at which the power loss occurs is in line with the blinking of a LED on the Rambo when I am trying to connect Repetier top the printer with the printer turned off. I am thinking about some sort of keep-alive signal during a normal connection, that makes the X stepper do this.

Does anyone have some ideas about this? The is a real PITA for me and keeping me from doing fun stuff...

I need to add that this behaviour is exclusive to my 0.92.9 firmware. The Seeme fw works flawless.

[Nylocke]

You shouldn't have to change anything in the IDE to get the firmware to work if you build the firmware correctly. I uploaded my config for my (mostly) stock printer. It may or may not be fully configured correctly (mainly PID values, delta calibration values, and possibly steps per mm for XYZ and E axes), but I know for sure the motors move correctly and the endstops trigger properly. Try uploading it straight without changing any pins.

RAMBo.zip

(454.58 KiB) Downloaded 199 times

It should work motors wise. One thing off the bat that is for sure different is the fan wiring. I have mine configured to use FAN-0 and FAN-1 instead of FAN-0 and EXT-1 ports which is stock for some reason.

[DeltaCon]

Thanks Nylocke! I uploaded your FW with only minor changes to the motor directions. However the problem persists. I should add that during the first minutes after power on there seems to be no problem. After a minute or 5 the problem introduces itself, and the X stepper starts "ticking" (disabling) for fractions of a second each 2 seconds or so, in which time I can manually move the X skate (see video in my previous message), or a motorized movement will stand still which causes the platform to move to or away from the X tower (see video in OP). Previously in this thread EMI was suggested, but since the old firmware does not show this behavior I can't swallow that. Besides I am not doing anything: no heating, no fans, no movement, what could possibly cause EMI in this exact occurrence? If I turn the power off and back on again, it will take another 5 minutes or so for the problem to return.

[CodonExe]

Did you try lowering your motor current percent? I would try 150

[Nylocke]

It sounds like the stepper drivers may be overheating. Try touching one of them when the RAMBo is on for too long. Is the fan that is supposed to be on them running properly?

[DeltaCon]

The stepper drivers are the chips located above the stepper connectors (within the thick yellow rectangle box) are they not? I have never seen pictures of a rambo board with fans on them. Or do you mean the little board cooler on the back of the board instead? Am at work now, will look at it tonight. But I guess you have a point, because it always happens when the steppers have been idle for a few minutes. Disabling them stops the effect, and after enabling again it takes a few minutes for them to start failing again. On the other hand that doesn't explain why I do not have any problem running the 0.91s firmware, even at a bit higher stepper current.

[img]http://hennekens.info/rostock/RamboSteppersDrivers.png[/img]

[Nylocke]

I'm not sure either, but it may be because the steppers are run at a higher frequency on the newer version, putting more stress on the drivers. But what you're experiencing sounds really similar to the overheating driver problem.

[DeltaCon]

I have been trying to touch these little squares, but they are damn hot! I can't lay my finger on it for more than a fraction of a second without getting burned! Is that normal? I have the Wantai Steppers in my machine. In my previous firmware I had the current setting as

Code: Select all

#define MOTOR_CURRENT {175,175,175,200,0}

(which I believe is the advised setting) while in the current(!) firmware i have them at

Code: Select all

#define MOTOR_CURRENT_PERCENT { 165,165,165,135,0 }

I just now see the difference in syntax... Which one is correct? Starting to think the syntax is wrong and the _percent part should drop off, but if that is so google and this forum would have undoubtedly already documented this error, because it is coming out of the repetier firmwaretool like this...

I think we nailed the issue however, because I took the rambo out of the base and fiddle with it in order to check the fan on the back. That fan is turning so that's okay, but in the period of about an hour I did not see the ticking problem as before. Looks like by getting the rambo out of the base it receives just enough cooling to prevent that from happening.

Can anyone say something about the syntax?

[DeltaCon]

Did some googling again on the above found syntax foor motor current and came up with this from the repetier forum:
(https://forum.repetier.com/discussion/1 ... r-behavior)

Bishop November 2015 Posts: 3
Okay...so I finally got this figured out.

Even though my printer was working with version 0.91, I went ahead and swapped out the power supply to rule this out as the cause. New power supply did not have any effect, so I started looking more into the code. What I found was version 0.91 did not actually use current percentages like the const MOTOR_CURRENT_PERCENT would have you believe.

RAMBo boards use digipots (digital potentiometers) to control the current and have a range from 0-255 (0 being the off and 255 being the max; which is 2.0A for my version).

Version 0.92 implemented a method (void setMotorCurrentPercent( uint8_t channel, float level)) to use MOTOR_CURRENT_PERCENT and actually treats it as a percentage. setMotorCurrentPercent calculated the percentage of max current ( level * 255 / 100 ) before setting the actual current level. So my problem was trying to set the percentage too high (based on the settings from version 0.91) which was causing the stepper motor controllers to overheat.

Given this finding, it was easy to calculate the actual percentage and adjust the Configuration.h file accordingly.

Code: Select all

#if USE_LOW_CURRENT // Kysan steppers require a lower current than the Wantai steppers
#define MOTOR_CURRENT_PERCENT { 55, 55, 55, 63, 0 } // 140 / 255 = 55% and 160 / 255  = 63%
#else
#define MOTOR_CURRENT_PERCENT { 68, 68, 68, 78, 0 } // 175 / 255 = 68% and 200 / 255 = 78%
#endif

I have been printing with these settings for two days and everything is working well.

Not sure if this will help anyone else, but I wanted to share just in case.

-Bishop

I will check back later for confirmation, but it looks like the cause of my problem!

[Nylocke]

Sounds right.

[DeltaCon]

About 2 hours later, with a lot of movement on the steppers I can tell that this problem looks solved! So glad, because this has taken about 2 weeks of trail and error for me. Thanks Nylocke for making me look in the right direction! The stepper drivers are now not half as hot as before. I was making them go flat out... Guess I am lucky the board did not fry.

So... on to the layer-fan issue. It doesn't work. I am trying to wrap my head around the pin assignments and how that should look in pins.h and configuration.h. I'll make a new topic for that if needed.

[Nylocke]

Are you using my firmware config? Just move the layer fan wires over to Fan-1 instead of EXT-1. For some reason the default SMC repetier uses EXT-1 for the layer fan.

[DeltaCon]

That's correct. The Assembly manual let's you connect the layer fan to heat-1. I really don't see why. But I like to keep that as standard as possible so I changed the pin number in the firmware. I am still using your firmware indeed, and changed the probing settings because I installed fsr's. It is probing now and now I'll have to master OpenDact, which looks to be an adventure too.