How to Use CAN Toolhead Boards Connected Directly to Octopus / Octopus Pro on CanBoot

[michaelmacintyre]

16 hours ago, dos said:

thanks for the reply @FRZ. i did get the octopus working via its own can interface and the ebb36 on the u2c (so can0 & can1). not the best way and could never get the octopus working via the "usb" ports on the u2c. if you have any help on that bit it would be greatly appreciated. i have no issues flashing the cards, i can just never see the octopus via the usb-c/can port through one of the u2c's usb/can ports. i can see the octopus via serial and/or canbus when i build the fw and connect it directly to the pi, but never when its plugged into the u2c. really damn annoying. 

so here is a stupid question maybe others can chime in on. since the ebb's support usb / serial communication (not just power for flashing) and you need to create a custom cable for using the rj11 of the octopus for canbus and add in 24v anyways, why even bother with canbus in the first place? i'm pretty sure most people have extra usb ports on their pi's. why not just use a usb-c cable for the serial connection rather than canbus and feed the 24v in the same way as before and achieve the same result with essentially the same amount of wires? it would be nice if they had terminal connectors for the 24v as to not need the molex plug. this would make doing the above even easier. 

You can plug the EBB into the u2c then connect that to your PI.

Your PI is already setup to the octopus so nothing else to do.

You can do it with or without canboot.

Have a read here if you haven't already.

klipper_canbus/ebb36-42_v1.1.md at main · maz0r/klipper_canbus (github.com)

If you use the v1.2 ignore the scary warning at the top of the page.

with this message you don't have to touch the octopus as your already connected to it. You simply plug the ebb into the u2c then that into the pi via usb.

 

Edited November 15, 2022 by michaelmacintyre

[dos]

17 hours ago, FRZ said:

I guess the first thing is to check that you installed jumpers for the "usb" ports

see page 6

https://github.com/bigtreetech/U2C/blob/master/BIGTREETECH U2C V1.0%26V1.1 User Manual.pdf

Pay very close attention to the firmware comms method and address. (i think it need to be just canbus not bridge im forgetting)

 

i've tried every combination and none of them work. my suspicion is btt/biqu just put their manual / marketing together without actually testing it. since you haven't posted your exact settings, i'm guessing you found something different about your setup otherwise you wouldn't just be guessing at what the problem is. if i had to bet, you probably have the v1.1 of the u2c. the v2.1 has a different chipset thats looking like it broke a lot of functionality. 

 

Quote

Also did you shouldn't reference a serial connection in your printer.cfg (this might be your problem)

it's not. i'm checking everything at the os level. if the os doesn't see it, then neither will klipper. 

[dos]

1 hour ago, michaelmacintyre said:

You can plug the EBB into the u2c then connect that to your PI.

Your PI is already setup to the octopus so nothing else to do.

You can do it with or without canboot.

that's not the point. the point is to run everything via canbus (through the u2c). granted per my last comment, i don't know what real benefit this achieves over running everything via serial / usb directly from the pi. at this point it's the principle and becoming more and more convinced this setup is not even possible. that then leads to the question of false advertising on btt/bigu part. per my other post, i'm guessing they made an untested hardware change that broke this initial configuration and will likely need to provide a fix.

 

Quote

 

Have a read here if you haven't already.

klipper_canbus/ebb36-42_v1.1.md at main · maz0r/klipper_canbus (github.com)

 

if you take a read through that you will see almost all of the u2c related content has been stripped out / scrubbed. this is a pretty good indicator that new new version of the board no longer functions as before. 

 

Quote

 

If you use the v1.2 ignore the scary warning at the top of the page.

with this message you don't have to touch the octopus as your already connected to it. You simply plug the ebb into the u2c then that into the pi via usb.

 

this is all on the test bench and don't even have a heater plugged in so it's not a concern. however the one of the points of this exercise is when new fw does need to be flashed, i don't need to physically touch anything on the printer. 

 

for the record, not blaming anyone on here and appreciate all the suggestions. i'm just providing feedback in case anyone else has this same issues (which seems like a lot do). i was just reaching out to see if ANYONE has this working and looks like no one does. as fun as an experiment this was, i'll probably end up ditching the u2c and just run it from the octopus which is what i wanted to do in the first place until btt/biqu conned me out of another $25 for a board that doesn't even work. my main gripe is the fact that i reached out to btt/biqu directly and was told the ONLY way to get the octopus pro and the ebb36 to work together is via the u2c. 

Edited November 15, 2022 by dos

[michaelmacintyre]

1 hour ago, dos said:

that's not the point. the point is to run everything via canbus (through the u2c). granted per my last comment, i don't know what real benefit this achieves over running everything via serial / usb directly from the pi. at this point it's the principle and becoming more and more convinced this setup is not even possible. that then leads to the question of false advertising on btt/bigu part. per my other post, i'm guessing they made an untested hardware change that broke this initial configuration and will likely need to provide a fix.

if you take a read through that you will see almost all of the u2c related content has been stripped out / scrubbed. this is a pretty good indicator that new new version of the board no longer functions as before. 

this is all on the test bench and don't even have a heater plugged in so it's not a concern. however the one of the points of this exercise is when new fw does need to be flashed, i don't need to physically touch anything on the printer. 

for the record, not blaming anyone on here and appreciate all the suggestions. i'm just providing feedback in case anyone else has this same issues (which seems like a lot do). i was just reaching out to see if ANYONE has this working and looks like no one does. as fun as an experiment this was, i'll probably end up ditching the u2c and just run it from the octopus which is what i wanted to do in the first place until btt/biqu conned me out of another $25 for a board that doesn't even work. my main gripe is the fact that i reached out to btt/biqu directly and was told the ONLY way to get the octopus pro and the ebb36 to work together is via the u2c. 

The reason maz has removed or replaced that content is because he now recommends using Canboot. This would fit one of your reasons which was as you said one of the points of this exercise is when new fw does need to be flashed . If you use Canboot you will be able to leave everything connected and update the firmware on the EBB. 

I use the V1.2 board with the latest u2c board with it and its a really simple setup.

you setup the pi for canbus/canboot then do nothing with the u2c other than plugging it in and do a one time flash on the EBB over usb. future updates will be done via canbus.

[FRZ]

5 hours ago, dos said:

that's not the point. the point is to run everything via canbus (through the u2c). granted per my last comment, i don't know what real benefit this achieves over running everything via serial / usb directly from the pi. at this point it's the principle and becoming more and more convinced this setup is not even possible. that then leads to the question of false advertising on btt/bigu part. per my other post, i'm guessing they made an untested hardware change that broke this initial configuration and will likely need to provide a fix.

if you take a read through that you will see almost all of the u2c related content has been stripped out / scrubbed. this is a pretty good indicator that new new version of the board no longer functions as before. 

this is all on the test bench and don't even have a heater plugged in so it's not a concern. however the one of the points of this exercise is when new fw does need to be flashed, i don't need to physically touch anything on the printer. 

for the record, not blaming anyone on here and appreciate all the suggestions. i'm just providing feedback in case anyone else has this same issues (which seems like a lot do). i was just reaching out to see if ANYONE has this working and looks like no one does. as fun as an experiment this was, i'll probably end up ditching the u2c and just run it from the octopus which is what i wanted to do in the first place until btt/biqu conned me out of another $25 for a board that doesn't even work. my main gripe is the fact that i reached out to btt/biqu directly and was told the ONLY way to get the octopus pro and the ebb36 to work together is via the u2c. 

can you post the MCU section of your printer.cfg?

I defiantly had my u2c working as BTT suggests, just hated it and ditched it as it just adds another later of hardware. 

it hard to know why yours didnt work.. without firmware settings you used for both cards and printer.cfg. I was just pointing to some common issues. 

[dos]

1 hour ago, FRZ said:

can you post the MCU section of your printer.cfg?

again, i don't have it added to the printer.cfg because the os never sees it so there is nothing to add. to expound on that, to add it to the printer.cfg file you need to know the uuid of the device. you find that by doing a canbus query. when i do no id for the octopus is ever returned. i get the the uuid for the ebb36 but not the octopus. 

when you created the klipper firmware for the octopus, what exact settings did you use? i'm happy to create another bin file and flash it and show you the results. again, i went through all of the canbus options and none of then worked. 

[dos]

4 hours ago, michaelmacintyre said:

The reason maz has removed or replaced that content is because he now recommends using Canboot. This would fit one of your reasons which was as you said one of the points of this exercise is when new fw does need to be flashed . If you use Canboot you will be able to leave everything connected and update the firmware on the EBB. 

I use the V1.2 board with the latest u2c board with it and its a really simple setup.

you setup the pi for canbus/canboot then do nothing with the u2c other than plugging it in and do a one time flash on the EBB over usb. future updates will be done via canbus.

agreed, to a point. i could never flash the ebb36 klipper firmware through the u2c successfully. if i flashed it manually or using the octopus as a canbus bridge i never had any issues, but for some unknown reason when i would try and do a canflash through the u2c, it would get about 50% through and then would throw a timeout error. 

 

what revision of the u2c do you have? 

 

the problem with the octopus canbus bridge route, is if i want to flash newer firmware onto the octopus via the canboot process the canbus relies on the klipper firmware to be up to create the canbus bridge. that whole process breaks because when you try and flash the new firmware it kicks the octopus to canboot which doesn't support a canbus usb bridge setup. having the u2c in the mix in theory would eliminate / decouple the octopus from being "the" canbus, to just being "on" the canbus. 

[michaelmacintyre]

1 hour ago, dos said:

agreed, to a point. i could never flash the ebb36 klipper firmware through the u2c successfully. if i flashed it manually or using the octopus as a canbus bridge i never had any issues, but for some unknown reason when i would try and do a canflash through the u2c, it would get about 50% through and then would throw a timeout error. 

what revision of the u2c do you have? 

the problem with the octopus canbus bridge route, is if i want to flash newer firmware onto the octopus via the canboot process the canbus relies on the klipper firmware to be up to create the canbus bridge. that whole process breaks because when you try and flash the new firmware it kicks the octopus to canboot which doesn't support a canbus usb bridge setup. having the u2c in the mix in theory would eliminate / decouple the octopus from being "the" canbus, to just being "on" the canbus. 

unless you have already flashed it with canboot you have to remove the EBB from the U2c and plug it into the Pi via usb then flash it. I have a mix of different ones on my printers but the latest one i added was two weeks ago from the BTT website so i assume it's the latest one. To be honest I would doubt the version of it has any relevance on the issues your having. they are just plug and go devices for the most part. As mentioned at the beginning of this message to get you started you have to do the first flash using usb but if you load Canboot onto it the Maz describes it after that you can flash it over the U2c i.e over canbus.

Can I ask what country are you in? Just trying to work out if we can initiate a call or something and I can try and help you.

[dos]

2 hours ago, michaelmacintyre said:

unless you have already flashed it with canboot you have to remove the EBB from the U2c and plug it into the Pi via usb then flash it. I have a mix of different ones on my printers but the latest one i added was two weeks ago from the BTT website so i assume it's the latest one. To be honest I would doubt the version of it has any relevance on the issues your having. they are just plug and go devices for the most part. As mentioned at the beginning of this message to get you started you have to do the first flash using usb but if you load Canboot onto it the Maz describes it after that you can flash it over the U2c i.e over canbus.

Can I ask what country are you in? Just trying to work out if we can initiate a call or something and I can try and help you.

the different versions of the u2c have different controllers with different firmware. as i mentioned before flashing klipper to the ebb through the u2c via canbus just doesn't work. here is the output of a completely fresh install of everything just to prove my point. 

 

pi@raspberrypi:~/CanBoot/scripts $ sudo python3 flash_can.py -q
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 0a06a9f1c20f, Application: CanBoot
Query Complete

here you can see the ebb36 being detected through the u2c (note the lack of octopus plugged into the same device)

 

pi@raspberrypi:~/CanBoot/scripts $ sudo python3 flash_can.py -f ~/ebb36_klipper_can.bin -u 0a06a9f1c20f
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 0a06a9f1c20f, Application: CanBoot
Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8002000
MCU type: stm32g0b1xx
Verifying canbus connection
Flashing '/home/pi/ebb36_klipper_can.bin'...

[##ERROR:root:Can Read Error <--- (starts flashing and fails at various point in time during the progress)

here you can see again it finds the ebb36, recognizes the mcu and opens a canbus connection and starts starts flashing the klipper fw as shown by the "[##..." progress and then errors out with the following messages...

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Flash Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 609, in main
    loop.run_until_complete(sock.run(intf, uuid, fpath))
  File "/usr/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
    return future.result()
  File "flash_can.py", line 475, in run
    await flasher.finish()
  File "flash_can.py", line 265, in finish
    await self.send_command("COMPLETE")
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [COMPLETE] to Can Device

this happens 100% of the time when using the u2c. if i do the exact same steps but using the octopus as a canbus bridge and connect the ebb36 directly to the octopus, this process works 100% of the time. so clearly it's an issue with the u2c in the mix. for kicks / aggravations i picked up a canhat just to see what happens.

i  can assure you, i am doing everything "technically" correct, the devices in question however do not. despite all the above, it still doesn't answer the question as to why the octopus isn't being detected on the canbus of the u2c. i think my next step is to mangle up a usb cable an splice it directly into the octopus's can port and see how that goes. 

[michaelmacintyre]

8 hours ago, dos said:

the different versions of the u2c have different controllers with different firmware. as i mentioned before flashing klipper to the ebb through the u2c via canbus just doesn't work. here is the output of a completely fresh install of everything just to prove my point. 

pi@raspberrypi:~/CanBoot/scripts $ sudo python3 flash_can.py -q
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 0a06a9f1c20f, Application: CanBoot
Query Complete

here you can see the ebb36 being detected through the u2c (note the lack of octopus plugged into the same device)

pi@raspberrypi:~/CanBoot/scripts $ sudo python3 flash_can.py -f ~/ebb36_klipper_can.bin -u 0a06a9f1c20f
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 0a06a9f1c20f, Application: CanBoot
Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8002000
MCU type: stm32g0b1xx
Verifying canbus connection
Flashing '/home/pi/ebb36_klipper_can.bin'...

[##ERROR:root:Can Read Error <--- (starts flashing and fails at various point in time during the progress)

here you can see again it finds the ebb36, recognizes the mcu and opens a canbus connection and starts starts flashing the klipper fw as shown by the "[##..." progress and then errors out with the following messages...

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
ERROR:root:Can Flash Error
Traceback (most recent call last):
  File "flash_can.py", line 469, in run
    await flasher.send_file()
  File "flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 609, in main
    loop.run_until_complete(sock.run(intf, uuid, fpath))
  File "/usr/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
    return future.result()
  File "flash_can.py", line 475, in run
    await flasher.finish()
  File "flash_can.py", line 265, in finish
    await self.send_command("COMPLETE")
  File "flash_can.py", line 187, in send_command
    % (cmdname))
FlashCanError: Error sending command [COMPLETE] to Can Device

this happens 100% of the time when using the u2c. if i do the exact same steps but using the octopus as a canbus bridge and connect the ebb36 directly to the octopus, this process works 100% of the time. so clearly it's an issue with the u2c in the mix. for kicks / aggravations i picked up a canhat just to see what happens.

i  can assure you, i am doing everything "technically" correct, the devices in question however do not. despite all the above, it still doesn't answer the question as to why the octopus isn't being detected on the canbus of the u2c. i think my next step is to mangle up a usb cable an splice it directly into the octopus's can port and see how that goes. 

Have you asked any of this over at Discord via the https://discordapp.com/channels/460117602945990666/1000794039832035530

[skl]

I would like to follow the guide in this post, but the instructions are not available anymore. Can somebody please provide a new link to the pdf?

[michaelmacintyre]

U2C/BIGTREETECH U2C V1.0&V1.1 User Manual.pdf at master · bigtreetech/U2C (github.com)

I just clicked this and it opened fine.

[smirk]

Worked for me, but just in case here's the file

BIGTREETECH U2C V1.0&V1.1 User Manual.pdf

[JGD13]

hi i have followed the guide upto page 20 but when i went to test can0 it wasnt there and the pi would not detect the octopus board.

went back and started at flashing canboot and now when i try to flash klipper i get this.

Quote

 

pi@mainsailos:~/CanBoot/scripts $ ls /dev/serial/by-id/*
/dev/serial/by-id/usb-CanBoot_stm32f446xx_330012000E5053424E363620-if00
pi@mainsailos:~/CanBoot/scripts $ python3 flash_can.py -f ~/klipper/out/klipper.bin -d /dev/serial/by-id/usb-CanBoot_stm32f446xx_330012000E5053424E363620-if00
ERROR:root:Can Flash Error
Traceback (most recent call last):
  File "/home/pi/.local/lib/python3.7/site-packages/serial/serialposix.py", line 385, in _reconfigure_port
    fcntl.flock(self.fd, fcntl.LOCK_EX | fcntl.LOCK_NB)
BlockingIOError: [Errno 11] Resource temporarily unavailable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 535, in run
    serial_dev.open()
  File "/home/pi/.local/lib/python3.7/site-packages/serial/serialposix.py", line 332, in open
    self._reconfigure_port(force_update=True)
  File "/home/pi/.local/lib/python3.7/site-packages/serial/serialposix.py", line 387, in _reconfigure_port
    raise SerialException(msg.errno, "Could not exclusively lock port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 11] Could not exclusively lock port /dev/serial/by-id/usb-CanBoot_stm32f446xx_330012000E5053424E363620-if00: [Errno 11] Resource temporarily unavailable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "flash_can.py", line 616, in main
    loop.run_until_complete(sock.run(args.device, args.baud, fpath))
  File "/usr/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
    return future.result()
  File "flash_can.py", line 537, in run
    raise FlashCanError("Unable to open serial port: %s" % (e,))
FlashCanError: Unable to open serial port: [Errno 11] Could not exclusively lock port /dev/serial/by-id/usb-CanBoot_stm32f446xx_330012000E5053424E363620-if00: [Errno 11] Resource temporarily unavailable
pi@mainsailos:~/CanBoot/scripts $

 

 

any ideas?
 

 

[michaelmacintyre]

Sorry this is the first I've been able to get back to here.

Did you manage to get sorted or are you still having problems?

[Thebigm93]

hello when i try and run the ls /dev/serial/by-id/* i get ls: cannot access '/dev/serial/by-id/*': No such file or directory
i have follow the guide several times and still this happens i have a pro 429

[JGD13]

17 hours ago, michaelmacintyre said:

Sorry this is the first I've been able to get back to here.

Did you manage to get sorted or are you still having problems?

yes i sorted it thanks had to use the reset button on the board not just power cycle 

[michaelmacintyre]

well done Glad your sorted.

[michaelmacintyre]

13 hours ago, Thebigm93 said:

hello when i try and run the ls /dev/serial/by-id/* i get ls: cannot access '/dev/serial/by-id/*': No such file or directory
i have follow the guide several times and still this happens i have a pro 429

did you get this sorted

[Thebigm93]

No i haven't figured it out

[michaelmacintyre]

On 12/3/2022 at 4:36 PM, Thebigm93 said:

No i haven't figured it out

Sorry for the late response but i've been i'll.

 

if you are still unable to get the command to run i would firstly start with a known good usb cable.

I take it this is right at the beginning when you first plug in via usb?

Also make sure if it's the big tree tech board that you connect the jumper for usb power.

[Pradit]

A silly question here.

Where do you connect the power to ebb36 from?

This HE0?

Or directly from 24v psu?

 

[michaelmacintyre]

4 minutes ago, Pradit said:

A silly question here.

Where do you connect the power to ebb36 from?

This HE0?

Or directly from 24v psu?

your power connector on the ebb board has a 24v power already and the HE0 will no longer be used. The heater on your toolhead will be powered by the ebb itself without the need for the heater port on the mcu.

Sorry if you meant where do you get 24v for the power connector from it needs to be something that's always on before klipper starts i.e power supply or some fused 24v fitting.

Edited December 5, 2022 by michaelmacintyre

[Thebigm93]

On 11/30/2022 at 12:46 PM, michaelmacintyre said:

did you get this sorted

 

9 hours ago, michaelmacintyre said:

Sorry for the late response but i've been i'll.

if you are still unable to get the command to run i would firstly start with a known good usb cable.

I take it this is right at the beginning when you first plug in via usb?

Also make sure if it's the big tree tech board that you connect the jumper for usb power.

which jumper is that cause on the voron documentation it says to remove the usb jumper

[michaelmacintyre]

1 hour ago, Thebigm93 said:

which jumper is that cause on the voron documentation it says to remove the usb jumper

Can I just verify that it's a Canbus board your trying to setup?

If it's jst a normal wired toolhead board it's different to setup.

I have attached a picture of a EBB36 can board with the usb jumper next to the usb port.