0.92.2 Powers off unexpectedly

AndyB

So, I am running a Rostock Max V2 and on versions 0.92 and 0.92.2, after heating the hot end, as the temperature passes over the set temperature, and starts dropping as it starts to converge on the set temperature, the entire board shuts off. I have to turn off the power to get the board to re-initialize. Once I saw a decoupled in the hot end display (dec), but normally I don't. I've turned on debugging, to see if I can find out why the board is powering down. On 0.91, I've put 6 days of printing without a hitch, so I know it is either a setting that I entered in the 0.92.2 config, or a bug.

I'm using a 40W cartridge heater, and a M3 screw in thermistor, but otherwise it's a stock V2. I'm using the type 3 heater control manager (as opposed to bang-bang or PID), and the lag is about 12.5 seconds. What should I be doing to isolate this problem? What routine is likely shutting down all of the power to the board? Is there some debugging I can use to either write to the SD card, or to MatterControl console?

Thanks,

Andy

AndyB

Wondering if this is a symptom of too low of a value for decouple test period, which seems to be set at 12...

AndyB

Upped the value to 120 seconds for decouple test period. Didn't make a difference. I hear some high frequency noises, like two moves of the servos, without seeing any motion, just prior to the shutdown. The shutdown happens sooner if the bed heater is enabled.

Repetier

In Extruder.cpp line 132 change

bool decoupleTestRequired = (time - act->lastDecoupleTest) > act->decoupleTestPeriod;

bool decoupleTestRequired = false;

to disable decoupling test. Just in case it is decoupling that causes this. Latest release allows shutdown on decouple but that must be explicitly set.

AndyB

Made the change and uploaded the new version. It's still happening, all I do is connect and send pre-heats. After the extruder reaches the set temperature, and the bed is approaching the pre-heat, it happens. Attached is the log file, and EEPROM settings.

Thanks for the help.

AndyB

Modified the Printer::kill function to call UI_STATUS_UPD(UI_TEXT_KILLED); followed by HAL::delayMilliseconds(5000); and watched the screen to see if the kill function was being called. I don't see that happening. Not sure what other functions could kill all the power to the board. Is pin 4 on a RAMBO connected to power input on this board? The pins.h suggests to me that this might be the case, but the schematic doesn't appear to have that type of control.

AndyB

I noticed that the WDT routine in HAL.h was changed for ATMega 2560 boards from version 0.91 to the latest version. Why was that, and would the watchdog triggering have the effect that I'm seeing?

Repetier

Changes were compatibility problems. Use M281 to see if watchdog is working (should reset printer). If so try comping without watchdog to see if that is the reason.

Your log does not show a restart. It also shows it is still heating the extruder, also it contains only a few seconds after reaching temperature.

Does it also happen if you preheat over host to same temperatures? Do you have a ATX power unit that gets switched off and rambo gets still power from your PC/5V standby? I have seen this happen for some PWM output values which caused the ATX pin to somehow toggle. Try setting PID drive max, MAX PWM to 255 which reduces PWM signals and helped.

AndyB

Ok, testing M281 caused the printer to reset. I compiled the code with FEATURE_WATCHDOG 0, and it still dies after reaching temperature.

Yes, the log does not show a restart. Right, after reaching temperature on the hot end, it dies within a few seconds. Nothing else shows up in the log except M105s from the host software. If I use the Preheat PLA on the printer, it also happens, so it doesn't seem to matter which way I tell it to preheat.

My ATX supply (EVGA 650W) does have the capability to provide standby 5V, but the RAMBO is not wired into that leg. Are you suggesting to change that from the current (no pun) wiring to allow the RAMBO to stay powered on?

I set the EXT0_PID_MAX, HEATED_BED_PID_INTEGRAL_DRIVE_MAX, EXT0_PID_INTEGRAL all to 255. Doesn't help. I re-ran the testing with just the extruder, and it won't shut off. I then re-ran the test with only the bed. Once the bed nears the set temperature and is no longer driving at 100%, and switches to 83%, the board dies.

AndyB

I switched the BED to bang bang mode and it no longer resets. So, does this imply some type of PWM noise that is causing my power supply to trip a safety? I'm still confused as to why it works on 0.91 just fine.

AndyB

What is HEATER_PWM_SPEED designed to do? I'm guessing that the impulse spikes for a fast PWM are probably triggering over current protection on the power supply.

AndyB

Switched to HEATER_PWM_SPEED 3, and the issue seems resolved.

Repetier

Maybe you have PDM instead of PWM selected on 0.92? PDM gives different pulse times just as HEATER_PWM_SPEED does. Not really sure why this has a influence on the power pin or if it is a PU it self doing this as a result to a special load pattern. All I know it is a electrical reason which is triggered at some spacial frequencies. Avoiding these helps as you see.

AndyB

I think I was using PDM. After making this change, I printed a 35 hour print with no issues.

Jrjones

I am having similar issues with my Rostock Max V2 after upgrading to 0.92.3, as soon as I try to turn on the heated bed (in any mode, PID, dead-time, bang-bang), the ATX power supply shutsdown.

I've tried changing HEATER_PWM_SPEED from 1 through 4 with no changes in being able to turn on the heated bed.

With V0.91 I had no issues with shutting down at all.

Do you have any more suggestions on what I can try? How do I make sure I have PWM selected instead of PDM?

Repetier

Have

#define PDM_FOR_EXTRUDER 0

Also try for the bed

#define HEATED_BED_PID_MAX 255

and use ping pong. In the cases where bed power disabled atx power it was always a special

frequency triggering it and this has the lowest possible frequency and bang bang for bed does not hurt.

Jrjones

Thanks, setting#define PDM_FOR_EXTRUDER to 0 did the trick.

ahhams

I was struggling with same issue as described above for a long time until I came across this chain. Setting PDM_FOR_EXTRUDER 0 did the trick. For about about two days...

It now reappeared and can't seem to get rid of it.

ATX power supply just switches off. Nothing in the log, firmware appears to be running fine: I only have to do M81 and M80 (doing just M80 does not work - I guess the firmware thinks it is still in the on-state). Then it just turns off again (can be after seconds, but also after 2 minutes).

It only happens when also the heated bed is turned on. I also noted something else: when the heated bed is turned on, the temperature of the extruder is much less stable - it moves around quite a bit. Without heated bed turned on, the temperature stays on target almost perfectly.

Heated bed and extruder are fed by separate circuits from ATX power supply, which should have more than enough power. I've also recently moved from Marlin which I have been using without problems (well... without this one I mean).

Any further suggestions (not already made above)?

sherif

I did the same a couple of days ago, I updated my Rostock MAX V2 to repetier 0.92 from 0.91 (I need the bed bump map feature), I made sure to plug in the exact same printer settings. I powered on the printer, at the beginning it was fine but then I realized that the stepper motors are making a lot of noise than usual, that typically means that they are operating at a high current. I started hearing some noise beats then suddenly the power supply went down (F2 fuse blew on the RAMBo board, the 12V to 5V buck regulator died and I had to desolder it).

I overlooked that the variable that controls motor current in 0.91 is MOTOR_CURRENT which should take values that range from 0 to 255 (I had 180 setting to 1A current). In 0.92 the variable changed to MOTOR_CURRENT_PERCENT which should normally take from 0 to 100 and I was overdriving to 180%, I had to measure VREF nodes and they were set to 1.7V instead of 1V (that's 70% increase in current). Then I had to dial down the MOTOR_CURRENT_PERCENT values significantly to get to the same 1V level in 0.91