This board is EXACTLY what I needed, thanks a lot for bringing this to our attention Modbot! As someone who's left a hypercube on standby for a year for the shear laziness and lack of time to do the toolhead wiring, this is just what I was looking for! Coming pre-flashed is such a nice touch! I wonder if it'll work with my manta and CB1
This is a great video on Nitehawk... really well done ! I'm really happy how well Nitehawk is working out , Nitehawk36 is going to be awesome when it's available
Another question- when setting up sensor less homing with the LDO Nitehawk SB what endstop pin is used for the diag? The original or the update mapping of "nhk:gpio13" as mention in the EricZimmerman git example?
I'm planning a 6 heads tool changer, and already testing canbus connectivity using two canbus boards. However this turned out to be pretty hard to setup, once done it seems to work fine. Now I see this USB type.. Looks way easier to setup, BUT: - Does it work through a USB hub, since I have 6 toolheads? - The failed connection errors was exactly what I was worried about with USB.. Some people told me 'USB is far more reliable than canbus' but this proves thatit is not that reliable.. I don't know how to proceed by build yet (still planning phase) .. Any suggstions on both points above?
Perfect timing. Just yesterday I ran across the Nitehawk and was hoping to see review/setup video on it. I plan to use it on a Zero G/Ender5+ upgrade I started this week. I may go this route though I could go with a regular CAN if it's less buggy. I'm not afraid of the setup of a CAN board, but if a bug-free USB setup saves a bunch of time, I'm into that. Who wouldn't be? Thanks
I've had so much trouble with the dwc USB stack on the pi3 and older. Even without any high speed devices, the driver tends to lock up the hardware when handling a large number of transactions concurrently. In many cases, it took a hw power cycle to clear
I got the same communication error while homing for a Canbus setup (BTT EBB36) and for me it stemmed from a bad cable connection to the board. I mostly noticed it when the Canbus cable started to bend during the homing sequence and I fixed it by re-crimping the cable connection and keeping that Canbus cable extending from the toolhead fixed upright (preventing any bending around the cables around the molex connector). I'm using a Raspberry Pi 5 along with an Octopus Pro controller board.
Great video, to the point and clear. Sadly my Nitehawk36 was a dud, could not be detected as an usb device. Had to take the soft recal from LDO, in about 2 month I'll get a new one. Meanwhile I'm going for the EBB36.
@@__zackm yeah. As much as I'd like to reserve judgment, I'm disappointed that so few 3d printing channels can resist the temptation to shill as they grow larger
Everyone who is running USB on EBB must have watched this video. Because I have only ever seen one other person run it using a 3rd party upgrade kit: lab4450.com/product/ebb36-can-to-usb-upgrade-kit/ I looked quite a while ago at what it would take to run over USB and couldnt figure out how to supply both the needed power and data over USB. It seems like the solution is to run a separate set of cables for power which isn't nearly as elegant of solution. If BTT had released a cleaner way of doing it then there would be a lot more people running it. I believe they are working on a USB specific board that will be similar in how it functions to Nitehawk.
@@ModBotArmy That's a fair point. You did mention that the adaptor board which combines USB and power into one cable is "where the magic happens." But although it is "one nice cable," it does have 3 wires. This would not be dissimilar to a USB cable + power and ground wires using the EBB, at least when considering the overall thickness of the combined wires. In other words, when you combine USB, pwr, and gnd in a sheath, I don't really see how the Nighthawk adaptor board offers any advantage. I guess I don't see how it's a much less elegant solution than having a breakout board in the back of the machine. There is no appreciable decrease in complexity, weight, or aesthetics with the LDO solution.
@@ModBotArmy It's an MCU like any other MCU. How you get power to it is up to you. Running a 24v connection along side the USB isn't exactly complex, but if absolute elegance is the goal, then breaking out a couple USB pins isn't some herculean task. The reality is canbus became a very buzzy concept within the space and everyone jumped on board. People weren't doing it because it was superior or more elegant, they were doing it because that's what they saw other people doing on youtube. USB has always been available and viable. I'm not sure why you're so adamant on rejecting the reality that so many people in the comments have described.
3 หลายเดือนก่อน
What are the umbilical “attachments” you are using? Basically the stuff the cable comes into both in the toolhead and back of the printer.
Having to start using sensorless homing has stopped me from installing some of the mods like this that I've already bought. Is it necessary to remove the cable chains if you go umbilical, or would it merely look silly to have both?
I actually just set up my Nitehawk-sb the other day on my 2.4. I have not seen any of the timeout issues that you have been experiencing, but I also run a Pi 4, and I only have a 1080p webcam. If you are upgrading your Pi, plug your webcam and your Nitehawk into two separate USB controllers (ie. webcam in USB3 port, NH in USB2 port). This way you can be certain that your webcam and NH will not be competing for USB bandwidth. Although, I suspect your timeout issues come from the fact that running your 4k webcam over USB2 is eating the majority of the bandwidth available to the USB controller. If you can reduce your resolution or the frame rate of your webcam, it may help to alleviate your connectivity issues until you can upgrade your Pi.
Unless you add it yourself, I'm not aware of any computer that ships with more than one USB2 Host Controller. Let alone an SBC like the Pi. As far as I'm aware, USB2 and USB3 are actually incompatible, and run over separate wires inside the connector. So a USB2 connection running through a USB3 port will be connected to the same Host Controller anyway. (I forget where, but I remember reading something about someone who separated the USB2 and USB3 connections, creating a Pi4 with 7 useable onboard USB ports, even if some where exclusive to a version of USB.)
I curious why you didn't want to use the endstop port on the board? According to the pinout there is a port for both X and Y. 05:11 GPIO 13 and GPIO12. Sensorless homing is cool but defeats the theme of simplifying things, and is not as precise as mechanical endstops. Also the option to use USB/serial connection is on most of the canbus enabled boards. Its interesting to see that LDO did it like this. It wouldn't have taken much to have a canbus transceiver on it too, although there are already pretty solid options available in that config.
Add debug mode and extra logging. The additional time logging will slow down the system and won’t fuck up. Had a similar issue using a USB expansion board for my ERCF.
Great video. I got the LDO nitehawk and encountered all the issues you mentioned hardware setup. Further, I am not sure if your issues with the MCU disconnected could be related to overloading on the pi as I am running a pi4 with 8gb RAM and I get the same random MCU disconnect and I still have not found the reason behind as it is very random. It can as soon as few minutes or it can be a few hours running a long print. Hope there is a solution to this soon beside the MCU disconnect issues, the LDO NiteHawk is a fanstistic board.
I've had the exact same issues with USB as you are describing, albeit I was running a Pi4 with a 1080p frame camera and 4k nozzle camera @ 1080p. I was still using CAN for my toolhead board, but it seems the Pi3 and Pi4 both have issues with USB easily getting overwhelmed and causing packet dropouts over CAN. I doubt moving to USB would improve things. Moving to a Pi 5 fixed things for me, although it seems absolute overkill for the actual computation the board is doing while running Klipper.
For your communication issues upgrading to a Pi4 or even Pi5 is a good idea. Klipper is very timing sensitive so any slight delay in message transmission would cause these issues. Also make sure your backup script is not running as a cron job as the git operation while printing can be deadly to your print :)
Pi4 will make a big difference in Performance especially with the camera. I would recommend plugging in the camera to the usb 3 and the mcus including nite hawk to the usb 2 ports. And if still having timeout issues, try lowering your resolution of the camera in crowsnest to 1080,720,or 480
Sounds like you not only need a Pi4 or Pi5 but also to plug the Nitehawk into USB 3.0 plug instead of a normal 2.0. Since your connection to the mainboard can run fine through USB 2.0, that leaves the two 3.0 USB ports open for the Hawk and Camera.
Modbot Thanks for covering this board. I got four of them from KB-3D at MRRF and plan on converting my V2.4s and Tridents from CANBus to these. Regarding weird issues with your Raspberry Pi, try adding an additional 5V power source. If connecting via the GPIO pins, then supply 5V to both 5V pins. This ensures the Pi has enough power (and amperage) when running multiple USB devices.
You need a dedicated PSU for the Pi. I was having similar issues with normal tollhead board and Pi cam. I was powering the Pi from the controller board and every now and then there's was a voltage drop and the Pi will throttle down producing the issues.
Troubleshooting CAN bus is easier than troubleshooting USB. The HAL and packing both on the SBC and MCU side is really sturdy, so you won't need to dive into the packet dumps to search for a missing one. The protocol includes error checking, so you don't really need to worry about retransmission either. The only thing you need to consider are the service on the SBC (not an issue, single config file to edit) and the hardware (which boils down to terminations and good contact). If things go wrong with USB on an SBC, it could be the drivers, the platform-specific microcode, the USB controller, bandwidth issues with a shared port, and so on. Without even talking about the lack of error checking, the much more fragile signal integrity and transmission lenght requirements, etc. It's not really an upgrade in terms of reliability, for sure.
USB 2 has crc and retransmit, supports cable lengths of 5 meters, 480mbit bandwidth oh… and is used to connect every canbus adapter so if there’s an error that’s far more to troubleshoot
@@williamanthony7224 USB is not a true differential signal protocol (it can have dual high signaling states) unlike CAN. 5 meters is the most it can reach, under perfect working conditions: CAN can work for tens of meters. It is not built to work in a noisy environment with EMF sources, like a 3d printer. There are plenty of posts on Klipper forums of poorly insulated USB cables that were causing a disconnection, over a very short length. USB byte retransmitting has a much, much lower threshold than CAN, and no auto bandwidth reduction for reliable connections while transferring. You can also use CAN hat, or an SBC/PC with integrated CAN adapters, if you have issues with your USb controller (i did so in a couple of cases). And all of this without even considering the area network advantage.
I have concerns about running timing-critical printing processes across two separate stacks with their own buffered movement ques.. that seems like a bad idea? CAN made sense when the MCU controlling the CANBUS was also the one stepping all the other axis, but once that is a USB to CANBUS that point suddenly becomes mute, now the USB host has to keep everything together instead of filling a single buffer with commands to eventually perform. Is desync between multiple USB devices with their own buffers not an issue at all then? 🤔
The BTT EBB and Mellow FLY toolhead boards have supported USB for a while and it's the standard way to connect a toolhead board on RatRig. This looks like it's pretty much the same except for the adapter. What am I missing?
RatRig has been brought up a few times in comments. I have built the V-Minion which doesn’t use a toolhead board so I’ve never seen their implementation. I recently got a V-Core 4 pre release in so I’ll have to see if they are using this or not. It isn’t really something I’ve seen discussed or used outside of there.
@@ModBotArmy Up until V-Core 4 they didn't come with toolhead boards by default but RatOS has had support for them for a while and they only officially supported USB and CAN wasn't supported. But still, even without RatOS, you could have used the EBB boards via USB since the start. It's the same as adding an additional MCU. And using multiple MCUs is a standard feature in Klipper.
Im in the process of adding a CPAP PC fan and I have the nitehawk already installed in the cable chains. I plan on moving the cable to the top back of the enclosure where the CPAP would be, I wish the Bord was CAN as it would allow me to have a CAN middleware for the CPAP too. Oh well, more cables to sort out later.
For the XY cable on my Trident I ended up removing the pins, then braiding the wires and putting the connector back on. I just let the XY cable hang below.
Great video! I would love to one day see a single motion rated USB-C cable connecting to my toolhead. “The most recent update, USB PD Revision 3.1, was announced in 2021 and allows up to 240W of power to be delivered over a USB Type-C cable and connector. Before this update, USB PD was limited to 100W.”
The latest usbc standard is 240w, but still 5a limited, so that means 48v. Unless your entire toolhead needs less than 5a, a pure usbc connection is out of the question
@@m_IDEX most are fine, but some hotends like a rapido are too much for them. Also depends on the extruder and other components used on the toolhead lile what fans and extruder motor
Had the exact same problem on a Pi4b with NightHawk, Beacon, Webcam, and Klipperscreen. Would see the CPU usage on the pi randomly spiking up to 100% with the occasional comm error. I could alleviate it by stopping Crowsnest or Klipperscreen. But that was just a work around. Fully solved it by moving to a Pi5 - plus added a NVME hat to the pi. Now it runs butter smooth and with the SSD, it boots to fully usable in around 10 seconds.
Swaping from Pi 3b+ to Pi 4b fixed my communication errors on two printers running canbus. at least a pi 4 is a must for canbus from my experience. Also make sure to set communication to 1 million!
I ended up putting a dedicated Pi in my Voron just for cameras. It removes the possibility of issues like USB bus contention, CPU load (even though NIC should handle that), and I can reboot or modify Klipper and the camera software without worrying about the other.
Are you having the cameras' Pi stream over the network to the Crowsnest instance in the Mainsail/Fluid GUI running on the Klipper? Curious as to how you set this up because I might do something similar but still want the webcam feeds on within the GUI
As someone who has worked, as an engineer, in the automotive and amusement ride industries, CanBUS is second nature to me. I however get that the 50 year old protocol can seem like black magic :)
I really need the one for orbiter this is awesome considering the only other options involved an adapter to mount can versions from btt. Can’t wait to grab one!
That is so wonderful that you shared that with us , I'm certain there are thousands of us that feel the need to bow down to you for knowing about this for so long .
@@alsson3137 I am not sure where you are coming from. I am agreeing that the protocol can be confusing, explaining why it is convoluted, and expressing that I am glad there is another option.
As someone who also spent years in the automotive industry, I was surprised to see how klipper uses CAN. It’s basically just using CAN as a transport for serial data, spreading data across multiple packets. I think it was using timing rather than any kind of full handshake. I really wish the devs had designed a better protocol. I’d love to see something with messages designated for different sensors, much closer to how it works in most vehicles.
IMHO, Klippers biggest problem when running on a System with a lot of stuff is the ordeal you're facing when an Update throws something out of sync which happened to me when I _had_ to update the ERCF and doing that brought its MCU Version out of sync with the rest of the System which then all had to be Updated too requiring a Firmware Update for the MCU. Royal fuckin' pain in the ass 😑 Kinda swore to myself I'd never be making another change to the System but alas that's easier said than done with me soon installing an entirely new Board ( BTT Kraken ), a MMB for the ERCF, and my own take on a CPAP /sigh
I believe rpi3 has a single USB2.0 bus which is shared with the Ethernet, while on the rpi4 there are separate busses for the USB2 and USB3 ports, and those are separate from the Ethernet. "lsusb -t" to see what I mean. This can be an issue with poorly-implemented webcams, they can just starve out the other USB2 devices. I've been considering upgrading a couple rpi3 to rpi4 simply because of the faster wifi. 2.4Ghz is fine, mostly, but periodically I'll have a big gcode file which just takes awhile to upload.
I had (/have) the timeout while homing error... After a while I realised that every time it happened the pi CPU would be hanging around 30% load constantly, even with the printer doing nothing. If I restart the Crowsnest service the CPU returns to 3% or so at idle and the problem goes away entirely (this works 100% of the time). If I reboot the crowsnest service immediately after I start the printer up, I never see the problem. I haven't had time to dig further into the reasoning but perhaps give it a try and see if it fixes things for you too
Mellow sht36 pro is the way to go so many high tier components to to mention 5160 driver for your extruder right on the board. Trouble shooting can is far easier than usb.
For anyone struggling to find the device in the USB list try changing the USB port the (in my case the octopus board) uses to another port for some reason once I moved that the toolhead showed up
The CAN setup has always seemed a bit like black magic in terms of getting it all talking to each other. This appears a lot more user-friendly to get going. I'm looking forward to seeing how reliably it performs long-term.
Looking at the schematics its directly wired through a resistor to a GPIO pin just like the FS and both aren't referred to in the config. So I would guess "supplementary". Both can probably being used as whatever you need.
I think people are neglecting a few things. Sure you can run an ebb36 board via usb AND power cables. No worries. Now go plug a beacon into it, Oh, you cant? So theres another cable you need to run back to your printer. Same with cartographer or any other device that uses USB. YOU cannot expand an ebb36's usb capabilities. LDO NH36 you can.
@ModBotArmy - Hey Daniel, just thoiught I'd throw my 2cents in here for ya! I switched out my pi4 for a 3A+ in a pinch and it CANNOT handle printing and 4k at once, I would get failed prints dude to overlaod, mostly of memory. Adding the NightHawk to the USB mix seems like a questionable mix. Try unplugging the cam and see how she goes! (I have an LDO 350 kit myself) 🍻
In the LDO sample config it has a section below. I do not have that in my current config, is that something that needs to be added or what was it controlled by with the standard SB set up. Sorry I am a complete klipper noob so not sure what I am talking about. "##################################################################### # Lights ##################################################################### ## Stealthburner Headlights [neopixel headlight] pin: nhk:gpio7 ## PCB Activity Light [output_pin act_led] pin: !nhk:gpio8"
This is true but from what I was shared it’s not quite plug and play. It looks like it requires cutting up a usb cable and needing a usb adapter board. I’m glad it exists as an option but it very much so seems like it is a hack and not intentional.
@@ModBotArmy I believe that's only if you want to use the CAN bus cable for unified power and USB data. If you're okay with another cable running between the electronics bay and the toolhead, you could simply run only power over the supplied CAN bus cable, and run another cable for the USB, or run your own power wires and then a cable for USB.
I don't know if it's worth calling it an "upgrade". It's a change. You may have reduced the number of cables but you've increased the "complication" of the entire printer, increasing the risk of further errors. Some solutions definitely improve the quality of life but is CAN or USB toolhead such a solution? I have mixed feelings
I've been running canbus (ebb36) for 2 years and my opinion is toolhead board? yes active circuitry toolhead boards? nah. just run umbilical with all the cables. you'll be happier in the long run.
Hehe the only reason I was excited to see this was because I get MCU timeout errors running canbus. But seems USB toolhead boards also suffer the same problem. Would be nice to see if a better pi solves it. I'm using a pi3a+ which might not be powerful enough as it runs into mcu timeout errors.
this seems like a silly intermediate solution to me, usb pd 3.1 allows for 48v, you could almost halv the heat-up time using the same heater and use half as much wire...
But still only 5A. If you take a 24v 40w heater and send 48v through it, it becomes a 160w one, which draws then 3,3A. 160w for a 20mm cartridge is a bit spicy if you ask me. Nevertheless i understand what are you trying to achieve, but i prefer good old molex plugs. Can be depinned, are cheap and have the locking lever, so no accidental pull out is possible. For the same reasons im also not a fan of these xt30+2 connectors
@@kilianlindlbauer8277 the 160w is an important aspect, I think the not locking usb-c is deceiving since it has a retention mechanism(so it can't gradually slide out) which XT-connectors do not
wonder if anyone has tried to use the nitehawk with a cnc tap? The probe pin is 24 volt, and I am running into issue figuring where to plug the tap into...
This is to fix your communication error during homing credit to Boxxy and TeachingTech - Communication time out during homing fix Changed TRSYNC_TIMEOUT value in “/home/pi/klipper/klippy/mcu.py” file from 0.025 to 0.050, i.e. was “TRSYNC_TIMEOUT = 0.025”, and became “TRSYNC_TIMEOUT = 0.050”, and the error “Communication timeout during homing probe” disappeared
Replacing the complex CAN bus protocol with the complex USB protocol is a bit of a sideways step. USB is good for bulk data transfers but is notoriously slow as a bus where you have to react to changes. The protocol is limited by the minimum message/response time for a packet and retries if theres a packet formation error - not good for real time responses. If youre going to go down that path, ditch both CAN and USB and go wireless. Probably more reliable with no cables (that "best part is no part quote") .
I love ALL my Endstops and ALL my Cables! Because bought too much....and 50 is not 5 Parts. That was a surprise!!! MUHAHAHAHAHAHA Stay safe, awesome, healthy, share Knowledge and Greetings goes out to all of you🤗🤗🤗
you should just jump to the raspberry pi 5... I had ton of issues with canbus, usb canbridge, webcams etc using pi 3 and pi 4s.... tons of hours of torubleshooting and frustration. On one hand the pi 3 doesnt handle the bandwidth properly. on the other the pi 4 doesn't see the devices with lsusb command, or they drop out over time
I'm not super surprised that the rpi 3 is getting overloaded with a 4k camera plus a usb toolhead.
I fail to see why a 3D printer needs a camera of that resolution in the first place..
@@TS_Mind_Swept I'm sorry to hear that. Admitting that you have a problem is the first step to getting help.
@@bryansiepert9222 hello, irrelevant reply, nice to meet you
Last week, my coworker recommended that I check out your channel. It turns out we both knew about your channel 👍
OMG, you really did get right into it without further ado! Bravo!
This board is EXACTLY what I needed, thanks a lot for bringing this to our attention Modbot! As someone who's left a hypercube on standby for a year for the shear laziness and lack of time to do the toolhead wiring, this is just what I was looking for! Coming pre-flashed is such a nice touch! I wonder if it'll work with my manta and CB1
it'll work with the CB1. It's the same way it communicates to your manta board.
This is amazing and well-timed. I broke a wire in my Voron cable chain and have been putting off the 'fix' and upgrade to a CAN toolhead.
actually you can also use the bigtreetech EBB36 (probably also the EBB42) over usb, you just need to flash klipper and of course add a 24v power cable
The data pins are even exposed, so no need for a usb cable to the toolhead, a short section of it from the pins to the port is enough
1:09 Nice Omnifixo Cameo! Such amazing tools.
This is a great video on Nitehawk... really well done ! I'm really happy how well Nitehawk is working out , Nitehawk36 is going to be awesome when it's available
The man himself! I am looking forward to playing around with it. Being able to set voltage and usb connection for something like beacon is sweet! 😊🔥
You don't have to keep doing the thumbs up swoosh if you don't want to.
I'll still like your videos if you don't 👍
139k Subs, 150 likes, the math would disagree with you :)
I do the swoosh with him
You must be a miserable little dude.
Nice work !
Another question- when setting up sensor less homing with the LDO Nitehawk SB what endstop pin is used for the diag? The original or the update mapping of "nhk:gpio13" as mention in the EricZimmerman git example?
I installed this on my trident and its an amazing upgrade!
I'm planning a 6 heads tool changer, and already testing canbus connectivity using two canbus boards. However this turned out to be pretty hard to setup, once done it seems to work fine. Now I see this USB type.. Looks way easier to setup, BUT:
- Does it work through a USB hub, since I have 6 toolheads?
- The failed connection errors was exactly what I was worried about with USB.. Some people told me 'USB is far more reliable than canbus' but this proves thatit is not that reliable..
I don't know how to proceed by build yet (still planning phase) .. Any suggstions on both points above?
Perfect timing. Just yesterday I ran across the Nitehawk and was hoping to see review/setup video on it. I plan to use it on a Zero G/Ender5+ upgrade I started this week. I may go this route though I could go with a regular CAN if it's less buggy. I'm not afraid of the setup of a CAN board, but if a bug-free USB setup saves a bunch of time, I'm into that. Who wouldn't be?
Thanks
I've had so much trouble with the dwc USB stack on the pi3 and older. Even without any high speed devices, the driver tends to lock up the hardware when handling a large number of transactions concurrently.
In many cases, it took a hw power cycle to clear
I got the same communication error while homing for a Canbus setup (BTT EBB36) and for me it stemmed from a bad cable connection to the board.
I mostly noticed it when the Canbus cable started to bend during the homing sequence and I fixed it by re-crimping the cable connection and keeping that Canbus cable extending from the toolhead fixed upright (preventing any bending around the cables around the molex connector).
I'm using a Raspberry Pi 5 along with an Octopus Pro controller board.
Great video, to the point and clear. Sadly my Nitehawk36 was a dud, could not be detected as an usb device. Had to take the soft recal from LDO, in about 2 month I'll get a new one. Meanwhile I'm going for the EBB36.
Am I missing something, or have USB tool head boards (e.g. BTT) been around for a while?
I have 6 custom idex printers using 12 EBB 36s all running over USB. So, yeah...Very strange video.
@@__zackm yeah. As much as I'd like to reserve judgment, I'm disappointed that so few 3d printing channels can resist the temptation to shill as they grow larger
Everyone who is running USB on EBB must have watched this video. Because I have only ever seen one other person run it using a 3rd party upgrade kit: lab4450.com/product/ebb36-can-to-usb-upgrade-kit/
I looked quite a while ago at what it would take to run over USB and couldnt figure out how to supply both the needed power and data over USB. It seems like the solution is to run a separate set of cables for power which isn't nearly as elegant of solution. If BTT had released a cleaner way of doing it then there would be a lot more people running it. I believe they are working on a USB specific board that will be similar in how it functions to Nitehawk.
@@ModBotArmy That's a fair point. You did mention that the adaptor board which combines USB and power into one cable is "where the magic happens." But although it is "one nice cable," it does have 3 wires. This would not be dissimilar to a USB cable + power and ground wires using the EBB, at least when considering the overall thickness of the combined wires. In other words, when you combine USB, pwr, and gnd in a sheath, I don't really see how the Nighthawk adaptor board offers any advantage. I guess I don't see how it's a much less elegant solution than having a breakout board in the back of the machine. There is no appreciable decrease in complexity, weight, or aesthetics with the LDO solution.
@@ModBotArmy It's an MCU like any other MCU. How you get power to it is up to you. Running a 24v connection along side the USB isn't exactly complex, but if absolute elegance is the goal, then breaking out a couple USB pins isn't some herculean task.
The reality is canbus became a very buzzy concept within the space and everyone jumped on board. People weren't doing it because it was superior or more elegant, they were doing it because that's what they saw other people doing on youtube. USB has always been available and viable.
I'm not sure why you're so adamant on rejecting the reality that so many people in the comments have described.
What are the umbilical “attachments” you are using? Basically the stuff the cable comes into both in the toolhead and back of the printer.
Thanks for this detailled video! What is the PG7 gland mount mod on the SB you used? Could you provide the source, please? Thanks!
Having to start using sensorless homing has stopped me from installing some of the mods like this that I've already bought.
Is it necessary to remove the cable chains if you go umbilical, or would it merely look silly to have both?
I actually just set up my Nitehawk-sb the other day on my 2.4. I have not seen any of the timeout issues that you have been experiencing, but I also run a Pi 4, and I only have a 1080p webcam. If you are upgrading your Pi, plug your webcam and your Nitehawk into two separate USB controllers (ie. webcam in USB3 port, NH in USB2 port). This way you can be certain that your webcam and NH will not be competing for USB bandwidth.
Although, I suspect your timeout issues come from the fact that running your 4k webcam over USB2 is eating the majority of the bandwidth available to the USB controller. If you can reduce your resolution or the frame rate of your webcam, it may help to alleviate your connectivity issues until you can upgrade your Pi.
Unless you add it yourself, I'm not aware of any computer that ships with more than one USB2 Host Controller. Let alone an SBC like the Pi.
As far as I'm aware, USB2 and USB3 are actually incompatible, and run over separate wires inside the connector. So a USB2 connection running through a USB3 port will be connected to the same Host Controller anyway.
(I forget where, but I remember reading something about someone who separated the USB2 and USB3 connections, creating a Pi4 with 7 useable onboard USB ports, even if some where exclusive to a version of USB.)
I curious why you didn't want to use the endstop port on the board? According to the pinout there is a port for both X and Y. 05:11 GPIO 13 and GPIO12. Sensorless homing is cool but defeats the theme of simplifying things, and is not as precise as mechanical endstops. Also the option to use USB/serial connection is on most of the canbus enabled boards. Its interesting to see that LDO did it like this. It wouldn't have taken much to have a canbus transceiver on it too, although there are already pretty solid options available in that config.
Any information on how you de-pinned the connector?
Was there supposed to be a heatsink for the 2209? If not have you noticed any issues with the temps?
Add debug mode and extra logging. The additional time logging will slow down the system and won’t fuck up.
Had a similar issue using a USB expansion board for my ERCF.
Most of BTT toolhead boards with CAN can work with USB. I use USB board for long time and it is way more stable than CAN BUS connection.
Does the SB version of Nitehawk have the additional USB port onboard to use with Beacon?
awesome... quick question do you have any video tutorial in doing Sensorless Homing?
Very interested in the camera setup you have for the 2.4. Have you got any more information about this setup as I am interested ? Thanks :)
Great video. I got the LDO nitehawk and encountered all the issues you mentioned hardware setup. Further, I am not sure if your issues with the MCU disconnected could be related to overloading on the pi as I am running a pi4 with 8gb RAM and I get the same random MCU disconnect and I still have not found the reason behind as it is very random. It can as soon as few minutes or it can be a few hours running a long print. Hope there is a solution to this soon beside the MCU disconnect issues, the LDO NiteHawk is a fanstistic board.
I've had the exact same issues with USB as you are describing, albeit I was running a Pi4 with a 1080p frame camera and 4k nozzle camera @ 1080p. I was still using CAN for my toolhead board, but it seems the Pi3 and Pi4 both have issues with USB easily getting overwhelmed and causing packet dropouts over CAN. I doubt moving to USB would improve things. Moving to a Pi 5 fixed things for me, although it seems absolute overkill for the actual computation the board is doing while running Klipper.
Well this is definitely more than I'd ever care to bother with, but I'm glad it makes you happy
a fair few CAN boards can also be run as USB driven, I've got that set up in my own scratch built printer.
For your communication issues upgrading to a Pi4 or even Pi5 is a good idea. Klipper is very timing sensitive so any slight delay in message transmission would cause these issues. Also make sure your backup script is not running as a cron job as the git operation while printing can be deadly to your print :)
Pi4 will make a big difference in Performance especially with the camera. I would recommend plugging in the camera to the usb 3 and the mcus including nite hawk to the usb 2 ports. And if still having timeout issues, try lowering your resolution of the camera in crowsnest to 1080,720,or 480
The CAN toolhead boards you showed (EBB36 and EBB42) already support USB
Daniel, one thing is missing in this otherwise very informative video: Did you notice any significant improvement on X and Y max accelerations?
Sounds like you not only need a Pi4 or Pi5 but also to plug the Nitehawk into USB 3.0 plug instead of a normal 2.0. Since your connection to the mainboard can run fine through USB 2.0, that leaves the two 3.0 USB ports open for the Hawk and Camera.
I also don’t get the “finally”.
The EBB36 has a usb-c port and has been available for quite a while now.
Modbot Thanks for covering this board. I got four of them from KB-3D at MRRF and plan on converting my V2.4s and Tridents from CANBus to these. Regarding weird issues with your Raspberry Pi, try adding an additional 5V power source. If connecting via the GPIO pins, then supply 5V to both 5V pins. This ensures the Pi has enough power (and amperage) when running multiple USB devices.
Does the nitehawk cable end go thru the PG7 gland parts you are using without modding the cable?
The cable plug has to be removed/depinned. The cable fits though.
Thanks for the reply - your videos are helpful.
I have been using Bluetooth on a couple of my BIGTREETECH EBB36 boards and it works great.
Wait what?? Bluetooth?? Do you have any more info on this??
You need a dedicated PSU for the Pi. I was having similar issues with normal tollhead board and Pi cam. I was powering the Pi from the controller board and every now and then there's was a voltage drop and the Pi will throttle down producing the issues.
how well does the nighthawk work with multiples? is this a good option for tool changers?
Ok maybe stupid question, why are we switching gears from canbus? Is usb a better solution for some reason, or is canbus bad for some reason?
Troubleshooting CAN bus is easier than troubleshooting USB. The HAL and packing both on the SBC and MCU side is really sturdy, so you won't need to dive into the packet dumps to search for a missing one. The protocol includes error checking, so you don't really need to worry about retransmission either. The only thing you need to consider are the service on the SBC (not an issue, single config file to edit) and the hardware (which boils down to terminations and good contact). If things go wrong with USB on an SBC, it could be the drivers, the platform-specific microcode, the USB controller, bandwidth issues with a shared port, and so on. Without even talking about the lack of error checking, the much more fragile signal integrity and transmission lenght requirements, etc. It's not really an upgrade in terms of reliability, for sure.
USB 2 has crc and retransmit, supports cable lengths of 5 meters, 480mbit bandwidth oh… and is used to connect every canbus adapter so if there’s an error that’s far more to troubleshoot
@@williamanthony7224 USB is not a true differential signal protocol (it can have dual high signaling states) unlike CAN. 5 meters is the most it can reach, under perfect working conditions: CAN can work for tens of meters. It is not built to work in a noisy environment with EMF sources, like a 3d printer. There are plenty of posts on Klipper forums of poorly insulated USB cables that were causing a disconnection, over a very short length. USB byte retransmitting has a much, much lower threshold than CAN, and no auto bandwidth reduction for reliable connections while transferring. You can also use CAN hat, or an SBC/PC with integrated CAN adapters, if you have issues with your USb controller (i did so in a couple of cases). And all of this without even considering the area network advantage.
I have concerns about running timing-critical printing processes across two separate stacks with their own buffered movement ques.. that seems like a bad idea? CAN made sense when the MCU controlling the CANBUS was also the one stepping all the other axis, but once that is a USB to CANBUS that point suddenly becomes mute, now the USB host has to keep everything together instead of filling a single buffer with commands to eventually perform. Is desync between multiple USB devices with their own buffers not an issue at all then? 🤔
The BTT EBB and Mellow FLY toolhead boards have supported USB for a while and it's the standard way to connect a toolhead board on RatRig. This looks like it's pretty much the same except for the adapter. What am I missing?
RatRig has been brought up a few times in comments. I have built the V-Minion which doesn’t use a toolhead board so I’ve never seen their implementation. I recently got a V-Core 4 pre release in so I’ll have to see if they are using this or not. It isn’t really something I’ve seen discussed or used outside of there.
@@ModBotArmy Up until V-Core 4 they didn't come with toolhead boards by default but RatOS has had support for them for a while and they only officially supported USB and CAN wasn't supported. But still, even without RatOS, you could have used the EBB boards via USB since the start. It's the same as adding an additional MCU. And using multiple MCUs is a standard feature in Klipper.
When i get a broken cable in my Trident cable chain, I'll be considering this.
Newbie question: Does the extra weight on the toolhead slow done print speed?
I am assuming if you are already running CanBUS there is no reason to change to USB.
Im in the process of adding a CPAP PC fan and I have the nitehawk already installed in the cable chains.
I plan on moving the cable to the top back of the enclosure where the CPAP would be, I wish the Bord was CAN as it would allow me to have a CAN middleware for the CPAP too.
Oh well, more cables to sort out later.
For the XY cable on my Trident I ended up removing the pins, then braiding the wires and putting the connector back on. I just let the XY cable hang below.
Great video! I would love to one day see a single motion rated USB-C cable connecting to my toolhead.
“The most recent update, USB PD Revision 3.1, was announced in 2021 and allows up to 240W of power to be delivered over a USB Type-C cable and connector. Before this update, USB PD was limited to 100W.”
i think this is how bambulab toolhead works
The latest usbc standard is 240w, but still 5a limited, so that means 48v. Unless your entire toolhead needs less than 5a, a pure usbc connection is out of the question
@@kilianlindlbauer8277 Many hotend heaters are just 30 to 60W. So even a 24V system would be enough. However a 48V toolhead would be very cool.
@@m_IDEX most are fine, but some hotends like a rapido are too much for them. Also depends on the extruder and other components used on the toolhead lile what fans and extruder motor
@@m_IDEX luke's laboratory does make 48v heater cartridges
You could also install a PI2 from btt and show us a video on that installation. Looking forward for the ebb36 version. Great video
Had the exact same problem on a Pi4b with NightHawk, Beacon, Webcam, and Klipperscreen. Would see the CPU usage on the pi randomly spiking up to 100% with the occasional comm error. I could alleviate it by stopping Crowsnest or Klipperscreen. But that was just a work around. Fully solved it by moving to a Pi5 - plus added a NVME hat to the pi. Now it runs butter smooth and with the SSD, it boots to fully usable in around 10 seconds.
Good to know, I have a pi5 I was gifted that I had another project planned for but this may be the perfect use for it now.
Swaping from Pi 3b+ to Pi 4b fixed my communication errors on two printers running canbus. at least a pi 4 is a must for canbus from my experience. Also make sure to set communication to 1 million!
Wasted half my day today trying to get another CAN board working ugh.
I ended up putting a dedicated Pi in my Voron just for cameras. It removes the possibility of issues like USB bus contention, CPU load (even though NIC should handle that), and I can reboot or modify Klipper and the camera software without worrying about the other.
Are you having the cameras' Pi stream over the network to the Crowsnest instance in the Mainsail/Fluid GUI running on the Klipper? Curious as to how you set this up because I might do something similar but still want the webcam feeds on within the GUI
Impatiently waiting for NH36
I really want to get my hands on one
I was just about to get one of these then I saw someone mention the upcoming 36. I'm hoping I don't need to wait more than a week or 2.
I dont get it, USB toolhead where around for years, they could just do CANBUS, too
I got the nitehawk (got it the same day Nero did a video/stream on it) right when it was available for prepurchase and have had 0 issues with my rpi 4
As someone who has worked, as an engineer, in the automotive and amusement ride industries, CanBUS is second nature to me. I however get that the 50 year old protocol can seem like black magic :)
I really need the one for orbiter this is awesome considering the only other options involved an adapter to mount can versions from btt. Can’t wait to grab one!
That is so wonderful that you shared that with us , I'm certain there are thousands of us that feel the need to bow down to you for knowing about this for so long .
@@alsson3137 I am not sure where you are coming from. I am agreeing that the protocol can be confusing, explaining why it is convoluted, and expressing that I am glad there is another option.
As someone who also spent years in the automotive industry, I was surprised to see how klipper uses CAN. It’s basically just using CAN as a transport for serial data, spreading data across multiple packets. I think it was using timing rather than any kind of full handshake. I really wish the devs had designed a better protocol. I’d love to see something with messages designated for different sensors, much closer to how it works in most vehicles.
IMHO, Klippers biggest problem when running on a System with a lot of stuff is the ordeal you're facing when an Update throws something out of sync which happened to me when I _had_ to update the ERCF and doing that brought its MCU Version out of sync with the rest of the System which then all had to be Updated too requiring a Firmware Update for the MCU. Royal fuckin' pain in the ass 😑 Kinda swore to myself I'd never be making another change to the System but alas that's easier said than done with me soon installing an entirely new Board ( BTT Kraken ), a MMB for the ERCF, and my own take on a CPAP /sigh
Well bambu uses a usb c toolhead, is it possible to have a third party one then?
I believe rpi3 has a single USB2.0 bus which is shared with the Ethernet, while on the rpi4 there are separate busses for the USB2 and USB3 ports, and those are separate from the Ethernet. "lsusb -t" to see what I mean. This can be an issue with poorly-implemented webcams, they can just starve out the other USB2 devices.
I've been considering upgrading a couple rpi3 to rpi4 simply because of the faster wifi. 2.4Ghz is fine, mostly, but periodically I'll have a big gcode file which just takes awhile to upload.
I had (/have) the timeout while homing error... After a while I realised that every time it happened the pi CPU would be hanging around 30% load constantly, even with the printer doing nothing. If I restart the Crowsnest service the CPU returns to 3% or so at idle and the problem goes away entirely (this works 100% of the time). If I reboot the crowsnest service immediately after I start the printer up, I never see the problem.
I haven't had time to dig further into the reasoning but perhaps give it a try and see if it fixes things for you too
You wouldn't happen to have the link to the stl files for the cable gland mounts?
Mellow sht36 pro is the way to go so many high tier components to to mention 5160 driver for your extruder right on the board. Trouble shooting can is far easier than usb.
For anyone struggling to find the device in the USB list try changing the USB port the (in my case the octopus board) uses to another port for some reason once I moved that the toolhead showed up
The CAN setup has always seemed a bit like black magic in terms of getting it all talking to each other. This appears a lot more user-friendly to get going. I'm looking forward to seeing how reliably it performs long-term.
Would a canbus tool head cable be compatible with USB?
Iam pretty sure that you can run an ebb42 over usb aswell
Would have been nice if the Nitehawk-SB also had gotten a USB expansion port for a USB probe (like beacon) like the Nitehawk-36 did.
I believe "SU" might be the equivalent of "FU" for filament unload. Similar to the pinout of the orbiter filament sensor.
Looking at the schematics its directly wired through a resistor to a GPIO pin just like the FS and both aren't referred to in the config. So I would guess "supplementary". Both can probably being used as whatever you need.
I think people are neglecting a few things.
Sure you can run an ebb36 board via usb AND power cables. No worries.
Now go plug a beacon into it,
Oh, you cant? So theres another cable you need to run back to your printer.
Same with cartographer or any other device that uses USB.
YOU cannot expand an ebb36's usb capabilities. LDO NH36 you can.
In theory you could use the can version of cartographer, connect it to the can pins of the ebb36 and configure it as can-bridge.
@@Alterproll yep, now tell me how to use beacon 😀
Can is super easy in the duet eco system. A couple of g code commands and some drag and drop files and everything is setup.
I’ve heard it’s great. I need to give Duet a try on a build.
@ModBotArmy - Hey Daniel, just thoiught I'd throw my 2cents in here for ya! I switched out my pi4 for a 3A+ in a pinch and it CANNOT handle printing and 4k at once, I would get failed prints dude to overlaod, mostly of memory. Adding the NightHawk to the USB mix seems like a questionable mix. Try unplugging the cam and see how she goes! (I have an LDO 350 kit myself) 🍻
could you make a seperate video about setting up sensoreless homing?
Mine showed up but did not have a heatsink for the 2209 driver on toolhead PCB. I have a million of them, so no big deal. Just FYI.
Yeah this stood out to me too, I didn't have any spares. Been running the printer without panels for now. Peak nitehawk temp on PLA prints is 55c.
In the LDO sample config it has a section below. I do not have that in my current config, is that something that needs to be added or what was it controlled by with the standard SB set up. Sorry I am a complete klipper noob so not sure what I am talking about.
"#####################################################################
# Lights
#####################################################################
## Stealthburner Headlights
[neopixel headlight]
pin: nhk:gpio7
## PCB Activity Light
[output_pin act_led]
pin: !nhk:gpio8"
USB toolhead boards existed for years. The EBB36 and EBB42 could be run over USB.
This is true but from what I was shared it’s not quite plug and play. It looks like it requires cutting up a usb cable and needing a usb adapter board. I’m glad it exists as an option but it very much so seems like it is a hack and not intentional.
@@ModBotArmy You just have to run USB & 24v power lines. Its no more of a 'hack' then running straight canbus.
@@ModBotArmy I believe that's only if you want to use the CAN bus cable for unified power and USB data. If you're okay with another cable running between the electronics bay and the toolhead, you could simply run only power over the supplied CAN bus cable, and run another cable for the USB, or run your own power wires and then a cable for USB.
@@ModBotArmysorry, looks like you completely out of context. No need to cut anything, you just need USB cable and 24v, that is it
Exactly. Just USB, power. Been doing it for years dude
I don't know if it's worth calling it an "upgrade". It's a change. You may have reduced the number of cables but you've increased the "complication" of the entire printer, increasing the risk of further errors. Some solutions definitely improve the quality of life but is CAN or USB toolhead such a solution? I have mixed feelings
I've been running canbus (ebb36) for 2 years and my opinion is
toolhead board? yes
active circuitry toolhead boards? nah. just run umbilical with all the cables. you'll be happier in the long run.
Hehe the only reason I was excited to see this was because I get MCU timeout errors running canbus. But seems USB toolhead boards also suffer the same problem. Would be nice to see if a better pi solves it. I'm using a pi3a+ which might not be powerful enough as it runs into mcu timeout errors.
I love my Nitehawks, so much easier to setup than canbus
this seems like a silly intermediate solution to me, usb pd 3.1 allows for 48v,
you could almost halv the heat-up time using the same heater and use half as much wire...
But still only 5A. If you take a 24v 40w heater and send 48v through it, it becomes a 160w one, which draws then 3,3A. 160w for a 20mm cartridge is a bit spicy if you ask me.
Nevertheless i understand what are you trying to achieve, but i prefer good old molex plugs. Can be depinned, are cheap and have the locking lever, so no accidental pull out is possible. For the same reasons im also not a fan of these xt30+2 connectors
@@kilianlindlbauer8277 the 160w is an important aspect, I think the not locking usb-c is deceiving since it has a retention mechanism(so it can't gradually slide out) which XT-connectors do not
wonder if anyone has tried to use the nitehawk with a cnc tap? The probe pin is 24 volt, and I am running into issue figuring where to plug the tap into...
This is to fix your communication error during homing credit to Boxxy and TeachingTech - Communication time out during homing fix
Changed TRSYNC_TIMEOUT value in “/home/pi/klipper/klippy/mcu.py” file from 0.025 to 0.050, i.e. was “TRSYNC_TIMEOUT = 0.025”, and became “TRSYNC_TIMEOUT = 0.050”, and the error “Communication timeout during homing probe” disappeared
Is it possible to connect a beacon probe or a btt eddy to the board ?
Not this version but the Nitehawk 36 has a USB connection that can be used for this.
I'm sort of surprised that no one really talks about how most of those CANbus boards can be configured to work over USB.
Just put a EBB 2209 (rp2040) on my V1.8, where was this video last week
Can-bus setup on the M8P v2 has very little documentation and I failed so many times
24 hours after this video was published Fabreeko put up the Nitehawk 36 for pre-order lol
Tbh, nothing ground breaking all of the canbus boards can be run over USB + 24v, GND. I setup my first canbus board this way.
I appreciate you!
Yeah this is good stuff
Replacing the complex CAN bus protocol with the complex USB protocol is a bit of a sideways step. USB is good for bulk data transfers but is notoriously slow as a bus where you have to react to changes. The protocol is limited by the minimum message/response time for a packet and retries if theres a packet formation error - not good for real time responses.
If youre going to go down that path, ditch both CAN and USB and go wireless. Probably more reliable with no cables (that "best part is no part quote") .
good morning/day/evening
I love ALL my Endstops and ALL my Cables! Because bought too much....and 50 is not 5 Parts. That was a surprise!!! MUHAHAHAHAHAHA Stay safe, awesome, healthy, share Knowledge and Greetings goes out to all of you🤗🤗🤗
Would be nicer if it used usb of 3.1 that supplied the 24v through the USB directly.
you should just jump to the raspberry pi 5... I had ton of issues with canbus, usb canbridge, webcams etc using pi 3 and pi 4s.... tons of hours of torubleshooting and frustration. On one hand the pi 3 doesnt handle the bandwidth properly. on the other the pi 4 doesn't see the devices with lsusb command, or they drop out over time