No, You’re good. I just needed the data dictionary for the MCU. I didn’t honestly realize it was generated when running make. I already made one based on the SB2209 settings.
Alright, cool.
So, as an aside, I have done a fresh install of the 32bit raspberry pi os lite, and used kiauh to install klipper. This is on a totally seperate raspberry pi 3, so my os and issues as you are diagnosing them are still intact.
This is the same process I used before, except for the OS being 64bit last time.
I made a small goof and put mainsail on it instead of fluidd, but the only other change is I added a btthdmi5. Its been in the works for 2 weeks (since my canbus was installed really).
Put the new os sd card in my printer, touched up my configs (theres that mainsail oops), and fired off a print.
First thing I’m noticing, is I’m not getting the throttled errors due to under voltage anymore (ill update if this changes). Once its done, Ill pull the logs for klippy and moonraker, then tack them onto my git list.
After that, I’ll probably put it back to the 64bit install we’ve been working on, and add the screen again so i can keep using it.
Fingers crossed.
Well that was a sad fail to wake up to just before my normal alarm. Strange thing to note, klipper screen was blank, and the mainsail OS web gui didn’t even show the printer as being halted. I hit E stop and dumped the logs. Starting to wonder if the Pi is just having issues now.
… I think I was stupid this morning. I think that print finished. My print end macro got booked, so it didn’t park right.
Going to try again
Sorry I forgot to reply a while ago, trying to parse the CAN Dump keeps giving me an error. Been messing with it trying to figure out why.
Well if it keeps failing I’ll run it again. I have lots to print, so many chances for it to die in flight.
Yeah try it again, and make sure you run it with the
-tz -Ddex command line args like:
candump -tz -Ddex can0
For some reason your data isn’t the right length to parse right and I’m trying to pick through the parsecandump script to see why.
So while I understand now that this will now flood my Putty with way too much info for me to ever log, I am a rank amature in the space of programing/console commands. Get to far past what I can copy and paste and I’m going to be pretty much useless. I have the CAN diagnostics page open, but I don’t know what to do to alter the command to get you what you need. If you can provide me with the appropriate command with the tags, I’ll happily run it.
Your most recent log just shows you used the emergency stop. Are you still having the missed digital out issue?
If so can you reproduce it and upload that log?
So that last log (labeled 32btest) that had the E stop on it was actually a run with a new SD card, with a new os flash on it. I went with 32bit raspbian lite, instead of 64bit raspbian lite.
That and I goofed and added mainsail instead of fluidd, but past that. Same RPi 3b+, and nothing else changed. I hit the estop because I woke up at 4am, saw a print head parked on a part, and assumed like a fool that it had crashed. It had not failed again, but instead had finished, and my slicer had the wrong end print in the finish Gcode, so it didn’t park in the rear like it’s supposed to.
I can simply stick with the 32 bit os, it seems to be fine, (I can’t tell, I haven’t combed the logs yet) or I can work on the one we’ve been working on. I only did the 32bit to see if there was a difference in the error pileup you mentioned I had.
(EDITED: So I fixed my hall effect endstop wiring today. Put my 64bit OS back in, and am running a fairly quick print. I’ll pull the logs after it finishes/fails and link them in the github. )
Print was small, so it finished. logs added anyway, hope the can log is usable. ran candump -tz -Ddex can0,#FFFFFFFF > mycanlog as per the troubleshooting page. All are under 64v to be easy to fine. Running a large print now that will likely fail, and I’ll get logs again.
Need one where the print fails. If you’re no longer getting any failures then we’re good to go anyways.
Good to know, just had a failure on the 64bit. It didn’t make it far. Logs updated.
… Why the heater keeps giving me issues I’ll never know. Time to order some new ones I suppose.
Well that figures. Print running, and Now I get a power blink. Man, what a day.
Well, I decided to switch to the 32bit operating system, and run a few prints. Got prints to run without issue that have failed back to back on the 64bit os. Looks like the issue was the raspberry pi being angry that I put a 64bit OS on it. I’m not going to complain, and I’m not going to waste any more of your time since I got it working.
I greatly appreciate all the help you have given me though. I still have the 64bit os if for whatever reason you want me to run anything from it for testing.
I figure my next upgrade will be a Raspberry pi 4, overkill though it might be. Then I can repurpose this 3B for my delta printer. Aught to prove to be one hell of a fight to get that set up with klipper.
1 Like
I have a Pi 3B in my Voron 0.2 and a Pi 4 in my Voron 2.4, I’ve honestly seen no difference between them. Klipper doesn’t really stress it. I thought about getting a Pi 5 mainly because of that never ending desire to have the “newest cool thing” but figured I’d probably just use it for Klipper anyways and that’s overkill.
Only thing I can think of that might be useful for is running multiple webcams but right now I don’t even use 1 so eh.
I’m using a 3B+ in the Voron, a Zero 2 w in my heavily modded ender 3, though I might be moving the voron to a 4b, and putting the 3b+ in my FLsun super racer and throwing klipper at it. Need a mainboard before I try that though. I do not want to slog through setting up the robin nano that it has stock.
Now just need to install open neptune on my Neptune 4 Pro and get it working with my klack ender properly, and I’ll be a happy 3d printer guy.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.