Kicad V6 Preview - Erfahrungen

Was mir so aufgefallen ist:

* neues Datenformat, hat Bernd ja schon ein paarmal geschrieben, die 
Dateinamen enden jetzt alle auf .kicad_*:
  * .kicad_pro Projekt
  * .kicad_sch Schaltpläne
  * .kicad_sym Symbol-Bibliothek
  * .kicad_pcb PCB (bereits früher so eingeführt)
  * .kicad_mod (in *.pretty-Verzeichnis) Bauteil-Bibliothek (bereits 
früher so eingeführt)
  * .kicad_prl Projektstatus (bspw. Konfiguration der Lagen-Anzeige)
* keine explizite Netzliste mehr notwendig
  * forward annotation über "Update PCB from Schematic" (ging schon in 
V5)
  * backward annotation über "Update Schematic from PCB" (neu; man kann 
bspw. Footprints oder Bauteilwerte im Board ändern und dies dann zurück 
kommunizieren)
  * Netzliste kann natürlich nach wie vor manuell exportiert werden
* Schaltplaneditor kann Image-Datei einbinden, Layout leider (noch) 
nicht, aber:
* der Bitmap-to-Component Konverter ist im Projektmanager drin; damit 
kann man bspw. ein Bitmap-Bild eines existierenden Boards vektorisieren 
und dann als "Bauteil" auf einer User-Lage im PCB Editor hinterlegen; 
ursprünglich für Dinge wie Logos konzipiert, habe das aber (schon in 
V5.x) benutzt, um ein Board vom Foto zu reengineeren
* viele User-Lagen im PCB-Editor
* im Schaltplaneditor können Elemente als "Exclude from Board" markiert 
werden (bspw. externe Komponenten, die auf diese Weise mit dokumentiert 
werden sollen)
* PCB-Bauteile können jetzt Sperrflächen enthalten (Leitungen, Vias, 
Flächenfüllen verbieten)

Das sind so die Dinge, die mir bislang aufgefallen sind.

Absturz hatte ich soweit noch nicht, hab's aber auch bislang nur in 
einem Mini-Projekt produktiv genutzt.

OldMac schrieb:
> Daher kann ich es leider nicht mal ausprobieren

Kannst ja zumindest gucken, was passiert … kenne mich aber mit den 
MacOS-Versionen zu wenig aus um einzuschätzen, warum das wohl so ist. 
Möglicherweise müsstest du es einfach nur mal selbst compilieren, weil 
das vorgefertigte Compilat auf neueren Libs aufsetzt?

Jörg W. schrieb:
> Dateinamen enden jetzt alle auf .kicad_*

Sehr fein, ich werde ja dazu genötigt Eagle parallel installiert zu 
haben also ist es gut, dass die Endung nun nicht mehr gleich sind.

mfg

OldMac schrieb:
> Selbst übersetzen wird bestenfalls gelingen, aber dann mit dem gleichen
> "unrecognized selector" enden weil das ein Methode von NSWindow ist die
> es auf einem älteren System einfach nicht gibt.

Muss nicht sein. Kann genauso gut sein, dass diese Methode beim 
Compilieren auf einem älteren System gar nicht genutzt würde. Sie 
benutzen ja wxWidgets als GUI-Toolkit, und du würdest dann gegen ein 
wxWidgets bauen, welches auf deinem System läuft.

Habes es mir gerade angesehen, schaut ok aus.
Die andere Optik, meh, wieder so eine "kühle" Office Oberfläche, man 
wird sich daran gewöhnen, aber warum?

Die neuen Menüs schauen aber ordentlich aus, also von der Aufteilung 
etc.
Praktisch, Bauteile werden blau hinterlegt wenn man sie anfässt.

mfg

A. K. schrieb:
> Habes es mir gerade angesehen, schaut ok aus.
> Die andere Optik, meh, wieder so eine "kühle" Office Oberfläche, man
> wird sich daran gewöhnen, aber warum?

Habe ich mich auch gewundert.

> Die neuen Menüs schauen aber ordentlich aus, also von der Aufteilung
> etc.

Einiges ist schon in V5 konsistenter geworden in dieser Hinsicht. Ich 
kann mich noch dran erinnern, dass der Workflow zum Anlegen und 
Einbinden neuer Bauteile in einer projekteigenen Bibliothek früher sehr 
verquer war. Jetzt kann man den jeweiligen Bauteil- oder Symboleditor 
öffnen, sagt "New Library", wird gefragt, ob global oder nur im Projekt, 
und darin kann man dann mit "New Symbol" oder "New Footprint" das 
jeweilige Element anlegen, welches danach auch ohne weitere Klimmzüge im 
Projekt benutzbar ist.

Jörg W. schrieb:
> * backward annotation über "Update Schematic from PCB" (neu; man kann
> bspw. Footprints oder Bauteilwerte im Board ändern und dies dann zurück
> kommunizieren)

...der Knopf "<-Back" war aber auch in V5 schon drin, zumindest im 
Eeschema...

Imo sehr nützlicher Zusammenschnitt der V5<->V6-Unterschiede:
https://techexplorations.com/blog/kicad/kicad-6-review-new-and-improved-features/

ZF schrieb:
> Allerdings schien der Schriftfont weiterhin fix zu sein?

Ja, sieht so aus. Habe zumindest nichts dergleichen gefunden, wo man das 
einstellen könnte.

Jan L. schrieb:
> ...der Knopf "<-Back" war aber auch in V5 schon drin, zumindest im
> Eeschema...

Witzigerweise ist er bei mir als Button nicht einmal in meinem 
5.99-Build drin, seltsam. Der Menüeintrag dafür ist allerdings da.

Jörg W. schrieb:
> Witzigerweise ist er bei mir als Button nicht einmal in meinem
> 5.99-Build drin, seltsam. Der Menüeintrag dafür ist allerdings da.

...und in V5.1.9 (Eeschema) hab' ich den nur als Button, Menü fehlt - 
strange, ist mir noch nie aufgefallen... :)

In 5.19 hatte ich den Menüeintrag, glaub ich, nur im pcbnew.

Ich habe jetzt wiedermal Kicad bei mir installiert und versucht, damit 
zurechtzukommen....

Hätte ja sein können, es hat sich was verbessert in der kryptischen, 
hobbyanwenderfernen Bedienung. Leider nein.

Sorry Leute,
das ist doch nur was für Masochisten.
Und da wird so ein Hype dazu veranstaltet ?!

Da ist ja Eagle anwenderfreundlicher und intuitiver ....

Und Diptrace erst, welches ich vor Jahren dankenswerter Weise entdeckte.

Hardy F. schrieb:
> Sorry Leute,
> das ist doch nur was für Masochisten.

Wenn ich so bei jeder Software gerantet hätte, die etwas Einarbeitung 
vorausgesetzt hat, wäre ich heute noch am Ranten, statt am Basteln ;)

Schlaumaier schrieb:
> Mit einer Indexorientieren Datenbank wäre das Leben 100 x einfacher.

Das ist OSS – du kannst es forken und verbessern. Deinem Gelaber nach 
hast du das ja an ’nem Wochenende fertig, so toll, wie du dich gibst.

Du solltest nun anfangen – bis Montag will ich das Ergebnis sehen. 
Alternativ könntest du auch einfach mal die Finger stillhalten, wenn du 
nämlich keine Ahnung hast. Wie eigentlich in fast jedem Thread, in den 
du die letzte Zeit geschrieben hast.

Schlaumaier schrieb:
> Meine sehr sparsam installierte Kicad 5 Version hat ca. 48.000 Dateien
> lt. Windows Zählung.

% pacman -Ql kicad | wc -l
433

Schlaumaier schrieb:
> Das Problem ist nur den Teil das klar zu machen.

Das Problem ist, dass du nicht den Hauch einer Ahnung hast, wie die 
Sachen zusammenhängen.

Ich verwende die V6 jetzt schon seit einiger zeit produktiv.
Die Vorteile überwiegen aktuell deutlich.

Eine Funktion ist jedoch mehr als nervig: Diese Intelligenz, die 
automatisch das wire-tool im Schematic auswählt, wenn man auf einem Pin 
ist, oder gelegentlich einen move-Befehl macht statt so ein 
Selektions-Rechteck macht.

Kann man das irgendwie ausschalten?

Die Idee dahinter ist ja irgendwie verlockend, es ist aber so, dass 
gerade im PCB so oft Flächen, Bauteile, Traces,... übereinander liegen, 
dass da auch die beste Logik einfach nicht vorhersehen kann was man 
eigentlich will...

73

Ich muss mal doof fragen - wie ist das eigentlich mit der 
Abwärtskompatibilität? Also, wenn ich jetzt mal in die 5.1.9 
reinschnuppere und ein kleines Projekt damit mache, dann wird die 6.0 
released und ich steige darauf um, dann gehe ich schon davon aus, dass 
ich die älteren Dateien damit auch öffnen kann - aber wenn ich daran 
dann wieder etwas ändere?

Dann müsste die 6.0 ja auf die Bibliotheken der 6.0 zugreifen, während 
in meinem Projekt noch welche aus der 5.1 verwendet wurden. Und wenn ich 
das Projekt dann wieder speichere - was ist es dann? Immer noch ein 
5.1-Projekt mit Einsprengseln aus der 6.0 oder wird das komplett 
konvertiert oder wie oder was?

Jaaa, ist ne Anfänger-Frage, ich weiß. Bin ja auch einer...

AndererSchlaumaier schrieb:
> Ist zwar noch Alpha, aber sieh Dir doch mal Horizon an.
> https://www.mikrocontroller.net/articles/Schaltplaneditoren#Horizon
> Das könnte genau das sein, was Du suchst.

Hat Zukunft !

Genialer Programmierer.

Schlaumaier schrieb:

> Kann man beide Versionen (5.x + 6.x) eigentlich nebeneinander
> installieren oder kommen die sich ins Gehege. ??

An sich sollten sie sich nicht ins Gehege kommen, die 
Bibliotheksverzeichnisse müssten sich separat einstellen lassen. Mir 
geht's selbst nur ein wenig wie OldMac da oben: ich compiliere sie zwar 
selbst (anders als er), bevorzuge aber, sie über die FreeBSD-Ports zu 
installieren, und die installieren beide Variante tatsächlich an die 
gleiche Stelle. Insofern lege ich mich nur durch das darunter liegende 
Buildsystem auf eine Variante fest. Dem Kicad selbst ist das aber eher 
wurscht.

Schlaumaier schrieb:
> Das merkt man an den komischen Dateinamen, und der Angewohnheit 100.000
> Dateien zu installieren. Alles was aus der Linux-ähnlichen Ecke kommt,
> macht eine Dateischwemme auf den PC.

Sorry, das hat mit dem Betriebssystem nun absolut nichts zu tun.

Altium (was vermutlich bei Kicad an vielen Stellen gedanklich Pate 
gestanden hat, aber Windows-only ist) macht das übrigens genauso: eine 
Datei pro Bibliotheksmodell, eine Datei pro Schaltplanseite. (Die haben 
sogar noch mehr, beispielsweise eine Datei pro "wire harness".) Damit 
ist das Argument "Linux-ähnliche Ecke" wohl für diesen Punkt hinreichend 
entkräftet.

Aber: der Thread war nicht für irgendwelche System-Grabenkriege gedacht, 
sondern für echte Erfahrungen mit Kicad 6. Wer diese nicht hat, möge 
seine Nicht-Erfahrungen bitte woanders diskutieren. Wem Kicad nach wie 
vor nicht liegt: OK, ist dann so, ist auch OK, das hier in einem 
Beitrag zu postulieren. Aber kein Glaubenskriege draus machen. Dafür 
gibt es speziell vorgesehene Einrichtungen in diesem Land, die kann man 
in Glaubensfragen gern aufsuchen.

Hans W. schrieb:
> Eine Funktion ist jedoch mehr als nervig: Diese Intelligenz, die
> automatisch das wire-tool im Schematic auswählt, wenn man auf einem Pin
> ist, oder gelegentlich einen move-Befehl macht statt so ein
> Selektions-Rechteck macht.

Ist mir so noch nicht aufgefallen.

Dafür ist mir aufgefallen, dass ich ohne Selektieren eines Bauteils 
nicht mehr einfach mit "c" dieses Kopieren kann. In der Voreinstellung 
will er da einen Bustap anlegen und beklagt sich, dass ich keine Bus 
ausgewählt habe, aber selbst mit geändertem Shortcut geht es nicht. Nur 
Selektieren - Ctrl-C - Ctrl-V geht.

"m" funktioniert dagegen nach wie vor auch ohne selektiertes Bauteil.

Matthias L. schrieb:
> Ich muss mal doof fragen - wie ist das eigentlich mit der
> Abwärtskompatibilität?

Aufwärts ja, also die 6er Version kann die alten Dateien importieren. 
Sie wandelt sie aber beim Speichern ins neue Dateiformat um, und das 
wird beim Laden auch als Warnung angezeigt.

Abwärts ist also nicht: Projekte, die du mit der 5.99 anlegst, kannst du 
nicht später mit der 5.1.9 weiter bearbeiten.

Jörg W. schrieb:
> Aufwärts ja, also die 6er Version kann die alten Dateien importieren.
> Sie wandelt sie aber beim Speichern ins neue Dateiformat um, und das
> wird beim Laden auch als Warnung angezeigt.
>
> Abwärts ist also nicht: Projekte, die du mit der 5.99 anlegst, kannst du
> nicht später mit der 5.1.9 weiter bearbeiten.

Prima, damit kann ich leben. Vielen Dank!

@Jörg Könntest du bitte ein Screenshot posten?

Richard B. schrieb:
> @Jörg Könntest du bitte ein Screenshot posten?

Wovon eigentlich?

Der oben verlinkte Review des Previews (:-) enthält einige.

Jan L. schrieb:
> Imo sehr nützlicher Zusammenschnitt der V5<->V6-Unterschiede:
> 
https://techexplorations.com/blog/kicad/kicad-6-review-new-and-improved-features/

daraufhin sollte ich es wirklich mal anschauen. Aber wie, speziell auf 
einem 32-Bit Debian stable? Was empfiehlt man denn jemandem, der noch 
nie cmake oder g++ gestartet hat? Bei Ubuntu gibt's nightly build debs, 
aber nicht für i386 oder nur veraltet :(

Unabhängig davon: Kann man IGES, STEP oder DCF exportieren, wenn man 
kein einziges 3D-Modell hat? Also nur die Platinenkontur, Bohrungen und 
evt. Nullpunkte der Bauteile?
Und, weiß man schon, wann es eine neue Library Convention gibt? Mit den 
alten Spielregeln möchte ich eigentlich garnicht erst anfangen

1

KLC is suspended until further notice. Rules are currently

2

being revised for KiCad version 6.

Bauform B. schrieb:

> daraufhin sollte ich es wirklich mal anschauen. Aber wie, speziell auf
> einem 32-Bit Debian stable?

Wenn du ein 32-Bit-System hast, dann vermutlich auch recht alte 
Hardware. Bist du dir sicher, dass du auf sowas ein CAD-System 
einschließlich OpenGL, 3D etc. laufen lassen willst?

> Was empfiehlt man denn jemandem, der noch
> nie cmake oder g++ gestartet hat?

Naja, irgendwann fängt jeder mal an. ;-)

> Unabhängig davon: Kann man IGES, STEP oder DCF exportieren, wenn man
> kein einziges 3D-Modell hat? Also nur die Platinenkontur, Bohrungen und
> evt. Nullpunkte der Bauteile?

Warum nicht? Die Platinenkontur und Bohrungen müssen ja so auch erzeugt 
werden, unabhängig vom Vorhandensein von 3D-Modellen für Bauteile.

Nullpunkte gibt's aber nicht. Anbei ein generiertes STEP-Modell, denk 
dir einfach die Bauteil-Modelle weg.

> Und, weiß man schon, wann es eine neue Library Convention gibt?

Da habe ich keine Ahnung.

Aber ich denke, das sind eher Formalismen dort. Grundlegend wirst du die 
gleichen dahinter liegenden Ideen auch für V6-Libraries anwenden können. 
Sie wollen ja nur keine alten Bibliotheken mehr integrieren. Wenn du für 
dich mit einer 5.99 Modelle anlegst, legst du eh bereits neue an.

Jörg W. schrieb:
> Bauform B. schrieb:
>> daraufhin sollte ich es wirklich mal anschauen. Aber wie, speziell auf
>> einem 32-Bit Debian stable?
>
> Wenn du ein 32-Bit-System hast, dann vermutlich auch recht alte
> Hardware. Bist du dir sicher, dass du auf sowas ein CAD-System
> einschließlich OpenGL, 3D etc. laufen lassen willst?

Mögen täte ich schon wollen, aber danke für die Warnung. So wird es noch 
spannender, Eagle läuft hier nämlich absolut flüssig; lspci sagt:

1

VGA compatible controller [0300]: Advanced Micro Devices, Inc.

2

[AMD/ATI] Mullins [Radeon R3E Graphics] [1002:9854] (rev 01)

> Die Platinenkontur und Bohrungen müssen ja so auch erzeugt
> werden, unabhängig vom Vorhandensein von 3D-Modellen für Bauteile.

Eigentlich ja klar, jetzt wo du es sagst, danke.

>> Und, weiß man schon, wann es eine neue Library Convention gibt?
> Aber ich denke, das sind eher Formalismen dort.

Naja, die Vorschriften, wie die diversen Namen gebildet werden, könnten 
sich durchaus ändern. Und wenn ein Teil davon irgendwo fest verdrahtet 
ist...

Bauform B. schrieb:
> Aber wie, speziell auf
> einem 32-Bit Debian stable? Was empfiehlt man denn jemandem, der noch
> nie cmake oder g++ gestartet hat? Bei Ubuntu gibt's nightly build debs,
> aber nicht für i386 oder nur veraltet :(

Werf deine i386 Kiste weg - die wird von künftigen Linux-Kernels nicht 
mehr supported.

Bauform B. schrieb:

> Mögen täte ich schon wollen, aber danke für die Warnung. So wird es noch
> spannender, Eagle läuft hier nämlich absolut flüssig;

Das braucht vermutlich auch kein OpenGL. Wer weder 3D machen will noch 
Transparenz, kommt natürlich mit sehr viel älterer Hardware hin.

Lukas hatte ja seinerzeit auch begründet, warum er für Horizon EDA eine 
bestimmte Mindestanforderung an OpenGL hat, um sich nicht in der Grafik 
mit dem Urschleim aufhalten zu müssen.

[Library Convention]

> Naja, die Vorschriften, wie die diversen Namen gebildet werden, könnten
> sich durchaus ändern. Und wenn ein Teil davon irgendwo fest verdrahtet
> ist...

Davon ist mit Sicherheit nichts hart codiert, und wenn ich mir deren 
Namensregeln ansehe, dann wird es keinen Grund geben, diese grundlegend 
zu ändern.

Jörg W. schrieb:
> Der oben verlinkte Review des Previews (:-) enthält einige.

Danke, habe ich nicht gesehen.
Sieht aber schöner aus (als bisher).

Ab wann ist mitn V6 Release in etwa zu rechnen?

Richard B. schrieb:
> Ab wann ist mitn V6 Release in etwa zu rechnen?

Laut Roadmap im dritten Quartal dieses Jahres.

Jack V. schrieb:
> Richard B. schrieb:
>> Ab wann ist mitn V6 Release in etwa zu rechnen?
>
> Laut Roadmap im dritten Quartal dieses Jahres.

Lt Fosdem Präsentation Ende Q1:
https://fosdem.org/2021/schedule/event/kicad/attachments/slides/4410/export/events/attachments/kicad/slides/4410/kicad_presentation_fosdem_2021.pdf

Cool. Da geht was weiter...

Jörg W. schrieb:
> Dafür ist mir aufgefallen, dass ich ohne Selektieren eines Bauteils
> nicht mehr einfach mit "c" dieses Kopieren kann.

Ctrl-D?

/regards

Andreas H. schrieb:
> Jörg W. schrieb:
>> Dafür ist mir aufgefallen, dass ich ohne Selektieren eines Bauteils
>> nicht mehr einfach mit "c" dieses Kopieren kann.
>
> Ctrl-D?

Auch das braucht ein vorher ausgewähltes Element.

Das frühere "C"[opy] braucht[e] das nicht, das funktionierte ohne 
vorherige Auswahl.

Jörg W. schrieb:
> Das frühere "C"[opy] braucht[e] das nicht, das funktionierte ohne
> vorherige Auswahl.

Stimmt. Das istja lästig :/

Ausserdem scheint ctrl-D auch parallel für Datasheet lookup benutzt zu 
werden.

/regards

Andreas H. schrieb:
> Ausserdem scheint ctrl-D auch parallel für Datasheet lookup benutzt zu
> werden.

Ja, aber das lässt sich entflechten (über die Einstellungen).

Andreas H. schrieb:
> Stimmt. Das istja lästig :/

Was mich vor allem daran wundert: "m" oder "g" funktionieren problemlos, 
auch ohne explizit ausgewähltes Symbol. Es sieht also eigentlich nicht 
so aus, als wäre das jetzt unbedingt konzeptionelle Absicht, dass man 
nur noch mit ausgewählten Symbolen operieren kann (wenngleich insgesamt 
was geändert worden ist in diesem ganzen Umfeld, siehe den Review, der 
weiter oben verlinkt worden ist).

Davon abgesehen, dass ich nicht auf die Idee gekommen wäre, "schräge" 
Leitungen zu zeichnen (musste ich erstmal explizit freischalten), 
funktioniert das hier problemlos.

1

Application: Eeschema

2

3

Version: 5.99.0-unknown, release build

4

5

Libraries:

6

  wxWidgets 3.0.5

7

  libcurl/7.74.0 OpenSSL/1.1.1h zlib/1.2.11 libidn2/2.3.0

8

9

Platform: FreeBSD 12.2-STABLE amd64, 64 bit, Little endian, wxGTK, , 

10

11

Build Info:

12

  Date: Jan 31 2021 21:56:47

13

  wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24

14

  Boost: 1.72.0

15

  OCC: 7.5.0

16

  Curl: 7.74.0

17

  ngspice: 32

18

  Compiler: Clang 10.0.1 with C++ ABI 1002

19

20

Build settings:

21

  KICAD_SCRIPTING=ON

22

  KICAD_SCRIPTING_MODULES=ON

23

  KICAD_SCRIPTING_PYTHON3=ON

24

  KICAD_SCRIPTING_WXPYTHON=ON

25

  KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON

26

  KICAD_SCRIPTING_ACTION_MENU=ON

27

  KICAD_USE_OCC=ON

28

  KICAD_SPICE=ON

29

  KICAD_STDLIB_DEBUG=OFF

30

  KICAD_STDLIB_LIGHT_DEBUG=OFF

31

  KICAD_SANITIZE=OFF

Edit: sorry, der FreeBSD-Ports-Build killt offenbar deren Logik zur 
Erkennung der Version. Das hier ist die zugehörige Info:

1

GIT_SRC_HASH=  8eca23aabe8736d07a0beeb0e2bb893320010290

2

GIT_SRC_DATE=  20210131014911

macOS 10.14 als Mindestvoraussetzung ist leider schon wirklich eine 
Hürde. Ohne den Entwicklern zu Nahe treten zu wollen - ich schätze deren 
Arbeit sehr - denke ich, dass gerade bei Open Source Projekten die 
Möglichkeit besteht, im Sinne der Nachhaltigkeit auch ältere Systeme zu 
unterstützen.

Bei Apple ist es leider so, dass es seit einiger Zeit jedes Jahr ein 
Major Update gibt bei dem irgendeine Software auf der Strecke bleibt 
oder Hardware nicht mehr unterstützt wird. macOS 10.14 wurde am 
04.06.2018 veröffentlicht, ist also noch nicht mal 3 Jahre her. Eine 
Unterstützung von 10.12 oder 10.13 wäre auf jeden Fall wünschenswert.

Oliver R. schrieb:
> Ohne den Entwicklern zu Nahe treten zu wollen

Wie oben schon vermutet, ist das wahrscheinlich weniger ein Frage von 
Kicad selbst sondern mehr davon, dass offenbar deren MacOS-Entwickler, 
von dem auch das kicad-mac-build Script stammt, damit arbeitet. Damit 
sind natürlich automatisch die erzeugten Binaries an mindestens diese 
Version gebunden. (Für den Builder hat er auch 10.14 als Voraussetzung 
dokumentiert - warum auch immer.)

Da müsste sich wohl mal jemand mit 10.13 hinsetzen und schauen, ob er da 
einen eigenen Build hin bekommt.

> macOS 10.14 wurde am 04.06.2018 veröffentlicht, ist also noch nicht mal
> 3 Jahre her.

Allerdings sollte man Macs doch ganz gut upgraden können, oder? Die 
wesentlichere Frage wäre daher eher, wie alt die Hardware ist, die durch 
10.14 dann aus der Unterstützung heraus gefallen ist.

Jörg W. schrieb:
> Allerdings sollte man Macs doch ganz gut upgraden können, oder? Die
> wesentlichere Frage wäre daher eher, wie alt die Hardware ist, die durch
> 10.14 dann aus der Unterstützung heraus gefallen ist.

Die Hardware ist das eine. Verständlicherweise ist Apples Interesse zur 
Unterstützung älterer Hardware begrenzt.

Das wirkliche Problem ist die Software. Als Mac User ist es ein 
ständiger Spagat  mit der OS Version zu arbeiten, bei der ältere 
Software noch und neuere schon läuft. Dazu kommen so "Kleinigkeiten", 
dass Apple zwischen zwei Versionen mal den kompletten USB Stack neu 
implementiert und plötzlich angeschlossene Hardware  zickt.

Die ganze Thematik hat ja in den letzten Jahren an Fahrt aufgenommen, 
weil sich die Taktung der Releases so beschleunigt hat. Dazu kommt, dass 
aktuell nicht wenige User auf die neuen ARM Macs schielen, aber 
verständlicherweise noch warten, bis diese stabil laufen bzw. 
professionellere Hardware auf den Markt kommt. Soll heissen, irgendwann 
ab nächstem Jahr oder so. Bis dahin werden viele noch mit älteren System 
arbeiten und dann erst den harten Schnitt wagen.

Jörg W. schrieb:
> Was mich vor allem daran wundert: "m" oder "g" funktionieren problemlos,
> auch ohne explizit ausgewähltes Symbol.

Habe mal versucht, mich etwas durch den Sourcecode zu wühlen.

Der Unterschied scheint zu sein, dass Vorgänge wie duplicate und delete 
in der Klasse ACTIONS beheimatet sind (also allgemein aufgebaut), 
während spezielle Schaltplanaktionen wie drag unter EE_ACTIONS fallen.

Andreas H. schrieb:
> Jörg W. schrieb:
>> Das frühere "C"[opy] braucht[e] das nicht, das funktionierte ohne
>> vorherige Auswahl.
>
> Stimmt. Das istja lästig :/

Hatte gestern ein Ticket dafür geöffnet:

https://gitlab.com/kicad/code/kicad/-/issues/7550

Scheint wohl nur mit einem bestimmten Versionsbereich ein Problem 
gewesen zu sein. Nachdem es dort hieß "works for me", habe ich nochmal 
aktualisiert, und jetzt funktioniert alles wie gewohnt.

Marek N. schrieb:
> It's not a bug, it a feature

Nicht ganz. Das zuvor beobachtete Verhalten, dass *ohne ausgewähltes 
Symbol* rein gar nichts passiert, wurde nicht als Bug abgestritten von 
den Entwicklern. Tritt aber mit aktuellem Git-Stand nicht mehr auf.

Der von dir zitierten Änderungen war ich gewahr, aber die betreffen das 
Verhalten, wenn man vorher was ausgewählt hat.

Schön währe es, wenn man in KiCAD seine Designs auch in Eagle 
exportieren könnte. Dann kann man mit mehreren Personen an einem Projekt 
arbeiten, ohne dass man umlernen muss.

Anita H. schrieb:
> Schön währe es

Schön wäre es, wenn man zwischen allen EDA-Systemen die Designs 
austauschen könnte. ;-) Aber das wird Wunschdenken bleiben, die zu 
Grunde liegenden Details sind in aller Regel so, das es praktisch keinen 
Import irgendwo ohne Datenverlust gibt.

Jörg W. schrieb:
> Anita H. schrieb:
>> Schön währe es
>
> Schön wäre es, wenn man zwischen allen EDA-Systemen die Designs
> austauschen könnte. ;-) Aber das wird Wunschdenken bleiben, die zu
> Grunde liegenden Details sind in aller Regel so, das es praktisch keinen
> Import irgendwo ohne Datenverlust gibt.

Bei KiCAD kann man ja von Eagle importieren. Also warum nicht auch nach 
Eagle exportieren?

Anita H. schrieb:
> Bei KiCAD kann man ja von Eagle importieren. Also warum nicht auch nach
> Eagle exportieren?

hmm, falsches Universum, Zeit läuft nicht rückwärts, aber gleich nebenan 
könntest du mehr Glück haben ;)
https://nypost.com/2020/05/19/nasa-finds-evidence-of-parallel-universe-where-time-runs-backward-report/

Bauform B. schrieb:
> Anita H. schrieb:
>> Bei KiCAD kann man ja von Eagle importieren. Also warum nicht auch nach
>> Eagle exportieren?
>
> hmm, falsches Universum, Zeit läuft nicht rückwärts, aber gleich nebenan
> könntest du mehr Glück haben ;)
> 
https://nypost.com/2020/05/19/nasa-finds-evidence-of-parallel-universe-where-time-runs-backward-report/

Du bist mein Held! Einen auf intelligent machen und Physik ins Spiel 
bringen. Lösung: 0! Bist du Politiker?

Anita H. schrieb:
> Also warum nicht auch nach Eagle exportieren?

Motivating force missing.

Dafür müsstest du wohl Eagle[-Nutzer:innen] fragen. Kicad[-Nutzer:innen] 
werden halt primär ein Interesse daran haben, existierende Eagle-Designs 
nach Kicad zu wandeln als umgekehrt.

ps: Bitte beim Thema bleiben. Es geht hier um die angehende Kicad V6, 
nicht um allgemeine Fragen zu Kicad oder EDA-Systemen.

Marek N. schrieb:

> Mir ist aufgefallen, dass wenn ich im Layout ein Bauteil mit "Drag"
> [Markieren + D] verschieben will, es beim Platzieren dann sogar aus dem
> Zeichnungsrahmen springt.

Kann ich bestätigen.

Müsste man vielleicht auch in paar Tagen mal wieder schauen … und dann 
ggf. eine Bugreport schreiben. Die scheinen zumindest sehr schnell 
erstmal zu reagieren.

> Mann muss es dann umständlich mit Move [M] wieder
> zurückplatzieren.

Naja gut, ^Z geht natürlich noch.

Jörg W. schrieb:
> Kann ich bestätigen.

Wobei es irgendwie nicht generell passiert, nur manchmal.

Hallo,
Jörg W. schrieb:
> Davon abgesehen, dass ich nicht auf die Idee gekommen wäre, "schräge"
> Leitungen zu zeichnen (musste ich erstmal explizit freischalten),
> funktioniert das hier problemlos.

Wie funktioniert das mit dem Freischalten?

rhf

Roland F. schrieb:
> Wie funktioniert das mit dem Freischalten?

An der Stelle da das Häkchen rausnehmen.

Hallo,
Jörg W. schrieb:
> An der Stelle da das Häkchen rausnehmen.

Vielen Dank.

rhf

Marek N. schrieb:
> Ich hab das nur über den Button in der linken Menüleiste gemacht.

Den hatte ich bisher übersehen …

Jörg W. schrieb:
> Scheint wohl nur mit einem bestimmten Versionsbereich ein Problem
> gewesen zu sein. Nachdem es dort hieß "works for me", habe ich nochmal
> aktualisiert, und jetzt funktioniert alles wie gewohnt.

Ui. Dann muss ich wohl auch noch mal schnell upgraden.
Das Feature will man ja eigentlich nicht vermissen, wenn wieder mal 
Cap-Batterien verlegt werden wollen ;)

/regards

Ich benutze das auch für anderes Hühnerfutter gern, weil man da das 
Gehäuse nur einmal rauskramen muss. Hinterher ggf. noch die Werte 
anzupassen ist einfacher.

Jörg W. schrieb:
> Was mir so aufgefallen ist:

Noch eine Neuerung finde ich recht nützlich: das DRC-Regelsystem 
gestattet es, Ausnahmen zu definieren.

Hatte hier ein Board, bei dem die Steckverbinder etwas gedrängt waren, 
passte "gerade so", aber die Courtyard-Definitionen waren natürlich 
etwas reichlicher. Stört mich erstmal nicht (Handbestückung), aber 
bringt natürlich DRC-Fehler.

Nun hätte man natürlich lokal in den Footprints die Courtyard-Definition 
"behacken" können, aber man kann das jetzt auch eleganter machen. In den 
Board-Einstellungen gibt es "Custom Rules", und zusammen mit der 
eingebauten Hilfe sowie kontextsensitiven Editor-Vorschlägen bin ich 
rausgekommen bei:

1

(version 1.0)

2

(rule "connector placement"

3

  (constraint courtyard_clearance (min -0.2mm))

4

  (condition "(A.Reference == 'J1' || A.Reference == 'J3') && B.insideCourtyard('J2')"))

Damit sind also explizit für J1 und J3 0.2 mm Überlappung zu J2 
zugelassen.

Jörg W. schrieb:
> das DRC-Regelsystem
> gestattet es, Ausnahmen zu definieren.

Und was für welche. mit sowas

1

(condition "A.insideArea ...")

könnte man z.B. auch (mit etwas basteln) trace necking DRC konform 
einbauen.
Also +3V3 mit min. width XX mil an einen TQFP mit 0,5mm anschliessen.

Die S-Expr finde ich auch übersichtlicher als den DRC Rule "Dschungel" 
von Altium :)

/regards

Andreas H. schrieb:
> Die S-Expr finde ich auch übersichtlicher als den DRC Rule "Dschungel"
> von Altium :)

Das Einzige, was mich daran etwas verwundert hat ist, dass die Bedingung 
alles in einem String landet, einschließlich logischer Operationen. Ich 
hätte Lisp-Verknüpfungen für übersichtlicher (und besser strukturierbar) 
gehalten.

Aber solange es funktioniert, kann es mir egal sein.

Jörg W. schrieb:
> Andreas H. schrieb:
>> Die S-Expr finde ich auch übersichtlicher als den DRC Rule "Dschungel"
>> von Altium :)
>
> Das Einzige, was mich daran etwas verwundert hat ist, dass die Bedingung
> alles in einem String landet, einschließlich logischer Operationen. Ich
> hätte Lisp-Verknüpfungen für übersichtlicher (und besser strukturierbar)
> gehalten.
>

Das hat mit Lisp nix zu tun sondern ist eher eine KiCad "Eigenart".
In Lisp sind solche Sachen meist sehr überschaubar: '(' operation 
{parameter}* ')', z.B.:

1

(defun read-gds-string (stream record-len)

2

  "Read a string from a GDS stream. The maximum number of bytes is record-len.

3

   The last byte might be a 00 char which is not appended to the string"

4

  (let ((chars nil))

5

    (do ((count 0 (1+ count)))

6

        ((<= record-len count) (concatenate 'string (nreverse chars)))

7

      (let ((char-id (read-gds-byte stream)))

8

        (when (> char-id 0)

9

          (push (code-char char-id) chars))))))

> Aber solange es funktioniert, kann es mir egal sein.
eben. Es lässt halt gut weiterverarbeiten ;)

/regards

Andreas H. schrieb:
> Das hat mit Lisp nix zu tun sondern ist eher eine KiCad "Eigenart".

Ja – ich meinte ja nur, dass ich Lisp-Bedingungen übersichtlicher 
gefunden hätte als dieses "alle Bedingungen stecken in einem String". 
Aber wenn's funktioniert und handhabbar ist, soll's mir recht sein.

Seltsam, ja.

Hier gerade probiert, kann solche Effekte nicht nachvollziehen.

Marek N. schrieb:
> Ich weiß, es sind nur Kleinigkeiten, trotzdem möchte ich mithelfen, ein
> fehlerarmes und einfach handhabbares OpenSource ECAD-Programm zu
> erstellen.

Verstehe ich, allerdings dürfte es dafür eines expliziten Bug-Tickets 
bedürfen. Den Thread hier lesen sich die Entwickler sicher nicht durch …

Was mir bis jetzt so aufgefallen ist:
Das Micky Mouse Design gefällt mir überhaupt nicht. Das fand ich vorher 
besser.
Im PCB Editor gefallen mir die Presets für die Layer sowie die 
Möglichkleit, die Opazität für die einzelnen Layer einzustellen.
Auch das Umschalten PCB/Schaltung und umgekehrt mit Markierung der 
Bauteile ist jetzt schön gelöst.

Andreas B. schrieb:
> Das Micky Mouse Design gefällt mir überhaupt nicht.

Meinst du damit die neuen Icons? Die hätte ich auch verzichtbar 
gefunden, aber sie stören mich auch nicht weiter.

Jörg W. schrieb:
> Meinst du damit die neuen Icons?
Ja, was die Jungs da geritten  hat, möchte ich mal gerne wissen.

Andreas B. schrieb:
> Jörg W. schrieb:
>> Meinst du damit die neuen Icons?
> Ja, was die Jungs da geritten  hat, möchte ich mal gerne wissen.

* Es war nicht mehr nachvollziehbar welches Copyright alle Icons haben
* Rot/Blau ist besser als Rot/Grün für Personen die Farbenblind sind
* Immer mehr Nutzer wünschten einen Darkmode, welcher mit den neuen 
Icons einfacher implementierbar ist
* Konsistente Icons

Danke für die Erklärung!

Andreas B. schrieb:
> Das Micky Mouse Design gefällt mir überhaupt nicht.
> Das fand ich vorher besser.

Eigentlich ist das erst jetzt "State of the Art" ...
Mit Mickey Mouse Design hat das NICHTS zu tun.

Marek N. schrieb:
> Ich habe noch viel mehr Funktionswünsche und Verbesserungsvorschläge,
> aber erst mal die vorhandenen Bugs und Inkonsistenzen beheben

Ich fürchte nur, dass das hier niemand groß von deren Team mitliest. 
Sinnvoll(er) wäre es wohl, wenn du bei ihnen dafür bug tickets 
eintütest.

Marek N. schrieb:

> Jörg W. schrieb:
>> Sinnvoll(er) wäre es wohl, wenn du bei ihnen dafür bug tickets
>> eintütest.
>
> Ja, ich muss mir wohl mal die E-Mail von dem Programmierer raussuchen.

Nein. Tickets kippt man nicht per privater E-Mail ein.

https://kicad.org/help/report-an-issue/

Habe das jetzt schon zwei- oder dreimal in letzter Zeit gemacht. Die 
Erstreaktion ist relativ schnell (eins von meinen Wünschen wurde dann 
allerdings als "nice to have" auf künftige Versionen verschoben, was für 
mich OK war).

Es steht bestimmt in irgendeinem Forum oder Blog, ich hab's trotzdem 
nicht gefunden - gibt's eigentlich eine realistische Schätzung, wann die 
6.0 released werden wird?

Matthias L. schrieb:
> gibt's eigentlich eine realistische Schätzung, wann die 6.0 released
> werden wird?

Beitrag "Re: Kicad V6 Preview - Erfahrungen"

(sowie der nachfolgende Beitrag)

Wobei: "Ende Q1" haben wir ja praktisch schon. ;-)

Ups, da hatte ich wohl einen Anfall von Betriebsblindheit - in DIESEM 
Thread hier hatte ich nicht gesucht.

Danke schön!