Nitehawk 36 setup

[kharrisma]

Hi Folks,

Dithering over CANbus -vs- a USB-based approach, finally came down on the new Nitehawk 36. It's going onto a heavily modified Ender 3, and I'm running a Galileo 2 extruder.

Connection is pretty simple: USB cable from printer to SBC host (RasPi4B), another USB cable from the SBC host to the adapter that comes with the kit, 24 V power to adapter, kit-provided harness wire from adapter to toolhead board. Got LEDs on the toolhead. So far, so good.

The Nitehawk has a configuration file that needs to be set up before it can be used, obviously. The config file needs a specific MCU ID string for the toolhead MCU. From the SBC host, I should be able to enter "ls /dev/serial/by-id," and I expected to see two entries: one for the SBC, and another for the Nitehawk's 4020-based toolhead. My issue here is, I get a return for only the one MCU id for the SBC: ( /dev/serial/by-id/usb-Klipper_stm32g0b1xx_310036000C50415833323420-if00 ) ... and nothing else, just the one entry. I expected to also see something like: ( usb-Klipper_rp2040_1234567890000000-if00 ), and it's not there.

Should I be using some other command besides the "ls /dev/serial/by-id," maybe "ls /dev/usb/by-id" or something? I can work with Linux on a "led by the nose" basis, but it's definitely a 'second language' for me, one I'm really not very familiar with. Any suggestions would be greatly appreciated!

PS... I'd attach the printer.cfg file, but the "attach files" function on this page doesn't even see any .cfg files.

 

[StevenB]

Can you post the output of "lsusb" from your ssh terminal?

 

[kharrisma]

Can you post the output of "lsusb" from your ssh terminal?

Will post it tomorrow morning. Thanks!

 

[kharrisma]

Here's what "lsusb" (which I was doing wrong, treating it like "ls /dev/serial/by-id" and entering "ls /usb") returned :

Last login: Tue Sep 17 11:05:01 2024
karl@mainsail:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 010: ID 258a:1006 SINO WEALTH USB KEYBOARD
Bus 001 Device 009: ID 214b:7250 Huasheng Electronics USB2.0 HUB
Bus 001 Device 004: ID 0484:5750 Specialix MPI7002
Bus 001 Device 013: ID 1d50:614e OpenMoko, Inc. stm32g0b1xx
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Apparently I'm operating from a realm of misunderstanding... I can't get an mcu id from the toolhead when using a keyboard and display connected to the SBC host... but if I just access the SBC via Mainsail through my browser, there's s ton of extra stuff in there that wasn't there previously, like "TOOLHEAD"... which looks a whole lot like it's actually working as it should. No idea why I can't get an mcu id from it, though....

 

[argusz]

You must folow the instruction found on Nitehawk36 github. All instruction are there. Did you connect all wires? Did the leds on the Nitehawk turned on?

 

[kharrisma]

You must folow the instruction found on Nitehawk36 github. All instruction are there. Did you connect all wires? Did the leds on the Nitehawk turned on?

No, wires are not attached at this point, I'm doing a total re-wiring job, and mostly it's out; about half of the new wiring is in place; I was going to replace the wiring to the hot end with the Nitehawk setup. Only the USB umbilical is connected so far. Yes, I get all the LEDs (all solid green.) What's stopping me is obtaining the serial# of the 2040 MCU on the toolhead board. "ls /dev/serial/by-id" gives only the MCU on the printer control card (BTT SKR Mini E3 -v- 3.0.) "ls usb" returns what's in the post above. Haven't yet tried dmesg... not sure how useful that will be to ME. Likely tons of relevant info for someone who knows his way around better than I do! So until I can get that MCU serial#, I can't edit the configuration file for the toolhead and get it working. That has to happen before much of anything else does, as far as I know.

 

[semixhalf]

Heh, I'm having the same issue: leds are on, nothing else connected, but mcu can't be found. I even wrote to their GitHub and support email. I just received one more Nitehawk (as I've already removed/cut lots of cables I had before, and there is no way back) - I plugged in a new tool board, and mcu got visible in the ls by id command response.

Can you try the "sudo dmesg" command? My not-working tool board was showing that the USB connection hadn't been established: "USB 1-1-port4: connect-debounce failed" in red as one of the response lines. I'm curious if you have the same issue as me.

Also, per the guide, did you try long pressing the reset and boot buttons on the tool head and releasing the reset before the boot? It wasn't working for me either.

 

[kharrisma]

Thanks semixhalf... Coming down the home stretch with the rewiring, everything's connected. Will be firing it up tomorrow to see if I still have a working printer (standard wiring... might as well start with stock and get IT running, *then* install the Nitehawk and see what develops. As soon as I have a working machine, no issues, I'll hook up the Nitehawk and try both "ls /dev/serial/by-id" (just to see if it works this time, not expecting much), then I'll give "sudo dmesg" and see what that gets me, and post the results here. Likely a couple of days.

 

[kharrisma]

Sorry for the long delay... life's been getting fairly 'lifey' lately... so the machine's all back together, running without issues, Klipper is installed and also has no issues (even got the camera to work this time!) All LEDs are lit. "ls /dev/serial/by-id" still shows only the one MCU on the printer control card. "dmesg |more" shows a GREAT MANY things, but aside from a few errors very early in the file (WELL before booting Linux or getting anywhere near the SBC or USB ports), no error messages, and nothing highlighted in red. On the off chance I stuck a charge-only cable between the SBC and the small adapter card that came with the kit, I took a known-good DATA cable and tried that one... no change. Rang out the unbilical from the kit with a meter, good continuity for all conductors. Even tried using the meter to see if the two data pins on the toolhead socket showed continuity to different areas of the toolhead board, and that's good too (fishing for maybe a cold-solder joint.)
As with you, pushing the boot/reset buttons as described did nothing (didn't expect it to, as those button-press procedures described are part of the process to flash the toolhead with Katapult boot-loader and Klipper, which it comes pre-flashed with.)

I think at this point I'm going to see if I can return it for exchange and hope the recall doesn't rule that out. I mean, this isn't some left-field thing I'm trying to do here... just get the toolhead MPU ID through the USB so I can add the toolhead section to my printer.cfg file, which is a pretty basic install function... and I can't even get that. Not as if there's a lot I could do wrong to make this basic step go sideways as it is.