BTT SPI problems from WOWElectronics continued

General Discussion
1

Basic Information:

highly modified E5+
BTT octopus pro
klippy.log

This is the continuing saga of WOWElectronics which I thought was in configs but cannot now find that thread.
I might add that this discussion actually started about a year ago, on a tronxy400 with the same problem that was not solve, then continued some time later with another copy of the same octopus pro board in a 2 trees sapphire 5, also ending w/o a solution.
Symptoms seem to be that if the driver0 and driver1 sockets are all 4 jumpered 2-3, then neither spi nor uart works. The question is why?
those 2 driver sockets have signal stealers fitted, and they are driving the opto coupled inputs of a pair of hanpose cl42 or cl57 drivers mounted of the frames close to the motors they control, and stepper_buzz stepper=stepper_x (or stepper_y) works as expected.
But, it cannot talk uart to tmc2209’s and it can’t talk spi to tmc5160’s.

So this is not a new problem, this is the third such failure in a row. with zero successes.

I have found on the last couple pages of Config_Reference.md,
a section of stuff on the spi buss that I don’t have in my .cfg file.
I reformatted that doc to contain the loooooong lines and printed it which added a page to its printed length. Heading of that section:

Common SPI settings.

The first item, unk to me, is:
#spi_speed: and it does not list a default, altho I recall reading some place that linux could do this at 400000 hz. next item is
#spi_bus: and has a lengthy explanation but no default value.
And I no clue where to find that info.

Now back to around page 96, under tmc5160 are several more entry’s I don’t have and ndi where to find them.
That listing also shows the above 2 config entries but has more:
#chain_position: does this have a base0 start, and does it start this chain at driver socket 2 from base0 where the first tmc5160 lives? or what? This looks important.

#chain length: which I assume would be 3 since there are three of the tmc5160’s in this Octopus pro ? next is
#hold_current: which I can define as a reduction from run current.
Then there is another 2 pages of stuff for the tmc5160!
You can even remap the motors microstep mapping.

Thanks for any info/insight.

Thunderbird has helpfully deleted my last msg from BTT’s tech guy, and BTT hasn’t “answered” the phone in about 2 weeks now… So I need someone who has made uart or spi actually work on an octopus pro. What do you have in your printer.cfg that I don’t have in mine, or is this a known bug in octopus pro’s. IDK.

2

Gene, I do not even have the faintest idea of what you are talking about.

For sake of your and our mental health: Follow the directions of GitHub - bigtreetech/BIGTREETECH-OCTOPUS-Pro: This is OCTOPUS Pro open source material
and GitHub - bigtreetech/BIGTREETECH-OCTOPUS-V1.0: This is Octopus open source material

In particular: BIGTREETECH-OCTOPUS-V1.0/Firmware/Klipper at master ¡ bigtreetech/BIGTREETECH-OCTOPUS-V1.0 ¡ GitHub and just leave the rest alone.

1 Like
3

My mental health has nothing to do with it. I just dl’d the docs on this that might be newer than what I have but since its my money, and I want to improve a consumer grade printer with a better controller and motors, even a carbon fiber part where alu was used, something that apparently scares you because you don’t understand what I write straight from klippers Config_Reference.md, then please ignore me.

I may be 89 yo, but I’m also a CET, rare birds indeed. We teach dummy’s with an EE sheepskin on the wall, stuff their incompetent prof failed to do. Electronic wise, I am as close to a JOAT as you’ll find in a lengthy search. So don’t play war of wits with me. I am used to doing what 4 EE’s watching me are saying can’t be done. I understand the physics of relativity and knew how to take advantage of it in that case.

I DO know what I’m asking about, which is the unstated defaults in the example configs for some of this stuff, stuff that the tech folks at BTT could quickly answer if they wanted to. klipper does not always assign defaults because they have to make it universal as much as possible. What I am seeking is data and possibly a bit of theory that only BTT can answer accurately. You are not BTT.

4

@gene1934

To net things out, the specific questions you are asking are:

  1. What is the default SPI bus speed?
    I just looked at the code (TMC5160.py which accesses TMC2160.py) and it’s 2.25MHz. Regardless, this shouldn’t be of any concern of yours; as I noted, it’s taken care of in the code and has been proven to work without issues.
  2. What is the “spi_bus” value that you should use?
    “spi1”. You can see it referenced here: Example Octopus printer.cfg
  3. Is the TMC5160 chain position zero based?
    Based on the Klipper documentation it’s 1 (but it should not be a concern):
#chain_position:
#chain_length:
#   These parameters configure an SPI daisy chain. The two parameters
#   define the stepper position in the chain and the total chain length.
#   Position 1 corresponds to the stepper that connects to the MOSI signal.
#   The default is to not use an SPI daisy chain.
  1. What is “hold_current”?
    That’s the current that runs through the stepper when it’s not moving, to hold it in place. From the documentation:
#hold_current:
#   The amount of current (in amps RMS) to configure the driver to use
#   when the stepper is not moving. Setting a hold_current is not
#   recommended (see TMC_Drivers.md for details). The default is to
#   not reduce the current.

However, the real problem seems to be that your Octopus Pro is unable to communicate with your stepper drivers. Rather than simply follow the template for “General Discussion” questions, you have filled fill up a page of meaningless information and questions that aren’t relevant to the basic problem that you are having.

As a personal observation; you are an extremely difficult person to help and I echo the frustration that @Sineos expressed in his reply. There’s a pattern to your questions in that you start with describing an outlandish system that is off the curve and difficult to fathom why you are doing this. To make matters worse, the actual problem is buried so that it isn’t obvious. When we start asking questions, you get defensive and proclaim that you’re smarter than anyone around here (I have no idea what “JOAT” is). Despite your proclamations of your intelligence and experience, you do not demonstrate a good understanding of the 3D printer systems and electronics that you are using; I was able to find the answers for questions 2 through 4 with references within a minute while I spent about 15 minutes searching out the answer to question 1 because I was curious - the answer I would normally give is "don’t worry about it and let the default do its thing.

We’re here to help and have a pretty good track record of getting people with problems working; we don’t get paid and the best we can hope for is for the person asking the question follows the template that comes up automatically then accurately answers our follow on questions along with working through the experiments that we ask them to try.

So, could I ask you to go back, start a new request, fill out the template as required (including your klippy.log) and keep the editorial comments to a minimum? We’ll do our best to help you get your printer working.

2 Likes
5

In that event, let me symplify the request. I need a control board with the possibilty of up to 8 motors that is known to work with all 3 modes of communicating with the drivers installed AT THE SAME TIME. The BTT octopus and the octopus pro have both failed in 3 different machines. I’m willing to throw money at it so just name the board that is known to work with a mix of drivers installed.

6

neither of those can be found in any section of the sample config linked to in your reply, Myke. So I haven’t the foggiest where to put them. I have all the klipper docs & sample configs, what file are they actually in? From reading the Config_Reference.md, I get the impression each socket should have its own spi address. Since the first socket to have a tmc5160 in it is socket/driver 2, I’d want to guess the chain_position would be 2 then 3 and 4 in each progression of driver sockets. So spi_speed: 2.25 mhz (and that might be only needed once?) with spi_bus: spi1. but is that the case? And chain length then might be a base 1, so 3 for length might be correct. So pending your corrections I’ll start with those in every tm5160 section and see what screams at me. But probably in the morning as my coffee is wearing off. But curiosty killed the cat. I put it all in, the commented out what it complained about and wind up with this when klipper is happy again:

Shit, damn. this editor in klipper does not have an undo so I erased the whole damned stepper_z entry by trying to slide the clicked mouse over it. Sucks dead toads thru soda straws, so I closed w/o save but its still lost when I reopened printer.cfg. That’s found on the ground behind the male bovine…
[tmc5160 stepper_z]
cs_pin: PC6
spi_software_miso_pin: PA6# Soft SPI
spi_software_mosi_pin: PA7
spi_software_sclk_pin: PA5
#spi_speed: 2.25 # assuming megahertz
#spi_bus: spi1
chain_position: 2
chain_length: 3
interpolate: True
#diag0_pin: PB14
run_current: 0.8
hold_current: 0.5

Make sure to update below for your relevant driver (5160)

[tmc5160 stepper_z1]
cs_pin: PC7

Soft SPI

#spi_speed: 2.25 # assuming megahertz
#spi_bus: spi1
#chain_position: 3
spi_software_mosi_pin: PA7
spi_software_miso_pin: PA6
spi_software_sclk_pin: PA5
#diag0_pin: PB13
interpolate: True
run_current: 0.8
hold_current: 0.5
#stealthchop_threshold: 0

Make sure to update below for your relevant driver (5160)

[tmc5160 extruder]
cs_pin: PF2

Soft SPI

#spi_speed: 2.25 # assuming megahertz
#spi_bus: spi1
#chain_position: 4
spi_software_mosi_pin: PA7
spi_software_miso_pin: PA6
spi_software_sclk_pin: PA5
#diag0_pin: PB13
interpolate: True
run_current: 0.8
hold_current: 0.5
#stealthchop_threshold: 0

So chain_length is set once
chain_position is set by the socket
and spi_bus and spi_speed are objected to.

But thats not right yet. attempted to home x, got:
Unable to write tmc spi ‘stepper_z’ register GLOBALSCALER
Once the underlying issue is corrected, use the
“FIRMWARE_RESTART” command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown
klippy.log (161.9 KB)

now, I really am going to bed. If you see anything in the log, please yelp. I’ll leave FF sitting here, watching the mail. Thanks Myke.

7

Questions back before some answers:

  1. Why do you want to mix drivers and communications methods? Theoretically it can be done but you would need to go through the schematics and make sure that there are not signal conflicts - maybe there’s a jumper setting that will allow “all 3 modes of communicating” but I’m not searching schematics and datasheets for them. Klipper can probably handle the different pin functions per driver but all the 3D printer implementations that I can think of use one driver part number for consistency and avoid potential issues like the ones mentioned above as well as keep things simple.

  2. What are “all 3 modes of communicating”? From what I see above, you’re only asking about SPI (for the TMC5160) and UART (for the TMC2209).

You’re making things overly complicated to start off and not taking advantage of the work many people working on Klipper have done to make things easier.

If you had gone through the example printer.cfg I linked, you’d see that a TMC2209’s operating specifier is quite simple:

########################################
# TMC2209 configuration
########################################

#[tmc2209 stepper_x]
#uart_pin: PC4
##diag_pin: PG6
#run_current: 0.800
#stealthchop_threshold: 999999

Remove the first comment character (“#”) and Bob’s your uncle. If you’re using sensorless homing on that axis, remove the second comment character before diag_pin.

It’s exactly the same with the TMC5160:

########################################
# TMC2130 configuration
########################################

#[tmc2130 stepper_x]
#cs_pin: PC4
#spi_bus: spi1
##diag1_pin: PG6
#run_current: 0.800
#stealthchop_threshold: 999999

I have no idea why you want to chain the SPI drivers when in the snippet from answer 3. above says:

#   The default is to not use an SPI daisy chain.

That says to me that it’s not needed. Just looking at your klippy.log, you’ve specify the SPI chain as device two of three on one TMC5160 (stepper_z) and in one case, you’ve set another TMC5160 (extruder) as device four.

It’s always a good rule to not use something if you don’t understand how it works.

I’m not sure why you’d specify a “Soft SPI” with all those parameters when the basic one provided by BTT is less than half the size.

In the future, if you’re putting in code, use the formatting block (</> above).

The smartest people I know all start off simply and if there are issues or things aren’t working as required they then look at ways to get the desired functionality.

KISS

I highly recommend that you follow the example printer.cfg as well as replace whatever you have in X & Y so you’re consistent and see how that works.

8

Curiosity got the better of me JOAT = jack of all trades

1 Like
9

Please use preformatted text for your code snippets. It’s for better reading.

Format

1 Like
10

Thanks for jumping in @mykepredko
Just to get some points straight and as I will not let myself be dragged in this rabbit hole:

  • Mixing different driver communication setting is possible
    • You can carbon copy the settings from the example cfgs. No need for a secret sauce
    • You need to set the jumpers right on the board as described in the relevant documentation of the board
  • The links I have provided @gene1934 are already answering all these questions
    • There is an example config that lists all possible and valid combinations of driver
    • There is the instruction manual that provides the needed jumper settings
  • NOWHERE it is mentioned you should setup a daisy chain or mess with software SPI - and it is NOT NEEDED
    • Daisy-chaining drivers is needed if you do not have enough pins, e.g. only one chip select pin and thus a driver needs to be addressed via its chain position. And no, it is not your choice if you would like it, it is a hardware requirement.
1 Like
11

I found a full color image of the board with all that info on it, a year ago, blew it up into 3 pages of photo paper, has all that stuff on the left end of image 6 of 8 in a jpg format, its in:
BIGTREETECH Octopus Pro v1.1-pin.jpg file inside of:
BIGTREETECH_Octopus-pro-master.zip, in the hardware directory.
See the SPI box in the lower left corner, EVERY jumper of every socket containing a QVH5160 from fitsec, which I was told was a tmc5160, is set as noted in that box. With or without the extra stuff in the config, no serial com is available. Step up to the UART box above the SPI box and set the socket jumpers like that, just one as sown in black there, and tcm2209’s can’t be talked to.
there is another long box at the bottom of the image, showing the EN STEP DIR CS pins, I just rechecked, its all correct.

Yet neither setup works. 4 Octopus v1.1 cards in a row in 3 machines have failed. Why?

I can afford to throw money at this so I ask for a board known to work with mixed drivers and that’s ignored, why?

Do I have something in makemenuconfig screwed up? We double checked that a year ago. But I’m willing to repeat that again. I just took all that stuff back out of printer.cfg, so it’s exactly as the samples show, try to home x, get this:

Unable to write tmc spi ‘stepper_z’ register GLOBALSCALER
Once the underlying issue is corrected, use the
“FIRMWARE_RESTART” command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

One other confusing thing, the board power pair of jumpers is missing but I can disconnect the big suppy leaving only the bpim5 powered and the board is still powered from the usb-c connecting the bpim5.

There is an “SPI3” dual row 10 pin header but its empty and the rest of the manual does not mention it. I am at the end of my available resources. I need a board that works as advertised. I do have genuine BTT tmc2209’s coming, here later this week.

12

Although proclaiming that you very well know what you are doing, you are just messing around without rhyme or reason.

This is going to be my very last input here. You can follow it or continue your way, I do not care

  1. Identify the MCU chip you have on your board
  2. Follow BIGTREETECH-OCTOPUS-V1.0/Firmware/Klipper at master ¡ bigtreetech/BIGTREETECH-OCTOPUS-V1.0 ¡ GitHub No 3 to build the proper firmware
  3. Flash the board
  4. Make sure to have set the motor power correctly according to GitHub - bigtreetech/BIGTREETECH-OCTOPUS-Pro: This is OCTOPUS Pro open source material
  5. Set the jumpers on the individual motor slots according to BIGTREETECH-OCTOPUS-V1.0/BIGTREETECH_Octopus_EN_updated_0719.pdf at master ¡ bigtreetech/BIGTREETECH-OCTOPUS-V1.0 ¡ GitHub Chapter 3, i.e. UART for the slots that you intend to poulate with TMC2209 and SPI for them with TMC5160
  6. Take BIGTREETECH-OCTOPUS-V1.0/Firmware/Klipper/generic-bigtreetech-octopus-pro-v1.1.cfg at master ¡ bigtreetech/BIGTREETECH-OCTOPUS-V1.0 ¡ GitHub as a basis.
    • Use the provided examples of #[tmc2209 ...] for the slots to be populated with TMC2209
    • The examples of #[tmc2130 ...] for the ones intended to be TMC5160.
    • Rename [tmc2130 ...] to [tmc5160 ...]
  7. Verify your board’s revision and check if adaptions according to GitHub - bigtreetech/BIGTREETECH-OCTOPUS-Pro: This is OCTOPUS Pro open source material are required

If you have followed these steps correctly, you will have a working board.

1 Like
13

Chuckle. People who don’t even know how a light switch works have accused me of having webbed feet cuz I can walk on water according to them. Enough times it got to be a joke. So when some business wants a business name to sell me something, I’m the owner of WOWElectronics. I spent the last 18 years of my working life as the CE of a cbs tv affiliate, working the service bench alone most of the time. I am a CET, a rare one with little official education, 8th grade, I quit school shortly after the 8th grade and went to work fixing tv’s at 14yo. I sat for the CET exam in 1972 w/o cracking a book. I scored a 98 on the AFQT in 1952, that got me 4f’d for life. They wanted cannon targets in Korea, not people who would argue with the sargent. Scored 147 on the Iowa test in the 6th grade. That’s equ to IQ. Now 89yo, with a chest full of stuff I wasn’t born with, I am winding down, but my pacemaker battery is still good for about 5 or 6 years yet.

14

Found some pin diffs in that last github link but the table has an error:

Octopus-pro-v1.1-error
Octopus-pro-v1.1-error954×440 41.8 KB

note PA0 is now for HE0 and motor4,extruder is now PA2
And motor 3,stepper_z1 is also !PA0
klipper obviously upset. which is wrong? cards has STM429 mcu.

15

Which version of the Octopus Pro are you working with and could you provide your klippy.log.

Anytime you make changes to your system and need help, provide the latest klipyy.log.

16

Octopus pro, v1.1 Myke, I think I’ll have to reboot. klippy.log got huge as were the log rotated versions, so I rm’d them all then touched klippy.log but it is not now making a klippy.log . reboot in progress. rebooted, and now have klippy.log again.
klippy.log (24.9 KB)

17

We need to set some ground rules if I, or anybody, am EVER going to be able to help you.

  1. Clearly explain your system. This means list the printer type, main controller type, driver type (which is critical in this case), host type and host to main controller connection.
  2. Include your klippy.log.
  3. Concisely articulate your primary concern and list any observations that you think may be useful - nothing more. NOTE: these three points are what you should have done when you first started this thread in “General Discussion”.
  4. When asked a question, answer it clearly. If you don’t understand what is being asked request an explanation. Don’t go off on a tangent.
  5. When a suggestion is made do that and nothing else. Report your observations and don’t add anything. Always attach the latest klippy.log; if it’s too big to attach then .zip it and attach the compressed file.
  6. Wait for a response. Don’t make any changes until you are instructed to do so.

I’m doing this because the klippy.log you just sent clearly shows that you just added a new printer.cfg file that you got from somewhere.

Here is the original klippy.log you attached, I’ve marked it with “6” as that is the entry in this thread it was posted: klippy_Gene_6.log (161.9 KB)

Here is the second klippy.log you attached, I’ve marked it with “16” as that is the entry in this thread where it was posted: klippy_Gene_16.log (24.9 KB)

Your [mcu] and '[printer]` statements from the first one:

[mcu]
serial = /dev/serial/by-id/usb-Klipper_stm32f429xx_3D004C001050325635383820-if00

[printer]
kinematics = cartesian
max_velocity = 600
max_accel = 10000
max_z_velocity = 5
max_z_accel = 100

Your [mcu] and '[printer]` statements from the second one:

[mcu]
serial = /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
restart_method = command

[printer]
kinematics = cartesian
max_velocity = 500
max_accel = 5000
max_z_velocity = 10
max_z_accel = 200

In the first klippy.log, your stepper_x pins are defined as:

[stepper_x]
step_pin = PF13
dir_pin = PF12
enable_pin = PF14

In the second klippy.log, your stepper_x pins are defined as:

[stepper_x]
step_pin = PC2
dir_pin = !PB9
enable_pin = !PC3

In the first klippy.log, you have [tmc5160 stepper_... statements that we were discussing. In the second klippy.log, there are none.

In the second klippy.log there are a number of [bed mesh,,,] statements that are not present in the first.

I can go on but it’s just going to piss me off even more.

If you actually want help and this is not some perverse form of entertainment for you, then I suggest that you start a new thread in “General Discussion” and follow the guidelines I have set out above to the letter (including providing the information and klippy.log requested) and follow the spirit of the guidelines; that you will make it easy for me or somebody else to help you.

My days of shooting at moving targets from a galloping horse with a blindfold on are over.

18

Just to follow up on what myke said, you don’t appear to have flashed the board properly either. The Octopus Pro v1.1 has the STMH723 processor, but your first log indicates you flashed a binary for the STM32F429 which was used on the v1.0. You can’t mix and match this stuff.

1 Like
19

Myke, I didn’t change any of that stuff so let me upload another after I double check I got it from the same machine. But that board was not the same board! One of the things that bother me is that most of the posts assume a STM723 (IIRC) mcu, and these boards are STM429’s. I just took a 16mm projector lens and rechecked this one to be sure. And just for the hell of it, I opened up another I just got from amazon 3 weeks ago, has a blue label that says its a 1.0.1, has a STM446 on it. The board I took out, presumably because a npn prox switch fed 24 volts blew the probe opto but it wasn’t a pro, and has an STM446 on it. and is labeled on the bottom as a octopus 1.1
printer.cfg (8.8 KB)
I apologize, when I went to repeat the upload, a miss-click got it from a QIDI XMAX-3, not the ender5+ my spastic mouse mistake, its too sensitive.

I thought it was odd as it was about 3x the size of the one I just uploaded. There are obviously many boards sold under the octopus label, so how in hell to I actually get docs for the random damned boards I actually have… There is not an obvious way to discern which is which on the BTT docs pages. My mistake. And my apologies. This is the correct klippy.log. But it is not from he same board as the log for a week+ back was from.

20

You need to pay better attention to detail. You seem to be conflating the Octopus v1.1, Octopus Pro v1.0, and Octopus Pro v1.1. All three are distinctly different boards that use different config files and pin assignments. They also use different MCUs.

Before you do anything else you need to identify which board and chip you have, flash the board with a binary that matches the MCU, and verify that you’re using the config file with pins that match the board.

1 Like