1. Dashboard
  2. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team
    4. Mitgliedersuche
  3. Forenregeln
  4. Forum
    1. Unerledigte Themen
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. AutoIt.de - Das deutschsprachige Forum.
  2. Mitglieder
  3. Code-Jack

Beiträge von Code-Jack

  • ERLEDIGT --> Raspberry Pi® 2 Model B Advanced-Set 1 GB

    • Code-Jack
    • 28. August 2016 um 16:22

    Etwas OT, aber Ich habe gerade eine Lötaufgabe, die auch mich vor ernste Herausforderungen stellt.

    Die Aufgabe:
    Ein 25-poliges Flachbandkabel (mit penibel einzuhaltender Länge) soll an beiden Enden auf 3-5mm abisoliert werden (aber ohne die Adern aufzusplitten, also in einem Rutsch sauber die Isolierung runter).
    Anschließend sollen beide Enden zusammengelötet werden, um genau eine Position versetzt, so dass sich eine Spule ergibt.
    Jeweils links und rechts gibt es am Ende also eine freie Ader, dazwischen bildet sich gewissermaßen eine Spirale.

    Das mit dem sauberen Abisolieren gelingt mir inzwischen in guter Qualität. Aber beim Zusammenlöten kämpfe ich mit Brückenbildung.

    Natürlich darf die übrige Isolierung auch nicht verbrutzeln; es soll schick aussehen, nicht nach Pfusch!

    Es sollen 100 Stück dieser Spulen gefertigt werden, muss also irgendwie halbwegs rationell vonstattengehen.

    Natürlich neigen die haarfeien Einzeldrähte zum Aufspleißen. Darum verzinne ich die Enden sofort nach dem Abisolieren vor, in der Absicht, diese Stummelchen dann einfach zusammen zu schmelzen.

    Meine ersten drei Versuche befriedigten mich nicht. Ich überlege schon, eine speziell Vorrichtung zu improvisieren, in die ich die Flachbandkabel einlegen kann und wo jede Brückenbildung, sowie jedes Aufspleißen, mechanisch verhindert wird.

    Klingt doch nicht schwer, oder? - Paar Kabelchen zusammenlöten ...
    Aber probiert es mal und macht ein Foto von dem Ergebnis.
    Derjenige, dessen Ergebnis wie geleckt aussieht, möge mich dann bitte erleuchten, wie er das hinbekommen hat!

  • ERLEDIGT --> Raspberry Pi® 2 Model B Advanced-Set 1 GB

    • Code-Jack
    • 27. August 2016 um 17:56
    Zitat von chip

    Nette Ausführung Code-Jack, allerdings alles eine Sache der Übung. Mein Vater lötet selbst kleine smb Bausteine ohne Probleme mit einer "Bleistift" - Lötspitze an.

    Es bestreitet ja niemand, dass es damit geht. Aber wenn Du Dir die von mir verlinkten Videos anschaust, dürfte Dir klar werden, dass solche Dinge mit einer Bleistiftspitze unmöglich sind.
    Der Witz der (korrekt gehaltenen) Hohlkehle ist der, dass sie per Kapillareffekt überschüssiges Lot wegschlürft, so dass nur exakt die richtige Menge zwischen Bauteilanschluss und Platine verbleibt.

    Eine Bleistiftspitze macht dagegen einfach nur heiß und fertig. Die zieht kein überschüssiges Lot weg.
    Sie ist gut geeignet für bedrahtete Bauelemente, ist auch noch ausreichend für einzelne SMD-Pins. Aber das Löten vielpoliger ICs im 0,4mm Pitch ist damit eine Qual. Da produziert man mehr Brücken, als sonst was.


    Zitat von chip

    Viele Sachen die es inzwischen zu kaufen gibt sind einfach nur für die Faulheit der Leute. Wenn man gescheit löten lernt, brauchst 90% davon nicht.

    Darum nannte ich nur billiges, teilweise ohnehin verfügbare simples Equipment. Heißluftgebläse aus dem Baumarkt, statt Rework-Station.
    Alufolie als Hitzeshield. Silikon-Matten statt einer Vorrichtung für Unterwärme.
    Mit solchen simplen Tool erhält man mit etwas Übung völlig astreine Ergebnisse, solange man nicht gerade die NASA mal kritisch draufschauen lässt, ob das auch für die Raumstation taugt.

  • ERLEDIGT --> Raspberry Pi® 2 Model B Advanced-Set 1 GB

    • Code-Jack
    • 27. August 2016 um 14:43

    Hier mal sieben sehr gute Videos, die die höheren Weihen des Lötens (zumeist mit Kolben) vermitteln:
    https://www.youtube.com/playlist?list=…yRXsEWCPDVbitvv

    @Alina, die von Dir gewählte Lötstation ist für den Preis absolut in Ordnung, ich habe auch so ein Ding.
    Empfehlenswert ist aber eine andere Lötspitze, als die Bleistiftform. Ideal ist eine Hohlkehle. Fast genauso gut ist eine schräge Abflachung.
    Die "Bleistiftspitze" eignet sich praktisch nur für einzelne Lötpins gut - mehr dazu in den verlinkten Videos. Ich empfehle sehr, sie alle vollständig anzusehen, sie sind sorgfältig ausgewählt.
    Es ist leider nicht ganz leicht, eine andere Lötspitze für genau diese Lötstation aufzutreiben (ich bräuchte selbst mal eine neue).

    An SMD-Chips geht man aber besser mit Heißluft ran.
    Ein billiges Heißluftgerät aus dem Baumarkt, mit zwei Heizstufen, tut da einen perfekten Job. Es muss gar nicht die spezielle SMD-Reworkstation mit Temperaturregelung sein.
    Man arbeitet mit dem Baumarkt-Gerät ausschließlich in der kleinen Heizstufe, ohne Düsenaufsatz, und wärmt eine satte Minute lang, mit kreisenden Bewegungen, aus etwa 10cm Abstand vor (da schmiltzt noch kein Lot). Erst nach gut einer Minute, wenn alles satt und reichlich durchgewärmt ist, geht man tiefer, auf 3, oder gar nur zwei Finger breit, bis das Lot schmilzt.
    Damit bewegt man sich genügend nahe am optimalen Lötprofil (Profis achten auf so was!).

    Die Hitzestrahlung dabei ist allerdings belastend. Trage eine Brille, z. B. eine schwache Lesebrille. Die hält schon mal einen Großteil der Hitze von den Augen ab.
    "Heißer" Tipp: Halte einen Silikon-Topflappen bereit. In dem Moment, wo das Lot flüssig wird, legst Du den Topflappen auf die Platine, neben der Lötstelle. Da kannst Du nun den Handballen auflegen, um die Pinzette schön ruhig halten zu können.
    Ohne den Silikon-Topflappen wird die enorme Hitze nur ein freihändiges Arbeiten erlauben und da merkt man erst mal, wie viel Tatter man bereits hat.

    Die Videos vermitteln es ja schon, aber es sei explizit betont, wie wichtig ein gutes Flussmittel (Flux) für das Löten an Chips und feinen Lötstellen ist! Besonders wenn man mit bleifreienm Lot arbeitet, wie es heutzutage üblich ist.
    Dein Nachbar hat Dir womöglich bleihaltiges Lot gegeben - das ist wesentlich gutmütiger beim Verarbeiten, aber es enthält halt giftiges Schwermetall.

    Zum Reinigen der Lötstellen eignet sich reines Isopropanol, in Verbindung mit einer alten Zahnbürste und Küchenpapier. Auch in Isopropanol getränkte Wattestäbchen sind recht nützlich. Per Drehbewegung reduzierst Du das Fusseln.
    Manchmal nehme ich auch Benzin. Da beseitigt angebrutzelte Flussmittelreste noch etweas besser, aber für die Endreinigung nehme ich immer Isopropanol.

    Vor Elektrostatik muss man sich nicht soooo dolle fürchten, trotz Silikon-Topflappen und Zahnbürste. Man sollte aber schon auf dieses Thema achten. Wer einen ungünstigen Teppich hat, der muss diesbezüglich Maßnahmen ergreifen. Und ein Fleece-Pulli ist nicht unbedingt das Kleidungsstück der ersten Wahl, bei sowas.

    Als Unterlage, bzw. Tischauflage, empfehle ich wiederum Silikon-Matten.
    Eine solche Matte, wie sie zum Auslegen von Backformen verwendet wird, ist super geeignet. Da brutzelt auch der Holztisch darunter nicht an, wenn du mit Heißluft bei gehst.
    Du kannst aber auch Plätzchenformen aus Silikon unter die Platine legen.
    Silikon-Matten können sich temporär verformen, bei starker Erhitzung und Kontakt zu Isopropanol, oder Benzin. Doch das hält nur eine Minute an, dann ist die Matte wieder wie zuvor. Meine Matten sind jetzt schon drei Jahre alt und sehen fast aus wie neu. Und ich repariere fast täglich Notebook-Mainboards.

    Wenn sich nahe der Lötstellen betont empfindliche Teile (aus Plastik) befinden, so solltest Du diese mit selbstklebendem Kapton-Band schützen (eBay). Zweifach gefaltete Alufolie tut aber einen ähnlich guten Job.
    Du kannst die Folie mit ein paar Schraubenmuttern, oder kleinen Steinchen beschweren, so dass sie dort gut anliegt, wo sie soll und nicht etwa von der Heißluft weggeblasen wird.

    Zum Üben staube vielleicht mal ein defektes Notebook-Mainboard vom PC-Doctor um die Ecke ab.
    Da entlöte zunächst mal ein paar Bauteile, um ein Gefühl dafür zu erlangen.
    Dann löte Bauteile wieder ein, unter Zuhilfenahme von nichts als Flux (neues Lötzinn ist überflüssig).
    Die Pinzette sollte antimagnetisch sein, sonst wirst du beim Einlöten große Schwierigkeiten haben.
    Sehr gut ist eine gewinkelte Pinzette, mit nicht etwa nadelförmigen, sondern etwas breiteren Spitzen. Damit bewältigt man kleinstes Hühnerfutter ganuso wie mehrpolige ICs.

    - Viel Erfolg!

  • Liegen zwei Partitionen auf gleicher Festplatte?

    • Code-Jack
    • 12. August 2016 um 17:57
    Zitat von autoBert


    seltsamer Zufall, das Skript enhält keinen kritsichen Code.


    Kann man sicher sagen, dass das Script auch mit virtuellen Laufwerken klar kommt?
    Ich hatte ein TrueCrypt-Archiv gemounted, als ich das Script startete.

  • Liegen zwei Partitionen auf gleicher Festplatte?

    • Code-Jack
    • 11. August 2016 um 22:50

    autoBert, ich habe "blind" Deinen Quelltext gestartet und sofort einen Bluescreen geerntet.
    Woran das lag, weiß ich noch nicht, ich wollte nur schnell die Warnung absondern, damit andere User nicht womöglich ebenfalls derlei Ungemach erleben ...

    War ja vielleicht nur Zufall, aber besser noch mal kritsch anschauen, vor dem Ausprobieren.

  • 465000 JPGs in einem einzigen Ordner ...

    • Code-Jack
    • 27. Juli 2016 um 15:24
    Zitat von Oscar

    1. Den Ziel-Dateinamen auch entsprechend den EXIF-Daten erstellen nach folgendem Muster: "JJJJ-MM-TT___HH-MM-SS_(C).jpg"
    Wobei man aufpassen muss, dass in der Sekunde evtl. auch mehrere Bilder gemacht worden sind, deswegen der Counter "(C)".

    Ja, macht Sinn.
    Ist zwar relaiv unnötig, schließlich kann Windows auch nach Aufnahmedatum sortieren, wenn man es entsprechend konfiguriert, aber mit einem Dateinamen nach deinem Vorschlag muss dazu nichts konfiguriert werden, das macht die Sache für 'nen DAU komfortabler.

    Statt desir vorgeschlagenen Counters nehme einfach den von PhotoRec vergebenen, einzigartigen Dateinamen (sind 8 bis 10 Zeichen), den ich an den Zeitstempel anhänge.
    Das dürfte schneller gehen, als vor dem Verschieben zu testen, ob eine gleichnamige Datei schon vorhanden ist und dann 'ne Zählschleife zu starten, bis eine freie Nummer gefunden wurde.


    Zitat von Oscar

    2. Statt FileMove zu benutzen, lieber FileCopy und die Rückgabe von FileCopy prüfen, wenn erfolgreich, dann FileDelete.
    Das ist sicherer als FileMove. Um ganz sicher zu gehen, könntest Du vor dem FileDelete auch ein Verify durchführen. Das ist aber sehr langwierig.

    Guter Vorschlag. Zwar trauere ich dann der Einfachheit von Filemove hinterher, das ja auch automatsich den Zielordner erzeugt, aber ich dachte mir sowieso schon, dass es Sinn macht, die Ordner quasi "von Hand" (mit ein paar zeilen Quelltext) zu erzeugen, statt Filemove das erledigen zu lassen.
    Einerseits um mehr Kontrolle zu haben, andererseits um jederzeit die Ordnerzahl zu kennen und im GUI anzeigen zu lassen, während das Script arbeitet:

    Anzahl erzeugter Ordner: 223
    Verschobene Dateien: 275356

    So kann man abschätzen, wie lange das Script wohl noch werkeln wird.
    Dazu dann noch ein Button zum Pausieren.
    Und so wie es gestrickt ist, kann man es auch jederzeit beenden und später neu starten, um den Rest weg zu sortieren. Man muss also nicht stundenlang im Stück den Rechner laufen lassen.


    Zitat von Oscar

    3. Unbedingt eine Fehlerbehandlung von "_FileGetProperty" einfügen. Wenn ein Bild fehlerhafte EXIF-Daten aufweist, erstellst Du falsche Ordner.

    Klingt auch gut.
    Ja, es sind ein paar sonderbare Ordner entstanden. Ohne von mir explizit so vorgesehen, landen alle Dateien ohne Zeitstempel in einem Ordner namens "--". Das ist nett, wenngleich unerwartet. :)
    Ein paar Dateien hatten unsinnige Zeitstempel, so dass ulkige Ordnernamen erzeugt wurden. Wobei ich bislang den Eindruck habe, dass das sogar ein angenehmer Effekt ist - so wird man auf die elegante Tour solche Dateien los, die z. B. aus Internet-Surfsessions stammen.
    Daher ja mein ursprünglicher Wunsch, zunächst nach Kameramodell zu sortieren und erst dann nach Datum.
    So hätte der Fotograf seine eigenen Aufnahmen schön getrennt von allem sonstigen Bildermüll.

    Ich werde wohl all Deine Vorschläge berücksichtigen und bedanke mich sehr, für die guten Einwürfe!

  • 465000 JPGs in einem einzigen Ordner ...

    • Code-Jack
    • 27. Juli 2016 um 12:41

    Der Zielpfad enthält ja ganz rechts den Backslash (siehe die aktive Zeile über filemove).

    Msgbox ist recht hinderlich, wenn sie oft kommt. Daher hatte ich während der Entwicklung die Consolewriteline drin, um zu sehen, ob die Pfade auch stimmig zusammengesetzt wurden.
    Die Pfade stimmen schon, da fehlt kein Backslash oder so.

    Getestet an 2000 Dateien entstehen ordnungsgemäß einige Ordner und in jedem befinden sich auch genau die Bilder, die an jenem Tag aufgenommen wurden.

  • 465000 JPGs in einem einzigen Ordner ...

    • Code-Jack
    • 27. Juli 2016 um 12:08

    Fataler Fehler,

    habe also stundenlang mein Script laufen lassen. Dabei hat sich zwischendrin eigenständig die USB-Platte abgemeldet, auf der die Aktion durchgeführt wurde (warum auch immer).
    Ungefähr die Hälfte der Dateien waren bis dahin bereits sortiert.
    Schulterzuckend das Script ein zweites Mal gestartet. Als alles fertig war, fand ich etliche leere Ordner vor und die Gesamtanzahl der Dateien betrug nur noch rund 274000 ... :(

    Theorie 1:
    Die folgende Zeile:
    FileMove($sFileWithPath, $sZielpfad & $sFileName, $FC_OVERWRITE + $FC_CREATEPATH)
    sollte vielleicht besser so aussehen:
    FileMove($sFileWithPath, $sZielpfad & $sFileName, $FC_CREATEPATH)
    Also nix Overwrite. Overwrite wird hier ja gar nicht benötigt, weil die von PhotoRec geretteten Dateien ohnehin einen individuell einzigartigen Dateinamen haben.

    Habe eben noch mal das Script mit der geänderten Zeile ausprobiert, an 2000 Dateien. Zwischendrin schoss ich gezielt das Script ab und startete es neu. Dabei ist kein Fehler aufgetreten. Nix leere Ordner und identische Anzahl Dateien wie vor der ersten Ausführung.

    Theorie 2:
    Die Windows-Option "Laufwerk für schnelle Dateisuche indizieren" war aktiviert.
    Eventuell hat sich Windows daran irgendwie verschluckt, dass während des Indizierens dauernd Dateien verschoben wurden.

    Theorie 3:
    Vielleicht war es auch nicht gut, dass der Windows-Papierkorb so konfiguriert war, dass er nur maximal 10% des Laufwerkplatzes verwendet.
    Ich hatte ja die Hoffnung, die verschwundenen Dateien im Papierkorb zu finden, aber darin war nur ein Teil vorhanden.

    Nun muss ich armer Wicht also die ganze Datenrettung wiederholen. Drei Tage im Stück hatte der Kram gedauert! :(

    Ich werde das Script doch noch etwas aufpolieren, so mit GUI und numerischer Anzeige der bereits bearbeiteten Dateien, statt dem simplen ConsoleWrite($sFileName & @CRLF).
    Wer noch gute Ideen hat, gerne her damit!


    Zitat von autoBert

    Für lau muß er nehmen was er bekommt, sprich sich selber hinsetzen und die Dateien manuel verschieben. Besser 465.000 unsortierte Bilder als gar keine.


    Das mit "lau" war nur die vereinfachte Wahrheit.
    Der Fotograf beauftragte mich mit der Datenrettung gegen Bezahlung. Ich machte ihm einen sehr günstigen Preis, weil ich es für keine hohe Kunst hielt, Photorec zu starten und den Rechner 1-3 Tage laufen zu lassen.
    Womit ich aber nicht gerechnet hatte, das war die enorme Anzahl an Dateien.
    Bei meinen früheren Erfahrungen mit PhotoRec kamen immer nur wenige tausend Bilder zusammen; eine Anzahl, die der Windows-Explorer noch problemlos bewältigte.
    Der Ordner mit 465000 Bildern hingegen, war in dieser Form komplett unbrauchbar. Da kann man nicht mal manuell Dateien verschieben. Windows rödelt schon minutenlang, wenn man den Ordner nur in Listenansicht öffnen will und drinnen liegt alles chaotisch durcheinander, mit kryptischem Dateinamen vor.

    Ich mag es generell nicht, nach einer Preisvereinbarung die Forderung wegen "unerwarteter Schwierigkeiten" zu erhöhen. Lieber nehme ich so etwas auf meine eigene Kappe.
    So gesehen war es "für lau". Alle Zusatzarbeit, die mir das bescherte, ist unbezahlt.
    Aber natürlich hat der Fotograf den geringen Obolus abzudrücken, der vorab vereinbart war. Und natürlich geht er dann davon aus, anschließend auch einen Nutzen von der Aktion zu haben. Da kann ich ihm keinen Chaos-Ordner mit 465000 wild durcheinander gewürfelten Dateien präsentieren, an dem sich Windows überhebt.

  • 465000 JPGs in einem einzigen Ordner ...

    • Code-Jack
    • 26. Juli 2016 um 20:17

    Hier nun das einsatzbereite Script:

    AutoIt
    ; Scriptname: PhotoRec-Butler
    ; Version: 1.0 vom 26.07.'16
    ; Autor: Stefan Denk (alias "Code-Jack", alias "Desi"), Fa. EDV-Dompteur
    ; Website: http://www.EDV-Dompteur.de
    ; Status: Freeware
    
    
    ; V E R W E N D U N G S Z W E C K :
    ; Dieses Script kommt zur Anwendung nach einer Datenrettung mit dem Programm "PhotoRec", aus dem Programmpaket "Testdisc",
    ; der ein Durchlauf des Scriptes "PhotoRec_Sorter" folgte.
    ; Im Anschluss an die Anwendung von PhotoRec_Sorter dürfte man einen Ordner namens "JPG" vorfinden, gefüllt mit nichts als massenhaft JPG-Dateien.
    ; In meinem eigenen Fall enthielt dieser Ordner über 465000 Dateien, was den Windows-Explorer völlig ausbremste. Es war kaum möglich,
    ; auch nur den Ordnerinhalt anzeigen zu lassen; es waren einfach gar zu viele Dateien darin vorhanden.
    ; Die Aufgabe des hier vorliegenden Scriptes ist es, die im JPG-Ordner vorhandenen Bilder, nach Aufnahmedatum sortiert, in automatisch angelegte
    ; Unterordner zu verschieben, so dass im Anschluss für jeden Tag, an dem ein Bild (bzw. mehrere) aufgenommen wurde(n), ein eigener Unterordner existiert.
    ;
    ; B E N U T Z U N G:
    ; Das Script soll sich NEBEN dem Ordner mit dem Namen "JPG" befinden, wenn es gestartet wird (also NICHT dort hinein kopieren!).
    ; Dann einfach das Script starten und abwarten. Im Anschluss findet man eine Ordnerstruktur nach folgendem Schema vor:
    ; ...\JPG\15-08-23
    ; ...\JPG\15-09-18
    ; ...\JPG\16-01-29
    ; etc.
    ; In jedem dieser automatisch angelegten Unterordner befinden sich nur genau jene Bilder, die an dem Tag aufgenommen wurden, der dem Ordnernamen entspricht.
    ;
    ; D A N K S A G U N G:
    ; Der Autor dankt folgenden Usern des großartigen Forums http://www.autoit.de für ihre Tipps, bzw. Code-Schnippsel:
    ; Simucal - für die Funktion _FileGetProperty, auf der dieses Script aufbaut.
    ; Oscar - für Codeschnippsel und präzise Hinweise.
    ; Xorianator - fürs Mitdenken.
    
    
    
    
    #include <FileConstants.au3>
    #include <MsgBoxConstants.au3>
    #include <WinAPIFiles.au3>
    
    
    Global $sQuellpfad = @ScriptDir & "\JPG\"
    Global $hSearch
    Global $sFileWithPath
    
    
    ; Das Handle der ersten Datei im Quellpfad ermitteln.
    $hSearch = FileFindFirstFile($sQuellpfad & "*.*")
    
    
    ; Überprüfen, ob obige Suche erfolgreich war.
    If $hSearch = -1 Then
      MsgBox($MB_SYSTEMMODAL, "", "Error: No files/directories matched the search pattern.")
      Return False
    EndIf
    
    
    ; Assign a Local variable the empty string which will contain the files names found.
    Global $sFileName = "", $iResult = 0
    
    
    While 1
      $sFileName = FileFindNextFile($hSearch)    ; Der Name der jeweils nächsten Datei.
      If @error Then ExitLoop                    ; Wenn keine weitere Datei vorhanden, dann Script beenden.
      ConsoleWrite($sFileName & @CRLF)           ; Dient nur der Kontrolle, ob das Script auch wirklich tätig ist und nicht etw "hängt"  :-)
    
    
      $sFileWithPath = $sQuellpfad & $sFileName  ; Der volle Pfad der Datei, samt deren Dateiname.
      $sAufnahmezeitpunkt = _FileGetProperty($sFileWithPath, "Bild aufgenommen am")  ;Das Datum, an dem das Bild tatsächlich aufgenommen wurde.
      ;ConsoleWrite($sAufnahmezeitpunkt & @CRLF) ; Dient nur zum Debuggen, sollte auskommentiert werden.
    
    
      $sJahr = StringMid($sAufnahmezeitpunkt, 7, 4)
      $sMonat = StringMid($sAufnahmezeitpunkt, 4, 2)
      $sTag = StringMid($sAufnahmezeitpunkt, 1, 2)
    
    
      $sZielpfad = $sQuellpfad & $sJahr & "-" & $sMonat & "-" & $sTag & "\"  ; Hierhin wird die Bilddatei gleich verschoben.
      ;ConsoleWrite($sZielpfad & @CRLF)          ; Dient nur zum Debuggen, sollte auskommentiert werden.
    
    
      ; Quelldatei in den neuen Ordner verschieben (Ordner wird automatisch erzeugt, falls noch nicht vorhanden).
      FileMove($sFileWithPath, $sZielpfad & $sFileName, $FC_OVERWRITE + $FC_CREATEPATH)
    
    
    WEnd
    
    
    ; Close the search handle.
    FileClose($hSearch)
    
    
    
    
    ;===============================================================================
    ; Function Name.....: _FileGetProperty
    ; Description.......: Returns a property or all properties for a file.
    ; Version...........: 1.0.2
    ; Change Date.......: 05-16-2012
    ; AutoIt Version....: 3.2.12.1+
    ; Parameter(s)......: $S_PATH - String containing the file path to return the property from.
    ;                     $S_PROPERTY - [optional] String containing the name of the property to return. (default = "")
    ; Requirements(s)...: None
    ; Return Value(s)...: Success: Returns a string containing the property value.
    ;                       If $S_PROPERTY is empty, an two-dimensional array is returned:
    ;                         $av_array[0][0] = Number of properties.
    ;                         $av_array[1][0] = 1st property name.
    ;                         $as_array[1][1] = 1st property value.
    ;                         $av_array[n][0] = nth property name.
    ;                         $as_array[n][1] = nth property value.
    ;                     Failure: Returns 0 and sets @error to:
    ;                       1 = The folder $S_PATH does not exist.
    ;                       2 = The property $S_PROPERTY does not exist or the array could not be created.
    ;                       3 = Unable to create the "Shell.Application" object $objShell.
    ; Author(s).........: - Simucal <Simucal@gmail.com>
    ;                     - Modified by: Sean Hart <autoit@hartmail.ca>
    ;                     - Modified by: teh_hahn <sPiTsHiT@gmx.de>
    ;                     - Modified by: BrewManNH
    ; URL...............: http://www.autoitscript.com/forum/topic/...property/page__view__findpost_
    ; Note(s)...........: Modified the script that teh_hahn posted at the above link to include the properties that
    ;                     Vista and Win 7 include that Windows XP doesn't. Also removed the ReDims for the $av_ret array and
    ;                     replaced it with a single ReDim after it has found all the properties, this should speed things up.
    ;===============================================================================
    Func _FileGetProperty(Const $S_PATH, Const $S_PROPERTY = "")
        Local Const $objShell = ObjCreate("Shell.Application")
        If @error Then Return SetError(3, 0, 0)
        Local $iPropertyCount = 300 ; arbitrary number used, Windows 7 only returns 289 properties, Windows XP only returns 38 (future proofing)
        If StringLeft($S_PATH, 1) = '"' Then StringTrimLeft($S_PATH, 1) ; deletes any quotes around the path\filename, otherwise will cause errors
        If StringRight($S_PATH, 1) = '"' Then StringTrimRight($S_PATH, 1) ; deletes any quotes around the path\filename, otherwise will cause errors
        If Not FileExists($S_PATH) Then Return SetError(1, 0, 0)
        Local Const $S_FILE = StringTrimLeft($S_PATH, StringInStr($S_PATH, "\", 0, -1))
        Local Const $S_DIR = StringTrimRight($S_PATH, StringLen($S_FILE) + 1)
        Local Const $objFolder = $objShell.NameSpace($S_DIR)
        Local Const $objFolderItem = $objFolder.Parsename($S_FILE)
        If $S_PROPERTY Then
            For $I = 0 To $iPropertyCount
                If $objFolder.GetDetailsOf($objFolder.Items, $I) = $S_PROPERTY Then Return $objFolder.GetDetailsOf($objFolderItem, $I)
            Next
            Return SetError(2, 0, 0)
        EndIf
        Local $av_ret[300][2] = [[1]]
        For $I = 1 To $iPropertyCount + 1
            If $objFolder.GetDetailsOf($objFolder.Items, $I) Then
                $av_ret[$I][0] = $objFolder.GetDetailsOf($objFolder.Items, $I - 1)
                $av_ret[$I][1] = $objFolder.GetDetailsOf($objFolderItem, $I - 1)
                $av_ret[0][0] += 1
            EndIf
        Next
        ReDim $av_ret[$av_ret[0][0] + 1][2]
        If Not $av_ret[1][0] Then Return SetError(2, 0, 0)
        Return $av_ret
    EndFunc   ;==>_FileGetProperty
    Alles anzeigen

    Mir ist bewusst, dass man da noch einiges optimieren könnte, aber mir reicht es so.
    - Vielen Dank noch mal an alle, die dazu beigetragen, oder auch nur mitgedacht haben!

  • 465000 JPGs in einem einzigen Ordner ...

    • Code-Jack
    • 26. Juli 2016 um 19:23

    Erfolg! :)
    Habe (wider eigenem Erwarten) erfreulich schmerzfrei ein Script hinbekommen und soeben mit 1000 Bildern getestet, die anstandslos in die automatisch angelegten Zielordner verschoben wurden.
    Bilder ohne Aufnahmedatum im EXIF landen dabei in einem gesonderten Ordner.

    Ich mache das Script nun noch hübsch und poste es im Anschluss.

  • 465000 JPGs in einem einzigen Ordner ...

    • Code-Jack
    • 26. Juli 2016 um 18:29

    Oh, ich habe gerade einen echten Durchbruch geschafft. Ich glaube, ich bekomme doch noch ein Script fertig, in den nächsten Stunden.
    Das Ergebnis werde ich dann hier posten.
    Vielen Dank schon mal an alle, die sich (laut oder leise) 'nen Kopf gemacht haben!

  • 465000 JPGs in einem einzigen Ordner ...

    • Code-Jack
    • 26. Juli 2016 um 17:50

    Es muss ja einen Grund geben, warum sich die von mir ausprobierten Tools aufhängten. Jedenfalls werte ich ein zweistündiges Festhängen des Fortschrittbalkens mal als Aufhänger.

    Mein Ansatz für ein Script wäre daher der, die Dateien einzeln auf den EXIF-Inhalt abzuklopfen und unmittelbar zu verschieben. Existiert der Zielordner noch nicht, wir er angelegt.
    Bei dieser Methode könnte man das Script jederzeit abbrechen und später neu starten; was bis dahin bereits abgearbeitet wurde, ist dann auch definitiv abgearbeitet.

    Tools hingegem, die bevor sie etwas verschieben zunächst mal fröhlich die EXIF-Daten aller Dateien auswerten, haben noch rein gar nichts erledigt, wenn sie sich noch vor dem Verschieben verschlucken.

    Und warum ich tagelang brauchen würde? - Weil ich mit AutoIt noch nicht so fit bin, wie Ihr.
    Der Fotograf will unbedingt morgen seine Festplatten abholen, trotzdem ich ihm sagte, dass ich noch an der Sortierung hänge. Bis morgen bekomme ich kein Tool gebacken - das lehrt meine Erfahrung mit anderen Scripten, wo auch dauernd scheinbare Kleinigkeiten in stundenlangen, am Ende tagelangen Kampf ausarteten.

  • 465000 JPGs in einem einzigen Ordner ...

    • Code-Jack
    • 26. Juli 2016 um 16:27

    Vorgeschichte:
    Habe für jemanden Daten von dessen Festplatte gerettet, mittels Photorec.
    Anschließend mit PhotoRec_Sorter.au3 die Dateien nach Endung sortiert.
    Resultat: Rund 20 Ordner, prall gefüllt mit den jeweiligen Dateitypen.

    Das große Problemkind ist der JPG-Ordner. Dieser beinhaltet über 465000 Bilder (und um Witzen vorzubeugen: nix Porno, sondern Fotograf).
    Mein eigentlicher Wunsch wäre, diese abdertausenden Bilder zunächst mal nach Kameramodell sotiert in Unterordner zu verschieben und dann, in einem zweiten Schritt, für jeden Aufnahmetag je einen Unterordner zu erstellen und die Bilder anhand dessen dorthin zu verschieben.

    OK, ich wäre schon genügend glücklich über allein nur den letzten Schritt. Also auf die Sortierung nach Kameramodell könnte ich husten, wenn es gelingt, einfach nur die Bilder nach Datum der Aufnahme in Unterordner zu verfrachten, gemäß dem Schema:
    2008-03-19
    2008-03-20
    2009-02-30
    ...

    Der Explorer meiner ollen XP-Kiste rödelt ewig, wenn ich versuche den dicken Ordner zu öffnen. Ich habe auch schon Tools von Heise.de heruntergeladen, die dazu dienen sollen, Dateien automatisch zu sortieren/verschieben. Aber auch damit gab es Probleme, in Form von Hängern. Es sind wohl einfach gar zu viele Dateien im Ordner.

    Sicher könnte ich jetzt ein eigenes Script schreiben für diesen Job, an dem ich aber vermutlich tagelang sitzen würde, bis es funzt. Etwas viel Arbeit, für nur einmalige Anwendung und für lau. Der Fotograf will eigentlich nur mal schnell auf bestimmte Bilder zugreifen können, ohne viel Zirkus. So wie es jetzt ist, nützt ihm meine Datenrettung "goa nix".
    Das Problem dürfte doch sooo exotisch nicht sein und es muss ja auch gar nicht mal unbedingt per AutoIt geschehen.
    Kennt vielleicht jemand ein real funktionierendes Tool für so einen Job, oder hat zufällig jemand ein halbwegs mundfertiges Script zur Hand?

    Die kleine Erschwernis liegt halt darin, dass nicht das Filedatum interessant ist, für die Sortierung, sondern das tatsächliche Aufnahmedatum des Bildes. Da müssen wohl die EXIF-Daten ausgewertet werden.
    Wie ich bereits weiß, gibt es ein UDF für den Zugriff auf EXIF-Daten.

    Wer weiß Rat?

  • modbus

    • Code-Jack
    • 26. Juli 2016 um 15:37

    Hmm, als relativer Neuling hier zögere ich zwar, einem gestandenen (und geschätzten, stets hilfbereiten) Poweruser zu widersprechen, aber ich möchte sagen, dass ich es optimal finde, so wie Homer es gemacht hat.
    Einerseits aus den von ihm schon genannten Gründen, andererseits weil man so alles, was thematisch zusammen gehört, schön in einem einzelnen Thread hat. Das ist sehr vorteilhaft, wenn man die Suchfunktion benutzt.
    Statt abertausender Threads, mit losen Informationshäppchen, hat man am Ende weniger Threads, aber die sind voller Gehalt und alle vielleicht wichtigen Nebenaspekte werden mit angesprochen.

    Übrigens wusste ich noch gar nicht, dass der Modbus so ein verbreiteter Standard ist. Ich dachte immer, jeder SPS-Hersteller kocht sein eigenes Süppchen. Für mich war dieser Thread hier daher sehr wertvoll, weil er Anstoß gab, mal anderweitig kurz zu recherchieren. Dabei stellte ich fest, dass der Modbus genau das bringt, was ich als Projekt (eigene SPS) schon jahrelang vor mir her schiebe und dass meine Eigenentwicklung eines Busprotokolls obsolet ist. Mein eigenes Protokoll war, wie ich hier & heute feststellte, zu praktisch 100% identisch mit dem, was in Form des Modbusses bereits ewig existiert.
    Das wäre mir vermutlich entgangen, hätte Homer einen neuen Thread aufgemacht; trotz Verweis, auf den alten Thread, gemäß chips Vorschlag.

  • Forum Problemsammlung

    • Code-Jack
    • 7. Juli 2016 um 00:54

    Lösung für "verkrüppelte" Darstellung dieses Forums.

    Verschiedentlich beklagte ich die bei mir irgendwie zerschossene Darstellung dieses Forums.
    Weiter oben, im Posting 84, fügte ich neulich einen Screenshot bei, der das übel vermurkste Erscheinungsbild des hiesigen Beitragseditors zeigt.

    Inzwischen fand ich die Ursache für dieses Problem:
    Und zwar habe ich meinen Firefox aus Sicherheitsgründen so konfiguriert, dass er Websites das Nachladen von Fonts aus dem Internet verbietet und statt dessen ausschließlich die lokal bei mir installierten Fonts verwendet.

    Alle möglichen Symbole werden hier aber (anders als in meinem eigenen Burning Board) offenbar mittels nachgeladener Fonts dargestellt, statt über kleine Grafiken.
    Vermutlich hat das einen klaren Vorteil: Fonts sind besser skalierbar. Aber der Nachteil ist halt der, dass das Verfahren mit einem gut abgeschotteten Browser nicht funktioniert.

    Es ist von den Admins sicher zu viel verlangt, dass sie sich den gewaltigen Aufwand antun, hier alles umzustricken. Aber ich wollte zumindest mitgeteilt haben, woran es liegt. Denn falls später noch weitere User über derartige Darstellungsprobleme jammern sollten, kann man denen die konkrete Lösung nennen.

  • "Gegenstände" im bild zählen

    • Code-Jack
    • 14. Juni 2016 um 14:30
    Zitat von Trubadour

    wenn dein Samen auch nur halbwegs elliptisch ist, passen viel mehr Samenreihen in der Breite nebeneinander, als in der Längsrichtung liegende Samen, bei Ausrichtung in Längsrichtung. Deshalb kann man, glaube ich, nicht einfach in der Breite mit dem selben Wert messen und damit multiplizieren.

    Das ist logisch. Meine Radieschensamen sind eher annähernd kugelförmig, scheinen mir aber gefühlsmäßig vom Volumen des Einzelsamens her zur Aufgabe zu passen.
    Gerhards Samen sind vielleicht schmaler, aber dafür länglicher, was in einem vergleichbaren Volumen resultieren dürfte.
    Die Ausmessung der annähernd kugelförmigen Samen dürfte also eine brauchbare Näherung ergeben (zur überschlägigen Abschätzung des ungefähren Zeitbedarfs allemal ausreichend und nur darum ging es).
    Wenn Gerhard Lust hat, kann er ja den nötigen Korrekturfaktor ermitteln.

    Es gibt übrigens Studien darüber, welche Form eines Schüttguts zu welcher Füllmenge pro Volumen führt.

    Allerdings habe ich das Gefühl, dass wir uns hier schon weit mehr Gedanken gemacht haben, als er sich selbst. Dass Gerhard noch keinerlei Vorstellung hatte, wie viele Samen überhaupt auf einen Quadratmeter passen, fand ich doch ... öhh ...


    Zitat von Trubadour

    Mich würde immer noch interessieren, warum man unbedingt zählen muss?

    Thread lesen. Das wurde diskutiert.


    Zitat von Trubadour

    die jeweils über Lichtschranke zählen.

    Lichtschranke ist zwar immer die erste Idee, wenn es um Zählung geht, aber tatsächlich ist die gar nicht in jedem Fall so gut geeignet. Hier z. B. eher weniger gut.
    Wenn doch mal zwei Samen nebeneinander hindurch fallen, dann erfasst die Lichtschranke die Einzelteile solcher Cluster nicht getrennt.
    Fallen sie hintereinander gereiht, so würde die Lichtschranke immerhin ein auswertbar längeres Signal liefern, aber das wäre nicht von einem besonders langen Korn zu unterscheiden.

    Der Piezo hingegen, kann auch quasi-gleichzeitiges Auftreffen zweier Samen als zwei Ereignisse erfassen.
    Im unwahrscheinlichen Fall absolut exakt gleichzeitigen Auftreffens, würde der Piezo immerhin noch ein stärkeres Signal erhalten, was wiederum auswertbar wäre, wenn auch nicht mehr per einzelnem Schmitt-Trigger (und wir hätten das Problem, dass zwei absolut exakt gleichzeitig auftreffende, kleine Körner von einem einzelnen, großen Korn nicht unterschedbar wären, analog zur Anreihung zweier Körner bei der Lichtschranke).
    Mein Vorschlag mit der Druckluft und Flugstrecke dürfte diesen Fall aber derat unwahrscheinlich machen, dass man ihn ignorieren kann. Denn genau das hatte ich bereits im Hinterkopf, als ich es vorschlug.


    Man kann auch mit Fließbändern separieren.
    Das Schüttgut auf ein laaangsam laufendes Fließband geben und an dessen Ende auf ein im 90 Grad Winkel angeordnetes, zweites, deutlich schneller laufendes Fließband fallen lassen. Das reißt alles schon mal auseinander. Man hat jetzt eine lange Reihe Körner.
    Dann noch auf ein drittes, abermals schnelleres Fließband fallen lassen, das wiederum im 90 Grad Winkel angeordnet ist.
    Das reißt die Reihe so weit auseinander, dass die Körner nun schön separiert vorliegen, so dass sie gezählt werden können - sogar mit einer Lichtschranke. :)

    Meine Druckluft-Methode erledigt das in einem Rutsch, ohne aufwändige Motoren und Förderbänder.
    Das Rohr ersetzt die ersten beiden Förderbänder und ordnet die Körner in einer Reihe an.
    Die Beschleunigung durch Druckluft ersetzt das dritte Förderband und separiert durch Auseinanderreißen der Reihe.
    Und falls es doch mal zwei besonders dünne Körner parallel ins Rohr schaffen, so sorgt die 2-Meter Flugbahn für eine hinreichende Unterdrückung gleichzeitigen Auftreffens.

  • "Gegenstände" im bild zählen

    • Code-Jack
    • 14. Juni 2016 um 11:35

    Ich habe gerade mal Radieschen-Saat vermessen.
    20 Körner, dicht aneinander gereiht, bilden eine Länge von genau 7 Zentimetern.
    Auf einen Zentimeter Länge gehen also 2,86 Körner, leicht abgerundet. (20/7)
    Auf einen Meter Länge kann man folglich 286 Körner anreihen.

    Auf einen Quadratmeter passen demnach 286 x 286 = 81796 Körner.
    Wenn die Waage nur eine Sekunde pro Messung benötigt (was schon schnell sein dürfte), kommt man auf knapp 23 Stunden ...

  • Forum Problemsammlung

    • Code-Jack
    • 14. Juni 2016 um 11:25

    Gun-Food hat dort eines meiner Postings gelöscht, auf Seite 1 (keine Ahnung warum?). Vielleicht hat das den Zähler eine Zeitlang irrtiert?

  • "Gegenstände" im bild zählen

    • Code-Jack
    • 14. Juni 2016 um 11:14

    Du schriebst mal was von einer Referenzfläche von einem Quadratmeter (alternativ: Blatt DIN-A4) ...
    Rechne mal aus, wie viele Körner auf einen Quatradmeter passen.
    Und dann stelle Dir vor, dass jede Zählung per Waage auch nur eine Sekunde dauert.

    Im industriellen Bereich kann man auch wesentlich schneller wiegen, was aber mehr Aufwand erfordert und Geld kostet (aber Du schlugst eine handelsübliche, billige Feinwaage vor).

    Das hier sind interessante und nicht teuer aussehende Apparillos:
    https://elmor.ch/

  • "Gegenstände" im bild zählen

    • Code-Jack
    • 14. Juni 2016 um 10:51

    Xorianator:
    Hmmm, die Druckluft-MP und den Arduino mit Piezo, dürfte ein halbwegs erfahrener 08/15-Bastler locker binnen eines einzigen Tages aus Bastelkisten-Schrott lauffähig zusammen gepfriemelt, den AVR programmiert und die Gesamtlösung fertig feingetuned & debugt haben.

    Ich würde aber in tiefer Ehrfurcht den Hut vor demjenigen Spezialisten ziehen, der die Körnerzählung in vergleichbarem Zeitrahmen und vergleichbar zuverlässig per Bilderkennung hinbekommt!

    Zugegeben: In diesem Forum sind sind wirklich ausgesprochen fähige Leute unterwegs, bei denen es sicher nicht an Programmierfähigkeit mangelt. Aber ...

    Schon allein für die perfekte Beleuchtung zu sorgen, ist vielleicht für 'nen professionellen Fotografen ein Klacks, aber ich habe bis heute Schwierigkeiten, gute Fotos von Platinen zu machen; das dürfte bei Körnen auch nicht anders aussehen. Ich habe mir mal eigens eine Ringleuchte mit transluzentem Diffusor gebastelt, für meine Kamera. Allein das war ein satter Tag Arbeit und erforderte einige Experimente, bis die Ausleuchtung so gelang, wie ich es brauchte. trotzdem bin ich noch immer nicht mit jedem Foto zufrieden.

    Weiterhin bleibt die schwierige Frage, wie man die Körner so angeordnet bekommt, dass sie überhaupt einfandfrei gezählt werden können? Also einlagig, überlappungsfrei, möglichst mit etwas Abstand zueinander.
    Irgednwie wohl mit Sieb / Kamm. Aber wie genau macht man das?
    Ein aufgeplatztes, doppelt breites Korn darf nicht als zwei intakte, nebeneinander leigende Körner gewertet werden. Das lässt sich ja theoretisch ausschließen, indem man die Körner gut vereinzelt und mit Abstand platziert. Aber ich habe keine Idee, wie man allein diese vorbereitende Aufgabe mit wenig Aufwand hinbekommt.Wären die Körner exakt identische, exakt linsenförmige Objekte, wäre es schon einfacher. Dann könnte man ein "maßgeschneidertes" Sieb nehmen (muss man erst mal haben!) und 'nen Rakel.
    Wie würdest Du diese notwendige Vorbereitung der Körner-Ausrichtung angehen, vor der eigentlichen Software-Geschichte?

    Und bezüglich der Bilderkennung gibt es einen Unterschied, zwischen:
    a) Eine Bilderkennungs-Routine im Internet aufzutreiben und zu installieren.
    b) Eine funktionierende Zählung der realen Körner hinzubekommen.

    Anders formuliert: Ich sehe einen Unterschied zwischen Theorie und Praxis.
    Oder präziser: Einen Unterschied zwischen einer konzepthaften Idee (die man noch nicht Theorie nennen kann) und realer Funktion - real funktionierend auch bei abweichender Korngröße/-Form (denn darum geht es ja).

    Da hat man sich das tollste Sieb und die tollste Vorrichtung selbst gebaut, oder bestellt, mit dem die separierte Platzierung bestens gelingt (woran ich erheblich zweifle!), doch nächstes Jahr sind die Körner 1/3 größer, oder kleiner ... oder irgendwie verformt ...

    Ich würde mal vorsichtig schätzen, dass Anbieter solcher Lösungen auf Industriemessen zu finden sind und für solche Apparaturen, die derlei Güter einwandfrei zählen können, Preise in der Größenordnung von 100.000 Tacken verlangen.
    Ich sehe nicht, wie man das mal eben so aus dem Handgelenk wuppen könnte.
    Eine grobe Zählung, mit hoher Fehlerrate: Meinetwegen. Aber schon die erforderliche Apparatur zur Vorbereitung, vor der eigentlichen Bilderkennung, dürfte weit komplexer ausfallen, als die Druckluft-MP mit Arduino.


    GerhardSchr:
    Die Methode mit der Waage ist aber krötenlahm und erfordert ebenfalls allerlei Drumherum, zur Separierung.

Spenden

Jeder Euro hilft uns, Euch zu helfen.

Download

AutoIt Tutorial
AutoIt Buch
Onlinehilfe
AutoIt Entwickler
  1. Datenschutzerklärung
  2. Impressum
  3. Shoutbox-Archiv
Community-Software: WoltLab Suite™