BIGTREETECH BTT Octopus Max EZ is there a cfg done yet?
Just trying to set up my voron 2.4 with new EZ board and Canbus (42 toolhead) on RatOS but cant find a cfg for it , is there one done or is one being worked on ?
68 Replies
Not yet, and i don't have the board unfortunately. Maybe someone else does and is willing to take a crack at it? For the toolboard RatOS uses USB. You can use CAN but it's a lot of manual setup, no debugging or automatic firmware flashing, in short there's no help there.
sunny-greenOP•2y ago
ok thanks , i really wanted to try the RatOS it looks so much better than the other front ends and i know you have put 100s of hours into coding it for us . i may just throw the octopus pro back in with usb canbus , just to see it in action , 10/10 from me....
https://github.com/FlorianKoegler/RatOS-configuration/commit/6a3fc01eb4627310d5c21925ce74c88781dfc99b
Maybe you can use this as a base.
I have managed to flash the board (manually via SD card) and boot it with this, but haven’t gotten to actually test the board for printing. I hopefully can during the next week.
Watch out, I think one pin in the official BTT document was wrong and needs to be corrected, I haven’t done this yet.
https://github.com/bigtreetech/Octopus-Max-EZ/issues/2 this was the pin.
We might need to check the other issues there too, if anything is relevant
GitHub
Bl touch pin · Issue #2 · bigtreetech/Octopus-Max-EZ
Attention in version V 1.0 of Octopus Max Ex, you have to reverse the connection of the two pins PB14 and PB!% inside printer.cfg. Otherwise the BL Touch does not work. I write the exact code here:...
Appreciate it!
Awesome 👍 Yeah wasn't this the board that potentially burns your house down in DFU mode, like the EBB 1.1's?
Uhmm I sure hope not also have not released any schematics for it, so it’s hard to tell without trying
let me see if i can find it
Ah it was the H723 Octopus Pro. No reason to worry, false alarm 😄 https://gist.github.com/kmobs/2c151bacc1aa74bafa93ea876f50f1b6
Gist
BTT H723 Octopus Pro Errata
BTT H723 Octopus Pro Errata. GitHub Gist: instantly share code, notes, and snippets.
Ah ok, thanks this issue can be ignored. It only applies to the firmware code that BTT provides, which is wrong.
The documentation, on which I based the .cfg, is right.
I also went through all pins with secondary function during boot. There is nothing connected to the heaters.
I think none of the the pins, that could get driven or pulled up/down during boot, should damage anything.
thanks for checking that!
sunny-greenOP•2y ago
hi cheers for this , i made the folder and created the files the configurator sees the new board entry but when i select it press compile nothing happens no bin is created , bit stuck as im not a coder more a simple user .
probably just need exec rights on the bash files in that folder you created. Cd into that folder and do
sudo chmod +x *.sh
and see if that fixes it.sunny-greenOP•2y ago
that fixed it . thanks
Small update: the config and board works fine.
I tested it with a mix of TMC5160 (SPI) and TMC2209 (UART).
4 pin fan works nicely with PWM and RPM pins without any tricks (it is on during klipper restart; but not on regular boot).
When using multiple SPI devices (like the stepper drivers), you will need to switch the ADXL to software SPI instead of hardware spi4, as the steppers are using the same. The only way to achieve this was to remove this line from config.cfg (idk if there is a better way to unassign the value?) and define the software SPI pins instead.
spi_bus: spi4
multiple-amethyst•2y ago
Sure ?? According to BTT´s pinout on github, the sck/miso/mosi pins on the spi expansion port are hardwired to the same cpu-pins as stepper spi and/or sd-spi. In all cases it´s spi4 ...
[CUT ON]
LCD-FPC SPI, Onboard SD card, expansion SPI pin header and TMC driver SPI, 4 features multiplexing the same hardware SPI4, and is converted to 5V to TMC driver
[CUT OFF]
So removing this line will only disable communication with the adxl itself. Using these pins for software spi will crash spi4 ...
Maybe my info is outdated, because I also see people reporting it working.
But communication with the stepper drivers failed when I tried hardware spi4.
It worked as soon as I switched to software.
multiple-amethyst•2y ago
Maybe give this a try: if you have the board up and running: shorten MISO / MOSI on that expansion port with a jumper and reenable that line ... If there´s no device connected, data will not get forwarded and therefore is "broken" at that point. The jumper will "emulate" a connected device (or better: replace the broken link in that spi4 daisy chain)
Why would there be a daisy chain, its a multi-slave topology with chip-select lines?
Also there won’t/can’t be a difference between implementation as „hardware“ or „software“ on this level.
There is a single MISO and a single MOSI wire on the board that runs to several components in parallel, not in series.
Same for SCLK.
Only the CSn lines are individual for every slave.
multiple-amethyst•2y ago
Ouch... You´re right (too late at night and my head is still full of the last C++-adventure with another stm32 chip xD) Have mistaken the topology here with my other hardware i use
But I will check if there was something missing while using hardware SPI. Klipper docu says:
If a device on a shared SPI bus is not configured, then it may incorrectly respond to commands not intended for it and corrupt the communication to the intended device.
multiple-amethyst•2y ago
Was the adxl connected, when hardware spi failed or did you leave that port open?
No, it was not connected yet
multiple-amethyst•2y ago
Theoretically it shouldn´t make any difference then... Even if klipper would check the presence of the adxl (what it doesn´t, as far, as i know) there would simply nothing come back on the miso-line 🤔
Yeah, and it wasn’t connected with the software SPI either
multiple-amethyst•2y ago
Maybe BTT mixed up the pin names or their function in the docs (as usual) 🤪 😂 and when you configure software spi, you assign them manually and everything works.... Hopefully i´ll find some time this weekend to check the datasheets for the pin assignments of that H723 cpu ...
By the way: I´m not sure, if this is important and how klipper handles these configs. But anyway: In that config.cfg for RatOS, there´s just a part for TMC2209´s and spi4 is never defined (like in btt´s example config for the 2130´s)
Where 2209´s just need UART, the 5160´2 (and 2130´s) need cs-pin and spi bus defined
example=
cs_pin: PG14
spi_bus: spi4
(uart_pin then of course removed)
Yes, this happens in the stepper file, which you need to include:
https://github.com/Rat-OS/RatOS-configuration/blob/v2.x/steppers/ldo/42sth48-2504ac/5160/50v-1.768a-x.cfg
GitHub
RatOS-configuration/50v-1.768a-x.cfg at v2.x · Rat-OS/RatOS-configu...
The RatOS modular klipper configuration. Contribute to Rat-OS/RatOS-configuration development by creating an account on GitHub.
Or alternatively to use hardware, I placed the steppers in the printer.cfg directly
multiple-amethyst•2y ago
That´s, how i have configured my printers xD I didn´t want always having to search for these configsnippets, just for tinkering around a bit 😂
Well, it modularizes the config, which is a good thing.
multiple-amethyst•2y ago
Yepp, that´s true. But if your user overrides in printer.cfg get´s way longer than the .cfg itself, there isn´t much left of that modularity xD I just took a quick look into the stepper file. They just use the same pins, as defined for hardware spi. So these definitions are correct. Otherwise also software spi couldn´t work...
multiple-amethyst•2y ago
One year ago, there was a similar bug with another board/cpu. Google just showed me that page and maybe it´s somehow similar:
https://github.com/Klipper3d/klipper/pull/5250
GitHub
BUG: Fix STM32 SPI CR1 by bigtreetech · Pull Request #5250 · Klippe...
STM32 SPI_CR1 should not be changed when communication is ongoing.
fix #5198
This is fine, that's what we do on Octopus Pro and others as well. There's a bug... somewhere, where SPI multiplexing only works in software.
Only if the other devices aren't running software spi as well, either all devices on the same bus run software spi or they run hardware spi.
multiple-amethyst•2y ago
Oufff.... After a whole weekend testing (and destroying an EZ5160 ...), tinkering and nearly giving up, i have some updates.
I installed that Octopus Max EZ V1.0, downloaded the files from github, copied them into the according RatOS-folder (boards), replaced templates.cfg and then the odyssey began... 1st at all i deleted the old printer.cfg, flashed klipper manually (following btt´s instructions) started the configurator and the board was in the list, but didn´t get found. Ok: ssh also showed nothing... After unplugging the adxl from the spi-port, the board started up and was shown as usual. In the configurator still not detected... Ok, i copied back my old printer.cfg, edited out the ols stuff and added serial:xxxxx. Voilá, It´s alive ! Then followed a lot of playing aound with the drivers, completing the setup, testing and so on.
After everything didn´t look too bad (And after changing back to 2209´s for x and y... Was my own fault, shit happens...), i reconnected the adxl. Long story short: When i kept it connected during startup, the board didn´t boot up, when i disconnected these 3 spi-pins (miso/mosi/sck), the board started without problems. I tried software-spi, hardware-spi and everything, i could think of: No chance to boot the board with the adxl connected to that expansion port.
Then after many Google-searches (with no results), i´had an idea: Back to "make menuconfig", setting up the GPIOS to set at startup and entered PE12,PE13,PE14. Compiling, SD-Card, reflashing and Voilá, the board starts up with and without that adxl connected.
Further tests with hard- and software-spi worked both, just the queried values looked a bit strange for me. Most of the time there was a value missing (y 0.0000) or x and y showed the same values.
Interesting: The shown frequency of the mcu was 400MHz (instead of the advertised 550). Maybe it´s the timing, maybe it´s a faulty board, i just don´t know. But in my humble opinion, there is definitely something more than wrong with these boards or / and the software.
Edit: I also got these "strange" values before i reflashed the board, when i started up, connected the adxl after booting and queried then ...
I installed that Octopus Max EZ V1.0, downloaded the files from github, copied them into the according RatOS-folder (boards), replaced templates.cfg and then the odyssey began... 1st at all i deleted the old printer.cfg, flashed klipper manually (following btt´s instructions) started the configurator and the board was in the list, but didn´t get found. Ok: ssh also showed nothing... After unplugging the adxl from the spi-port, the board started up and was shown as usual. In the configurator still not detected... Ok, i copied back my old printer.cfg, edited out the ols stuff and added serial:xxxxx. Voilá, It´s alive ! Then followed a lot of playing aound with the drivers, completing the setup, testing and so on.It wasn't detected because you didn't flash it with RatOS firmware like it instructs you to.
After everything didn´t look too bad (And after changing back to 2209´s for x and y... Was my own fault, shit happens...)I'm not following, how did you "destroy" your 5160's?
i reconnected the adxl. Long story short: When i kept it connected during startup, the board didn´t boot up, when i disconnected these 3 spi-pins (miso/mosi/sck), the board started without problems. I tried software-spi, hardware-spi and everything, i could think of: No chance to boot the board with the adxl connected to that expansion port.I've heard about this before on the Manta M8P but haven't been able to reproduce it. My best guess is miswiring.
Then after many Google-searches (with no results), i´had an idea: Back to "make menuconfig", setting up the GPIOS to set at startup and entered PE12,PE13,PE14. Compiling, SD-Card, reflashing and Voilá, the board starts up with and without that adxl connected.Can you explain this?
multiple-amethyst•2y ago
I also tried flashing the firmware, compiled by the configurator 😉 It also didn´t get detected 😦
Miswiring isn´t possible. I didn´t change that plug (before it was connected to a octopus 1.1), i crosschecked many times with the pinout of the old board and last, but not least: It worked after altering some softwaresettings...
As explanation for the gpios: I thought, maybe on that adxl board pulls one or more of these pins low (where they should be high after spi init, if i´m not wrong...) so i forced them high xD
Then you probably didn't run
sudo ~/printer_data/config/RatOS/scripts/ratos-update.sh
to update the udev rules. You were manually modifying the files so the githooks wouldn't have run.multiple-amethyst•2y ago
Yepp, that´s true 🙂 Didn´t even know that ...
Except it didn't, you talk about weird values later after you forced PE12, 13 and 14 high.
Besides the adxl issues, it doesn't sound like there's anything wrong with the board
I believe the 400mhz is a klipper limitation
multiple-amethyst•2y ago
It showed the same behaviour also without forcing them high... I could start the board without these Pins connected, plug them in after booting (one dupont plug on the adxl). So the state of these pins at startup didn´t affect the function
Ah okay, good to know
Did you run a noise measurement?
It may have been working fine
multiple-amethyst•2y ago
Can do... Just ran the query until now... Gimme 2 minutes xD
Axes noise for xy-axis accelerometer: 17.621850 (x), 18.298562 (y), 60.491029 (z) 🤔
I guess you just experienced a case of this: https://www.youtube.com/watch?v=o8ym0HBvpFA
multiple-amethyst•2y ago
😂
btw: i never had any trouble with my adxl´s, so i never measured that noises xD I even don´t know, if these are good values 🤪
Meanwhile i ran that test a couple of times and it´s +/-3 always in th same range 🙂
as long as they're < 100hz you should be good 🙂
multiple-amethyst•2y ago
Thanks for the hint with the manta m8p ... Just googled and found something interesting:
https://github.com/bigtreetech/Manta-M8P/issues/27
Back to the drawing board, 1st fixing RatOS with the githooks, config back to "normal" and trying to swap Mosi/Miso with software spi... Wish me luck xD
GitHub
Manta M8P Boot Loop on SPI1 with ADXL345 · Issue #27 · bigtreetech/...
Connecting an ADXL345 to SPI1 on my Manta M8P causes the MCU to not boot. It seems like the bootloader is conflicting with some other device on SPI1 on boot. Can anyone confirm if there is any othe...
multiple-amethyst•2y ago
Success No.1: Board reflashed, got recognized immediately 🙂
One question about this: Update Manager still shows "Dirty". I guess, when i run a soft recovery, the new board is gone again ?
Update: The board now in the state, as it should be, it´s still not booting up with the adxl connected. Then i physically swapped miso and mosi. Of course i edited the config.cfg and changed from spi4 to software spi (of course with the correct pins) and voilá: Everything works, as it should... BUT one problem still exists: This way, it´s impossible to use 5160´s 😦 Unfortunately there it´s impossible to swap 2 pins
Correct, it's dirty because you made modifications when you added the board.
5160's should work fine with software_spi as well
Same thing we do on the Octopus Pro
multiple-amethyst•2y ago
Correct, they would, if the pins on that expansion header wouldn´t be the same, as for the steppers... So if i swap miso/mosi to get the adxl up and running (or better: the board itself...), communication with the steppers would fail 😦
No this works fine with software_spi, there's a bug with hardware spi that prevents multiplexing from functioning but it works fine with software_spi. Again, there's the exact same situation on the Octopus Pro where both the steppers and ADXL are on bus 3.
If you need to swap miso/mosi then the ports are actually swapped (or your wires were swapped all along).
multiple-amethyst•2y ago
I had to swap the miso/mosi pins physically AND in the config 😉
You should be good
ah... 🤔
that makes no sense
I think you need to talk to btt #bigtreetech
multiple-amethyst•2y ago
In the config for the adxl i swapped PA13 and PA14 as well. This way, the board boots up. But at the steppers i can´t swap these two lines 😦
Well... The guys from that thread, i linked... They were in contact with them until btt decided to keep silence...
not physically, but you can config wise
@.alan.ma I have a user with an Octopus Max EZ that won't boot up with an ADXL345 hooked up to the SPI header. I have a similar report from a user with an Manta M8P. Can you reproduce this on your end?
Sounds weird, especially if you need to swap twice...
I'd like to help you and try this out, but I can't find my ADXL anywhere (might have taken it to work for soldering, idk?).
So it might take until Tuesday before I can report on this issue. the flashing: I also did some tinkering before it worked, but iirc it had more to do with the SD card being wrongly formated.
If you copied all files from my git commit, it should have worked similar to other boards.
Seems like it was just the udev rule that wasn't linked (requires running
sudo ~/printer_data/config/RatOS/scripts/ratos-update.sh
)So, I cannot confirm the trouble with the ADXL.
I have connected an ADXL343 module to this header with the pinout below.
https://learn.adafruit.com/adxl343-breakout-learning-guide/pinout
Board config is this (switched to software SPI for now):
https://github.com/FlorianKoegler/RatOS-configuration/blob/v2.x/boards/btt-octopus-max-ez/config.cfg
Adafruit Learning System
Analog Devices ADXL343 Breakout Learning Guide
Get up and running (tapping, free-falling, whatever!) in no time with this quality 3-axis accelerometer.
GitHub
RatOS-configuration/config.cfg at v2.x · FlorianKoegler/RatOS-confi...
The RatOS modular klipper configuration. Contribute to FlorianKoegler/RatOS-configuration development by creating an account on GitHub.
Actually I stand corrected. The ADXL345 works and the board boots without issues, but the steppers are no longer responsive!? 😅
5160's?
Yes
If I unplug the ADXL, they work again.
So I will just connect it to the Raspberry Pi directly for now
please make sure you're using software_spi on the 5160's
and the adxl345 as well for that matter
Everything on that bus needs to run software_spi for multiplexing to work
If it still doesn't work, try using an arbitrary other GPIO for the CS pin on that adxl345.
Yes, software SPI was enabled already for the 5160s and I did the same for the ADXL (see the linked file).
This might be something to try, but I have already rewired the connector now, so that it fits the Raspi Header.
strange
Could it be due to insufficiently shielded or too long wires?
I didn’t want to cut up a good 10GBbit RJ45 cable and didn’t have anything else, so I used regular wires and twisted it up.
Maybe it makes sense to re-test with some short jumper wires to rule this out ?
multiple-amethyst•2y ago
@miklschmidtWas there meanwhile any response from @.alan.ma about these spi isues ?
Nope, nothing yet
Yes if the ADXL345 wasn't working, but it is, so.. It shouldn't affect the other devices on that SPI bus.
Just to confirm, even though "Octopus Max EZ " is not officially supported, I can still run RatOS as long as I connect the ADXL directly to the Pi for now. Is this correct? (oh, and need to follow BBT instructions to flash the board)
Doesn't matter 🙂
If you want to use it you need a pin map and you need to manually flash it and set the mcu serial
equal-aqua•2y ago
THANK YOU for your help on this support post. Saved my butt. Every issue I had getting the Max EZ to work just needed me to read a little further 😂
Now I just gotta figure out my stepper wiring 🤔