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
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.
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
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
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. 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.
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.
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 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.
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.)
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.
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 :)
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'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?
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.
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.
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.
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.
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.
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.
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
@@__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.
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!
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.
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.
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.
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
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.
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.
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? 🤔
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
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
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.
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
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?
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.
@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) 🍻
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.
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 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 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
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...
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
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🤗🤗🤗
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
Swapping parts without having to undo wires, quicker upgrades, and more free ports for things like chamber fans, electronics fans, chamber thermistors etc. It really depends on how complex of a build your running and what your wanting to accomplish.
@@ModBotArmy thanks for your fast respond! So... I don't need it. I don't change my toolhead or other things. Maybe I change the nozzle any time for a different material, but that's it.
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
OMG, you really did get right into it without further ado! Bravo!
Last week, my coworker recommended that I check out your channel. It turns out we both knew about your channel 👍
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
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.
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 !
I installed this on my trident and its an amazing upgrade!
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
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.
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.
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
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
Thanks for this detailled video! What is the PG7 gland mount mod on the SB you used? Could you provide the source, please? Thanks!
Well this is definitely more than I'd ever care to bother with, but I'm glad it makes you happy
Daniel, one thing is missing in this otherwise very informative video: Did you notice any significant improvement on X and Y max accelerations?
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.
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.
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.
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.
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 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.
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.)
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.
The CAN toolhead boards you showed (EBB36 and EBB42) already support USB
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 :)
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'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?
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.
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.
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.
What are the umbilical “attachments” you are using? Basically the stuff the cable comes into both in the toolhead and back of the printer.
a fair few CAN boards can also be run as USB driven, I've got that set up in my own scratch built printer.
awesome... quick question do you have any video tutorial in doing Sensorless Homing?
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.
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 :)
Wasted half my day today trying to get another CAN board working ugh.
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 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??
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
Any information on how you de-pinned the connector?
When i get a broken cable in my Trident cable chain, I'll be considering this.
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.
You could also install a PI2 from btt and show us a video on that installation. Looking forward for the ebb36 version. Great video
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!
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.
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.
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.
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
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
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 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.
Was there supposed to be a heatsink for the 2209? If not have you noticed any issues with the temps?
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.
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? 🤔
Iam pretty sure that you can run an ebb42 over usb aswell
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.
You wouldn't happen to have the link to the stl files for the cable gland mounts?
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
I also don’t get the “finally”.
The EBB36 has a usb-c port and has been available for quite a while now.
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
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
Does the SB version of Nitehawk have the additional USB port onboard to use with Beacon?
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
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?
Newbie question: Does the extra weight on the toolhead slow done print speed?
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.
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.
@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) 🍻
how well does the nighthawk work with multiples? is this a good option for tool changers?
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.
I'm sort of surprised that no one really talks about how most of those CANbus boards can be configured to work over USB.
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.
could you make a seperate video about setting up sensoreless homing?
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?
I am assuming if you are already running CanBUS there is no reason to change to USB.
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 😀
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"
24 hours after this video was published Fabreeko put up the Nitehawk 36 for pre-order lol
Well bambu uses a usb c toolhead, is it possible to have a third party one then?
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
I love my Nitehawks, so much easier to setup than canbus
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...
I appreciate you!
I dont get it, USB toolhead where around for years, they could just do CANBUS, too
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.
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.
Would a canbus tool head cable be compatible with USB?
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
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 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🤗🤗🤗
Yeah this is good stuff
Would be nicer if it used usb of 3.1 that supplied the 24v through the USB directly.
good morning/day/evening
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
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 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 don't understand what the benefit of a toolhead board should be, except the accelerometer. A good mainboard has everything I need.
Swapping parts without having to undo wires, quicker upgrades, and more free ports for things like chamber fans, electronics fans, chamber thermistors etc. It really depends on how complex of a build your running and what your wanting to accomplish.
@@ModBotArmy thanks for your fast respond!
So... I don't need it. I don't change my toolhead or other things. Maybe I change the nozzle any time for a different material, but that's it.
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