Chasing Missed digital out event

So while I hadn’t looked at the klipper info on this, The only thing that stands out to me is the txquelen amount. I followed Esoterical’s Guide, and it looks like the largest thing I see different is the size of that txquelen. Klipper says 128, his guide says 1024. So I am running at 1M speed, and 1024 txquelen. I’m wondering if this has any negative bearing on this.

I’m sure the canbus is solid, if it wasn’t it wouldn’t be in motor vehicles and who knows what else. It just isn’t working in my printer. Your printer sounds very interesting though. If that was behaving like mine, I think I’d have just given up and left it in a closet. I’d be happy to have just one board working.

My only goal right now is making canbus as reliable as my old wire loom was. After that, I’m building ERCF, and that is also going to be canbus, so whatever I get working here will be applied there.

I had heard of canbus before I decided to install the board, but this upgrade to my voron has been a nightmare, and after 2 weeks of fighting with it, I’m tired.

Just a little rant. I have posted in reddit, voron’s forum, voron’s discord channel for canbus, a specific help ticket in said discord, and finally, here. I didn’t post here sooner, because I figured this wasn’t actually a klipper issue. I’m wishing I would have posted here sooner, because I’ve been ignored everywhere else.

Okay, rant done.

Testing for intermittent connection is fine by me, I’d rather be sure. If I seem angry, or upset, please be assured I am not. Not with you, or your requests to diagnose this issue. You are spending your time helping a fool like me, and again I appreciate this.

I’ll go ahead and mention that I do have another Raspberry pi 3b (Not a + though), and a BTT Pi. The BTT pi is probably the closest to being ready to just drop in in place of my current pi and loading up with my current configs.

I am also not opposed to reflashing my u2c (I would need to reflash it to adjust the txquelen?) and the SB2209.

I’m going to pass out now, I was in bed over an hour ago, and being angry at the discord help ticket response has kept me up.

Talk to you tomorrow after I get home from work. If this was disjointed, I apologize.

You’re all good, I understand the frustration. Especially with 3d printers. I can’t tell you how many times I’ve left my printer in pieces on the floor and said “@#!@ it, I’m done. I don’t even care anymore”

Only to come back later that day or a few days later.

Or texting friends that also 3d print saying “Have I ever told you how much I !@%@ing HATE 3d printers???” (which of course I had, many, MANY times).

3d Printers are definitely a love to hate/hate to love relationship.

When they work and work, it’s amazing and liberating and you can show off to people how good your print quality is and the things you’ve made.

When they don’t work you want to take it out into a field and strap it with Tannerite and blow it all to hell with a rifle.

I’ll check out your Klippy log and see what I can think of by the time you come back.

1 Like

Your RTO and invalid_bytes are still super high. You might have a bad cable altogether.

Do you have a spare Ethernet cable laying around? What you might due to rip it open and pull out one of the twisted pairs and crimp a pin header connector to one side for the SB2209 and just use the screw connectors on the U2C.

That way you can try with a fresh cable.

As for the txqueuelen mine is 1024 without issue, so I don’t think it’s critical as long as it’s not too low.

1 Like

Well, sadly I do not have a spare ethernet cable. However, I do have a spare stock cable that came with my ercf control board, spools of wire that I can work with, and a purpose ordered 5tf length of syncroflex cable that is not only shielded, but twisted as well.

Gonma have to wait on the synchro cable for later tonight. Gonna throw some pins on the spare cable, and lock it in.

Question, do my errors start high, or do they seem okay, then jump suddenly? I’m wondering if my toolhead mount isnt up to the task I’ve assigned it. I can always make another after all.

The red flag is the bytes invalid, which start growing pretty much immediately.
Which to me looks like just a poor connection in general rather than a sporadically flaky connection.

Okay, that certainly points more toward a bad cable. Or maybe it was just loose as hell. I dunno. Gonna do a print, and then log, then I’ll change the cable and another print. For science.

Sorry I didn’t get this done last night. I died in flight and slept for like 12 hrs.
Check out klippylock.log and moonrakerlock, those are from the successful print after I locked the cable into the new holder .Going to change the cable now and run another long print to see if it dies.

Cable changed, just waiting on the print now.

1 Like

Wow, I made a goof there. Forgot to hit commit for those first logs.
4 new logs. 2 with the cable properly locked in place, two with a brand new cable.

Well, Good news and bad news.

Good news is, Your RTTVar and SRTT aren’t rising anymore which means your RTO is flat. So that’s good. More solid communication.

Bad news is your bytes_invalid are still rising so something funky still going on with the CAN communication.

You said you were using a BTT U2C?

1 Like

Yes I am. I had a BTT pi with a can module, but managed to rip the pins off, so it’s no good. Only alternative I have for that u2c is to reflash or to put the octopus in bridge mode. Though I could just get a new one if it’s borked.

Have you flashed the most up to date firmware on it? The U2C that is?

1 Like

That is questionable. I followed the guide mafe bu esoterical, anf it had an alternate firmware. Might be old sonce it was still candelight, but the one I flashed was meant to remedy an issue with the u2c.

Ill see what I can do to DFU mode the U2C tonight.

I also just got a Pi 4, so if needed I can now upgrade if required.

The newest Candlelight firmware should work fine too, Just wanted to make sure you weren’t using something super old. Next step might need to be getting the CAN dump logs to see if there are messaging errors.

That’s described here:

https://www.klipper3d.org/CANBUS_Troubleshooting.html

1 Like

Ran the two commands indicated for can.logging. putty proceeded to stop working? It was strange. It wouldnt run any commands anymore, and keystrokes that normally do things just produced a raw input to text?

I closed it and then started a print. Hope it does as told.

Whoops. I made a mistake. Ran a stock orca slicer profile for my voron without looking. My print looks like the steps leading up to a temple because the travel accell is waaaaaay too high. Killed the print, will upload logs soon.

Okay, klippylock2, moonrakerlock2, and mycanlog are now on the github. I hope the termination of the print doesn’t screw this up. The parts were already beyond any hope of salvage, and I’ll be redoing them on a more sane setting. 7k for move actions is just too much for my printer it seems.

Well that print failed in a real hurry. Got new logs, lock3 for the others, and downloaded mycanlog2. Size was the same, hope it’s different. If not, I can always run the command again and try another.

Going to need you to generate a dictionary file before I can read the candump.

See the instructions here:

https://www.klipper3d.org/Debugging.html#translating-gcode-files-to-micro-controller-commands

1 Like

This fails with the following text after my attempt to run the command after the make command. (I had to program a make for my RP2040 board so it would do something)

Traceback (most recent call last):
  File "/home/Oghma/klipper/./klippy/klippy.py", line 407, in <module>
    main()
  File "/home/Oghma/klipper/./klippy/klippy.py", line 332, in main
    debuginput = open(options.debuginput, 'rb')
FileNotFoundError: [Errno 2] No such file or directory: 'test.gcode'

Realized my printer was in a crash state. Tried to restart firmware. 5 attempts later, no connection to the SB2209 was made. I can see it has power, my toolhead lights are on. Forced to restart my entire system. Finally got it to reconnect to the toolhead board.
Ran command again, error is exactly the same.

Nevermind, I’m dumb and even I didn’t read the instructions.

I’ll parse the CAN dumps here in a few and get back to you.

Oh, I thought I did something wrong. I noticed there was a parse tool in the canlog page as well. Do I need to obtain a file from that for you? If I do I certainly will.