date-created: 2024-06-30 09:15:30 date-modified: 2024-10-09 06:52:04

Index

tags: #Social #Website

Overview

Hi, I’m Evelyn a cs-student at the university of tuebingen in Germany.

I “built” this website to gather experience with git-hooks, experience with mdbook and its features to parse md-files to html, well and to provide a space for:

  • my ideas
  • thoughts
  • projects
  • scripts and documentations
  • maybe some scripts.

Goal and motivation:

Besides the reasons given above I generally wanted to share different thoughts and findings / experiences on some platform that are not dependant on another platform - i.e. social media or discord. Hence I’ve always thought of creating a webpage where I could give those things a foundation to rest on yet my first webpage was not updated often and I dropped the idea - primarily because I had no CMS running and it was entirely hardcoded, meaning I had to connect to the server whenever I wanted to change an information or write new entries - well and consider that i would have to update internal links, references and more, its a pain without any dedicated CMS running!

For some years - since 2022 I think - I’ve been logging, collecting and organizing my material, education and more via Obsidian and grew accustomed to the idea of writing everything down in markdown. With that idea in mind my optimal solution would’ve been a structure where I could write down things in Obsidian and then copy and link them to a repo which I could then update and push to some repo that would build a website out of it. At first I was thinking of doing that myself and thought this to be a good chance to work and experience Rust a little more, however I conceptualized a lot but had no to time to actually begin writing this all. While tutoring software engineering - 2023 - we began posting the script for our lecture via mdbook and that made me think whether I could make use of this infrastructure to finally deploy a website without much effort at all.

I describe the whole concept and idea of this blog in another post - here 452.07_own_webpage and 452.10_obsidian_vault_to_mdbook

and likely some more which I’m not listening or forgot about.

Some Quotes I like:

“We are perpetually trapped in a never ending spiral of life and death”.

Tormented by the fear of not being necessary

The intimate desire of acceptance

Overwhelmed by the fear of being alone

Documentation is a love letter that you write to your future self

In case you would like to contact me I provide the following option(s):

-> mail: social.scattereddrifter@proton.me

where you might find me too:


date-created: 2024-04-08 12:22:10 date-modified: 2024-05-19 01:14:00

3d-Printing Filament

anchored to [[410.00_anchor|410.00_anchor]]


Introduction:

Theres different filament available that comes with different traits. I list those here in case they might be:

  • good manufacturers
  • interesting material
  • interesting colours
  • have interesting properties

PLA

  • Sunlu CF PLA link
  • Polytera matte PLA
  • ESUN PLA
  • Prusament

ABS

  • ESUN ABS
  • Sparta ABS or the german equivalent alchemy3d

Filament Clog | How to resolve them

anchored to 410.00_anchor


Overview

Whenever speaking about a filament clog the following scenarios are meant:

  1. something is obstructing the path from extruder to nozzle (mostly within the hotend to the nozzle) like metal parts, old filament or something else
  2. the heatbreak was clogged because the filament could heat up enough to melt the filament before reaching the hot-end thus being stuck. The latter is usually caused by retractions -> whenever the system is quickly pulling filament to prevent oozing / stringing. Because the heatbreak might be hot enough to soften/melt the plastic outside the heating-area (hotend) this retraction could then create a blob of filament stuck within the heat-break. Once this was caused one will not be able to print.

Fixes:

there are some tips / tricks that could help to resolve a clog within the heatbreak/hotend:

  1. Using something (paperclip or drill bit etc.) to heat and poke through the assembly Heating up the component to use will allow to melt the plastic that is obscuring the path. Denote that it should be smaller than 1.7mm in diameter to fit through.

  2. Heating up the heatbreak+heatsink to soften the filament link

Simply: Remove fan for the heatsink, heat up the hotend/heatbreak until it reaches a temperature where the plastic should soften/melt. Then poke it through with filament or something fitting through the tube.

This method is taken from the given post:

I have had PLA jamming in the heat break for various reasons. I am using a simple method to clear the heat break. I am sharing the method with you all. I’d love to get some thoughts on the safety of this method, possible drawbacks, pitfalls, etc.

My objective is to clear the heat break with the least possible disassembly. I did not want to remove the heat sink, nozzle, hotend, etc.

As a first step, I unscrew the heat sink fan and move it away. I also move away the cooling fan and the PINDA probe. Next, the extruder cover is removed. This completely exposes the heat sink portion. I move things away to make sure that all the sensitive items are as far away from the heat as possible. At this point, things look like this :

Remove the extruder idler screws. At this point I push a length of filament as far as possible through the PTFE tube, take it out, and reconfirm that the block is in the heat break.

By careful measurement, it should be possible to figure out exactly how much filament is stuck inside. Note that the E3D design is freely available - engineering drawings with dimensions are at http://wiki.e3d-online.com/wiki/E3D-v6_Documentation . I haven’t done this exercise, however.

Next, heat the nozzle to 210 degrees. Place a little book or piece of cardboard over the heat bed. If anything hot falls down, this will ensure that the heat bed is not impacted.

Wait a couple of minutes. Regularly keep sensing the temperature of the heat sink. Exercise care to ensure I don’t burn up any fingers. Once think the heat sink is hot enough, try pushing the filament in, through the PTFE tube. Note that the whole heatsink does not need to be hot - only the bottom portion closer to the heat break. That’s where the filament is stuck.

In a few minutes (2-4 minutes maximum - I did not time it), I am able to push the filament down with minimal effort and do some manual extrusion.

I now pull out the filament in quick motion. I issue a “Preheat | Cool down” command. The heat sink is in contact with ABS all the while, so ensure that you don’t keep it hot for any longer than absolutely required. You certainly don’t want the ABS to melt !

After everything cools down, push a filament through the PTFE tube as far as possible, check that the length that you are able to push in is much more than earlier - and something that looks enough to reach the heater block.

If you reached here, congratulations! Your heat break is clear. Put back everything back as it was earlier. Move the Z axis as far up as possible. Issue a Z calibration & check everything is still in order.


Preventing:

  • printing with hotter temperatures
  • reducing retraction (for all-steel heatbreaks - made for ABS - its recommend to stay below 0.4mm)
  • install better fan to increase cooling capabilities for the heatsink

Issues with CANable - General Discussion - Klipper

anchored to [[410.00_anchor|410.00_anchor]] source: klipper.discourse.group read - estimated by firefox: 59–74 minutes


Hi,

I can’t post all the links as new user, so I put them all here: Kit: https://www.3dptronics.com/electronics/56-621-voron-24-complete-ptfe-wiring - Pastebin.com 18. I will refer to them in the body of this post. Sorry for the inconvenience.

I have Voron V2.4 350x350 with recent Canbus (EBB36) upgrade, using CANable adapter (1st link). Raspberry Pi 3B+ (32 bit kernel) and Octopus board. Upon install and setup, I had issues of random error “Lost communication with MCU ‘can0’” while printing. Following this post (2nd link), I found out that it is not hardware/wiring issue, but firmware issue, because ip -details -statistics link show can0 reports no dropped bytes, but mcu can0 interface statistics on Mainsail reported lots of bytes_invalid and bytes_retransmit.

I followed the advice in that post, and flashed updated firmware(3rd link) to CANable via dfu-utils. This got rid of the bytes_invalid and bytes_retransmit (both stayed at 0 even when testing).

However, my printer still randomly shuts down during bed mesh sometimes with the same “Lost communication with MCU ‘can0’” error. Klippy.log ends with Got error -1 in can write: (11)Resource temporarily unavailable'. If I run sudo dmesg, I get several Under-voltage detected! (0x00050005) errors. However, if I run vcgencmd measure_volts core (as well as sdram_c, sdram_i, sdram_p), I get completely nominal voltages.

Here are a few screenshots: (4th link)
My klippy.log: (5th link)

I am pretty sure there should be no actual undervolt, because everything was working fine before I added CANBUS to my printer setup. Can anyone help me figure this out?


How are you powering the rpi?
Undervoltage is to be taken seriously.


I am powering it via the 5V PSU on the Voron

image

That PSU is supplying 5.1V. Rpi is receiving 5.1V as well (I measured at both ends).

P.S. I added an extra 5V and GND wires from the PSU to the other pins on the Rpi, just to add some redundancy in case something is shaking loose, although connections look really strong and crimping is good.


It’s probably not your problem but you should never have multiple power/ground wires in parallel as you can get induced voltages with the ground/Vcc loops that you have added to the system.

A better place to look is how you made up your CAN bus wiring. How was that implemented?


Thank you for your reply. I had this whole issue even before I added these additional wires to Rpi. I can remove one pair and leave only one pair of really thick wires. However, when I added these additional wires yesterday, I stopped getting undervoltage warnings. Bed meshes seemed to work, so I thought maybe the issue is fixed, and tried another long print - and got a new error message some 4 hours into the print:

https://imgur.com/a/kE4Iwb3 5

(Also attaching my Klippy.log, I trimmed the middle. But it really doesn’t show anything relevant that I can see).

Sudo dmesg shows this:

https://imgur.com/a/mg4KwF5 3

Some kind of “power save enabled” that I have never seen before. Not sure if this is relevant or not. This might have happened some time after the print failed, because I left it overnight and found it dead in the morning.

To answer your question about wiring, I am using the pre-crimped wires supplied with that kit I linked to. 4 wires in total. They are crimped onto a 4 pin connector, and connected to the EBB36. I am using several zip ties and strain relief gland to make absolutely sure the connector cannot move in any way when the toolhead moves. That part is rock solid. The wires then go through the umbilical sleeve into the electronics bay. CAN_LOW and CAN_HIGH are connected to the terminals of CANable and screwed down tight. 12V wire goes to the 12V PSU output, and GND goes to 12V PSU ground. Another wire goes from the third CANable to terminal also to the 12V PSU ground. CANable is connected to Rpi using a high quality 30cm USB cable. Let me know if this is what you wanted to know.

Thank you for your reply. I had this whole issue even before I added these additional wires to Rpi. I can remove one pair and leave only one pair of really thick wires. However, when I added these additional wires yesterday, I stopped getting undervoltage warnings. Bed meshes seemed to work, so I thought maybe the issue is fixed, and tried another long print - and got a new error message some 4 hours into the print:

https://imgur.com/a/kE4Iwb3 2

I can’t attach my Klippy.log because of the damn forum restrictions, I will post it in separate reply.

Sudo dmesg shows this:

https://imgur.com/a/mg4KwF5 3

Some kind of “power save enabled” that I have never seen before. Not sure if this is relevant or not. This might have happened some time after the print failed, because I left it overnight and found it dead in the morning.

To answer your question about wiring, I am using the pre-crimped wires supplied with that kit I linked to. 4 wires in total. They are crimped onto a 4 pin connector, and connected to the EBB36. I am using several zip ties and strain relief gland to make absolutely sure the connector cannot move in any way when the toolhead moves. That part is rock solid. The wires then go through the umbilical sleeve into the electronics bay. CAN_LOW and CAN_HIGH are connected to the terminals of CANable and screwed down tight. 12V wire goes to the 12V PSU output, and GND goes to 12V PSU ground. Another wire goes from the third CANable to terminal also to the 12V PSU ground. CANable is connected to Rpi using a high quality 30cm USB cable. Let me know if this is what you wanted to know.

P.S. Before this new error happened last night, I also added a jumper on the “120R” pin on the EBB36, because I found some info that it helped some people. Apparently it didn’t help in this case.

On one of my printers I got the “Power Save Enabled” warning when I was powering my Raspberry Pi from a Mac that was nearby (I didn’t have a 5V AC/DC hooked up at the time). I replaced the PC/Mac connection with a Raspberry Pi wall wart and the issue went away.

When you say “one pair of really thick wires”, what do you mean? For my current connection, I’m using 16 AWG connected to a 5A AC/DC bulk supply soldered into a USB C prototyping connector for powering the rPi:

2023.04.22 - rPi Power Connection

For a straight Raspberry Pi that isn’t powering anything, this would be overkill but in this printer the rPi is mounted to a BTT PITFT5.0 touch panel. When I measure the current on my bench supply in this configuration, it’s about 3.2A and 16 AWG is appropriate.

If you have a Raspberry Pi with no display mounted to it, the maximum current draw I’ve observed (with the rPi not powering any external devices) is 1.4A so you’ll want to use something like 20 AWG or 22 AWG to make sure your power cable losses are minimal.

I’m going through this level of detail because when I look at the schematics for the various CANable versions (1.0, 2.0 and Pro) it’s MCU is being powered by the Raspberry Pi. I’m guessing (based on the datasheet) that the CANable is drawing 200mA or so.

Now, you say that you are using an Octopus board, did you pull the USB Power jumper? If you don’t, the rPi will be providing 5V power for the entire board even when there is a bulk supply - expect the Octopus to draw at least an Amp with the stepper driver modules installed.

image

So, my big question is; what do you have attached to your Raspberry Pi’s USB and what is the current rating for the bulk 5V AC/DC that you are using? If you are powering the Octopus, CANable then the total 5V current draw is going to approach 3A. If you’re also powering a display like the BTT PITFT5.0 that I’m using then total rPi current draw will be north of 5A and, depending on your bulk supply and wire AWG size, you’ll see some voltage dips and the “Power Save Enabled” warning.

If you do have the Octopus’ USB power jumper in, pull it and see if this fixes the problem.

If all you have is the CANable and the EBB36 then you should have the jumpers enabling the 120 Ohm terminating resistors installed in both boards.

Good luck!

Thank you for your extensive reply. To answer your questions:

  1. I am using 18 AWG wires to power RPi (during yesterday’s experiment I even had two pairs of 18 AWG wires).
  2. The RPi is connected via USB only to the Octopus board (but the jumper you showed is not installed, so the Octopus board must be getting it’s power from the larger 24V PSU (Mean Well LRS-200-24)), and the CANable adapter - I’m pretty sure RPi is powering that one, because CANable doesn’t have any power lines coming to it, only ground. So it must be getting it’s power via USB.
  3. My LCD is connected and powered from the Octopus board (so, also not related to the 5V PSU).
  4. The PSU I am using for RPi is Mean Well RS25-5 (rated at 5A). It is powering nothing else, just RPi.
  5. I had installed the 120 Ohm jumpers on both the CANable and the EBB36 when the last print failure happened. Sorry I forgot to mention it.

So, to sum up - 5V PSU is only powering RPi, and RPi is only powering CANable. RPi and PSU connected with 18 AWG wires, and the total load should be well below 5A. Octopus, EBB36, LCD and the rest are all powered from the 24V PSU.

So basically my current setup during the last print failure already matches what you suggested :confused: What do I do now?

Have you put a voltmeter on the output of the Mean Well 5V supply? It has an adjustment, maybe it’s a bit low from the factory.

The only other thing that I can think of is that there is a problem with your rPi’s 5V wiring - could you share a picture of the wires and how they go into the Raspberry Pi? If things got better when you added a second set of wires, that sounds like there may be an issue with the basic wiring.

Other than those two things, I can’t think of anything else. The “under-voltage” detected warning is pretty specific to the power supply going into the Raspberry Pi.

I measured the voltage out of 5V PSU - it is actually 5.1V. I also measured voltage at RPi - it is the same, meaning there is no drop due to wiring. If I knew when the issue is going to occur, I could measure at that time… But I don’t know how to cause it to happen on purpose, and chances are, if there is any voltage drop, it is very sudden and difficult to notice.

Here are the pictures you asked for: Imgur: The magic of the Internet 6

Sorry for bad cable management - I am trying to work out the issue so I’m rearranging things a lot. As you can see I still have two 5V wires going from the PSU to RPi (the two adjacent 5V pins). As for ground, I tried one to 5V PSU, one to 24V PSU (since the ground is shared, it shouldn’t matter, but I still wanted to try).

Thing is, if you remember, after adding the second pair of wires, I don’t get low voltage error anymore - just that “power save enabled”. Maybe it’s the same thing, I don’t know.

In any case, are you absolutely sure that this power supply issue is what’s causing CANable to lose connection? I really don’t know what else to do here as far as power supply goes.

You have a ground connection from each of the 5V and the 24V power supplies going to the Raspberry Pi? There’s a good chance that’s your problem - at the very least you have a big ground loop and, most likely, you have ground shift between the two power supplies that’s effectively lowering the 5V applied to the rPi.

Disconnect the Raspberry Pi ground lines from both the 5V and 24V supplies and run a new one, the same size as your 5V power line, from the 5V supply’s “-V” pin to the rPi’s Gnd.

It also looks like the CANable has a ground line connected to the 24V supply - you might want to disconnect that as well (I’m not impressed by the quality of the CANable circuitry).

Let’s see if this fixes your problem.

My apologies - I wasn’t aware that there is such a thing as ground loop. I thought it’s always best to connect all the grounds. I will try what you suggested, but then I have a question: should I connect the grounds of 5V and 24V PSU together or keep them separate? Also, what about the ground of the EBB36 and CANable - should I connect their grounds to RPi or instead to the 5V PSU “-V”?

No, keep the 24V and 5V grounds separate to the different devices. They’ll actually be connected through the USB connection between the rPi and the Octopus.

Honestly, I wonder if your problem is due to the thin ground wires on the rPi - the one going back to the 5V supply can’t carry all the current being provided so some of it is being shunted to the 24V supply with problems ensuing.

I’m not sure about the CANable with the third screw terminal that connects to “Ground”. I think you might have to leave that unconnected.

Let me know how things work.

Perhaps, I won’t pretend I understand how this all works :smiley: But in any case, I have rigged up the wiring as you suggested: 5V PSU connected only to the RPi, CANable connected only to RPi (via USB) and to EBB via CAN_HIGH and CAN_LOW, EBB only to 24V PSU. No ground shared between 5V and 24V PSUs, except through the USB cable between RPi and Octopus. Printer boots up so far, I will attempt a previously failed print (without filament) overnight. If anything I listed here is wrong, let me know. Otherwise, I will report the results tomorrow.

Okay, apparently we won’t have to wait. My printer halted during QGL, with the same error “Lost communication with MCU ‘can0’”. Klippy log shows nothing of interest at the end. “Sudo dmesg” shows “power save enabled” again. So basically everything the same as before, so I’m skipping screenshots.

I am at a complete loss. Like I wrote, RPi 5V and GND are connected to +5V and -5V on the PSU. No ground loops this time. Nothing else connected to these lines. The only other connections are via USB to CANable and Octopus.

EDIT: It seems that whatever we did, made things worse. I now get printer shutdown every time I try to QGL. Can’t even make a single one succeed. Klipper log now ends with b'Got error -1 in can write: (11)Resource temporarily unavailable'. Firmware restart doesn’t work, I am forced to use on/off switch to restart the printer.

I know it’s of little consolation but a consistent error like this is generally easier to find than an intermittent one.

Can you:

  1. Share your klippy.log
  2. Draw out your wiring? I feel like we’re missing something here.

Thanx.

Yeah, you are right. It’s always better when the issue is reproducible. Attaching my klippy.log after the last shutdown during QGL.
klippy(9).log (1.2 MB)

I have drawn out the wiring. Very crudely so, sorry for that. But it is accurate:

image

P.S. If you check my Klippy.log, something really interesting is happening at around line 8152 and onwards.

Power schematic looks good -that’s what I would expect. Based on what I’m seeing in the klippy(9).log and it not having any Under-voltage detected errors, I would say that the cleaned up wiring has fixed that problem.

Now, when I go through your klippy.log your Quad Gantry Level execution looks messed up. You have a metric shit tonne of macros in your printer.cfg and I can’t begin to follow them but it looks like you’ve set some really aggressive movements when you start the QGL (at line 8001). I guess you’re running with Klicky (based on the Probe “Dock” operation) and doing four probes for each point (based on what I’m seeing). I’m really not an expert at decoding klippy.log but I think you’re problem is being flagged at line 8127 with a Lost communication with MCU 'can0'.

Did you write all these macros or did you pick them up somewhere? Have they ever worked (with the CAN Bus) before?

Yes, I would expect the undervoltage issue is gone too, but like I said, I still get the “power save enabled” message when running “sudo dmesg” after printer has halted.

I have the UnKlicky probe on the toolhead. Yes, there are a lot of macros, I picked them up from various places. For example, QGL macro came with default Klipper install I think. Klicky related macros came from Klicky guides. Nozzle cleaning macro came from the wire brush guide. There are some macros for controlling LEDs and for sounds. I wrote a few maintenance macros myself, like bringing toolhead to various positions, etc.

Basically when I start new print, this is the sequence:

  1. Set bed temperature to target, heat soak for 5 minutes (I print PLA, so it is enough most of the time)
  2. Home all
  3. QGL
  4. Home Z
  5. Bed mesh
  6. Heat nozzle to 180°C
  7. Clean nozzle on the brush
  8. Auto-calibrate Z offset
  9. Heat nozzle to target temp
  10. Clean nozzle on the brush
  11. Move tool head to the center of the bed
  12. Print

To answer your question, yes, this setup worked really well for me. It worked without any issues before I installed CANBUS, and after installing it, sequence still works without issues on the occasions when I don’t get lost connection with mcu can0. So I don’t think this sequence is what triggers the lost connection, especially because like I said, if printer does get through this sequence, I still get print terminations several hours into the print.

Attaching my whole config directory if you want to take a look. I admit I could tidy it up a bit, so sorry for the mess!
2023 04 23.zip (34.2 KB)

Thank you, I will attempt this. For clarity, am I supposed to run the dump utility right after the printer loses connection with can0? I tested this tool out with candump -t z -Ddex can0,#FFFFFFFF, and it just slowly prints memory contents to the terminal. Is it going to eventually write them to a file?

No, just start logging to the candump.log file. You will need this file to use parsecandump.py.
Here is an informative video https://www.youtube.com/watch?v=ef4akXEDKOQ 5 about candump. You may also find a lot here in the forum. Many people have some problems with CAN bus.

Okay, I got the dump, attaching it. How do I use that parsecandump.py? It requires more arguments than just the dump file, I can’t find any documentation on this tool.
candump-2023-04-23_153346.log (449.2 KB)

EDIT: It says it requires can ID and something called mcu.dict, but I have no idea where to get that.

You have a LOT of macros and if you “picked them up from various places” then I would be very surprised if you have any idea what’s going on with them and how they interact. When I tried reading your klippy.log, there are things that don’t make sense, like setting max_velocity to 500 (along with your acceleration/deceleration/square corner velocity/etc.) repeatedly before starting your QGL.

Could I suggest that you eliminate essentially all of them and start working through the operation of the printer to eliminate the chance there is a macro problem before assuming you have a CAN problem or any other problem?

I think I have a decent understanding of how they work, and I included them for a reason. But sure, I can do what you suggested. Can you tell me specifically what I should do? Because right now, I just boot up the printer, press Home All in the Mainsail interface, then run QGL - and bam, I get shutdown due to loss of connection with can. So basically I’m just running two commands, and none of these macros should be called. They are listed in the klippy.log, but they aren’t called I think. So let me know what I need to change for the testing and I’ll do it.

Based on your previous posts and what I see in the klippy.log and what you’ve shared you’re doing an awful lot more than just basically “just running two commands”. When I look at your klippy.log, there’s a lot of commands executing I don’t understand the purpose of and you’re not paying me enough to figure them out.

You want to know what I think you need to change for testing? In looking at the printer.cfg, I would say start by taking out/commenting out the following lines:

[include stealthburner_leds.cfg]
[include purge_macro.cfg]
[include tones.cfg]
[include movement_macros.cfg]
[include calibration_macros.cfg]
[include toolhead_btt_ebbcan_G0B1_v1.2.cfg]

Which is basically literally everything but the basic mainsail.cfg macros (virtual_sdcard, PAUSE, RESUME, etc.).

Next, in printer.cfg, remove/comment out everything after “# Macros” including [include klicky-probe.cfg] When I look at klicky-probe.cfg I see:

#Simple way to include all the various klicky macros and configurations
# the current home for this configuration is https://github.com/jlas1/Klicky-Probe, please check it

#[include ./klicky-specific.cfg]                #place to put other configurations specific to your printer
[include ./klicky-variables.cfg]                #Required
[include ./klicky-macros.cfg]                   #Required
[include ./klicky-bed-mesh-calibrate.cfg]      #bed mesh, requires klipper configuration
#[include ./klicky-screws-tilt-calculate.cfg]   #help adjust bed screws automatically
[include ./klicky-quad-gantry-level.cfg]       #level 4 Z motors
#[include ./klicky-z-tilt-adjust.cfg]           #level 2 or 3 Z motors

Which moves us into several more levels of macros. I should point out that several of these macros aren’t included in the .zip file you provided.

Then, when you’ve done that, put in the basic Klicky dock and undock functionality and start testing.

Sorry for being so brutal, but I want to throw up my hands when I see header comments like:

# This macro was provided by discord user Garrettwp to whom i give my thanks for sharing it with me.
# I have tweaked it a lot.
# They are based on the great Annex magprobe dockable probe macros "#Originally developed by Mental,
# modified for better use on K-series printers by RyanG and Trails", kudos to them.
# That macro as since evolved into a klipper plugin that currently is pending inclusion in klipper, 
# more information here, https://github.com/Annex-Engineering/Quickdraw_Probe/tree/main/Klipper_Macros
# User richardjm revised the macro variables and added some functions
# User sporkus added led status notifications

It’s like the power set up; go back to being as basic as possible, draw out the process and start working from there.

I apologize for my lack of knowledge. I am very new at this, and I’m trying to learn as fast as I can. I appreciate your patience.

Okay, so I did what you told me - for now, I removed all includes except for mainsail.cfg and toolhead_btt_ebbcan_G0B1_v1.2.cfg. I commented out all macros from the printer.cfg. Didn’t even include Klicky macros yet. Left the bare minimum. After doing this, I cannot even make a full restart - Klipper gets stuck in Klipper reports: STARTUP blue screen for a while, and then throws mcu 'can0': Unable to connect again. Klippy.log keeps growing and is not resetting - meaning, at the beginning I still see logs from old tests, and the new log is just appended at the end of the file. Attaching for you to see.
klippy(14).log (2.2 MB) Not even turning printer power off and on back again fixes this. I am really confused.

I cleaned up printer.cfg as much as I could - removed all unnecessary comments, organized everything, moved in everything needed to boot up the printer except for mainsail.cfg (which is still included):
printer.cfg (9.0 KB)

And I still get the same issue, printer is not booting due to can0:
klippy(16).log (2.3 MB)

The log has one line that I didn’t notice before, or maybe it is new:
mcu 'can0': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available

Researching this now, but just letting you know.

Okay, what I would recommend is going through the CAN set up procedure again following something like:

or this video which is highly rated/go to for Vorons:

Hopefully things will come together from doing that and you can start moving forwards again.

Okay, I went through the whole procedure again like you suggested, step by step, not missing anything. Still the same. Printer is not booting with the same error.
klippy(17).log (2.3 MB)

I guess there is no docu. I never used parsecandump.py. koconner stated “It works similarly to the existing klippy/parsedump.py tool”. I would look here in the documantation Debugging - Klipper documentation

Line 109 in parsecandump.py says: (sorry I can’t quote the original source, discourse shows not what I write). Just have a look at the original file https://github.com/Klipper3d/klipper/compare/work-parsecandump-20230417 1
usage = “%prog <candump.log> >canid> <mcu.dict>”

I would take can0 for >canid>, but for <mcu.dict> I have no clue. I guess it has something to do with debugging Klipper in batch mode.

What do you get when you do an ifconfig command in ssh?

You should be seeing something like this at the start of the response:

can0: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 256  (UNSPEC)
        RX packets 1031046  bytes 7522103 (7.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 85056  bytes 566641 (553.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Let’s first make sure can0 exists in your system.

Thanks, I figured it out, the python script referred to klipper.dict in the out directory. So I ran python parsecandump.py candump-2023-04-23_153346.log afac3c9694c2 ../out/klipper.dict and got this:

image

Sorry - the script doesn’t output it into a file, I don’t know how to do it, hence the screenshot.

It seems to exist. Here is what I get:

pi@V24RP:~/klipper/klippy $ ifconfig
can0: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 55460831  bytes 443686648 (423.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 24 (24.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:12:1e:4d  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 79067  bytes 29945480 (28.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 79067  bytes 29945480 (28.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.170  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fda3:85e6:18dd:0:11e4:10f0:29b4:5e2e  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::9241:5f6b:371:8a94  prefixlen 64  scopeid 0x20<link>
        inet6 fda3:85e6:18dd::2de  prefixlen 128  scopeid 0x0<global>
        ether b8:27:eb:47:4b:18  txqueuelen 1000  (Ethernet)
        RX packets 57670  bytes 4416704 (4.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 70942  bytes 66710953 (63.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

cool, do us a favor and post all files you got zipped @https://pastebin.com/

:stuck_out_tongue: yes, that was also my feeling, klipper.dict! I never heard about mcu.dict.

Can you clarify what files you meant? This python script produces none, it only outputs everything to the console, but the console can’t handle that many lines, so I only get the last part of the parse. What do you want me to upload?

Please do the hole procedure again. Do what you what to do until you get your failure.

And than post every file you generated after using parsecandump.py. Just post everything.

Please post the contents of /etc/network/interfaces.d/can0.

It’s also not clear to me if the firmware you flashed on the CANable is meant for the MKS clone. I built candlelight firmware from source specifically for the MKS clone if you want to try it. I’ve been using the non-pro version of the MKS CANable for quite some time on my 2.4 with no issues. I run Huvuds on my A and B motors, and an SB2040 on the toolhead all running through the CANable at 1M.

CANable_MKS_fw.bin.zip (12.7 KB)

Contents of /etc/network/interfaces.d/can0 are:

auto can0
iface can0 can static
	bitrate 5000000
	up ifconfig $IFACE txqueuelen 1000

Previously I also tried:

allow-hotplug can0
	ifface cam0 can static
	bitrate 10000000
	up ip link set can0 txqueuelen 1024

There seems to be no difference - I get the error with either one of them.

I now will try to flash that firmware you provided, than you.

Both of these have problems and won’t work. You’ve specified a bitrate in the top one of 5M which is not valid. You need to change it to 500000, and I would also suggest using a txqueuelen of 128 as recommended in the Klipper docs. Try using this:

auto can0
iface can0 can static
    bitrate 500000
    up ifconfig $IFACE txqueuelen 128

You also need to reboot after editing this file.

I should mention, I’m assuming you’ve flashed your EBB36 with firmware for 500k baud. If you flashed it for a different speed, you need to match that speed in your interfaces file. You can’t mix and match.

Thank you very much. I guess this was what I messed up. I flashed with 1M baud. So now I set my /etc/network/interfaces.d/can0 to:

auto can0
iface can0 can static
    bitrate 1000000
    up ifconfig $IFACE txqueuelen 128

And the printer finally boots. I will now attempt to bring in a minimum amount of macros to perform homing and QGL to see if the issue persists.

Okay, so after this change, printer boots, but it still crashes during QGL with Lost communication with MCU 'can0'

For clarity:
My /etc/network/interfaces.d/can0 is:

auto can0
iface can0 can static
    bitrate 1000000
    up ifconfig $IFACE txqueuelen 128

My printer.cfg is:
printer.cfg (9.1 KB)
(I included the minimum amount of Klicky configs/macro files to make it possible to perform QGL)

sudo dmesg reports:

pi@V24RP:~ $ sudo dmesg
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.10.103-v7+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1529 SMP Tue Mar 8 12:21:37 GMT 2022
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
[    0.000000] random: fast init done
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Reserved memory: created CMA memory pool at 0x34000000, size 64 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x0000000037ffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000037ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000037ffffff]
[    0.000000] On node 0 totalpages: 229376
[    0.000000]   DMA zone: 2016 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 229376 pages, LIFO batch:63
[    0.000000] percpu: Embedded 20 pages/cpu s50828 r8192 d22900 u81920
[    0.000000] pcpu-alloc: s50828 r8192 d22900 u81920 alloc=20*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 227360
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  console=tty1 root=PARTUUID=b1d487b5-02 rootfstype=ext4 fsck.repair=yes rootwait
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 826024K/917504K available (10240K kernel code, 1312K rwdata, 2952K rodata, 1024K init, 862K bss, 25944K reserved, 65536K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] ftrace: allocating 32081 entries in 95 pages
[    0.000000] ftrace: allocated 94 pages with 5 groups
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000]  Rude variant of Tasks RCU enabled.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] random: get_random_bytes called from start_kernel+0x3ac/0x580 with crng_init=1
[    0.000000] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[    0.000007] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[    0.000024] Switching to timer-based delay loop, resolution 52ns
[    0.000310] Console: colour dummy device 80x30
[    0.001131] printk: console [tty1] enabled
[    0.001204] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
[    0.001263] pid_max: default: 32768 minimum: 301
[    0.001489] LSM: Security Framework initializing
[    0.001753] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.001802] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.003274] cgroup: Disabling memory control group subsystem
[    0.003559] CPU: Testing write buffer coherency: ok
[    0.004076] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.005334] Setting up static identity map for 0x100000 - 0x10003c
[    0.005543] rcu: Hierarchical SRCU implementation.
[    0.006481] smp: Bringing up secondary CPUs ...
[    0.007653] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.008929] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[    0.010244] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[    0.010402] smp: Brought up 1 node, 4 CPUs
[    0.010456] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[    0.010488] CPU: All CPU(s) started in HYP mode.
[    0.010515] CPU: Virtualization extensions available.
[    0.011520] devtmpfs: initialized
[    0.029036] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4
[    0.029332] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.029394] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[    0.032438] pinctrl core: initialized pinctrl subsystem
[    0.033640] NET: Registered protocol family 16
[    0.037856] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[    0.043600] audit: initializing netlink subsys (disabled)
[    0.044514] thermal_sys: Registered thermal governor 'step_wise'
[    0.045310] audit: type=2000 audit(0.040:1): state=initialized audit_enabled=0 res=1
[    0.045537] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.045579] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.045901] Serial: AMBA PL011 UART driver
[    0.065276] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[    0.080151] raspberrypi-firmware soc:firmware: Attached to firmware from 2021-12-01T15:08:00, variant start_x
[    0.090163] raspberrypi-firmware soc:firmware: Firmware hash is 71bd3109023a0c8575585ba87cbb374d2eeb038f
[    0.134405] Kprobes globally optimized
[    0.139425] bcm2835-dma 3f007000.dma: DMA legacy API manager, dmachans=0x1
[    0.141802] SCSI subsystem initialized
[    0.142088] usbcore: registered new interface driver usbfs
[    0.142174] usbcore: registered new interface driver hub
[    0.142267] usbcore: registered new device driver usb
[    0.144203] clocksource: Switched to clocksource arch_sys_counter
[    1.863374] VFS: Disk quotas dquot_6.6.0
[    1.863527] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.863751] FS-Cache: Loaded
[    1.864006] CacheFiles: Loaded
[    1.873968] NET: Registered protocol family 2
[    1.874317] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    1.876414] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[    1.876509] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[    1.876654] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    1.876867] TCP: Hash tables configured (established 8192 bind 8192)
[    1.877072] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[    1.877151] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[    1.877456] NET: Registered protocol family 1
[    1.878306] RPC: Registered named UNIX socket transport module.
[    1.878341] RPC: Registered udp transport module.
[    1.878370] RPC: Registered tcp transport module.
[    1.878399] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.880069] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 7 counters available
[    1.883792] Initialise system trusted keyrings
[    1.884080] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[    1.893697] zbud: loaded
[    1.895846] FS-Cache: Netfs 'nfs' registered for caching
[    1.896765] NFS: Registering the id_resolver key type
[    1.896827] Key type id_resolver registered
[    1.896857] Key type id_legacy registered
[    1.897028] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    1.897065] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[    1.898297] Key type asymmetric registered
[    1.898331] Asymmetric key parser 'x509' registered
[    1.898403] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[    1.898443] io scheduler mq-deadline registered
[    1.898473] io scheduler kyber registered
[    1.902011] bcm2708_fb soc:fb: FB found 1 display(s)
[    1.914701] Console: switching to colour frame buffer device 82x26
[    1.922021] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 656x416
[    1.931116] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
[    1.936046] bcm2835-rng 3f104000.rng: hwrng registered
[    1.939042] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[    1.945056] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[    1.962602] brd: module loaded
[    1.977575] loop: module loaded
[    1.982145] Loading iSCSI transport class v2.0-870.
[    1.986802] usbcore: registered new interface driver lan78xx
[    1.989525] usbcore: registered new interface driver smsc95xx
[    1.992124] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[    2.723189] Core Release: 2.80a
[    2.725758] Setting default values for core params
[    2.728272] Finished setting default values for core params
[    2.931149] Using Buffer DMA mode
[    2.933673] Periodic Transfer Interrupt Enhancement - disabled
[    2.936287] Multiprocessor Interrupt Enhancement - disabled
[    2.938874] OTG VER PARAM: 0, OTG VER FLAG: 0
[    2.941416] Dedicated Tx FIFOs mode

[    2.944431] WARN::dwc_otg_hcd_init:1074: FIQ DMA bounce buffers: virt = b4114000 dma = 0xf4114000 len=9024
[    2.951524] FIQ FSM acceleration enabled for :
               Non-periodic Split Transactions
               Periodic Split Transactions
               High-Speed Isochronous Endpoints
               Interrupt/Control Split Transaction hack enabled
[    2.962491] dwc_otg: Microframe scheduler enabled

[    2.962572] WARN::hcd_init_fiq:457: FIQ on core 1

[    2.966892] WARN::hcd_init_fiq:458: FIQ ASM at 807cb8b8 length 36

[    2.971322] WARN::hcd_init_fiq:497: MPHI regs_base at b8810000
[    2.975773] dwc_otg 3f980000.usb: DWC OTG Controller
[    2.978085] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[    2.980453] dwc_otg 3f980000.usb: irq 89, io mem 0x00000000
[    2.982774] Init: Port Power? op_state=1
[    2.985020] Init: Power Port (0)
[    2.987542] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
[    2.992130] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.994611] usb usb1: Product: DWC OTG Controller
[    2.996969] usb usb1: Manufacturer: Linux 5.10.103-v7+ dwc_otg_hcd
[    2.999364] usb usb1: SerialNumber: 3f980000.usb
[    3.002543] hub 1-0:1.0: USB hub found
[    3.005026] hub 1-0:1.0: 1 port detected
[    3.008849] dwc_otg: FIQ enabled
[    3.008862] dwc_otg: NAK holdoff enabled
[    3.008874] dwc_otg: FIQ split-transaction FSM enabled
[    3.008892] Module dwc_common_port init
[    3.009183] usbcore: registered new interface driver usb-storage
[    3.011851] mousedev: PS/2 mouse device common for all mice
[    3.015549] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[    3.020736] sdhci: Secure Digital Host Controller Interface driver
[    3.023275] sdhci: Copyright(c) Pierre Ossman
[    3.026573] mmc-bcm2835 3f300000.mmcnr: could not get clk, deferring probe
[    3.029819] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
[    3.032639] sdhci-pltfm: SDHCI platform and OF driver helper
[    3.037180] ledtrig-cpu: registered to indicate activity on CPUs
[    3.040203] hid: raw HID events driver (C) Jiri Kosina
[    3.042958] usbcore: registered new interface driver usbhid
[    3.045600] usbhid: USB HID core driver
[    3.053493] Initializing XFRM netlink socket
[    3.056149] NET: Registered protocol family 17
[    3.058767] Key type dns_resolver registered
[    3.061732] Registering SWP/SWPB emulation handler
[    3.064266] registered taskstats version 1
[    3.066613] Loading compiled-in X.509 certificates
[    3.069822] Key type ._fscrypt registered
[    3.072147] Key type .fscrypt registered
[    3.074505] Key type fscrypt-provisioning registered
[    3.088018] uart-pl011 3f201000.serial: there is not valid maps for state default
[    3.092879] uart-pl011 3f201000.serial: cts_event_workaround enabled
[    3.095420] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 114, base_baud = 0) is a PL011 rev2
[    3.102649] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[    3.106958] mmc-bcm2835 3f300000.mmcnr: mmc_debug:0 mmc_debug2:0
[    3.109484] mmc-bcm2835 3f300000.mmcnr: DMA channel allocated
[    3.134353] Indeed it is in host mode hprt0 = 00021501
[    3.198677] sdhost: log_buf @ (ptrval) (f4113000)
[    3.239557] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    3.243678] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    3.247762] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    3.251130] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[    3.256441] of_cfs_init
[    3.259010] of_cfs_init: OK
[    3.262501] Waiting for root device PARTUUID=b1d487b5-02...
[    3.275535] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[    3.342603] mmc0: host does not support reading read-only switch, assuming write-enable
[    3.347499] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    3.350239] Indeed it is in host mode hprt0 = 00001101
[    3.414448] mmc0: new high speed SDHC card at address aaaa
[    3.417931] mmcblk0: mmc0:aaaa SD32G 29.7 GiB
[    3.423519] mmc1: new high speed SDIO card at address 0001
[    3.428482]  mmcblk0: p1 p2
[    3.454310] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[    3.456659] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[    3.584653] usb 1-1: New USB device found, idVendor=0424, idProduct=2514, bcdDevice= b.b3
[    3.589370] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.592729] hub 1-1:1.0: USB hub found
[    3.595432] hub 1-1:1.0: 4 ports detected
[    3.648351] EXT4-fs (mmcblk0p2): recovery complete
[    3.653103] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    3.658477] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    3.669267] devtmpfs: mounted
[    3.679548] Freeing unused kernel memory: 1024K
[    3.682763] Run /sbin/init as init process
[    3.685421]   with arguments:
[    3.685432]     /sbin/init
[    3.685443]   with environment:
[    3.685454]     HOME=/
[    3.685465]     TERM=linux
[    3.914269] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    4.044637] usb 1-1.1: New USB device found, idVendor=0424, idProduct=2514, bcdDevice= b.b3
[    4.049986] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    4.053725] hub 1-1.1:1.0: USB hub found
[    4.056689] hub 1-1.1:1.0: 3 ports detected
[    4.154271] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    4.261393] systemd[1]: System time before build time, advancing clock.
[    4.301277] usb 1-1.2: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[    4.306772] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    4.309591] usb 1-1.2: Product: stm32f446xx
[    4.312323] usb 1-1.2: Manufacturer: Klipper
[    4.315084] usb 1-1.2: SerialNumber: 400043000451303431333234
[    4.420807] NET: Registered protocol family 10
[    4.425104] Segment Routing with IPv6
[    4.505866] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[    4.515448] systemd[1]: Detected architecture arm.
[    4.593923] systemd[1]: Set hostname to <V24RP>.
[    4.624330] usb 1-1.3: new full-speed USB device number 5 using dwc_otg
[    4.758316] usb 1-1.3: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
[    4.764271] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    4.767263] usb 1-1.3: Product: CANable-MKS gs_usb
[    4.770436] usb 1-1.3: Manufacturer: makerbase
[    4.773154] usb 1-1.3: SerialNumber: 001C00355741570D20393033
[    5.054284] usb 1-1.1.1: new high-speed USB device number 6 using dwc_otg
[    5.184863] usb 1-1.1.1: New USB device found, idVendor=0424, idProduct=7800, bcdDevice= 3.00
[    5.190352] usb 1-1.1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    5.470818] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized): No External EEPROM. Setting MAC Speed
[    5.499824] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized): int urb period 64
[    5.552735] random: systemd: uninitialized urandom read (16 bytes read)
[    5.569920] random: systemd: uninitialized urandom read (16 bytes read)
[    5.574405] systemd[1]: Listening on Journal Socket.
[    5.581156] random: systemd: uninitialized urandom read (16 bytes read)
[    5.592343] systemd[1]: Starting Restore / save the current clock...
[    5.600212] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[    5.611215] systemd[1]: Listening on Syslog Socket.
[    5.618867] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[    5.630231] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[    5.641080] systemd[1]: Listening on udev Kernel Socket.
[    5.864043] mc: Linux media interface: v0.10
[    5.907659] videodev: Linux video capture interface: v2.00
[    5.959066] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[    5.966234] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[    5.968743] [vc_sm_connected_init]: start
[    5.972080] [vc_sm_connected_init]: installed successfully
[    6.000203] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[    6.047573] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[    6.367928] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    6.521192] systemd-journald[120]: Received request to flush runtime journal from PID 1
[    7.173891] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
[    7.181790] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13
[    7.182279] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14
[    7.182679] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15
[    7.183138] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16
[    7.183167] bcm2835-isp bcm2835-isp: Register output node 0 with media controller
[    7.183209] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
[    7.183231] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
[    7.183252] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
[    7.183470] bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp
[    7.203627] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[    7.241543] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[    7.241628] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[    7.247905] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[    7.247964] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[    7.256263] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[    7.256320] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[    7.259702] bcm2835-codec bcm2835-codec: Device registered as /dev/video18
[    7.259757] bcm2835-codec bcm2835-codec: Loaded V4L2 image_fx
[    7.261831] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[    7.270875] bcm2835_audio bcm2835_audio: card created with 8 channels
[    7.631116] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    7.636921] CAN device driver interface
[    7.642777] gs_usb 1-1.3:1.0: Configuring for 1 interfaces
[    7.644460] usbcore: registered new interface driver gs_usb
[    7.743364] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[    7.745029] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    7.745797] usbcore: registered new interface driver cdc_acm
[    7.745816] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    7.784772] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
[    7.849990] brcmfmac: F1 signature read @0x18000000=0x15264345
[    7.877801] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    7.884787] usbcore: registered new interface driver brcmfmac
[    8.173404] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    8.210731] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov  1 2021 00:37:25 version 7.45.241 (1a2f2fa CY) FWID 01-703fd60
[    8.775615] random: crng init done
[    8.775642] random: 7 urandom warning(s) missed due to ratelimiting
[    9.468919] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[   10.148728] 8021q: 802.1Q VLAN Support v1.8
[   10.314241] Adding 262140k swap on /var/swap.  Priority:-2 extents:2 across:286716k SSFS
[   10.332944] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[   10.521145] 8021q: adding VLAN 0 to HW filter on device eth0
[   15.875783] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   17.760770] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.wlan0.retrans_time - use net.ipv6.neigh.wlan0.retrans_time_ms instead
[   30.031546] can: controller area network core
[   30.031627] NET: Registered protocol family 29
[   30.043749] can: raw protocol
[  111.595151] usb 1-1.2: USB disconnect, device number 4
[  113.165586] usb 1-1.2: new full-speed USB device number 7 using dwc_otg
[  113.312610] usb 1-1.2: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[  113.312623] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  113.312630] usb 1-1.2: Product: stm32f446xx
[  113.312637] usb 1-1.2: Manufacturer: Klipper
[  113.312643] usb 1-1.2: SerialNumber: 400043000451303431333234
[  113.314773] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device

ifconfig reports:

pi@V24RP:~ $ ifconfig
can0: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 128  (UNSPEC)
        RX packets 1282863  bytes 10257756 (9.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1749  bytes 10162 (9.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Klippy.log right after crash:
klippy(20).log (457.6 KB)

In my experience this is usually a wiring issue. With the printer powered off, make sure you have 60 ohms between H and L on the CAN bus wires. If your CAN wires aren’t twisted, I would suggest doing that as well.

Shouldn’t it be 120 Ohms? Everywhere I read it says 120. My EBB36 and CANable have jumper pins labeled “120 Ohm”, and I put the jumpers on both of them as I was instructed by several people. I measured the resistance between the lines, and it is 119.6 Ohms. Please clarify. I will attempt to twist the wires now.

Two 120 ohm resistors connected in parallel is 60 ohms. If you’re reading 120ohm, then one resistor is not connected.

Both jumpers are definitely in place, I double checked. Am I measuring it wrong maybe? I am placing my tester leads on the CAN_LOW and CAN_HIGH terminals on the CANable adapter.

Try disconnecting the wiring and measure the resistance on both boards. You should have 120 ohms on each board, and 60 ohms when the wiring is connected between them. And yes, you are measuring in the correct place. The resistance is measured between H and L.

It should be ~60Ohms. If it’s 120, then something isn’t in place.

Which version of CANable do you have? If it’s Version 1.0 or Pro, then you need to put in J4, If it’s 2.0, then the jumper needs to be on pins 1 & 2 of J2.

For your EBB36, if it’s Version 1.0, then you need to put a jumper on J3. If it’s Version 1.1, then you have to make sure the jumper is on JP1.

@jakep_82 has a good suggestion to disconnect your CAN bus cable and measure the pins on the CANable and the EBB36.

I wouldn’t recommend running the data rate at 1Mbps, I’m running multiple printers at 500kbps without issues. Remember that you have to rebuild the Klipper firmware for the EBB36 when you change the data rate.

Okay, clearly something was wrong there. The EBB36 was showing 0 Ohms when everything was disconnected. I replaced the jumper with a new one, and now it reports 120 Ohm as well. 60 Ohms between lines with everything connected. I guess my jumper was simply worn out.

I have also twisted the low/high cables, and after all these changes, I finally managed to get QGL from start to finish. I am going to attempt a long dry print overnight now, and if it fails, I will reflash EBB36 firmware with 500k baud and retry. Will keep you posted. And thank you for sticking out with me, guys. Really appreciate your patience.

For reference, I have CAN running at 1M on both of my Vorons. My Switchwire has an EBB42 on the toolhead (still running an old CW1 extruder), and before that it had a Huvud on it. I ran it at 500k for the first year with a Huvud 0.5, but when I upgraded to the 0.61 a year ago I found that 500k was insufficient to handle the bandwidth required for input shaper tuning with the new built in ADXL345. YMMV, but for me I’ve never completed shaper tuning at 500k and I’ve not had any real problems at 1M over the past year.

Good to know - I’ve never done shaper tuning.

Are you using the controller (I’m using CanBoot with the Octopus) or an USB to CAN adapter?

I’m using the MKS CANable (non-pro) on my V2.4, and a UCCB 2 on my Switchwire. I was using an Octopus in bridge mode on the 2.4 for a while, but decided to standardize on the Manta M4P board and CB1 so I could sell all my Pis while the prices are absurd.

Manta M4P on a Voron 2.4? Aren’t you short by two stepper drivers for X/Y movement (I presume the four with the M4P are for the Z axis).

Why wouldn’t you go with an M8P?

If you read my earlier posts in this thread, you’ll see that I have Huvuds on my A and B motors. I have only 4 wires in my Z chain, and they connect to a CAN distribution PCB which distributes CAN and power to the 3 different CAN boards inside my chamber (SB2040 on the toolhead).

Okay, guys, after the last changes (fixing the 120 ohm jumper and twisting the wires), I still had one more shutdown. I was also asking about this issue on Voron discord, and guys there suggested that it’s actually a mistake not to connect the grounds of the PSUs. Apparently USB connection might not ground some devices enough. So on top of the changes and fixes we did, I restored the ground connections between PSUs and also grounded the CANable through the terminal next to the com lines. And it appears we finally solved the issue. I just ran three dry 5h prints, and then one actual print - not a single failure so far.

I am still not entirely sure what was the cause, but it feels like it was a combination of things, and everything had to be set up just right for the CAN to finally work reliably. I guess CAN is just a very sensitive device at this stage of it’s development, and any little thing can cause it to crash.

I can’t begin to thank you guys enough for the time and effort you spent to help me with this. You saved my printer.

To whoever reads this post later, this is the final setup that worked for me:

Wiring:

image

-Jumpers on 120 Ohm pins both on EBB36 and on CANable (check if you actually get 60 Ohm between CAN_LOW and CAN_HIGH lines)
-Twisted CAN_LOW and CAN_HIGH wires all the way from CANable to EBB36;
-18 AWG or thicker wires from +5V and -5V PSU to RPi 5V and GND pins. Ensure you are not getting undervoltage messages by entering SSH into the Pi, and running sudo dmesg.

/etc/network/interfaces.d/can0:

auto can0
iface can0 can static
    bitrate 1000000
    up ifconfig $IFACE txqueuelen 128

CANable firmware, if you are using a MKS clone like I did - the one @jakep_82 provided: https://klipper.discourse.group/t/issues-with-canable/7970/40?u=laukejas

That’s about it. Again, thanks to everyone who helped me figure this whole thing out. You guys are amazing.

Sorry, but something isn’t right here. The additional ground wires should not be required as you establish a common ground between devices with the USB connections. I just checked on one of my printers with an Octopus, BTT USBtoCAN board and separate rPi and verified that this true.

Could you do me a favour and disconnect the additional ground cables (ie restore the circuit to the one you drew two days ago) and check the resistance between -24V on the 24V PSU, -5V on the 5V PSU, GND on the CANable? With the USB cables in place, the resistance should (actually, must) be zero. If you disconnect the USB connectors, the resistances should go up to very high values.

CAN is actually a very mature and very robust communications medium when wired correctly. It’s been a standard in the automotive industry for about 30 years.

I’ve never used CANable, I’ve only worked with the USB2CAN boards as well as the CAN controllers built into the Octopus and Manta m8P boards, so I can’t comment on its operation but I’ve never had any issues like the ones you have been describing with my set ups.

I’d be interested in seeing images of your cable and how you’ve wired it as I wonder if there is a problem them (although CAN is very robust in different situations).

I tested what you requested. With current wiring, all resistances between grounds show as 0 Ohms, as expected. When I restore the original wiring, I get this:

Between -24V on the 24V PSU and -5V on the 5V PSU: 0.2Ω
Between -24V on the 24V PSU and GND on the RPi: 0 Ω
Between -5V on the 5V PSU and GND on the RPi: 0 Ω
Between -24V on the 24V PSU and GND on the CANable: 0 Ω
Between -5V on the 5V PSU and GND on the CANable: 0 Ω
Between -24V on the 24V PSU and GND on the CANable: 0 Ω

So everything should be as expected. And yet, I just tried to run the printer again with this wiring - it crashed again during QGL. Tried 5 times, all crashed. Restored the additional grounds - working without issues (so far). It is really puzzling.

@laukejas

Just to clarify: Either you have GND or a negative voltage.

-24V and 24V makes 48V

Don’t mix up GND with this negative voltage stuff.

There are actually PSUs with -24V, GND and 24V clamps.

Thanx. Did you check with the two USB cables removed? In that case, you should have open circuits between the 24V PSU and the 5V PSU negative voltages as well as between the CANable and both of the supplies.

Now, just some follow up questions on the wiring (and follow up with the comment from @EddyMI3D):

  1. How are you wiring the line in power into the 24V PSU and the 5V PSU? Do you have LINE going into “L” on the two power supplies and NEUTRAL going into “N” on the two power supplies?
  2. What about the EARTH from the line in power? Where is it connected? I would expect that it goes to the printer’s frame as well as the GND Symbol (upside down TV Antenna) on the 24V PSU and 5V PSU.
  3. How are the 24V PSU and the 5V PSU mounted to the frame?

@EddyMI3D is right, there may be a few 3D printer power supplies that are marked with something like as being 24V with a “+24V” and a “-24V” along with a GND and being marked as being a “24V Power Supply”. You typically see that on PC power supplies that are labeled as being “12V”. But I don’t think that’s the case here as you have a Voron 2.4, I expect that you’re working with the standard Mean Well LRS-200-24 or LRS-350-24 that many people (me included) use along with the RS-25-5 (or IRM-605ST which I use) so I don’t think anything will have a “Gnd” pin that is different from the negative voltage.

I’m picking up on the post from @EddyMI3D as I wonder if you have something that is causing a ground shift and when you put in the explicit wires, you’re getting a consistent ground (which is a good thing) but there is current flowing through it (which ranges from quite bad to extremely bad).

Again, with the wiring diagram you put a few days ago, you shouldn’t need to put in these extra ground wires.

Could you please confirm how you wired your AC line in with regards to the two power supplies?

What wire gauge do you use for the 24V rails from PSU to the Octopus board and the EBB36?
And what gauge for the 5V rails?

Hey guys, apologies for late reply, I was down with the flu. @mykepredko, to answer your questions, with USB cables removed, I had no continuity between grounds.
About power line wiring: it is wired exactly as per the Voron 2.4 assembly manual. I double-checked it. To save time on drawing new diagram, I’m just attaching one from the manual. My wiring matches this.

image

And yes, I do have earth connected to the frame. I used a dremel to expose bare metal on one of the frame members, drilled and tapped an M3 hole, clamped the earth wire with a bolt, and checked for continuity. Both PSUs are mounted to the frame using 3D printed brackets that attach to the DIN rails. Also as per the manual.

@EddyMI3D , thank you for clarification on the markings. My PSUs have “V+” and “V-” marked on them. I must have mistaken that for “+24V” and “-24V” by looking at some examples on the internet or something. My apologies. In any case, multimeter shows 24V between them, so it’s a regular PSU. Same with the 5V one. To answer your last question, I was using 18 gauge from PSU to Octopus. For the EBB36 I am not sure - the wires from the kit I linked to previously, it doesn’t state what gauge it is. For the 5V rails, also 18 gauge.


date-created: 2024-09-22 02:39:57 date-modified: 2024-09-22 02:46:52

Rook |

anchored to 410.00_anchor tags: #3DP #Crafting #electronics


Overview

This printer builds upon the concept of : https://www.printables.com/model/798733-rook-2020-mk2 Which is the mk2 and steel version of the Rook 3D-Printer which can be - mostly at least - 3d printed.

It acts as entry level CoreXY machine that helps to learn about the structure and all around. Furthermore this printer is great for tinkering or to achieve high speed printing –> due to its rigid structure and small size.

I’ve build the MK1 version already and decided to rebuilt it with the metal frame and all. For that matter I had to reorder some parts.

Build LOG

On DayPlanner-20240921 I’ve continued building the rook. I began with the frame some month before…

Current status in images:


date-created: 2024-04-08 12:32:38 date-modified: 2024-08-28 01:10:43

Ender 3 | Yuria

anchored to 410.00_anchor


Overview:

This is my first 3D printer which I was gifted by 025.19_Svea_Victoria_mann s Dad back in 2018 or so. He bought it once to tinker and play with it yet did not have enough time to make much with it or maintain so he offered me to take it with me to play around and well to learn something - He was the kind to see and hope that people he knows are using their skillset (in case they see some in people) and extend it by tinkering and training. Especially he wanted to give me the opportunity to explore fun topics and things and thus gave me the printer or other tools/material to play and learn with. After receiving it I began learning and playing with the printer and began to mod it soon after as well. My first upgrade were minor parts for aesthetics of the printer, then I upgraded to a better part cooling, then hotend and another pcb (MKS Robin E3). A second Z-screw followed afterwards and I also changed some smaller mechanical parts like the gears, extruder and such.

Feature-Set:

As of now it has the following features:

  • MKS Robin E3 motherboard with Klipper
  • RPI 2 running mainsail, klipper
  • dual z lead screw
  • pei sheet bed + magnet sheet
  • (planned / in progress) stealthburner toolhead with direct drive
    • with 5050 mod link
  • (planned / in progress) electronic housing (switchwire-esque) : https://www.printables.com/model/385532-ender-3-pro-voron-themed-electronics-enclosure/files
  • V6 hotend (trianglelabs) with bowden setup
  • (planned) ceramic heating part
  • BMG Extruder Clone
  • meanwell power supply
  • (planned / in progress) sleeved cables

Log

On DayPlanner-20240407 I cleaned and disassembled the hotend, electronic compartment. I planned to swap the hotend with a heroMe Gen7, however I thought of building an afterburner to refine this whole build a little more. Furthermore I came to think about building the electronics enclosure to have an opportunity to improve my cable management.

Currently Rebuilding with new enclosure and afterburner HOTEND

On DayPlanner-20240518: I was redoing the cables and began sleeving them. Further I have continued assembling the Stealthburner –> decided to build it with a clockwork direct extruder too!

On DayPlanner-20240827

I calibrated her input further, basically testing:

  • overhangs which are currently fine up to 45 Degree
  • print speed –> smth of the speeds of my voron right now, but its not really calibrated for speed either !
  • printing temperature

Whats missing :

  • pressure advance!
  • calibrating resonance –> would help tremendously with ghosting on Y-Axis and X-Axis
  • improved speed!

Her quality is fine so far I think:


date-created: 2024-04-08 12:22:10 date-modified: 2024-05-21 10:39:08

My Voron Trident 350 | Eleonora

anchored to [[410.00_anchor|410.00_anchor]]


Overview

In December 2023 [[DayPlanner-20231222]] I bought a Voron Trident 350 from Gizzle.

It took me some time to transport it to Tübingen as I’ve asked several people whether they would travel across Nürnberg to pick up the machine on the go. Later we also anticipated to gather the printer ourselves - depicted in [[week-2024-07]] - in a small journey with a rented car however this failed due to planning reasons and such. I then drove by train and transported it for a whole day.

I love this printer a lot, its pretty / cute and all.

I bought it for 850€


Configuration

  • CR3D Bett mit Keenovo Heater und Schnitzel-PEI
  • LDO 2504 auf XY und LDO Spec Motoren auf Z
  • LDO Frame
  • Vonwange Rails auf Y und Z
  • Lightweight X-Achse mit CNA Medium Preload Rail
  • Fushi Lager mit Pins Mod in den XY Joints und Idlern.
  • Rapidburner Toolhead mit Dragon UHF und VzHextrudort Extruder
  • Mellow SHT V2 CAN Toolboard
  • Euclid Probe
  • Fysetc Spider Board mit TMC2209 Treibern

Nitpicks in Config

The current Offset for PEI-Sheets is set to : 0.325+ default one the default is set to: 10.600


Log of events

the first week after gathering it - [[week-2024-08]] - I was calibrating and testing it. Especially to understand the printer and its components better.

I wanted to print some test with ASA to get replacement parts.

What I noticed during the time:

  • Z-Offset is not correct and had to be corrected up
  • several screws were loose –> expected after transport
  • I tensioned the belts - without enough experience to evaluate whether its good or not
  • when printing ASA the can board seems to disconnect after some time –> due to heat supposedly, as the logs suggest

[!Important] Culprit of sudden shutdown Found this issue on [[DayPlanner-20240224]] I may have found the issue causing the printer to randmly shutdown after printing for a while -> usually around 2-3hrs at most. It seems that the system is running low on space and will simply shutdown due to this error –> klipper log denoted that there was no space left to log and thus it stopped operating. I can fix this easily luckily! Yet I will have to reinstall everything onto a new sd-card soon-ish. I will buy a replacement sd-card on monday in person to have the replacement ready!

[!Warning] wrong suspect aboves possible suspect for causing random shutdowns was proven wrong. I monitored the space available and there was no correlation between the available disk space and the availability of my printer. In fact it did not change much while it was running and crashed still!

I ran a lot of tests on [[DayPlanner-20240225]] to find the issue or to potentially fix it. So far - 2020 - I was not able to find the issue itself. I tried reflashing the board - but failed connecting to it in the first place. Then I also found out that the cable for the umbilical cord was loose and resoldered that. This fixed an issue that occurred while searching for the solution of the former so at least something gained. I ran through some forum entries denoting the following:

  • possible wiring issue -> not the case, causes are differently
  • the 64-bit version of raspbian that causes the usb-driver to have issues from time to time. I tried solving it by using the recommended driver instead. see here
    • https://github.com/raspberrypi/firmware/issues/1804
    • https://github.com/jens-maus/RaspberryMatic/issues/1002

The overall pattern of this issue is rather strange and seemingly random -> sometimes it starts and works for some time, sometimes it dies directly after starting the system.

I’m considering buying an RPI4 to maaybe overcome this issue, although I cannot really pin point the issue to be coming from the RPI3

The USB-driver may have fixed the issue? At least right now I was able to have like 2x continuous prints without the system crashing? –> it was like 4hrs in total I think. This sounds rather good but I dont want to set the hopes too high yet. I will see tomorrow!

[!Tip] Issue cause The described issue was caused by one of the cables of the canbus coming loose. I had this like 2 - 3 times already and its always been the same cable. fixed it on DayPlanner-20240520 once more and bought a replacement cable in case its happening again!

Calibration of rotation_distance (esteps) for Klipper

  1. Mark you filament 120mm above the entry to your extruder.
  2. Heat up the nozzle to your desired printing temperature
  3. Home all axis to get in “printer ready” state
  4. Lift up your nozzle by 50mm (to make room for the filament!)
  5. Execute the following commands (one by one)
    5a) G92 E0
    This resets the “extruded material” value to 0.
    5b) G1 E100 F100
    This extrudes 100mm filament with 100mm/min.
  6. Now measure the distance between your extruder entry and the mark on your filament.

I.e if it is 28mm instead of 20mm (120mm - 100mm) than you are UNDERextruding by 8mm ==> 92mm instead of 100mm. If it shows 15mm than your are OVERextruding by 5mm ==> 105mm.

Now calc:

c := current value in configuration.cfg
m := measured left over filament
d := desired mm
n := new value for configuration.cfg

((120 - m) / d) * c = n
((120 - 28) / 100) * 0.010500 = 0,009660
(92 / 100) * 0.010500 = 0,009660

As you can see, for underextrusion the new value is lower than the old one.
You may play around with the last two numbers to fine tune.

[Things] I wish I had known

source: docs.vorondesign.com anchored to [[400-499_avocation/440-449_general_computer_science/441_OperatingSystems/441.00_anchor|441.00_anchor]] reading time approx: 4–5 minutes


Introduction

Advice commonly given to newcomers is to ask questions in Discord. After reading through the docs, the BOM, the sourcing guide, and watching Nero’s videos, a person normally has the basics down and Discord fills in the cracks that aren’t covered or things just missed. Some things, though, are not obvious to ask, so without months of lurking on Discord and watching discussions, important details may be missed. Often this information is just part of the fast-paced learning the Voron community goes through as recommended practices adjust over time as a result of community learning.

This guide as a result intends to be a summary of lessons learned that can be quickly adjusted over time. Information is meant to be sparse but searching in Discord or asking questions can fill in the gaps. The lessons are focused on the 2.4 printer, but may also apply to other printers.

Lessons

Expensive

  1. Bed tacos are expensive and can be avoided by not heating too fast and not tightening fasteners cold! When tightening do one screw tight, 2 firm, and last one loose or not even there. You can confirm a taco by rotating the bed 90 degrees then doing a bed mesh to see if it rotates as well. Twisted extrusions could also make a bed look tacoed.
  2. Nozzle crashes can bend the frame.
  3. The button by the control knob is an e stop but only kills the z motors … Wire the boards together and it will be for them all
  4. The kits from MagicPhoenix, DigMach, or most vendors with channels on the Voron Discord server will likely be of good quality. In contrast, most kits from China are considered suspect quality, especially for the power supply and SSR.
  5. Important: Do not unplug or re-plug motors from MCUs without powering down the printer. Damage to MCU may result.
  6. Do not move the the stepper motors fast by hand if they are plugged in, since they act as generators, and the generated back current can damage your stepper drivers.

Build

  1. The pulleys used on the Z motors are 16-tooth pulleys. At a glance, they look almost identical to the 20-tooth pulleys used elsewhere in the printer.
  2. Z cubes should move a little.
  3. Loosen screws on gantry to derack.
  4. While not spec, most people use a PEI on spring steel attached the the bed with a magnet.
  5. Common options for magnet (don’t use Energetic) Whambam, or McMaster.
  6. How do people hide the wires? (There is a 3d printed wire hider on Thingiverse that fits 2020 extrusions.)
  7. T nuts what are they the types and how to put them in – Nero’s video on frame has some information on them.
  8. You can tell Keenovo to not put on adhesive so that high-temp RTV silicone glue can be used instead.
  9. Belt tension meter
  10. Nero in a video mentioned that RobotDigg’s black rails are more brittle.
  11. Misumi has economy alternatives.
  12. Spare belts are handy since local sources are often pricey.
  13. There is a printable corner tool for lining up the frame.

AfterBurner

  1. There is a catch on the claw in the AfterBurner that fits into a notch. If you filament does not grip tight at all, check out the diagrams in the build guide to see if this is the issue.
  2. Hone the AfterBurner filament path with a very sharp drill bit or a reaming bit.

Wiring

  1. Connectors for hotend and the probe could be put below the cover to help save space in the cover and make toolhead swaps faster
  2. Wago wire nuts can help the build be more tidy.
  3. Use PTFE wiring from Remington.
  4. Only wiring on the drag chain needs to be PTFE, silicone, or etc.
  5. The heater should be 20 gauge but the others on the drag chain can be 24 gauge.

Things not in the sourcing guide

  1. DIN rails – DigiKey has some
  2. Amazon has cheap SSR mounts

Tips for better prints - HackMD

source: hackmd.io anchored to 410.00_anchor

Introduction

With some care and preparation your Voron printer is able to produce high quality prints in a wide range of materials. This page contains some of the tips and best practices collected from the Voron community.

For practical purposes this page focuses on printing with ABS filaments on a Voron 2 series printer. However; many of these tips will translate to other printer models and filaments.

If you are looking for some inspirations and impressions stop by the #voron-showcase channel in the Voron Discord.

Filament Choice

3d printing filaments from different manufacturer will vary in formulation and physical properties which causes them to behave vastly different. Even filaments from the same manufacturer may show different characteristics depending on the filament color and sometimes even the batch of the filament.
Not all manufacturers will meet the dimensional tolerances they specify for their filaments, you may want to invest in some measuring tools and verify their claims.

When picking a filament include price and availability into your considerations:

  • A “boutique material” may have a prohibitively high cost or limited availability… the one spool you got may print great, but it doesn’t do you any good once it’s empty.
  • “Cheap as dirt” filament is often cheap for a reason, be mindful of particulates in the filament, dimensional tolerances and quality of the moisture seal.

If possible, try different filaments from different brands and find some that work for you and your printer. Once you found a filament stock spare spools depending on your printing habits.

Depending on your local climate you may want to take extra precautions when storing opened filament spools for longer periods of time. Unless you live in a dry climate consider purchasing a large airtight container and some desiccant packs for medium/long term storage.

If your printer is in a humid environment (your basement may qualify as humid) consider building a “filament dry box” to protect your filament at all times.

Printer maintenance

  • Periodically check the printers hardware and make sure all components are properly attached and securely fastened. Check printed parts for stress signs (white discoloration) and cracks.

  • Pay attention to the X carriage. You should not be able to rock the printhead up and down. If you can move it check the seating of the Quick Change Toolhead and the attachment of the carriage to the linear movement.

  • Verify the proper seating of the PTFE tube, it must be inserted all the way and must not rock in and out. If the tube backs out check the filament path and coupler.

  • Check the hotend, make sure it does not wiggle and is securly fasted. If you are using a V6 make sure the block is properly attached to the heatbreak.

  • Dust near a pully is indicative of a belt rubbing on the flange of a pully. This will introduce unwanted artifacts into the print and should be resolved.

  • Periodically check belt tension. Belts will stretch during their break in period. If the belt consistently looses tension check for a hardware fault.

  • Check the extruder for filament shavings and other debris. If you find an exessive amount the filament path may be obstructed.

  • Relubrication of the movement is only required every few thousend hours if the recommended lubrication was used. Oil based lubrication may need to be reapplied on a much short schedule.

  • Other consumeable need to be replaced on a suitable schedule. PTFE tubes on a 500-1000h schedule, nozzles and PEI as required. Refer to the Consumables section.

Preparation/Startup routine

A consistent print preparation and startup routine is essential in achieving consistent print results.

  1. Clean print chamber
    Dust and debris will collect in your print chamber and may transfer to the print if left unchecked. Periodically remove any dust and debris by wiping down all surfaces or by the use of compressed air.

  2. Clean print surface
    The print surface needs to be dust, oil and fat free as those will impact print adhesion. Clean the print surface with a suitable degreaser before every print. Isopropyl alcohol (IPA) is readily available and an excellent degreaser.

  3. Flex-plates / removeable surfaces
    If you are using a flexplate, springsteel or other type of removeable print surfaces be mindful of it’s orientation and the printers state. Depending on orientation of the plate and temperature of the bed the surface may deform slightly different causing inconsistent print results.
    Always install the flex-plate in the same orientation and the same bed state (hot vs cold). Tests with springsteel sheets seem to suggest that they are best installed after the bed has reached temperature and had time to equalize.
    If you are placing it on a hot bed use appropriate PPE to prevent burn injuries.

  4. Bed temperature
    The bed temperature reading mat does not reflect the temperature of the print surface, rather it reads the temperature of the heater mat. In addition, the plates temperature might require an additional 10+ minutes to equalize.

  5. Chamber temperature
    The print chamber of a Voron 2 is passively heated by the print bed. As the temperature in the chamber has a direct impact on material expansion and some of the sensors found inside the printer let the temperature reach a stable point before starting a print. This process can take upwards of 30 minutes.
    Set the bed temperature to the desired temperature for printing and let the printer “heat soak” until the chamber temperature reaches a stable point in the >40°C range.

  6. Axis movement
    Repeatedly moving the printer’s axis over the full range of movement can help with the consistency during leveling/homing and initial layers. This can be combined into the “heat soak” and used to prevent timeouts.

  7. Homing and gantry leveling
    The inductive probe used for Quad Gantry Leving (QGL) is sensitive to temperature changes. Ensure that the chamber temperature is stable before running the QGL. The QGL can run with the hotend at temperature or with a cold hotend, experiment to see what gives you the most consistent results for your printer.
    The final homing before the start of a print must be done with a fully heated hotend to ensure repeatability of the z position.

  8. Hotend heating, ooze and purge
    During heatup filament may ooze from the nozzle, remove this from the nozzle prior to the final homing operation. The ooze may cause inconsistency in the homing and transfer to the print.
    Filament left in the heated zone of the hotend for prolonged period of times will deteriorate. Use slicer generated purge features (e.g. “skirts”) or dedicated purge line to fully remove the “toased” filament from the heated zone prior to printing any actual parts.

Slicer choice

All modern mainstream slicers are able to produce high quality prints when properly configured for your printer. The Voron community maintenances a set of slicer profiles that you can use as a known good starting point for further tuning.

Proper understanding of slicer settings will have a tremendous impact on print results. Try to learn more about your favorite slicer and tweak the settings to meet your needs.

While using different slicers for different kinds of prints can be beneficial avoid blindly hopping between slicers and slicer profiles just because someone posted a nice print sliced with a different slicer.

Consumables

3d printing filament is not the only consumable of the printer. Nozzles, PTFE tubes and the PEI print surface are also considered consumables and need periodic replacement.

Consider the shipping time for your consumables and if required stock at least one full set of replacement parts.

The PTFE tube will wear due to friction of the filament and should be replaced on a 500h schedule to ensure the best possible print results.

Nozzles will wear depending on the nozzle material and filament used or may simply clog due to dust and debris entering the filament path.
Brass nozzles will wear even with unfilled filaments, consider replacing them on a schedule to ensure consistent print results.

The PEI surface may get scratched or otherwise damaged by the removal of prints. While keeping a spare sheet is considered good practice consider the ~1 year shelf life of the 3M 468mp sheets that are used to glue the PEI to the plate.
In addition PEI is not immune to acetone and it will develop cracks with frequent usage of acetone.

|<< :: Athena // IWA150 :: >>|

a replacement pcb for V4N4G0N, ortho-gonizing

anchored to [[461.00_anchor|461.00_anchor]]


| Overview |

The orig V4N4G0N is purely row-stagger, yet we ( Bonk / me) and probably others like orthogonal keyboard stagger too. Hence came the idea to create another replacement pcb to give the ability of an ortho drop in for the original case ( and its thousand variants).

The layout will likely be similar to this one : https://trashman.wiki/community/pcbs/v4n4g0rth0n link

Yet we strive for another mid decoration.

There were some initial thoughts of creating more space for iso-enter-placement or some other shenanigan, yet we may end up with the same layout as pictured above.

| Considerations | Naming

Athena is likely not going to be the final name of this pcb. As this whole pcb serves as drop-in for the V4NG0N, which is based of a car we cannot go into greek mythology. Well we could but it would be off regarding the theme.

Alternatives for names could be:

car/vehicle references:

  • miata / mr2 ? –> don’t like them that much
  • Wagon –> train reference
  • DB-Baureihe 103 –> geiler E-Zug!
  • UIC-Z-Wagen –> Wagon aus DR von VEB Bautzen
  • Because we stick to vans –> IWA 150 (popular GDR van)

| Considerations | >> Design

[!Definition] First Design Idea The first idea takes advantage of the original underglow within the pcb. We leverage this ability and then allow a cutout in the middle to have light shine through.

There are some ways to implement this:

large cutout: ![[Pasted image 20231216233749.png]]

partial cutout ( with some ornaments / decoration maybe) ![[Pasted image 20231216233928.png]]

[!Definition] First Idea _Advancement: To prevent direct holes to the lower part of the case, we could position / attach some acrylic above this cutout in the middle.

Here it could either be positioned with an offset ( to match case-height) or be positioned directly above the pcb. one could also make an acrylic stack to fill this space, yet:

  • mounting space is limited

a rough sketch of how that could look like: ![[Pasted image 20231216234154.png]]

| Considerations | >> Layout

There went some thoughts into improving the given layout to accommodate a more or less symmetric appearance, or to give more room for decorating ( by decreasing the amount of keys available per side).

Those are some layouts we came up with: ![[Pasted image 20231216234352.png]]

[!Tip] Option 2 as favorite As of now we favour option 2 so basically a .75u space in the middle with two blocks of switches left and right of it.

Project :: Endeavour V 2


Current status ::

  • Idea set

planned features ::

  • Feature 2

notation for new revisions ::

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #ortho #rp2040


date-created: 2024-08-21 03:05:59 date-modified: 2024-08-21 03:07:46

CERN Open Hardware Licence Version 2 - Permissive

link to original: https://cern-ohl.web.cern.ch/home

Preamble

CERN has developed this licence to promote collaboration among hardware designers and to provide a legal tool which supports the freedom to use, study, modify, share and distribute hardware designs and products based on those designs. Version 2 of the CERN Open Hardware Licence comes in three variants: this licence, CERN-OHL-P (permissive); and two reciprocal licences: CERN-OHL-W (weakly reciprocal) and CERN-OHL-S (strongly reciprocal).

The CERN-OHL-P is copyright CERN 2020. Anyone is welcome to use it, in unmodified form only.

Use of this Licence does not imply any endorsement by CERN of any Licensor or their designs nor does it imply any involvement by CERN in their development.

1 Definitions

1.1 ‘Licence’ means this CERN-OHL-P.

1.2 ‘Source’ means information such as design materials or digital code which can be applied to Make or test a Product or to prepare a Product for use, Conveyance or sale, regardless of its medium or how it is expressed. It may include Notices.

1.3 ‘Covered Source’ means Source that is explicitly made available under this Licence.

1.4 ‘Product’ means any device, component, work or physical object, whether in finished or intermediate form, arising from the use, application or processing of Covered Source.

1.5 ‘Make’ means to create or configure something, whether by manufacture, assembly, compiling, loading or applying Covered Source or another Product or otherwise.

1.6 ‘Notice’ means copyright, acknowledgement and trademark notices, references to the location of any Notices, modification notices (subsection 3.3(b)) and all notices that refer to this Licence and to the disclaimer of warranties that are included in the Covered Source.

1.7 ‘Licensee’ or ‘You’ means any person exercising rights under this Licence.

1.8 ‘Licensor’ means a person who creates Source or modifies Covered Source and subsequently Conveys the resulting Covered Source under the terms and conditions of this Licence. A person may be a Licensee and a Licensor at the same time.

1.9 ‘Convey’ means to communicate to the public or distribute.

2 Applicability

2.1 This Licence governs the use, copying, modification, Conveying of Covered Source and Products, and the Making of Products. By exercising any right granted under this Licence, You irrevocably accept these terms and conditions.

2.2 This Licence is granted by the Licensor directly to You, and shall apply worldwide and without limitation in time.

2.3 You shall not attempt to restrict by contract or otherwise the rights granted under this Licence to other Licensees.

2.4 This Licence is not intended to restrict fair use, fair dealing, or any other similar right.

3 Copying, Modifying and Conveying Covered Source

3.1 You may copy and Convey verbatim copies of Covered Source, in any medium, provided You retain all Notices.

3.2 You may modify Covered Source, other than Notices.

  You may only delete Notices if they are no longer applicable to the
  corresponding Covered Source as modified by You and You may add
  additional Notices applicable to Your modifications.

3.3 You may Convey modified Covered Source (with the effect that You shall also become a Licensor) provided that You:

   a) retain Notices as required in subsection 3.2; and

   b) add a Notice to the modified Covered Source stating that You have
      modified it, with the date and brief description of how You have
      modified it.

3.4 You may Convey Covered Source or modified Covered Source under licence terms which differ from the terms of this Licence provided that You:

   a) comply at all times with subsection 3.3; and

   b) provide a copy of this Licence to anyone to whom You Convey Covered
      Source or modified Covered Source.

4 Making and Conveying Products

You may Make Products, and/or Convey them, provided that You ensure that the recipient of the Product has access to any Notices applicable to the Product.

5 DISCLAIMER AND LIABILITY

5.1 DISCLAIMER OF WARRANTY – The Covered Source and any Products are provided ‘as is’ and any express or implied warranties, including, but not limited to, implied warranties of merchantability, of satisfactory quality, non-infringement of third party rights, and fitness for a particular purpose or use are disclaimed in respect of any Source or Product to the maximum extent permitted by law. The Licensor makes no representation that any Source or Product does not or will not infringe any patent, copyright, trade secret or other proprietary right. The entire risk as to the use, quality, and performance of any Source or Product shall be with You and not the Licensor. This disclaimer of warranty is an essential part of this Licence and a condition for the grant of any rights granted under this Licence.

5.2 EXCLUSION AND LIMITATION OF LIABILITY – The Licensor shall, to the maximum extent permitted by law, have no liability for direct, indirect, special, incidental, consequential, exemplary, punitive or other damages of any character including, without limitation, procurement of substitute goods or services, loss of use, data or profits, or business interruption, however caused and on any theory of contract, warranty, tort (including negligence), product liability or otherwise, arising in any way in relation to the Covered Source, modified Covered Source and/or the Making or Conveyance of a Product, even if advised of the possibility of such damages, and You shall hold the Licensor(s) free and harmless from any liability, costs, damages, fees and expenses, including claims by third parties, in relation to such use.

6 Patents

6.1 Subject to the terms and conditions of this Licence, each Licensor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section 6, or where terminated by the Licensor for cause) patent licence to Make, have Made, use, offer to sell, sell, import, and otherwise transfer the Covered Source and Products, where such licence applies only to those patent claims licensable by such Licensor that are necessarily infringed by exercising rights under the Covered Source as Conveyed by that Licensor.

6.2 If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Covered Source or a Product constitutes direct or contributory patent infringement, or You seek any declaration that a patent licensed to You under this Licence is invalid or unenforceable then any rights granted to You under this Licence shall terminate as of the date such process is initiated.

7 General

7.1 If any provisions of this Licence are or subsequently become invalid or unenforceable for any reason, the remaining provisions shall remain effective.

7.2 You shall not use any of the name (including acronyms and abbreviations), image, or logo by which the Licensor or CERN is known, except where needed to comply with section 3, or where the use is otherwise allowed by law. Any such permitted use shall be factual and shall not be made so as to suggest any kind of endorsement or implication of involvement by the Licensor or its personnel.

7.3 CERN may publish updated versions and variants of this Licence which it considers to be in the spirit of this version, but may differ in detail to address new problems or concerns. New versions will be published with a unique version number and a variant identifier specifying the variant. If the Licensor has specified that a given variant applies to the Covered Source without specifying a version, You may treat that Covered Source as being released under any version of the CERN-OHL with that variant. If no variant is specified, the Covered Source shall be treated as being released under CERN-OHL-S. The Licensor may also specify that the Covered Source is subject to a specific version of the CERN-OHL or any later version in which case You may apply this or any later version of CERN-OHL with the same variant identifier published by CERN.

7.4 This Licence shall not be enforceable except by a Licensor acting as such, and third party beneficiary rights are specifically excluded. CERN Open Hardware Licence Version 2 - Permissive

Preamble

CERN has developed this licence to promote collaboration among hardware designers and to provide a legal tool which supports the freedom to use, study, modify, share and distribute hardware designs and products based on those designs. Version 2 of the CERN Open Hardware Licence comes in three variants: this licence, CERN-OHL-P (permissive); and two reciprocal licences: CERN-OHL-W (weakly reciprocal) and CERN-OHL-S (strongly reciprocal).

The CERN-OHL-P is copyright CERN 2020. Anyone is welcome to use it, in unmodified form only.

Use of this Licence does not imply any endorsement by CERN of any Licensor or their designs nor does it imply any involvement by CERN in their development.

1 Definitions

1.1 ‘Licence’ means this CERN-OHL-P.

1.2 ‘Source’ means information such as design materials or digital code which can be applied to Make or test a Product or to prepare a Product for use, Conveyance or sale, regardless of its medium or how it is expressed. It may include Notices.

1.3 ‘Covered Source’ means Source that is explicitly made available under this Licence.

1.4 ‘Product’ means any device, component, work or physical object, whether in finished or intermediate form, arising from the use, application or processing of Covered Source.

1.5 ‘Make’ means to create or configure something, whether by manufacture, assembly, compiling, loading or applying Covered Source or another Product or otherwise.

1.6 ‘Notice’ means copyright, acknowledgement and trademark notices, references to the location of any Notices, modification notices (subsection 3.3(b)) and all notices that refer to this Licence and to the disclaimer of warranties that are included in the Covered Source.

1.7 ‘Licensee’ or ‘You’ means any person exercising rights under this Licence.

1.8 ‘Licensor’ means a person who creates Source or modifies Covered Source and subsequently Conveys the resulting Covered Source under the terms and conditions of this Licence. A person may be a Licensee and a Licensor at the same time.

1.9 ‘Convey’ means to communicate to the public or distribute.

2 Applicability

2.1 This Licence governs the use, copying, modification, Conveying of Covered Source and Products, and the Making of Products. By exercising any right granted under this Licence, You irrevocably accept these terms and conditions.

2.2 This Licence is granted by the Licensor directly to You, and shall apply worldwide and without limitation in time.

2.3 You shall not attempt to restrict by contract or otherwise the rights granted under this Licence to other Licensees.

2.4 This Licence is not intended to restrict fair use, fair dealing, or any other similar right.

3 Copying, Modifying and Conveying Covered Source

3.1 You may copy and Convey verbatim copies of Covered Source, in any medium, provided You retain all Notices.

3.2 You may modify Covered Source, other than Notices.

  You may only delete Notices if they are no longer applicable to the
  corresponding Covered Source as modified by You and You may add
  additional Notices applicable to Your modifications.

3.3 You may Convey modified Covered Source (with the effect that You shall also become a Licensor) provided that You:

   a) retain Notices as required in subsection 3.2; and

   b) add a Notice to the modified Covered Source stating that You have
      modified it, with the date and brief description of how You have
      modified it.

3.4 You may Convey Covered Source or modified Covered Source under licence terms which differ from the terms of this Licence provided that You:

   a) comply at all times with subsection 3.3; and

   b) provide a copy of this Licence to anyone to whom You Convey Covered
      Source or modified Covered Source.

4 Making and Conveying Products

You may Make Products, and/or Convey them, provided that You ensure that the recipient of the Product has access to any Notices applicable to the Product.

5 DISCLAIMER AND LIABILITY

5.1 DISCLAIMER OF WARRANTY – The Covered Source and any Products are provided ‘as is’ and any express or implied warranties, including, but not limited to, implied warranties of merchantability, of satisfactory quality, non-infringement of third party rights, and fitness for a particular purpose or use are disclaimed in respect of any Source or Product to the maximum extent permitted by law. The Licensor makes no representation that any Source or Product does not or will not infringe any patent, copyright, trade secret or other proprietary right. The entire risk as to the use, quality, and performance of any Source or Product shall be with You and not the Licensor. This disclaimer of warranty is an essential part of this Licence and a condition for the grant of any rights granted under this Licence.

5.2 EXCLUSION AND LIMITATION OF LIABILITY – The Licensor shall, to the maximum extent permitted by law, have no liability for direct, indirect, special, incidental, consequential, exemplary, punitive or other damages of any character including, without limitation, procurement of substitute goods or services, loss of use, data or profits, or business interruption, however caused and on any theory of contract, warranty, tort (including negligence), product liability or otherwise, arising in any way in relation to the Covered Source, modified Covered Source and/or the Making or Conveyance of a Product, even if advised of the possibility of such damages, and You shall hold the Licensor(s) free and harmless from any liability, costs, damages, fees and expenses, including claims by third parties, in relation to such use.

6 Patents

6.1 Subject to the terms and conditions of this Licence, each Licensor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section 6, or where terminated by the Licensor for cause) patent licence to Make, have Made, use, offer to sell, sell, import, and otherwise transfer the Covered Source and Products, where such licence applies only to those patent claims licensable by such Licensor that are necessarily infringed by exercising rights under the Covered Source as Conveyed by that Licensor.

6.2 If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Covered Source or a Product constitutes direct or contributory patent infringement, or You seek any declaration that a patent licensed to You under this Licence is invalid or unenforceable then any rights granted to You under this Licence shall terminate as of the date such process is initiated.

7 General

7.1 If any provisions of this Licence are or subsequently become invalid or unenforceable for any reason, the remaining provisions shall remain effective.

7.2 You shall not use any of the name (including acronyms and abbreviations), image, or logo by which the Licensor or CERN is known, except where needed to comply with section 3, or where the use is otherwise allowed by law. Any such permitted use shall be factual and shall not be made so as to suggest any kind of endorsement or implication of involvement by the Licensor or its personnel.

7.3 CERN may publish updated versions and variants of this Licence which it considers to be in the spirit of this version, but may differ in detail to address new problems or concerns. New versions will be published with a unique version number and a variant identifier specifying the variant. If the Licensor has specified that a given variant applies to the Covered Source without specifying a version, You may treat that Covered Source as being released under any version of the CERN-OHL with that variant. If no variant is specified, the Covered Source shall be treated as being released under CERN-OHL-S. The Licensor may also specify that the Covered Source is subject to a specific version of the CERN-OHL or any later version in which case You may apply this or any later version of CERN-OHL with the same variant identifier published by CERN.

7.4 This Licence shall not be enforceable except by a Licensor acting as such, and third party beneficiary rights are specifically excluded. CERN Open Hardware Licence Version 2 - Permissive

Preamble

CERN has developed this licence to promote collaboration among hardware designers and to provide a legal tool which supports the freedom to use, study, modify, share and distribute hardware designs and products based on those designs. Version 2 of the CERN Open Hardware Licence comes in three variants: this licence, CERN-OHL-P (permissive); and two reciprocal licences: CERN-OHL-W (weakly reciprocal) and CERN-OHL-S (strongly reciprocal).

The CERN-OHL-P is copyright CERN 2020. Anyone is welcome to use it, in unmodified form only.

Use of this Licence does not imply any endorsement by CERN of any Licensor or their designs nor does it imply any involvement by CERN in their development.

1 Definitions

1.1 ‘Licence’ means this CERN-OHL-P.

1.2 ‘Source’ means information such as design materials or digital code which can be applied to Make or test a Product or to prepare a Product for use, Conveyance or sale, regardless of its medium or how it is expressed. It may include Notices.

1.3 ‘Covered Source’ means Source that is explicitly made available under this Licence.

1.4 ‘Product’ means any device, component, work or physical object, whether in finished or intermediate form, arising from the use, application or processing of Covered Source.

1.5 ‘Make’ means to create or configure something, whether by manufacture, assembly, compiling, loading or applying Covered Source or another Product or otherwise.

1.6 ‘Notice’ means copyright, acknowledgement and trademark notices, references to the location of any Notices, modification notices (subsection 3.3(b)) and all notices that refer to this Licence and to the disclaimer of warranties that are included in the Covered Source.

1.7 ‘Licensee’ or ‘You’ means any person exercising rights under this Licence.

1.8 ‘Licensor’ means a person who creates Source or modifies Covered Source and subsequently Conveys the resulting Covered Source under the terms and conditions of this Licence. A person may be a Licensee and a Licensor at the same time.

1.9 ‘Convey’ means to communicate to the public or distribute.

2 Applicability

2.1 This Licence governs the use, copying, modification, Conveying of Covered Source and Products, and the Making of Products. By exercising any right granted under this Licence, You irrevocably accept these terms and conditions.

2.2 This Licence is granted by the Licensor directly to You, and shall apply worldwide and without limitation in time.

2.3 You shall not attempt to restrict by contract or otherwise the rights granted under this Licence to other Licensees.

2.4 This Licence is not intended to restrict fair use, fair dealing, or any other similar right.

3 Copying, Modifying and Conveying Covered Source

3.1 You may copy and Convey verbatim copies of Covered Source, in any medium, provided You retain all Notices.

3.2 You may modify Covered Source, other than Notices.

  You may only delete Notices if they are no longer applicable to the
  corresponding Covered Source as modified by You and You may add
  additional Notices applicable to Your modifications.

3.3 You may Convey modified Covered Source (with the effect that You shall also become a Licensor) provided that You:

   a) retain Notices as required in subsection 3.2; and

   b) add a Notice to the modified Covered Source stating that You have
      modified it, with the date and brief description of how You have
      modified it.

3.4 You may Convey Covered Source or modified Covered Source under licence terms which differ from the terms of this Licence provided that You:

   a) comply at all times with subsection 3.3; and

   b) provide a copy of this Licence to anyone to whom You Convey Covered
      Source or modified Covered Source.

4 Making and Conveying Products

You may Make Products, and/or Convey them, provided that You ensure that the recipient of the Product has access to any Notices applicable to the Product.

5 DISCLAIMER AND LIABILITY

5.1 DISCLAIMER OF WARRANTY – The Covered Source and any Products are provided ‘as is’ and any express or implied warranties, including, but not limited to, implied warranties of merchantability, of satisfactory quality, non-infringement of third party rights, and fitness for a particular purpose or use are disclaimed in respect of any Source or Product to the maximum extent permitted by law. The Licensor makes no representation that any Source or Product does not or will not infringe any patent, copyright, trade secret or other proprietary right. The entire risk as to the use, quality, and performance of any Source or Product shall be with You and not the Licensor. This disclaimer of warranty is an essential part of this Licence and a condition for the grant of any rights granted under this Licence.

5.2 EXCLUSION AND LIMITATION OF LIABILITY – The Licensor shall, to the maximum extent permitted by law, have no liability for direct, indirect, special, incidental, consequential, exemplary, punitive or other damages of any character including, without limitation, procurement of substitute goods or services, loss of use, data or profits, or business interruption, however caused and on any theory of contract, warranty, tort (including negligence), product liability or otherwise, arising in any way in relation to the Covered Source, modified Covered Source and/or the Making or Conveyance of a Product, even if advised of the possibility of such damages, and You shall hold the Licensor(s) free and harmless from any liability, costs, damages, fees and expenses, including claims by third parties, in relation to such use.

6 Patents

6.1 Subject to the terms and conditions of this Licence, each Licensor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section 6, or where terminated by the Licensor for cause) patent licence to Make, have Made, use, offer to sell, sell, import, and otherwise transfer the Covered Source and Products, where such licence applies only to those patent claims licensable by such Licensor that are necessarily infringed by exercising rights under the Covered Source as Conveyed by that Licensor.

6.2 If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Covered Source or a Product constitutes direct or contributory patent infringement, or You seek any declaration that a patent licensed to You under this Licence is invalid or unenforceable then any rights granted to You under this Licence shall terminate as of the date such process is initiated.

7 General

7.1 If any provisions of this Licence are or subsequently become invalid or unenforceable for any reason, the remaining provisions shall remain effective.

7.2 You shall not use any of the name (including acronyms and abbreviations), image, or logo by which the Licensor or CERN is known, except where needed to comply with section 3, or where the use is otherwise allowed by law. Any such permitted use shall be factual and shall not be made so as to suggest any kind of endorsement or implication of involvement by the Licensor or its personnel.

7.3 CERN may publish updated versions and variants of this Licence which it considers to be in the spirit of this version, but may differ in detail to address new problems or concerns. New versions will be published with a unique version number and a variant identifier specifying the variant. If the Licensor has specified that a given variant applies to the Covered Source without specifying a version, You may treat that Covered Source as being released under any version of the CERN-OHL with that variant. If no variant is specified, the Covered Source shall be treated as being released under CERN-OHL-S. The Licensor may also specify that the Covered Source is subject to a specific version of the CERN-OHL or any later version in which case You may apply this or any later version of CERN-OHL with the same variant identifier published by CERN.

7.4 This Licence shall not be enforceable except by a Licensor acting as such, and third party beneficiary rights are specifically excluded.


date-created: 2024-06-08 10:13:38 date-modified: 2024-06-08 10:18:26

Project Endeavour BLE

anchored to 431.00_anchor Tags: #Keyboard #wireless

also linked to 431.01_endeavour


Current status

Planned features

  • Feature 2

Notation for new revisions ::


Other projects:

LIST 
FROM "400-499_avocation/430-439_hobbies/431_keyboards" AND #Keyboard 

Project :: BURAN


Current status ::

  • Prototypes working
  • case design complete >> alternative is bubbles case

possible features for next revision ::

  • smaller LDO >> .5 mA cheaper and available
  • different flash ?
  • utilization with additional I/O Expander ?
  • Caps Led ?

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #ortho #rp2040

![[Pasted image 20221120200806.png]] cost for 10 pcbs in red

  • 12.80€ for one pcb
  • 8€ marge for myself to reach 20 per pcb

New deal:: replace knob wth trackpad

Project :: Plain-60 - RP2040 Edition


Current status ::

  • Done, working

planned features ::

notation for new revisions ::

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #ortho #rp2040

Project :: Salacia


Current status ::

to be conceptualised OK so this board could be one that you can fold in half.

In this state it might be a macropad and one could enhance its capability by unfolding it.

It could then be used like a Norma board ( maybe in the form of a Buran/Chiffre ?

Connection both halfs?? –> Maybe use those magnetic connectors that ebastler also uses? Otherwise make it a Split-Keeb with wireless capability!

This could be the new iteration of CynoSureIII !

A possible

notation for new revisions ::

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #ortho #rp2040


date-created: 2024-08-21 03:05:29 date-modified: 2024-08-22 12:24:27

Buran-Ortho

A 39-key orthogonal keyboard with support for two knobs.

Used License :: Cern Open hardware


Status ::

  • Rev 3 released
  • Case options were updated accordingly
  • untested LED-Pinout

Features ::

  • PCB supports MX, Alps and Choc v1 switches
  • QMK and Vial Support
  • built with rp2040 and additional flash storage allowing for plenty of combos, layers, led matrices etc.
  • easy to order with jlcpcb –> check release for files
  • support up to two encoders
  • additional pinouts for further modifications
    • technically could fit an OLED or some other additional parts
  • gasket mounted case
  • case designed for 3d printing
  • several layout-options for middle part.

Layout ::

Below all possible layouts can be observed. All the observed layouts can be choosen and used with Vial or Qmk

Case ::

All files for the case are to be found here.

For the top-part of the case there are several options available, where each of them was designed for a specific layout.

Firmware ::

the pre-compiled file for Vial and the whole Qmk-userspace for this keyboard can be found here

To enter the bootloader - which is necessary in order to flash a new firmware - press the button next to the encoder on the back of the pcb and plug-it into your keyboard while keeping the button pressed. It should show up as a regular usb-stick in your file explorer now and you can drag the .utf onto this usb-stick. Once done it will restart and use your newly flashed firmware!


Building your own ::

On the verge to build this keyboard your own? Below you can find a little guideline on what is required and how to obtain everything:

Getting PCBs ::

in the directory production you can find both the gerber and POS-Files required for assembly. I usually use JLCPCB for my prototypes, the procedure should be fairly similiar for other manufacturers however, and they require the gerber_buran_pcb.zip and for assembly of all SMD-components also their positions (buran-pos-bottom.csv) and the BOM (buran-BOM.csv) all of which can be found in the production/assembly directory.

Building Case ::

The case consists of three parts: the bottom-part, top-part (various layouts available) and the plate. Print all of them yourself or have someone print them for your (JLCPCB also offers MFJ printing which could be used (althought untested!)). Now to assemble the case you further need:

PartQuantity
2mm thick foam to use as gasket14x cut pieces
20mm M38x

The length for the Gasket can be taken from the existing cutouts in the case

As alternative one could also replace the screws with small 3mm diameter magnets.

Building the board ::

  1. Prepare your pcb accordingly.
  2. Further add the plate and position your switches with them, later solder them to the pcb.
  3. add any feature, like LEDS or knobs.
  4. add the cut foam to each lip of the plate. It ought to be positioned both at the top and bottom of the plate –> to isolate properly from the rest of the case!
  5. Position everything and screw the case together.
  6. Run Vial on your system and configure the keyboard accordingly

Images of Case ::

Case-option for additional acrylic :

Case-option without additoinal buttons in the middle :

Image by Isp

Case-option with an alternative bottom design : Design and Image by DeadCatAlive

Images of PCB ::


banner: “![[Pasted image 20230105205913.png]]”


Project :: SpaceWalk


Current status ::

  • Software missing
  • ordered prototypes
  • 112.86$ total cost, 75 have been supplied already

Status : ![[Pasted image 20230105205913.png]]

planned features ::

  • per-key with simple leds
  • split space
  • underglow - WS28
  • small accent with WS28 >> led right blocker
  • daughterboard - no internal usb
  • breakout for additionals features >>
  • layout option rshift 1.25u n more
  • Silkscreen is a replica of the underlying groundfill
    • Goal is a blue pcb with white silkscreen, creating some sort of contrast

notation for new revisions ::

  • write : Pcb by ScatteredDrifter for next revision!
  • maybe no groundfill
  • no soldermask / transparent

TimeTracking::

Saturday 19.11.2022 :: ==30min== outlines and design Sunday 20.11.2022 :: ==1.5hr== basic placement, schematic Friday 25.11.2022 :: 1.5hr schematic finalization, placement, routing Saturday 26.11.2022 :: ==3,5hr== + ==1,5hr== = 5hr Thursday 05.01.2023 :: from stuttgart to leipzig ~ ==4hr == Sunday 08.01.2023 :: ==3,5hr== Thursday 12.01.2023 :: ==1.5hr== Friday 13.01.2023 :: ==2.5hr== Saturday 14.01.2023 :: 3hr Sunday 26.02.2023:: 3hr

a total of 24.5hr

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #stagger #rp2040

Project :: <name>


Current status ::

  • Prototypes working

[!Important] Updating this: I should adapt this board to be capable of supporting wireless connection I would like to have a good case for this board too! maybe I can improve its available keys a little more? for example I could add some pinky keys ( cus I like then fm most of the time

planned features ::

  • Feature 2

notation for new revisions ::

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #ortho #rp2040

Stucco10-15 | Comission for Technofrikus

anchored to [[461.00_anchor|461.00_anchor]]


Overview:

This board is a TKL but orthogonal. Its able to be broken apart and then being used as a 4 row keyboard. Otherwise it would be useable as 5row keyboard too!

The link to my repository: https://github.com/ScatteredDrifter/Stucco10_15

Current status ::

  • prototypes done
  • firmware functional too
  • rev1 had the issue that I’ve fucked up positions of the bottom row stabilizers because this prevents ppl from attaching stabilizer accordingly!
  • furthermore there were issues of non functional rows and numpad layers when breaking off the fifth row!
    • those have been addressed and resolved

what to check:

  • routing after having rounded it all
  • stabilizer orientation!
  • routing close to numpad
  • routing close to controller!

planned features

  • backlight with breakout for extension ( led strip for example)
  • GPIO breakouts for additional fun or functions
  • alternative layout for bottom row

notation for new revisions ::

Images

Below I’ll provide some images

Monorail - Redux | Commission for M4NU:

anchored to [[461.00_anchor|461.00_anchor]]


Overview:

This board is an adapted version of the monorail by KiserDesigns. It was commissioned by M4NU for an adapted case by him. Originally I only wanted to add some minor changes, however because the KiCad schematic was somewhat broken for me, I completely rerouted and redesigned it. So to say its a complete new board with similar edge-cuts, layout options and components.

The link to my repository: https://github.com/ScatteredDrifter/Monorail_Redux

Current status ::

  • prototypes done
  • firmware functional too
  • rev1 had the issue that I’ve fucked up positions of the bottom row stabilizers because this prevents ppl from attaching stabilizer accordingly!
    • it has been mentioned in [[432.01_general-keyboard_design]]

what to check:

  • encoder functionality
  • led function
  • layouts

planned features

  • backlight with breakout for extension ( led strip for example)
  • GPIO breakouts for additional fun or functions
  • alternative layout for bottom row

notation for new revisions ::

Images

Below I’ll provide some images

Render V¹

![[Pasted image 20231022210142.png]] ![[Pasted image 20231022210147.png]]

Images

Project :: Clacky-40


Current Status |

  • Prototypes done
    • working
    • v1 issue was fixed too
  • updated / new repository with build images and more

planned features ::

  • per-key-led
  • encoder support –> bottom row
  • encoder top left corner
  • underglow

notation for new revisions ::

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #ortho #rp2040

Project :: SPEKTR

named after a module attached to MiR, featuring four solar panels https://de.wikipedia.org/wiki/Spektr


Current status ::

  • Prototypes working

planned features ::

  • Feature 2

notation for new revisions ::

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #ortho #rp2040

Project :: SO[H]ORTHO!


![[]](Image of planned pcb )

  • replacement / fork of the Horizon keyboard https://github.com/skarrmann/horizon

Planned Features ::

  • onboard rp2040
  • upfacing LEDS to enlight Mcu-plane
  • Usb-C
  • optional bottom row > without stabilizier cutouts for 2u
  • optional blocker for whole mid-colunns >> lumberjack-esque styling
  • per-key rgb >> optional not compatible with pcb as bottom plate

this document is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboards runs on a [[rp2040]] #ortho #rp2040 #qmk


banner: “![[bulliso_kle.png]]” banner_y: 0.048

Project :: bullISO

An adaption of the original bully by zhol Features ISO and some derivation of the original layout as well


Current status ::

  • silk almost done

planned features ::

  • alternative layout, as seen above
  • rp2040
  • 3 pinouts for additional tooling
  • 1 led strip pinout
  • unified daughterboard mount

Layout :: ![[bulliso_kle.png]]


notation for new revisions ::


time tracking ::

Sat 14.01.2023 :: 30m initial setup Thu 19.01.2023 :: 2hr initial placement, routing etc. Fri 20.01.2023 :: 2hr , routing, refinement Fri 21.01.2023 :: 2hr Sat 22.01.2023 :: 2hr , equals to :: 8.5hr,

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #ortho #rp2040

| Project | BURAN - XL Mriya

anchored to [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor|431.00_anchor]]


Current status :w

  • planned to be prototyped soon ( within 2023)

| Overview |

This pcb / board tries to resemble the same idea taken with [[431.03_buran]] yet scaled up to incorporate a numpad and 6x5 blocks for both the left and right side.

| Naming |

I’m not quite sure how to name this Board.

Considering that its larger than buran it should also be larger than the actual, if it was named after another vehicle / aircraft. Hence I just went with buran_xl until finding a good enough to take.

With suggestion from 40’s community I may look into using either one of the names below:

  • Virtus named after wiki
  • Mriya named after wikiA
    • I think I will go for this name as it makes more sense historically –> after all it was carrying Buran!

| TODO |

  • check wiring for Trackpad support
    • #Keyboard #Leisure maybe even build simple firmware to test its functionality on another board like [[431.08_quasar67]]
  • update silkscreen to remove number for the sk68 leds
  • last go over wiring once more
  • create silkscreen https://drawingdatabase.com/antonov-an-225-mriya/

planned features ::

  • 5 degree orthogonal keyboard, similar layout as [[431.03_buran]]
  • features Numpad in the middle
  • Cirque-Support
  • 3d-printed case
  • tadpole mount
  • 2 rotary encoders possible
    • 2 positions for them
  • per-key RGB

notation for new revisions ::

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #ortho #rp2040

Project :: Quasar-67


Current status ::

  • Prototypes working
  • LEDS untested

planned features ::

  • Feature 1
  • Feature 2

notation for new revisions ::

this is part of [[400-499_avocation/430-439_hobbies/431_keyboards/431.00_anchor]] this keyboard runs on a [[rp2040]] #ortho #rp2040


date-created: 2024-06-14 04:02:10 date-modified: 2024-11-24 12:56:54

CV | Lebenslauf:

anchored to [[032.00_anchor]] tags: #Work #skills #Selbstbild


This is a accumulation of things that I’ve done / might have skills or some experience in:

Involvements | grammar school

  • Vorstand des Schülerrates im Bereiche Kommunikation und Medien
  • Mitglied der Digitalisierungs-Ag des Gymnasium Coswig ~2 Jahre
  • Mitglied der Jahrbuch-Ag des Gymnasium Coswig ~3 Jahre
    • Setzen von Seiten eines Magazines mittels Corel Draw etc.
  • Mitglied der Bibliotheks-Ag des Gymnasium Coswig ~3 Jahre
    • Einrichten und aufsetzen des Katalogisierungssystems “Koha”
    • gelegentlicher Support bei Instandhaltung des Systems - Debian / Koha %% - 2 wöchiges Praktikum bei Bürosysteme Baumann Coswig > Rahmen der 9. Klasse %%
  • Teilnahme am 11. Schulenergietag am 3.5.2018

Involvements | university

[!Information] currently doing B.sc. Computer Science at University of tuebingen

  • FSI - student association computer science - since WiSe 2024/25
  • voluntarily Netz-AK since 2023
  • Tutor*in Grundlagen Internettechnologien Uni Tübingen (SS 2023)
  • Tutor*in Software Engineering Uni Tübingen (WiSe 23/24)
  • dorm council from SoSe 2022 until WiSe2023/24
  • Werksstudentin bei GB-IT - Bereich Netzwerkinfrastruktur - des UK Tübingen seit Mai 2024

“Skills” | Generally

  • network administration and conception for MM Massivbau Coswig ~1 Jahr | 2019
  • repairing Iphones (6,7,8), Laptops (Hp/Dell/Lenovo), Desktop Computers
  • pcb design with KiCad and EasyEDA
  • CAD Design mit Fusion360 - Student Edition
  • 3d printing { Klipper, Voron Trident, Ender modded }
  • soldering - SMD SOD123, 0805, 0403 and similar
  • VmWare Esxi / Vsphere
  • Proxmox
  • Pfsense/Opnsns
  • using LaTeX (Beamer)
  • programming in Python,Php,Javascript,Rust, (Java)
  • ausgiebige Hilfe einiger Student*innen bei Fragen der Programmierung während des Studiums
  • FPV Drone building / flying
  • using obsidian as knowledge database
  • writing protocols for voluntary institutions

Interests

  • #politics
  • #Network network architectures, routing, SDAs (although not much experience with it)
  • #3DP 3d-printing - mostly FDM, yet the whole field is interesting
  • #Music and #djing , likely also creating music 353.01_music_links
    • learning an instrumeent - piano / drums
  • listening to vinyls
  • building computers
  • #Keyboard, designing pcbs for them

cards-deck: 100-199_university::111-120_theoretic_cs::111_algorithms_datastructures

| MST | M inimal S panning T rees

anchored to [[111.00_anchor]] proceeds from [[111.13_Graphen_basics]] and [[111.23_Graphen_ZHK]]


| Overview |

| Intuition |

Wir möchten das Prinzip eines MST durch ein Beispiel näher bringen. Betrachten wir ein Netz von Computern. Wir möchten jetzt ein Netzwerk bauen, bei welchem alle Computer verbunden sind, und dabei die Kosten gering bleiben. Also wir wollen einen Teilgraph des Gegebenen betrachten, sodass wir darin dann die minimalste Verbindung finden können

[!Example] Beispiel MST ( rot ) in einem Graphen ![[Pasted image 20221121141641.png]] Zu erkennen sind hier folgende Eigenschaften des Baumes:

  • erst ist azyklisch ( also wir haben keine Zykel in der Verbindung) [[111.18_Graphen_Traversieren]]
  • ist der günstigste Weg, der in diesem Graph möglich ist \

[!Important] ein MST ist immer ein [[111.08_algo_datastructures#Trees Grundlegende Definition|Tree]] warum ist das so? #card Wenn man die Knoten, die durch einen MST genommen werden, betrachtet, dann wird man hier immer einen BAUM erhalten. -> Dabei hat jeder Knoten viele Leafs, die dann wieder welche haben können Aber es kann hier keine Zykel geben, also wird dieser Baum nur in die Tiefe ausgebaut, aber nicht mehr nach oben verlinken. ( Es ist einfach eine Baum-Struktur D: ) ^1704708900392

| Historische Betrachtung von MST |

Für eine historische Betrachtung der Konzeptionen zur Findung von MST können wir folgend betrachten:

  1. Kruskal’s algorithm -> published in 1956
  2. Union-Find data structure (by Fisch, Galler) -> published in 1964
    • there are still improvements and publication happening for this structure now!
  3. Prim’s algorithm ->published 1957
    • R. Prim - shortest connection networks and some generalizations.
    • ((maybe already invented by V. Jarnik 1930))

| Definition | MST |

Wir wollen ferner noch definieren, was einen MST ausmacht.

[!Definition] Definition MST was ist ein MST von einem Graphen ? 3 Eigenschaften #card Sei ein ungerichteter Graph mit Knoten und Kanten. Wir benennen jetzt einen Teilgraph mit $V’ \subset V, E’ \subsetE$ als aufspannenden Baum, wenn folgendes für gilt: 1. T ist azyklisch (acyclic)

2. , also der Teilgraph beinhaltet alle Knoten aus dem originalen Graph

3. , also die Menge der Kanten ist minimal und damit eigentlich 1 kleiner, als die Menge der Knoten ^1704708900404

[!Important] Kosten beim MST wie sind die Kosten des Teilbaumes /Graphen definiert? #card Betrachten wir den entstehenden Teilgraphen , dann werden dessen Kosten folgend definiert: Also die Kosten aller Kanten werden einfach summiert.

Wichtig ist, dass die Kosten hier minimal sein müssen! ^1704708900412

Betrachten wir dafür noch ein Beispiel, damit die Intuition innerhalb eines Graphen etabliert und verstanden werden kann.


| Nicht-Eindeutigkeit |

Sofern bei einem Graphen mehrere kürzeste Pfade zu bestimmten Knoten existieren, können diese mehreren Pfade auch angewandt werden, um etwa einen MST verschieden aufzuspannen.

[!Definition] MST sind nicht zwingend eindeutig warum? #card Sofern unser Graph mehrere kürzeste Pfade zu bestimmten Punkten hat, kann ein MST auch aus diesen einzelnen Pfaden aufgebaut werden.

Somit gibt es dann mehrere MST für einen Graphen –> Sie sind also nicht zwingend eindeutig in ihrer Definition ! ^1704708900421


| Beispiele für MST |

| Beispiel 1

[!Example] Graph und dessen MST ![[Pasted image 20231208200034.png]] Wie könnte in diesem Graph ein MST aussehen? #card ![[Pasted image 20231208200104.png]] -> Dieser Graph ist Zykelfrei! er hat die kürzesten Pfaden drin ^1704708900429

| Beispiel 2

Wir können noch ein Beispiel betrachten:

[!Example] ![[Pasted image 20221121151340.png]] ![[Pasted image 20221121151346.png]] ![[Pasted image 20221121151355.png]]


| MST | Bestimmen / Finden |

Wir möchten jetzt verschiedene Wege finden, um einen MST bestimmen und aufbauen zu können.

| Kruskal’s Algorithmus | Greedy | #refactor

Wir möchten dafür zuerst einen [[111.39_greedyAlgorithm|Greedy Algorithmus]] betrachten, welcher Schritt für Schritt die beste Option für einen MST sammeln wird.

[!Definition] Kruskal’s Algorithmus wie funktioniert dieser, was macht er? #card

\begin{algorithm} 
  \caption{Kruskal's Algorithmus} 	
	\begin{algorithmic} 
	\State $\text{sort edges in nondecreasing order by weight w} e_1,\dots,e_m \text{ so dass} c(e_1) \leq c(e_2) \leq \dots \leq c(e_m)$
	\State initialize  $E_{T} = \emptyset$ 
	\For{$i = 1, \dots,m$} 
	\Comment{traverse all edges from graph}
		\If{$E_{T} \cup \{ e_{i} \} acyclic$}
			\State $E_{T} = E_{T} \cup \{ e_{i} \}$ 
			\Comment{also immer die nächst kleinere Kante übernehmen, und schauen, dass es azyklisch bleibt}
		\EndIf
	\EndFor
	\end{algorithmic} 
\end{algorithm}

Intuition: Der Algorithmus sucht also von der geringsten zur höchsten Wichtung der Kanten, immer die heraus, sodass folgende Eigenschaften erhalten werden:

  • der Graph bleibt azyklisch ( wir schauen also, dass der entstehende Graph sich nicht looped)
  • der Graph bleibt minimal ^1704708900437

Intuition von Kruskal’s Algorithmus :

  • Wir fangen also mit einem leeren Baum an, den wir jetzt immer mit der günstigsten Kante füllen wollen
    • wir fügen jetzt immer die günstigste Kanten zum Baum hinzu und schauen, dass kein Zykel entsteht
  • Wenn alle Knoten erreicht werden beenden wir den Algorithmus

[!Error] Kruskal ist ein dezentraler Algorithmus, also er sucht global eine Lösung und fügt sie anschließend zusammen

[!Important] Korrektheit von Kruskal’s Algorithmus | warum ist dieser Algo korrekt? #card Mit jeder Iteration, suchen wir von den geringsten Kanten ( deren Gewichten ) diese, die man in den neuen Graphen ( dem MST) aufnehmen kann, ohne dabei ein Zykel zu erzeugen. Das heißt also: Jede minimale Verbindung zwischen zwei Knoten wird betrachtet und anschließend übernommen. Wenn sie dann ein Zykel bildet, heißt das, dass wir in einer vorherigen Iteration ( wo die Gewichte kleiner waren!) schon eine Verbindung dahin gefunden haben, also schon die geringste Verbindung besteht!

Dadurch wird der Algorithmus mit jeder Iteration diese Eigenschaft des minimalsten Spannbaumes erhalten! ^1704708900447


Wir möchten bei dem Beweis der Korrektheit des Algorithmus einer bestimmten Intuition folgen:

–> Bedeutung “gut”: eine Menge nennen wir jetzt gut, wenn sie zu einem MST erweitert werden kann ( also minimal ist und azyklisch ist!)

| Nitpick | Finden von guten Kanten |

Wir können bestimmte Paradigmen betrachten, um solche guten Kanten in einem Graphen finden zu können. Mehr dazu findet sich hier [[111.29_Graphen_MST_find_safe_edges]]

| Beweis der Korrektheit |

[!Important] Ansatz des Korrektheitsbeweises Sei eine gute Teilmenge und sei hier die billigste Kante, so adss azyklisch ist (bleibt). Aus dieser Betrachtung folgt jetzt, dass weiterhin gut ist

Mit dieser Annahme können wir jetzt folgend die Korrektheit beweisen:

Sei jetzt die Erweiterung von zu einem MST.

  1. Ist jetzt , so ist auch gut -> also stimmt unsere Behauptung
  2. Ist jetzt dann betrachten wir
    • in dieser Betrachtung enthält dann H einen Zykel –> denn ist schon ein MST, brauch aber scheinbar nicht -> also wird er schon von einer anderen Kante abgedeckt
    • Da auch azyklisch ist, gibt es in dem Zykel eine Kante , die nicht in liegt Da wir entsprechend gewählt haben: ( weil wir ja von geringer, nach höherer Wichtung sortiert haben!) -> Da ein MST ist, so erhalten wir auch einen MST, wenn durch ersetzt wird ( da die beiden Eigenschaften erhalten werden!)

Beispiel Anwendung | Kruskal |

Betrachten wir folgenden Graphen, dann möchten wir hier als Beispiel Kruskals-Algorithmus zum bestimmen eines MST anwenden:

[!Example] Betrachte folgenden Graphen: ![[Pasted image 20221121142820.png]] Unter Anwendung von Kruskal: wie könnte ein möglicher MST aussehen? #card Wir würden chronologisch die kleinsten Kanten nacheinander betrachten und dann einen MST bauen können: mögliche Konstruktion:

  1. B–>C
  2. C–>D
  3. C–>F
  4. F–>E
  5. D–>A ^1704708900457

| Kruskal | Implementieren |

Vorbetrachtung: Wenn wir den Algorithmus tatsächlich implementieren wollen, müssen wir bestimmte Dinge beachten und prüfen:

  • Testen, ob eine neue potentielle Kante ein Zykel erzeugen würde, oder nicht
  • wir müssen die Kanten nach Gewicht ordnen

[!Definition] Ein möglicher Ansatz zum Verhindern von Zykeln Wir könnten uns Partitionen der Knoten erzeugen, sodass die Kanten aus (also dem zu erzeugenden Baum) immer auf die Knotenmenge induzieren. Durch diese Betrachtung: Hängen dann für die Teilmengen nicht zusammen Wir können so also zum Anfang eine eine Partitionierung, folgend aufbauen: –> also für jeden Knoten ein eigenes Set ( eigene Partition aufmachen).

| Kruskal’s Algorithmus | UNION <> FIND |

Durch diesen Ansatz Zykel zu verhindern müssen wir jetzt folgend zwei Operationen definieren:

  1. Find(x) –> liefert den Namen der Menge ( Partition) , wo der gesuchte Knoten drin ist –> damit wir wissen, ob er sich in einer Partition befindet, die wir schon haben / oder nicht
  2. Union(A,B) –> Wir vereinigen zwei Mengen (Partitionen) und zu einer einzigen!
    • damit werden dessen Inhalte also zusammengefasst ( und wir wissen, dass da kein Zykel ist!)

[!Important] Intuition dieser Implementierung wenn wir Find und Union einbringen und alles in Partitionen aufteilen, was ist es dann für ein Algorithmus? #card Wir haben hier mehr oder weniger Union-Find aufgebaut, wo wir quasi Schritt für Schritt kleine “Blasen” von Knoten nacheinander verbinden und zu einer großen Zusammenführen.

Dadurch haben wir am Ende eine Implementation, die folgend den MST aufgebaut hat! ^1704708900465

Ferner wollen wir die Erweiterung zu Union-Find betrachten wie funktioniert dieser ALgorithmus? #card

\begin{algorithm} 
	\caption{erweiterer Kruskal Algorithmus}
	\begin{algorithmic} 
	\State $\text{sort edges in nondecreasing order by weight w} e_1,\dots,e_m \text{ so dass} c(e_1) \leq c(e_2) \leq \dots \leq c(e_m)$
 		\State initialize  $E_{T} = \emptyset$ 
 		\Comment{der Anfang ist also gleich, wie vorher!}
 		\For{$i = 1,\dots, m$}
	 		\State sei $e_{1}= (v,w)$
	 		\Comment{also wir schauen, uns die Verbindenden Knoten der Kante e an!}
	 		\State $A = Find(v)$
	 		\State  $B = Find(w)$ 
	 		\If{($A \neq B$)}
		 		\State $E_{T}= E_{T} \cup \{ e_{i} \}$
		 		\State $Union(A,B)$
		 		\Comment{Wir haben zwei unverbundene Partitionen gefunden, also kein Zykel, wenn wir sie verbinden!}
	 		\EndIf
 		\EndFor
	\end{algorithmic}
	\end{algorithm}

Wir wollen hier noch betrachten, wie dann die Funktionen Find und Union aussehen müssen: Dafür müssen wir uns folgende Struktur für eine solche Partition überlegen: ^1704708900474

[!Definition] Forderung für die Abbildung wie sehen die Funktionen Find / Union für Union-Find aus? Was brauchen sie? #card , so dass Also sie muss bei einem gegebenen Knoten sagen können, wo dieser drin ist.

Daraus können wir jetzt Union und Find ableiten und definieren:

\begin{algorithm} 
\caption{Find(x)} 
  \begin{algorithmic} 
  	\Return $R(x)$ 
  	\Comment{find(x) gibt also einfach den Wert, der sich in R befindet }  
  	\end{algorithmic} 
\end{algorithm} 

und weiter noch

\begin{algorithm}
\caption{Union(A,B)}
\begin{algorithmic} 
\For{$i = to~ n$} 
\If{$R(i) = A$}
\State $R(i) = B$
\Comment{Wenn der Knoten i in A ist, dann setzen wir ihn auf B}
\EndIf 
\EndFor 
\end{algorithmic}
\end{algorithm} 

^1704708900483

| Laufzeit 2. Kruskal’s Algorithmus |

Wir möchten jetzt für die erweiterte Struktur die Laufzeit betrachten und evaluieren:

[!Tip] Laufzeit-Betrachtung mit Erweiterung durch Find / Union wie ist die Laufzeit beider Implementationen? #card Wir wissen:

  • dass ist, da es nur einen Wert ausgeben muss, der sofort abrufbar ist
  • dass -> da es jeden einzelnen Knoten durchgeht und zu B hinzufügt, wenn er in A ist ! Weiterhin schauen wir jetzt, wie oft wir diese beiden FUnktionen ausführen:
  • -> weil wir alle Kanten betrachten
  • -> weil wir nach und nach von N viele Partitionen in eine einzige Reduzieren werden!

Dadurch resultiert folgende Laufzeit: ^1704708900493

Ein Problem was hier auftritt: Union ist zu langsam mit ! -> Um das zu lösen könnte man beispielsweise die Namesänderung proportional zur Größe der kleineren Menge machen und somit den Namen der größeren beibehalten ( dadurch müssen wir nicht alles traversieren)


| Verbessern von |

Aus der Betrachtung heraus, dass unser angepasster Kruskal-Algorithmus aufgrund der Union-Funktion relativ langsam werden kann, möchten wir eine bessere Implementation betrachten, den den obigen Vorschlag einbezieht, dass man die Namensänderung proportional zur Größe der kleineren Menge umsetzt.

[!Definition] Anpassung von für eine schnellere Union/Find Implementation was müssen wir jetzt für die Partitionen weiter betrachten, um sie schneller zu bekommen? #card Für die neue Implementation brauchen wir folgende Grundstrukturen:

  1. die Mengen ( Partitionen) sollen jetzt Listen sein. Ihre Größe muss gemerkt werden (damit wir sie später vergleichen können!)
  • die Größe soll mit abgerufen werden können!
  1. die Abbildung soll weiterhin erhalten bleiben, also für ! ^1704708900501

[!Important] Es müssen jetzt folgende Anpassungen für den PseudoCode von Kruskal eingebracht / umgesetzt werden: welche 2 sind es? #card

  1. initialisieren der Größe jeder Partition am Anfang des Algorithmus!
  2. die Union-Funktion muss angepasst werden, sodass sie nach der Größe entsprechend zusammenfässt
  3. bleibt gleicht ^1704708900514

| Aktualisierter PseudoCode | Was müssen wir mit unserer neuen Implementation ändern? Wie sieht jetzt aus? #card

\begin{algorithm} 
	\caption{erweiterter Union / Find Algorithmus }
	\begin{algorithmic} 
		\Procedure{initializePartition}{}
			\For{$i = 1,\dots,n$}
				\State $R(i) = i$ 
				\State $Elem(i) = i$
				\State $size(i) = 1$
				\Comment{Wir initialisieren hier die Partitionen und setzen ihre Größe auf 1} 
			\EndFor 
		\EndProcedure
	
		\Procedure{find}{x}
			\Return $R(x)$
		\EndProcedure
		
		\Procedure{Union}{A,B}
			\If{$size(A) < size(B)$} 
				\State tausche A und B 
			\EndIf 
			\For{all $x \in Elem(B$}
				\State $R(x) = A$
				\State append(x,Elem(A)) 
				\Comment{we are now expanding A with all entries of B}
				\Comment{For that reason we are also swapping A and B, in case B is larger; we always append the smaller partition to the larger one} 
			\EndFor
		\EndProcedure
	\end{algorithmic} 
	
\end{algorithm} 

^1704708900523

| Laufzeit von |

Wir haben durch diese Anpassung jetzt eine neue Laufzeit für Union etablieren können.

[!Definition] Laufzeit vom neuen warum ist es jetzt schneller, was ist besser? #card Da wir jetzt bei Union nicht mehr alles durchlaufen, sondern nur die Elemente der kleineren Menge, können wir entsprechend reduzieren, wie viele Knoten wir per Durchlauf anschauen müssen!

Es folgt eine neue Laufzeit: ^1704708900530

| Verbesserte Laufzeit von Kruskal’s Algorithmus mit neuem |

Da wir jetzt die Laufzeit reduzieren bzw von den Größen der Partitionen abhängig machen, können wir in der allgemeinem Implementation [[#Kruskal’s Algorithmus UNION <> FIND]] eine neue Laufzeit betrachten.

[!Tip] Laufzeit des Algorithmus ( Unions werden ausgeführt) inwiefern ist jetzt die Laufzeit anders, wenn wir den neuen Union-Algo nutzen? #card Die insgesamt Unions, die wir im Algorithmus ausführen, haben jetzt folgende Laufzeit: wobei hier die Größe der kleineren Partition ist, bei der -ten Iteration des Algorithmuses ( das kommt daher, dass wir ja immer nur die kleinere Menge in den großen einfügen müssen, und somit nur diese Einträge durchlaufen und aktualisiert werden müssen!)

Es gilt jetzt folgend: wobei jetzt die Zahl der Mengenwechsel für angibt. ^1704708900539

Wir können daraus folgende Behauptung entnehmen / betrachten: Behauptung: für a ( also jedes Element wird ) mal seine Menge (Partition) wechseln wie können wir das beweisen? #card Beweis: Wenn die Partition wechselt, und vorher in einer Menge mit Einträgen ( Knoten) war, dann die neue Menge die Größe . Gleichzeit haben wir nach wechseln dann eine Größe von aufgebaut und daraus folgt jetzt: –> Es folgt also daraus, dass wir immer größere Mengen erhalten und die kleinen Partitionen in die größeren fallen, dann der Fall, dass jeder Eintrag mal die Partition / Menge wechseln wird / kann! ^1704708900547

[!Definition] aktualisierte Laufzeit von Kruskal’s Algorithmus | Union Find Es resultiert eine Laufzeit

( es ist hier die amortisiert Analyse von Union-Find)

| Prim’s Algorithmus | Dijkstra aber für MST |

Neben Kruskal können wir jetzt noch eine Implementation betrachten, welche in ihrem Prinzip [[111.22_Graphen_SSSP_dijkstra]] ähnelt.

-> [[111.27_Graphen_MST_Prims_Algorithm]]

Pseudocode | Code vereinfacht darstellen:

anchored to [[111.00_anchor]]


Motivation:

Wir möchten Algorithmen so darstellen, dass man einen ungefähren Ablauf dieser betrachten und die Abläufe genauer beschreiben kann. Dabei möchten wir möglichst programmiersprachenunabhängig beschreiben, da eine genaue Implementation je nach Sprache stark variieren kann. Ein PseudoCode soll hier dann etwas als Grundlage zur Implementierung des abgebildeten Algorithmus dienen, dabei also die Details zur Implementierung nicht betrachten.

Definition | Pseudo-Code

Wir möchten mit PseudCode eine Sprache definieren, die es uns erlaubt, Algorithmen allgemein notieren und beschreiben zu können. Hierbei möchten wir Plattformunabhängige Beschreibungen von Abläufen und Vorgehensweisen darstellen und interessieren uns nicht für spezifische Umsetzungen in Programmiersprachen etc.

[!Tip] Intention of Pseudo-Code

Pseudo-Code is often used to implement description of algorithms
We omit language specific operators and use a common-sense system that is easily human-readable. hence indentation is important

mögliche Operationen

Mit Pseudo-Code lassen wir Sprachenspezifische Beschreibungen und Operationen weg, nehmen aber die Grundsätze von Datenflüssen mit auf. Das heißt, dass wir folgende Paradigmen mit anwenden dürfen:

  • iterative / rekursive Funktionsaufrufe
  • If-Konditionen
  • For-Schleifen
  • While-Schleifen

Vereinfachung / Verallgemeinerungen: Weiterhin möchte man manche Befehle vereinfacht darstellen, sodass zuvor gelöste oder betrachtete Punkte eines Algorithmus nicht nochmal bearbeitet oder definiert werden müssen.

[!Example] Setzt man beispielsweise für einen Algorithmus voraus, dass die Datenstruktur sortiert werden muss, bevor die spezifische Implementation ansetzt, kann man den Vorgang des Sortierens mit vereinfach darstellen.

Randomized Algorithms :: formal setup

Extending RAM Model ::

We add a new module to the RAM-Machine, a random-bit generator

  • A randomized algorithm has access to a random bit generator - black box mechanism that can produce either 0 or 1 with probability 1/2 for each >> even.
  • Generating oen random bit costs one unit of time.

==Observations==::

  • in practice, the random operation in an algorithm is often not a single coin flip, but requires many coin flips.
  • For example we might want to draw a random element from a set of n elements.

Discrete uniform distribution ::

Draw a random number from the set {1,…., N} where each element has the same probability 1/n to be chosen.

Think of a probable solution for this system ?

J. Lumbroso: Optimal Discrete Uniform Generation from Coin Flips, and Applications. Arxiv, 2013 ==link to solution ::== http://arxiv.org/pdf/1304.1916v1.pdf

Generic Labeling methods

anchored to [[111.00_anchor]]


convenient generalization of Dijkstra and Bellman-Ford::

  • for each vertex, maintain some sort of status variable S(v) in (unreachable, labelchanged,settled) >> marking their current status for further use
  • Repeatedly relax edges >> updating their status variable
  • Do this until nothing changes any more - we reached a status of everything being finite ![[Pasted image 20221118111205.png]]

Principle acts as blueprint for labeling and traversing through graphs and their vertices..

  • a vertex could be scanned several times and change its status often
  • the quantity of those scans and changes depends on line 8 of the code >> how the vertex is picked
  • if managed to select a vertex v ==such that== v.dist is already the correct distance, then we scan each vertex once at max >> optimal solution
  • Dijkstras algorithm is a special case of labeling method :
    • one can show that if we choose the vertex that has the smallest distance value among all verties with status “labelchanged” then the algorithm is equiv to DIjkstra and each vertex gets scanned at most once.

cards-deck: 100-199_university::111-120_theoretic_cs::111_algorithms_datastructures

Run-time analysis:

anchored to [[111.00_anchor]]


Overview:

Whenever we would like to evaluate the running time of an algorithm we have to take some metrics that denote this behavior and their occupied time.

Simply taking physical time is not feasible to evaluate the time of an algorithm, simply because its dependant on hardware, thus we can’t use those measurements to account for analysis

Instead we are introducing a simplified model of a computer that simplifies the process of evaluating running-times:

RAM-machines | Random Access Machine:

Traits of a RAM-machine:

  • they have sequential processing because parallel processing would be too difficult as of now ( or is not possible [[112.04_non_deterministische_automaten]])
  • it features uniform memory –> all access to memory takes the same amount of time
    • so we don’t have optimization like caching, memory hierarchy etc –> its just one uniform memory space.

Uniform operations:

This defined ram-machine requires a specific time for an operation. Those operations and their time taken are defined as follows:

  • load one bit from memory –> takes one unit of measurement “Rechen-Einheit”
  • write one bit of memory –> takes one unit
  • Elementary arithmetic operation for numbers of bounded length, we assume that we can add, subtract, multiply, divide them in a constant time
  • Similarly, each logical operation (and, or not ) is an elementary operation ( so )

All those operations take one unit of time –> one Rechen-Einheit

Examples | calculating amount of operations:

cost of adding two numbers that are represented with N bits:

How many time units does the computation of the two numbersrepresented with -bits take? #card
Without a constant ( or better actually defined ) size for a number (64bit for example) it would take time-units ^1704708599285

To give an example: Lets assume that: and the actual computation is denoted with how many operations would we have now? #card
To conclude we have operations to work with ^1704708599293

Now to look at multiplication: Lets assume that and the actual task is how many computations would this take? #card with each number we have to multiply all others. To visualize that would be:

  • -> first multiplication
  • -> second
  • -> third
  • -> fourth after that we have to add all numbers together –> the size of this complete addition would then be or ^1704708599298

Further examples:

  1. add two standard integers (int) :: O(1) so its a constant operation ^1704708599302

  2. write matrix into memory :: also eine Matrix mit Spalten, Zeilen ^1704708599306

  3. Read string of length : because its dependant on the size

Worst-Case Laufzeiten:

Mit Worst-Case Laufzeiten betrachten / beschreiben wir die Umstände zur Ausführung eines Algorithmus, die die längste Laufzeit verursachen kann. Dabei ist wichtig, dass es sich um eine theoretische Schranke handelt.

[!Tip] Intuition for worst-cases: Worst cases are crucial for safety-critical systems because they are only setting the upper bounds of the running time of any particular instance. Some algorithms behave very well in practical thus the constructed theory may lead to rly bad worst case scenarios that are not as bad normally because they are rather rare. Example: Sorting an array with a good in practice system that yet still poses a heavy worst case scenario in theory. Although this worst case scenario exists it may not occur often while the good / average cases are common.

Betrachten wir für ein Problem alle Instanzen , dann möchten wir damit bestimmen, wann der Algorithmus am längsten brauch, um das Problem zu lösen.

Dafür definieren wir folgend:

  1. als die Menge aller Instanzen der Länge –> also abhängig von
  2. Wir beschreiben die Laufzeit mit auf einer gegebenen Instanz Damit können wir die Worst-Case-Laufzeit folgend beschreiben: wie? #card –> also die maximale Laufzeit aus der Menge aller Laufzeiten ( obviously) bildet die worst-case running time. ^1704708599312

Average-Case Laufzeiten:

Wenn wir die Average-Case Laufzeit betrachten, dann möchten wir damit erfassen: -> Wie lange brauch der Algorithmus im Durchschnitt bei -vielen Instanzen?

Dafür ist es auch wieder notwendig einige Grundlagen zu definieren: Let denote the space of all instances of length Further we are denoting the time taken by defining it with , where is the instance. We can now define the average case running time as follows: #card

[!Tip] Intuition Das heißt wir nehmen die Menge der Instanzen, summieren deren Zeit, die resultierte und anschließend teilen wir sie durch die Menge der Instanzen, die durchgeführt wurden. Also eine einfache avg-Rechnung ^1704708599316

There are some subtleties regarding avg-case times, because they seem to depend on the amount of instances. This may pose some issues but we are not focusing on this aspect in this lecture.

Spezialfälle bei Laufzeiten:

Es gibt diverse Beschreibungen, die angewandt werden und eine explizite Laufzeit meinen. Sie beschreiben hier also eine spezielle Landau-Notation [[111.04_laufzeitanalyse_onotation|Onotation]]

linear :: ^1704708599320

sublinear :: ^1704708599324

superlinear :: (echt größer ) ^1704708599328

polynomial :: ( genau gleicher Anstieg, wie ein Polynom abhängig von N ) ^1704708599333

exponential :: ^1704708599336

Space complexity:

[!Important] it is necessary to know how much capacity an algorithm is utilizing / requiring

For this lecture we will use the structure of the One-model unit. meaning that we are setting the size for the following units:

  • a letter
  • a logical bit
  • a number of fixed / bounded length

[!Info] Reasoning with space complexity: #card For many problems there is a certain space/time tradeoff available.

That means:

  1. Some algorithms are very fast, but need a lot of space
  2. Other algorithms are very slow, but need nearly no storage er and close to no space

As example: One could calculate the Fibonacci at runtime or storage to retrieve the cache later ^1704708599340


cards-deck: 100-199_university::111-120_theoretic_cs::111_algorithms_datastructures

| Relaxation | Relaxieren |

anchored to [[111.00_anchor]]


Overview

[!Definition] Intuition von Relaxation was beschreiben wir damit, was wird für jeden Knoten gespeichert? #card Wir wollen für jeden Knoten einen Wert speichern, der mit oder auch $\detlta(v)$ beschrieben wird. Dieser Wert dient dabei der derzeitig vermuteten Distanz von einem Ursprung zu dem ausgewählten Punkt .

Zu Beginn setzen wir diesen dabei auf , weil wir damit angeben dass es noch keinen Pfad gibt ( und weil wir später immer checken, ob es einen kleineren Wert gibt und es somit einfacher wird).

Führen wir die Funktion jetzt aus, checken wir folglich, ob es einen kürzeren Pfad gibt ^1704708762291

Wir tracken mit einer Relaxation also die derzeitige Distanz zu unserem ausgewählten Knoten vom Startpunkt .

Umsetzung

[!Tip] Relaxation Ausführung wir haben das Konzept kürzere Kosten zu eine Punkt zu finden, wie setzen wir das um ? #card Generell ist der Ansatz: -> Herausfinden, ob wir den derzeit kürzesten Pfad verbessern können. Dabei betrachten wir die Kanten , also jene, die von einem Punkt zu unserem jetzigen hinzeigen. Dadurch können wir dann herausfinden, ob (u,v) kürzer ist, als das derzeitig gespeicherte –> Es wird hierbei die Distanz aus entnommen und auf die Kosten der Kante hinzuaddiert! ^1704708762304

Wir können jetzt einen möglichen PseudoCode schreiben, der diesen Vergleich darstellt / definiert:

def Relax(u,v):
# wir prüfen, ob die neue Distanz kürzer ist
if v.dist > u.dist + w(u,v) # bzw bei uns v.dist > u.dist + c(u,v) 
	# sie ist kürzer, update also
	v.dist = u.dist+ w(u,v)
	v.Vorgaenger =u # wir speichern, also woher er zuvor gekommen ist!

Anwendung

Wir können dieses System immer dann verwenden, wenn wir Algorithmen betrachten, die irgendwie den kürzesten Pfad suchen ( SSSP/ASAP)

Wir finden ihn etwa in

  • Bei Bellman-Ford

Point to Point Shortest Paths:

Shortest path between to given points S and T in a Graph

BI-Directional Dijkstra ::

==Idea== ::

  • Instead of Dijkstra at s and waiting until we hit t, we start two copies of the dijkstra algorithm simultaneously
  • while executing we are alternating between the two algorithms
  • we stop once the algorithms and their ==progression meet==.

![[Pasted image 20221118105345.png]]

Observations ::

  • less time to explore unnecessary paths between starting point and target
  • ==Dijkstra is advancing like a wave and thus we explore a certain radius before hitting the target==
  • thus we can take two of them and let the waves of exploration meet faster because dijkstra is not progressing as much into all directions

Could we run multiple dijkstras too ?:: what is necessary is to find an approximate middle point of two targets, lets say travelling from tübingen to hamburg and choosing Frankfurt as the third point for a djikstra application.

The issue occuring :: now it is required to take a path via Frankfurt thus we are restricting ourselves to taking that pre-defined path, even if it was no the shortest path available.

![[Pasted image 20221118105556.png]]

case of k-dimensional grid ::

  • Consider s and t as points on a k-dimensional grid, having distance of d(s,t) : L
  • Standard-Dijkstra visits about vertices - volume of a circle of radius L of this order up to a given constant
  • The Bi-directional Dijkstra visits about vertices >> that is because we create two new circles that meet at some point and are definitely smaller than the L radius of the single dijkstra
  • The resulting ==speedup factor==

Execution of bidirectional Dijkstra ::

  • If graphs are directed :: reverse all edges in the backward search, so that we have a an algorithm that is traversing trough the original path and one that is taking the reversed path – it is inverted because we search from the path from A to B, but starting from the Position of B.

    • If it was not directed that wouldnt be a problem, but because it is, we have to check for valid paths from A to B, starting at B ![[Pasted image 20221118110731.png]]
  • Running Dijkstra on G, starting from S and Dikstra on G starting from T until both of them meet.

Pseudo-Code of Bidirectional-Graph ::

![[Pasted image 20221118110938.png]]

Theorem :

If T is reachable from s, then the algorithm BiDirectionalDijkstra(G,s,t) finds an optimal path, and it is the path stored with delta

A* search - heuristic approach ::

to finding shortest path between two points

==fill Def==

in given graph the value in each node is the approximated distance to the destination >> approximated Luftlinie that was inserted before

A* takes this value and the actual cost of the path currently given, and calculates the approximate distance to each node attached via a vertices.. once calculated the shortest distance - actual cost + assumed distance from node to destination - is determined and the given node choosen for the next operation. From there procedure continues until done and shortest path found

==Important==:: Approximated values ought to be correct, otherwise A* is going to fail, or could potentially. ![[Pasted image 20221118112645.png]] the distance assumption is taken and added to the value

==bidirectional A* search :: == https://stackoverflow.com/questions/62239310/bidirectional-a-a-star-not-returning-the-shortest-path

Local Search (Heuristic)

broad part of [[111.00_anchor]]

![[Pasted image 20230109152041.png]] Given example of a reel-function :: How would we find the global minima of the given function ?

An attempt would be taking the first Ableitung and then searching for all x where f(x) = 0 and then take the smallest one.

Another numeric solution:

  • start at arbitrary point
  • compute derivative, walk a small step - downhill
  • procee until we’ve found a local optimum. However we cannot guarantee that this optimum is the global optimum so the algorithm is not perfect at all.

More general principle :

Local Search :

  • Start with some initial solution - mostly randomly selected
  • explore the local neighborhood and try to find a better solution in this neighborhood.
  • If we’ve found a better solution, we take it.
  • We stop if we cannot find any better solution in the local neighborhood than the one we already have.
  • We may repeat that procedure with several initial solutions.

With that system we perpetually traverse through local solutions searching for the global solution step by step.

![[Pasted image 20230109152536.png]]

Example : Traveling Salesman ::

Local search for tsp :

Recall the traveling salesman problem. We are given a graph with weighted edges, edge weights are interpreted as distances here. We ought to find a tour through that graph that has the smallest length possible.

==Approach== :

  • Start with arbitrary tour - we select and initial tour to take through graph - is mostly randomly selected
  • Define a “local change” - we exchange the order of two points on the tour at most. We are striving for optimizing the path between these paths by exchanging the orders to travel better.
  • Then we check for each pair of points whether the tour gets shorter if we swap these points
  • We do that until no further improvmenent is possible anymore ![[Pasted image 20230109152955.png]] ![[Pasted image 20230109153003.png]] ![[Pasted image 20230109153012.png]]

This is a local search:

We create a inital state that is locally defined. Now we are improving the solution step by step to enhance the overall path locally step after step. Once we’ve found the optimal solution for all patsh in our local proble, we’ve found the optimal solution.

Depending on the overall implementation we will definitely have a termination::

  • if we have negative cycles in the graph, it will not terminate
  • if we define the premise that each solution must be strictly better than the previous, we will also terminate at some point
  • if we are not checking for strict improvement then we cannot guarantee termination.

==Improving the solution==

  • we can increase the size of the neighborhood, we swap more than just two points per step.\
    • By increasing the neighborhood we explore more possibilities, and thus are able to find even better solutions that wouldnt’ve been found in our smaller scope

==Tradeoff==

  • The larger the “neighborhood” the more complex the search gets - finding the best swap between k points, then round of swapping takes O(n^{k})
  • But the larger the neighborhood, the better the local optimum is going to be.

In order to escape traps of local optimums, we may have to adapt the size of our neighborhoods, in order to get out of those fields.

Principle : We have a large neighborhood at start and get partially smaller each time.

Inspired by physics of crystallization :

  • We start with liquid state, particles can move freely
  • We cool down the system, particles are moving into more regular positions
  • Annealing - ausglühen/aushärten >> we want the system to freeze completely fast

We apply that principle to algorithms::

  • we have a parameter called temperature T
  • at the beginning, T is larger - we are decreasing it later in time
  • THe larger T, the more freedom we have to walk through the search space - even if we worsen our current solution
  • As T decreases, we can only ove towards better solutions in the search space

Simulated Annealing - Idea :

let s be any starting solution  
repeat  
	randomly choose a solution s ′ in the neighborhood of s  
	if ∆ = cost(s ′ ) − cost(s) is negative:  
		replace s by s ′  
	else:  
		replace s by s ′ with probability e −∆/T

With high Temperature we are likely to jump to the new position because delta /T is leaning towards 1 With a high delta we are probably not jumping towards the new destination because the probability will be small.

THe probability to jump to a “bad” state depends on two things then ::

  1. the current temperature T
  2. and how bad the state is compared to the current state –> we use Delta

Now we apply and “annealing schedule” we slowly decrease T.

At the beginning, we start with a large T. then the algorithm can move freely in space and decrease it over time We then reduce the temperature and the lower T, the less the probability to escape from a local optimum is gonna be.

comments regarding Simulated annealing ::

  • Simulated annealing is somewhat of an art - finding good annealing schedules is not easy
  • But sometimes it works quite well and may be very popular too.

Discussing local Search ::

Local search always end in a local optimum - where local refers to the neighborhood relationship - the set that was explored after all. > local optimum = best solution in a given neighborhood

Typically we don’t have any guarantees to end in the global optimum, and we also don’t have any guarantees about how much better the global optimum might be, compared to our current solution. That is primarily because we cant ensure that we’ve found the global optimum during our run, because the neighborhood may’ve not covered it.

approximating success ::

The success of local search depends primarily on the choice of the neighborhood. ==main strategy to define neighborhoods==: Apply local transformations to the current solution. For example, in a graph cut problem, it would be useful to define a particular partition as a set of all partitions that agree with the given one in all but a single vertex. We set pre-requirements that must be met to define a neighborhood.

Time-Accuracy-Trade offs ::

With Small neighborhoods we provide aspects like :

  • easy to search, yet more local optima - the algorithm could stop at worst solution With large neighborhoods we have aspects :
  • more computational time to search through the neighborhood
  • yet better chances of finding a good optimum

An alternative would be :: Constructing a large neighborhood, yet not searching through it exhaustively. Instead apply some fast search procedure - like done with greedy algorithms - that are only inspecting certain parts of the neighborhood.


Takeaways ::

  • Local search is about the first thing oe can try when solving an optimization problem.
  • In many cases it leads to pretty poor solutions. We can increase the overall quality by multiple restarts - increasing quantity of searches - or adding some heuristics to it.
  • Whenever we have a more direct algorithm available, ==we should tend to that one!==
  • Local search is better than having nothing at all, so see it as ==last resort== It is especially useful for many problems where there is no efficient algorithm available - NP etc.
    • ==Be aware of its limiations==
  • In some sense, local search is also a greedy algorithm :: it only moves on to better solutions, yet will never trace back to a “previous/worse” one
  • There exist many variants of local search, and also more sphisticated local search principles such as simulated annealing. Yet there efficiency and usefulness also depends on the context and application.

Bloom Filters | schnell taggen mit Hash-Funktionen

anchored to [[111.00_anchor]] more specific application of [[111.10_hash_functions]]


Motivation:

Consider we are an ISP that caches frequently served webpages. A new request was issued and we have to determine whether the requested page is in its cache or not. Now usual we would have to query said cache and search for the entry. With millions of webpages that would cost us a lot, so we would like to improve speed by searching less. We do this with multiple Hash-functions processing the requested webpage.

Characteristics:

  • needs to respond fast
    • if not found, load immediately
    • if found, search within cache
  • not a disaster if a wrong decision was made – its not necessary to be right 100%
  • dont waste too much space to be able to make that decision > space efficient

Solving -> Indicate whether its contained or not:

  1. consider the universe that represents all web pages
  2. we now create a table with at most entries.
  3. Further we would like to construct -hash functions, with the following characteristic:
  • Initially our bloom filter is an array A with m elements, all are initialized to 0
  • if we want to insert a new to bloom filter. To do, we compute all values of the hash functions and set their corresponding field to 1 - was 0 initially

![[Pasted image 20221031152516.png]]

executing Query ::

if we query for website :: compute all hash values for each hash function and check whether all entries are set to 1 or not :: possible Results ::

  • all values are 1 >> website was loaded before - maybe not
  • if at least one value is 0 >> 100% not cached so far >> cant be false

Only yes can be false positive >> collision, whereas no is always correct

Time complexity ::

Both insertions and queries are just O(k), independently of the number of keys >> constant time!

Space complexity ::

Theoreme betrachten :: einzelne Parameter anschauen und gucken, was ist, wenn Parameter X sehr groß ist >> was ist ihr möglicher Einfluss auf die Gleichung / das Theorem Die großen und kleinen Schranken abdecken und durch simples testen evaluieren, wie der Verlauf sein könnte


cards-deck: 100-199_university::111-120_theoretic_cs::111_algorithms_datastructures

<| QuickSort |>

anchored to [[111.00_anchor]] proceeds from [[111.31_Mengen_Sortieren]] specifically continues from [[111.32_merge_sort]]


Overview

We’ve looked at MergeSort now, however we are usually just splitting the whole array into halves without actually checking whether we can pre-sort those two parts a little

Now with QuickSort we want to introduce a Pivot-Element which is used as anchor to decide where to put an element ( either left or right of it ( larger or smaller than the element))

Definition

[!Definition] Consideration / Intuition for QuickSort what are we doing with quicksort, whats the pivot-element? #card Consider an input We would like to sort this Set accordingly. We are now doing the following steps:

  1. Choose a pivot-element ( usually just the first entry because easy to access)
  2. Split our set into two smaller sets as follows:
  3. Save those arrays accordingly in the left/right part of the set, so
  4. Now we are going to recursively apply thise principle again ^1704708956467

We may now look at the running time of this algorithm that tries to improve on merge sort:

[!Important] Runtime of QuickSort which runtime can we result with? Consider decision of pivot element, sorting accordingly etc #card
In Worst Case our algorithm can result with the following runtime: So actually pretty bad, lol. HOWEVER the worst case is really really unlikely to happen and thus most of the time not the limiting factor. We then result with a avg runtime of here! ^1704708956479

We may proof why the average Case is so much better or more often to occur:

Consider a probability model: Die Elemente sind paarweise verschieden, und alle Permutationen der Eingabe sind gleichwahrscheinlich aufzutreten:
Das heißt wenn wir etwa eine Menge nehmen, dann ist die probability jetzt: Unter dieser Betrachtung erfüllen die Teilprobleme der Größe und auch die Annahme. Dafür möchten wir jetzt noch betrachten:

  • sei jetzt eine mittlere Anzahl Vergleiche an Problemsgröße
  • wir meinen mit
  • Ferner können wir jetzt noch auf

Wir können einfach zeigen, dass die average Laufzeit von Quicksort ist.

Graphen | Informationen vernetzen:

anchored to [[111.00_anchor]] belongs to [[111.08_algo_datastructures]]


Basic Definition:

Wenn wir von einem Graphen sprechen meine wir folgende Struktur:

[!Definition] Graphen was sind Graph, womit werden sie aufgebaut? wie mathematisch? #card Ein Graph besteht grundlegend aus Knoten und Kanten. Dabei sind Knoten irgendwelche Datenpunkte, die wir mit Kanten ( als Verbindungselemente ) in Beziehungen zueinander setzen können. Kanten können gerichtet ( also die Orientierung ist wichtig!) oder ungerichtet sein!

Ein Graph ist jetzt und besteht dabei aus einer Menge von Kanten, wobei ist. ( also es gibt zwischen allen Knoten Kanten, aber meist ist das nicht der Fall)

![[Pasted image 20221104101944.png]]

Es existieren also gerichtete Graphen und ungerichtete Graphen, welche sich folgend unterscheiden: #card

  • gerichtete Graphen haben Kanten mit Orientierung, also wenn wir von A -> B meinen, geht hier nicht B ->, außer wir fügen diese Kante hinzu. Dann wird daraus <->
  • ungerichtete Graphen beschreiben nur, ob etwas verbunden ist oder nicht –> hier ist keine Orientierung der Beziehung zwischen Knoten wichtig!

[!Tip] Adjazent was meinen wir damit? #card Wir nennen zwei Knoten adjazent (benachbart), wenn es eine Kante zwischen beiden gibt. Also etwa heißt, dass adjazent zueinander sind!

Notationen:

Wenn wir ungerichtete Graphen betrachten, beschreiben wir mit :: dass diese beiden benachbart sind, also zwischen beiden eine Verbindung besteht!

Betrachten wir einen gerichteten Graph, beschreiben wir mit :: , dass eine Kante von u nach v existiert, also

Kosten und Gewichte auf Kanten beschreiben wir folgend mit :: für Gewicht und für Kosten

Es gibt Spezialfälle, wo alle Kantengewichte zwei Zustände haben können :: -> keine Kante, -> eine Kante

Wir sprechen von einem Loop / Selbstschleife, wenn :: ![[Pasted image 20231109151149.png]]

Anwendung von Graphen:

Eigentlich können wir Graphen überall bzw oft anwenden, um Probleme anders darzustellen ( Bäume etwa ).
Weiterhin gibt es viele Anwendungen bei:

  • Netzwerken
  • Such-Algorithmen
  • großer Datenverarbeitung ( Interessen oder Gruppen herausfinden können )
  • using graphs for representing a cluster of possible outcomes that ought to form a consens [[462.01_consensus_algorithms]]

Grundbegriffe | Grad:

Wir möchten jetzt die Eigenschaft des Grades eines Knotens betrachten.

[!Definition] Wir definieren den Ausgangsgrad was beschreibt dieser? #card Wir beschreiben damit, die Menge an Kanten, die von dem Knoten ausgehen. Anders beschrieben also :

Wir könnun auch noch den Eingangsgrad betrachten, der analog dazu ist

[!Definition] Eingangsgrad eines Knoten was meinen wir damit? #card Der Eingangsgrad ist, analog zum Ausgangsgrad, die Menge von Kanten, die zu dem Knoten zeigen Formal beschrieben also:

Wir können jetzt noch die Zusammenführung beider “Grade” betrachten:

[!Definition] Der Grad eines Knoten was beschreibt er, wie bilden wir ihn? #card Der Grad eines Knoten beschreibt dessen Ein-, und Ausgehenden Kanten! Es werden also alle Kanten, die in Relation zu diesem Knoten stehen gezählt. Formal definieren wir ihn dann:

Folgend noch ein Beispiel, was die Nutzung beschreibt:

[!example] Grad von Knoten Betrachte folgenden Knoten ![[Pasted image 20231109152745.png]]

  • outdeg von 2 ?
  • indeg von 1 ?
  • deg von 4 und 3 ? Beantworte die Fragen #card

[!Important] Convention | Number of vertices and edges Wir werden in dieser Vorlesung nur finite Graphen betrachten, also solche bei denen gilt was ? #card –> Menge der Knoten –> Menge der Kanten ![[Pasted image 20221104103141.png]]

Pfade | Graphen folgen

Wir möchten folgend ein paar Terme definieren, die Pfade auf bzw in Graphen beschreiben können.

[!Definition] Pfade wie definieren wir einen Pfad in Graphen? #card Sei ein Graph. Wir nennen jetzt die Folge von Knoten einen Pfad, wenn für alle Kanten besagte Kanten-Kombination existiert: –> Vereinfacht gesagt heißt das, dass wir von einem Pfad sprechen, wenn wir von einem Knoten zu einem anderen Knoten durch den Graphen traversieren können. Es muss also entsprechende Kanten geben, die das ermöglichen.

Wir können jetzt noch ein Zykel als spezielle Form eines Pfades betrachten:

[!Definition] Zykle - Pfad was meinen wir mit einem Zykel? #card Mit einem Zykel meinen wir einen Pfad , wo der Startpunkt gleich dem Endpunkt ist. Also –> wir bewegen uns also Zyklisch und haben einen Kreis-PFad in dem Graphen gefunden.

[!Example] Betrachtung eines Graphes. ![[Pasted image 20231112145729.png]] Finde den Pfad und die Zykel #card

Forests | Graphen mit Binärbäumen:

Wir möchten noch den Begriff eines Forests einführen, welcher solche Graphen beschreibt, die in ihrer Form aus mehreren disjunkten Bäumen bestehen.

[!Definition] Bezeichnung eines Graphes als Baum: welche Eigenschaften (3) muss erfüllen? #card Sei hierfür ein Graph. Er heißt jetzt Baum, wenn folgendes gilt

  1. V enthält genau ein , mit –> Also ein Knoten, bei welchem nichts hineingeht und nur abgeht (Das ist die Wurzel unseres Baumes)
  2. –> Also jeder weitere Knoten hat immer genau eine Eingehende Kante –> die des parents
  3. ist azyklisch –> hat also keine einzigen Zykel in sich.

[!Important] Erweiterung eines Graphen als Forest: wann sprechen wir von Forests? #card Wir nennen einen Graphen Forest, wenn gilt, dass aus mehreren disjunkten Bäumen besteht –> also wobei ein Baum ist

[!Example] Folgend sind ein paar Forests gelistet: ![[Pasted image 20231112150733.png]]

Acyclic Graphs:

[!Definition] acyclic Graphen #card Mit acyclic Graphen bezeichnen wir solche Graphen, die in gar keinen Cyclus in den Pfaden aufweisen. Das heißt demnach, dass wir nur von einer Richtung in die andere Traversieren können, und so der Anfangs-Knoten in einem Pfad niemals der Ziel-Knoten sein kann.

Da diese Form speziell ist, bekommt sie noch ein Akronym, damit man direkt weiß, worum es geht:

[!Important] DAG - Directed - Acyclic Graph –> Sind Graphen die gerichtet sind, und dabei keinen Zykel aufweisen!

Vollständige Graphen ( Complete graphs):

Mit vollständigen Graphen beschreiben wir solche Graphen , bei denen folgend gilt: #card

  • für beliebige Knoten –> also jeder Knoten im Graphen ist mit jedem Knoten verbunden.

[!Example] Beispiel für vollständigen Graph ![[Pasted image 20231112170158.png]]

Bipartite Graphen:

Wir sprechen bei einem Graphen von bipartite, wenn folgend gilt: #card

  • Wir können die Menge der Graphen in zwei Gruppen unterteilen.
  • Dabei ist wichtig, dass sich die Knoten in einer Gruppe nicht verbinden
  • Ein jeder Knoten aus einer Gruppe trifft (alle) Knoten aus der anderen Gruppe
  • Formal heißt das: und weiterhin für die Knoten und umgekehrt

[!Example] vollständiger, bipartiter Graph ![[Pasted image 20231112170634.png]]

induzierter Graph:

Wir möchten ferner einen Teilgraphen von als induziert bezeichnen, wenn gilt: #card

  • und folgend mit gilt jetzt auch
  • Also wenn wir eine Verbindung zwischen Knoten haben und diese Knoten auch in dem neuen Graphen enthalten sind, müssen sie die alten Verbindungen übernehmen ( um gleich dann induziert genannt zu werden )

[!Example] induzierte Teilgraphen ![[Pasted image 20231112171128.png]] Er ist nicht induziert, weil hier nicht die Kanten zwischen a.g.f,b bezeichnet bzw genannt werden.

Zusammenhängend:

Wir möchten einen **ungerichteten (undirected) ** Graphen als Zusammenhängend bezeichnen, wenn #card

  • zwischen zwei beliebigen Knoten existiert ein Pfad, sodass beide Knoten verbunden werden.
  • Die Pfade müssen also die Endpunkte haben an.

Zusammenhangskomponente (ZK):

Nennen wir dann schließlich einen Bereich eines ungerichteten Graphen Zusammenhangskomponente, wenn für den Graphen gilt: #card

  • der maximale, zusammenhängende Teilgraph bezeichnet jetzt die Zusammenhangskomponente

[Example] Beispiel für Zk: ![[Pasted image 20231112171813.png]]

stark zusammenhängend:

–> Gilt nur für ==gerichtete Graphen==! Wir können jetzt einen Graphen stark zusammenhängend beschreiben, wenn folgendes gilt:

    • Das heißt also, dass es für jeden Knoten in dem Teilgraph eine Verbindung zwischen beiden Knotengibt. Dabei ist die Verbindung aber beidseitig, wir können also von aber auch !

starke Zusammenhangskomponente (SZK):

Wir beschreiben mit einem SZK :: einen maximal stark zusammenhängenden Teilgraph eines gerichteten Graphen

  • zusammenhängend, weil alle Punkte miteinander verbunden >> im Bild ersichtlich
  • maximal sodass es keinen größeren Verbund gibt, welcher ebenfalls eine Teilmenge des Graphes bildet. ![[Pasted image 20221104103745.png]]

Multi-path-Graphs

Wir können uns einen Graphen anschauen, welcher womöglich mehrere Kanten für eine Verbindung zwischen aufweist. -> Meist sind diese in ungerichteten Graphen vertreten, aber können auch in gerichteten vorkommen.

[!Example] ![[Pasted image 20221104105948.png]]

dense graph(dicht besetzter Graph) :: has very many edges :: based on context, very many is not specifically defined. Used when the number of m of edges is more than logarithmic in the number of vertices, in particular

sparse graph(dünn besetzter Graph) :: contains few edges each vertex has a very small degree compared to n possible ones. May be called sparse if number of edges is O(n log n) or O(n)(rare)

Graphen Darstellen / Repräsentieren:

Wir können Graphen jetzt grundsätzlich konstruieren und später diverse Vorteile ihres Konzeptes anwenden, brauchen aber weiterhin eine Grundform bzw. Datenstruktur in welcher wir diese Graphen repräsentieren können.

Darstellen als Matrix:

Als erste Lösung könnte man sie in Form einer Matrix bilden:

[!Definition] Adjazenzmatrix für Graph wie ist diese aufgebaut? #card Wir beschreiben die Matrix, die diese Verbindungen zwischen den einzelnen Knoten darstellt folgend: , wobei jetzt

Betrachten wir folgenden Graphen und stellen ihn als Matrix dar: ![[Pasted image 20231112181035.png]]

[!Definition] Besonderheit der Matrix bei ungerichteten Graphen Betrachten wir ungerichtete Graphen, dann sehen wir, dass sie Symmetrisch sind

Kosten und Aufwand:

Wenn wir einen z betrachten, also einen Graphen der Größe mit einer Menge von Kanten .

[!Definition] Platzbedarf für diese Matrix? Wenn wir hier Knoten haben, dann müssen wir maximal alle möglichen Knoten, also die Menge, die bei eine vollständigen Graphen auftreten könnte, abdecken können! Es folgt daher ein Platzbedarf von , denn wir brauchen eine Matrix von Größe –> jeder Knoten, kann theoretisch mit jedem Knoten verbunden sein.

[!Definition] Zugriffszeit bei einer Adjazenzmatrix: was bildet ein Problem? #card Wir wissen, wo sich bei der Matrix ein Eintrag für die Kanten befindet. Aus diesem Grund ist es ein statisches abrufen mit:

Ein Problem entsteht, wenn man dünne Graphen hat, also solche die kaum Verbindungen haben. Da ist der Platzbedarf weiterhin mit beschrieben, obwohl wir beispielsweise nur Elemente haben.

Fragen bei Matrizen:

Man kann jetzt folgende Fragen definieren:

  • Welche Knoten hat die meisten eingehenden Kanten? –> am beliebtesten
  • Welches Knotenpaar ist am weitesten auseinander?
  • Welcher Knoten ist zentral

Darstellen als Adjazenzliste:

Alternativ zu einer Matrix können wir die Abhängigkeit von Knoten auch durch Listen darstellen. Das heißt demnach, dass wir für jeden Knoten die Nachbarknoten dieser speichern.

bei gerichteten Graphen müssen wir dabei zwei Repräsentationen betrachten: welche, warum? #card

  • –> also alle die, die in einen Knoten führen
  • $OutADJ(v) = { w\in \V | (v,w) \in E }$ –> also alle die, die von dem Knoten ausgehen

bei einem ungerichteten Graphen können wir die Speicherung der Adjazenzlisten etwas vereinfachen: wie? #card

  • wir brauchen nur ob eine Verbindung vorliegt oder nicht. Es gibt also keine Information darüber, wie sie verbunden sind!
  • Dadurch folgt

Betrachten wir dafür ein Beispiel:

[!Example] Adjazenzliste eines gerichteten Graphen: Wir wollen den folgenden Graphen betrachten: ![[Pasted image 20231112190558.png]] wie sieht dessen OutADJ Liste aus? #card ![[Pasted image 20231112190613.png]]

ein weiteres Beispiel: ![[Pasted image 20221104112300.png]]

[!Important] Platz für Adjazenzlisten: wovon ist er abhängig? #card Wir können den Platz, der für eine Adjazenzliste benötigt wird folgend definieren:

[!Definition] Zugriff auf spezifische Kanten und Geschwindigkeit dieses Zugriffes ? #card Wenn wir auf eine Kante von zugreifen möchten, dann müssen wir entsprechend alle Adjazenz-Elemente von betrachten –> da diese Speichert, wohin von verbunden wird. Aus diesem Grund ist die Zugriffszeit notiert mit , wobei: meint, also die Größe der Liste, von den ausgehenden Verbindungen des Knoten

Folgerung für Adjazenzlisten:

Wie wir sehen können ist der Zugriff auf eine Adjazenliste nur so groß, wie die Menge der verbundenen Knoten, also . Weiterhin ist der Platzbedarf verhältnismäßig klein und vorallem dynamisch zur Menge von Elementen, also .

Aufgrund dieser Eigenschaften können wir folgern:

[!Definition] Platzverbrauch und Vergleich zu Matrixdarstellung #card -> die Platzverwendung ist hier deutlich effizienter, weil die Größe dynamisch mit der Menge von Knoten und Kanten linear steigt und nicht wie bei Matrizen explodiert. Es kann hier jedoch sein, dass der Zugriff langsamer ist, weil wir unter Umständen eine gewisse Menge von Einträgen durchsuchen müssen, um unsere Lösung zu finden.

When to use matrix or list:

if the graph (knowingly) is rather small - couple of 100 vertices at most - its does not matter much which representation to choose from, because the time wont differ much.

However if a graph is dense we can observe that for both representations ::both take about the same amount of storage, yet a matrix is faster for calculation and so preferred over the adjacencylist.

if graph is sparse use an adjacency list

  • there are circumstances where it is good to use adjacency matrices, because given issues could be solved using linear algebra
    • Consider the following example:
      • in an unweighted graph represented by an adjacency matrix, how can you compute the number of paths of length 2 between two vertices, using linear algebra

Weitere Betrachtungen:

  • [[111.22_Graphen_SSSP_dijkstra]]
  • [[111.18_Graphen_Traversieren]]
  • [[111.14_Graphen_gerichtet]]
  • [[111.21_algo_graphs_ShortesPathProblems]]
  • [[222.16_graph_centrality]]