Radds 1.6 or due not initializing/booting correctly on 1.0.2

ZibbeZabbe

Hi, first of all apologies if this is the wrong category.

Quick rundown of my hardware.
Wanhao i3 plus base printer
Radds 1.6 from youprintin3d.de
Radds 4x20 display
TMC2130 steppers from watterott
Arduino Due (Currently clones from Amazon.co.uk)

Quick history
I burned my first two (genuine) arduinos because my printer had a PCB on the hotend sent 24v into ground of hotend thermistor. (burned ADC and shorted some analog pins to gnd and 3.3v)
Then i skipped trying to keep the default cable and hot end PCB setup and went for RC silicone wires and ethernet cable for fans ziptied together. Expensive lesson as I spent about 50euro on each of them.

I have soldered SPI for the TMC2130 on the underside and it worked for some test prints.

Now. The problem.

Short story, I boot printer and display shows this 90% of the time.

Long story.
I've had the problem that the firmware wont boot or the UI wont boot properly 90% of the time see image above. My highest successrate of booting is just running the arduino via USB. then it boots 60% of the time. Previously it never booted first try and would always boot when reset. Now reset does not help.
This affects both my arduinos, happens on basically stock firmware aswell.

So I am currently alternating between two different firmwares (both 1.0.2), one I call "stock" and one I have my settings and such in.

Config.h "Stock"
Config.h "WIP"

Full download
I included the full download because I also did some changes in pinter.cpp as two z stepper drivers thing was a bit broken, something something z2_stepper instead of ext1_stepper.

Honestly "WIP" is still very much a work in progress, I think I've disabled a few things while troubleshooting and honestly this is now my last resort as I don't want to bother people with my uneducated questions. I should have researched more before opting to upgrade my printers motherboard instead of just replacing the one that broke.

Edit: forgot the usual apologies for any misspellings and such, I am not a native speaker but I still should be able to do better than this. I'm also tired from a lot of troubleshooting.

Repetier

At least I know the not boot on first power up from some arduino due clones. That is caused by a wrongly dimensioned capacitor if I remember right. It causes the processor to start too early and it then crashes. As a test use the normal blink script from arduino. For me it did not work on startup but after a reset. As a test if that is your problem you should also run the blink script with a output that has a led. 13 is default whcih is a led on the arduino board it self.

ZibbeZabbe

Okay. So today i finally got my genuine DUE in the mail. I still have the same problem. it does not start first time and pushing reset does nothing. :/

Repetier

Please test the blink sketch first. Then firmware with no TMC enabled. In that case it might block if eeprom is not responding. That will cause a lock forever. If that then works you might test with TMC special drivers. If it then blocks it is the SPI making problems most likely.

ZibbeZabbe

Blink works fine, i flashed with the config I have labeled "stock" as that has no TMC enabled.

That worked!

If you don't mind, could you explain a bit more what you mean with "TMC special drivers"

Now (later) i am gonna try changing the CL pins, i have no real reasoning behind that though.

My SPI and CL things are soldered so that may have caused some part of the errors. I'll redo the solderwork, I only had multi-cored copper wire and i will redo it with some single-cored cable (and use some glue to keep em tidy)

Anyway, thank you for your helpful comments, this one test gave me more information than most of my tinkering these last few weeks (ive mostly done config.h iterations) :)

Repetier

TMC2130 can be programmed with spi if you configure firmware to use TMC2130 drivers. If you do not do that, they will still work but without trying to set current/microstepping. That way you can narrow down the problem to firmware in general or spi not perfectly working.

ZibbeZabbe

Does SPI still need to be soldered? Like this, or is this not relevant anymore. I had it soldered before so I am currently re-soldering it

Repetier

Yes I think so. That is from the guy who wrote the TMC2130 driver addition. I don't have it used so far. What I mean is when it is not activated as driver it does not set driver settings but will work in step/dir/enable mode with defaut values. That is not for final solution but to test if the spi is causing the problem.

ZibbeZabbe

Okay. I am back. I've re-soldered SPI cables and now it boosts
But only when:
No stepperdrivers are on the board
0.92 is flashed
1.0.2 w/o TMC is flashed

Drivers in with drivers enabled crashes.

In pins.h there is a segment with HW and SW SPI. Does this need to be changed to be compatible with the TMC2130 resolder?
"// 10 if using HW SPI. 53 if using SW SPI

#define SDSS 53"

Do I need to configure it to use the pins on the SDcard connectors for SPI or is that already how it should be?
Honestly I've gone through so many different test builds lately to gain more information I can share that I am starting to dream about the Arduino IDE and code.

Also I just want to thank you for all your help so far. I very much appreciate it

Repetier

"// 10 if using HW SPI. 53 if using SW SPI

#define SDSS 53"

That is not part of radds board definition, so ignore it.

You should be using hardware spi and there is only one hardware spi. All you need is a CS pin per device so you talk to the right spi device.

Please try first without display. Not sure if the sd card configuration can make trouble. Should not be a problem because without sd card it will simply use the sd card from the radds, but it adds cable length and all share same MISO/MOSI/CLOCK cable, so that might catch up interference.

Maybe you should try 1.0.3dev - I reduced spi frequency there. Maybe with the 4mhz spi frequency it works better. Just a try, configuration is the same.

Since the author of the extension uses a radds for development I wonder that it is so problematic.

ZibbeZabbe

Currently testing 2 versions of dev. w/ and w/o LCD enabled. Also tested my old "main" with SDSUPPORT set to 0 and added "#undef SDCARDDETECTINVERTED". Don't know if it was needed but the one I got from the configuration had it.

Just tried those two versions of dev fw and still no response. I did disable SDSupport in both configs though so that may be an error source. I'm gonna keep trying stuff, will update if I find something that works.

Just figured i should mention, if I have "mirror Z to other driver" as in I have Z2 I need to change EXT1 to Z2 in Printer.CPP

Like so:
<blockquote class="Quote">#if TMC2130_ON_EXT1 > 0 Printer::tmc_driver_e1 = new TMC2130Stepper(Z2_ENABLE_PIN, Z2_DIR_PIN, Z2_STEP_PIN, TMC2130_EXT1_CS_PIN);

Repetier

I don't think the modification was really necessary. Z2_ENABLE_PIN was assigned the value of EXT1_ENABLE_PIN in your configuration I guess. So it is still calling it with the same parameter.

But I looked at the sport and see that the drivers get initialized before firmware sends "start". So there is a simple test to check where and what exactly fails.

A bit below add after

Com::printFLN(Com::tStart); HAL::showStartReason();this line:

HAL::delayMilliseconds(100);it will wait so the "start" message will appear in host log when you connect. At least if initialization works. So if you see "start" in the log you know that the init was ok. If not disable one by one by commenting out the new TMC2130Stepper line together with the following configTMC2130... line . Maybe it is just one driver that is making problems during init. Then you know wiring is bad for that one or it is defect if all others work. Since motors do not get used at startup I think one of these lines causes the blocking. The other parts are only used on special moves or commands but would not prevent start of firmware.

ZibbeZabbe

Sep 11.
Okay so I've spent a few hours troubleshooting. So with some tinkering I got it to boot, i got drivers to move (+ only still need to change some settings i think)

However i do believe something is still fubar. Its slow to boot. Like we are talking 40+ seconds. sometimes boardering on 5min boot times.
After flashing it again a few times, now it wont boot again. I am now pretty sure either my RADDS may be damaged or one of the drivers are the cause.

Sep 12.
I added your command and further troubleshooting has it in the FW, but it does not seem to have had an effect.

Sep 13.
Okay, a few more hours and I'm pretty sure I have something... Maybe.

Basically. It seems LCD encoder position affects boot chance.
SOMETIMES (not always, not often but many times) turning the encoder while on "frozen" screen (/w 2 bars as pictured in earlier comment) it starts up
NOTE. Does not boot w/o screen. May be due to not flashing a FW without screen though.

Also! removing one stepper driver (the one placed on E1, E1 wiring is okay though and E2 which is connected THROUGH E1 causes no issues.) has increased boot success to around 70% along with the above technique. No steppers give 100% (dont know if it fails 1 in a 100 or not. not that inclined to test)

Also, don't know if it matters or it is correct behaviour or not.

While connected to my RADDS pins 50, 48 measure GND (aka ENC_P and ENC_B)

Tomorrow I will look into removing a resistor and doing a solder join on the stepper motors instead as they said on page 5 here.

Rep-Host logs
All drivers connected, wont boot (via only USB), not much to look at
One stepper removed, wont boot via USB so booted via PSU then connected

Sorry if the comment is rather long. I've spent a lot of hours the last two days troubleshooting and collecting information. Tomorrow I will also be attempting a dialog with Alexsomesan, but I'm not sure what to hope for as he is probably a busy man.

Again. Many thanks :)

Repetier

From the logic side having display connected or not should not make a difference. Display lines are just send never received. Input lines stay high (assuming pullup on) so as long as none does trigger reset or a function (switches normally open should work).

Boot time is normally a few seconds never more or watchdog would trigger. Do you have it disabled? Otherwise it might also explain the high time if oyu are in a reboot loop. Maybe initializing the tmc takes long. The only other thing that would block is reading eeprom on radds. But since it works without tmc enabled I think the tmc init takes so long. Maybe it verifies settings and when something goes wrong it retries until it succeeds.

Hopefully alex has some time and can say more.

ZibbeZabbe

I have watchdog enabled I do believe. I've got the printer booting 100% reliably now. There is still a significant difference in boot time now, sometimes it boots in 2sec, other times 50 sec. Honestly don't know whats changed.

Where do I see if watchdog is enabled, I want it enabled but when I load my config.h into the configurator watchdog isnt on so I assume its not enabled in config.h.

Ill look into the booting difficulties but meanwhile I'll take this time to see if I can get it stable.

There seems to be a bit of SW SPI code in the tmc2130 library now so I'll have to check later if that is functional or experimental.

Repetier

Check configuration.h for

/* A watchdog resets the printer, if a signal is not send within predefined time limits. That way we can be sure that the board is always running and is not hung up for some unknown reason. */ #define FEATURE_WATCHDOG 11 is on 0 is off.

Good that it working now also such difference in boot time is strange.

ZibbeZabbe

Watchdog is on, ill try and disable it and see if it may be a cause for boot time.
Boot time may be something like some capacitator or such hasnt discharged completely. i dont know. Would kinda explain my previous weirdness with the encoder boot.

Turning off watchdog did nothing for boot times, atleast first time. First boot took about 1 min 20 sec. Then second about 20 sec, third 9 sec.
Now it consistenltly boots in about 4 seconds

Does it take a few boots to "flush" out the old flash?

Ill flash again with watchdog and see if that was a cause.
Flashed with watchdog back turned on
1st boot: 19 sec. 2nd: 9 sec. 3rd: 30 sec.
After this its back to consistently booting in 4 sec.

Maybe also bootloop until perfect storm conditions allows it to boot.

Also, is the movespeed for "move z fast" set anywhere? I increased max feedrate and homing feedrate from 2 to 20(max) 10(home) yet it still moves INCREADIBLY slow. Homing from around 3 cm up takes about a minute or so.
Takes about 3 seconds to turn 1/4th rotation of stepper

is max feedrate mm/s or steps?

Steps/mm Leadscrew pitch Step angle Stepping
400.00 8 mm/revolution1.8° 1/16th#define XAXIS_STEPS_PER_MM 80 #define YAXIS_STEPS_PER_MM 80 #define ZAXIS_STEPS_PER_MM 400
#define MAX_FEEDRATE_X 200 #define MAX_FEEDRATE_Y 200 #define MAX_FEEDRATE_Z 20 #define HOMING_FEEDRATE_X 40 #define HOMING_FEEDRATE_Y 40 #define HOMING_FEEDRATE_Z 10

Repetier

Really strange thing the different boot times. Flash is not the problem.
What is your definition of boot time? Until you see "start" in log?

Regarding speed did you check settings in eeprom? They do not get overwritten with new flashing so it may contain older values.

Speeds are in mm/s in configuration.

ZibbeZabbe

Was away for a few hours. First "cold" boot took 2 minutes. If I leave the printer on for a while the boot is then it boots faster next time.

As for Z move. I missed EEPROM

ZibbeZabbe

Boot time is time from seeing this to display showing printer FW version and printer name.

Here is a vid of printer boot. Only thing I do off camera is switching PSU on.
(skip to 00:45 if you don't want to wait)