Fernbedienung für 25 und mehr SX200IS gleichzeitig?

[Karmaschinken]

Hmmmmm... Das nutzt mir leider auch nichts, weil die Kameras ja nicht per USB am Rechner hängen, sondern an der Fernbedienung. Ich würde gerne am Bild erkennen können, aus welcher Kamera es kommt.

Wenn es nicht anders geht, muss ich auf jeder Speicherkarte Dateien ablegen, über die die Bilder zugeordnet werden können. Das würde dann aber bedeuten, dass jede Kamera ihre spezifische Karte hat, und das ist wieder eine potentielle Fehlerquelle. Hmhmhm... Na gut, mal sehen...

Mal noch was anderes: Ich habe die 50 Netzteile für die Kameras in ChingChangChong bestellt, da waren die Batterieeinschübe für die Kameras dabei, also die Akku-Dummies. Die heißen bei Canon DR-30, man kann sie aber nirgends einzeln bestellen. Die Chinadinger sind aber so billig und minderwertig, dass ich für einen ernsthaften Betrieb des Arrays unbedingt Ersatzteile brauche, zur Not eben selbst gebastelte... Hier im Forum gibt es Bauanleitungen dafür, aber da wird der Saft einfach nur durchgeschleift. Wenn ich die Chinakracher aber aufmache, sind da Bauteile drin, wieso?

[fe50]

Ich würde gerne am Bild erkennen können, aus welcher Kamera es kommt.

Dann trage doch einfach mittels Canon-Software bei den Kameras einmalig etwas beim Eigentümer (Owner) ein, das wird im Flash permanent gespeichert und in den EXIF-Daten abgelegt...

[msl]

Wenn ich die Chinakracher aber aufmache, sind da Bauteile drin, wieso?

Das sieht mit nach Dioden als Verpolungsschutz aus. Die kann man eigentlich weglassen. Man muss halt nur auf die richtige Polung achten oder sicherstellen, dass die Polung nicht verdreht werden kann.

Gruß msl

[h3px]

Hi Karmaschinken,
im Exif-Tool wird unter MARKER die ImageUniqueID ausgegeben. Davon scheinen die letzten 20/21 Ziffern je Kamera konstant zu bleiben.
Gruß h3px

[Karmaschinken]

Tatsächlich? Muss ich gleich angucken. Ansonsten scheint auch die Lösung mit dem Owner praktikabel! Ich wusste nicht, dass das an den Kompakten auch geht... Und ich wäre auch nicht auf diese Idee gekommen!

Das mit dem Verpolungsschutz dachte ich mir schon, also kann ich selbst was basteln, alles klar! Danke!


Ihr seid alle sooooo schlau! Und soooo guuuuuut!

[rudi]

Hallo Karmaschinken,

Wenn ich die Chinakracher aber aufmache, sind da Bauteile drin, wieso?

Da es sich um zwei gleiche Bauteile handelt, die optisch nicht nach Diode ausehen, tippe ich eher auf zwei Spulen in SMD-Bauform zur Funkentstörung. Siehe auch hier.

Gruß rudi

[Karmaschinken]

Na gut, auch das braucht man wohl nicht unbedingt, oder? Verpolung schließe ich aus, Störungen ebenfalls . Sollte also so gehen...

Ist jetzt zwar etwas OT, aber vielleicht weiß doch jemand Bescheid!?! Ich versuche nun diese vermaledeite ImageUniqueID auszulesen, die in der Tat bis auf die ersten vier Stellen kameraspezifisch und fix zu sein scheint. Hier wird sie auch gelistet: Click

Wenn ich mit exiftool nun aber "exiftool -ImageUniqueID bla.jpg" ausführe, sehe ich nichts... Was mache ich da wohl falsch? Wenn ich "exiftool -a -u bla.jpg" ausführe, wird mir die Nummer gelistet. Komisch...

[h3px]

Also bei mir geht das... links- wie rechtsrum

Gruß h3px

[Karmaschinken]

Tatsache! Mein exiftool war zu oll, ich habs neu runtergeladen, jetzt gehts... Alles klärchen! Vielen Dank!

[Karmaschinken]

Und noch ein Problemchen, bitte schön! Ich versuche gerade ptp zu installieren, bekomme es aber nicht hin. Ich habe den alternativen USB-Treiber installiert, WIA-Support deaktiviert, den Canon Access Library-Service auch und es passiert einfach nix. Rechner ist neu gestartet, ich versuche mit chdkcam auf die Kamera zuzugreifen... Was mache ich falsch? Danke Euch!

Achso, OS ist Windows XP 32bit...

Achso 2: Ich habe die Remote-Funktion von CHDK auf der Kamera deaktiviert, wenn ich in chdkcam auf "Connect" klicke schaltet sich die Kamera aus...

Komisch, mit ptpCamGUI funktioniert es...

[msl]

chdkcam ist "outdated".

Das funktioniert mit dem jetzt in CHDK integrierten PTP-Modul nicht. Das Projekt chdkcam wird nicht mehr weiterentwickelt, auch wenn es durch sein Live-Bild interessanter war. Man könnte das Projekt nur mit riesigem Aufwand weiterführen. Es lässt sich einfach nicht richtig auf mehr als 70 Kameras anpassen.

Wenn du es mal testen möchtest, benutze diese Version oder compiliere dir selbst eine Version, in dem du meinen Branch als Quellcode verwendest.

Mit der jetzigen PTP-Interface-Version kannst du als Konsolen-Programm ptpcam oder die darauf aufbauende GUI benutzen. Aber die kennst du ja schon.

Gruß msl

[Karmaschinken]

Vielen Dank... Eigentlich brauche ich das Livebild nicht, das wichtgste wäre, dass ich die Daten aus den Kameras auslesen könnte, ohne die Stromversorgung abziehen, die Speicherkarten rauziehen, in einen Leser einstecken und wieder zurückbringen müsste. Grundsätzlich ginge das ja mit ptpCamGUI, AAAAAAABER:

Da ich ja sämtlich USB-Anschlüsse an der Fernbedienung hängen habe und diese alle zu einem Kabel, dem Auslöseknopf, zusammengeführt werden, habe ich ja die USB-Stromversorgungskabel für die Remote-Geschichte belegt.

Ich bin nun auf die Idee gekommen, einfach die signalführenden Kabel in mein Notebook zu stöpseln und die 5 Volt der Stromversorgung, die ja urprünglich ebenfalls aus meinem Notebook-USB-Anschluss kämen, einfach weiter von meinem stabiliserten NEtzteil kommen zu lassen. Aber das scheint nicht zu gehen. Aber warum nicht? Ich kann mir nicht vorstellen, dass über die 5Volt-Adern zusätzlich Signale geschickt werden, oder? Ich meine, 5 Volt an die stromführenden Kabel sind 5 Volt, es sollte doch egal sein, wo die herkommen, ob nun aus dem Notebook oder nicht? Aber dem scheint nicht so zu sein ?!?

Wenn ich es hinbekäme, dass ich die signalführenden Kabel, und wenn es auch nacheinander einzeln wäre, an den USB-Port eines Rechners anschliessen könnte, dann könnte ich die JPGs von den Kameras download und die Karten leeren, und auch die Verteilung von Presets zu den Kameras würde sich DEUTLICH vereinfachen. Habe ich einen Denkfehler, oder müssen es tatsächlich die 5 Volt aus demselben USB-Port sein, über den auch die eigentliche Kommunikation läuft????

-- 16.02.2011, 15:19 --

Ah! Kommando erledigt! Ich hate die Abschirmung nicht zusammengezwirbelt, funzt jetzt auch! So, das bedeutet einen völlig neuen Status für die Kommunikation mit den Kameras. Damit drängt sich diese Möglichkeit des Auslesens der Kameras förmlich auf, und noch viel weitergehend natürlich die gesamte Inititalisierung des gesamten Arrays.

Jetzt ist natürlich eine ganz entscheidende Frage: Geht das auch mit mehr als einer Kamera? Ich meine kann ich über einen HUB sagen wir 10 SX200IS mit 10 gleichzeitig laufenden ptpCams ansprechen. DAS wäre natürlich der HAMMER! Weil das die ECHTZEITAUSLESUNG aller 50 Kameras ermöglichen würde und dann, wenn man es einigermaßen programmiert bekäme, auch diee Voransicht eines Ergebnissen binnen sagen wir mal 3-4 Minuten. Bisher ist die Sichtung der Ergebnisse erst nach Beendigung des Shootings geplant, wenn es mir alerdings gelänge, das in Realtime zu zeigen, und 4 Minuten gelten mir als solche, das wäre der MEGAHAMMER! Ächz! Ich muss das SOFORT auschecken...

[Karmaschinken]

Jetzt brauche ich nochmal Eure Hilfe, ich komme nicht weiter! Ich habe es nun immerhin geschafft, dass die ptpcam-console zwei Kameras sieht - sogar an einem Hub -, aber ich finde nicht heraus, wie ich sie ansprechen muss. Über --bus= und --dev= sollte ich doch klar definieren können, an welche kameras ich kommandos sende, oder? aber seltsamerweise scheint --dev beliebige werte klaglos anzunehmen, also auch phantasiewerte... Sämtliche Kommandos scheinen stets an device 0 zu gehen? Weiß jemand, was ich da falsch mache?

So sieht das auf meiner console aus:

[Karmaschinken]

Also, falls jemand in naher oder ferner Zukunft mal mehr als eine Kamera mit ptpcam an seinem Rechner würde betreiben wollen und falls derjenige zu dieser Stelle gelangt sein würde, dann wird ihm hiermit folgendes berichtet worden sein: Ich hatte es damals nicht geschafft, mit ptpcam zwei Kameras anzusprechen, obwohl mir beide gelistet worden waren. Im Readme von ptpcam hatte gestanden:

"If ptpcam detects more than one camera you need to pass --bus=BUS-NUMBER and, or --dev=DEV-NUMBER arguments otherwise ptpcam tries to talk to first detected camera. If you specify only bus or dev number ptpcam talks to first matching camera."

Genau dies war ja mein Problem gewesen: "ptpcam talks to the first camera".

Ich hatte den ursprünglichen Erfinder Mariusz Wołoszyn deshalb um Hilfe gebeten und der hatte folgendes geschrieben:

It's not stated clearly but ptpcam (and libusb) was developed under Linux not Windows. Although it works there, there are certain issues and incompatibilities. Unfortunately I cannot test it by myself (I got only one PTP camera at the moment and I do not run libptp under
Windows) but I can give you a couple of hints you may try (beside the "Switch to Linux" which certainly would do the trick .

Let's start with some basics: both BUS-NUMBER and DEV-NUMBER are just numbers. Under Linux the libusb returns the path to the device just as numbers but apparently under windows it puts there some junk from underlying windows usb subsystem. What you should try it to insted of the fnacy string try just 1 or 2 (or in general the number you find after libusb0-XXXX--0x04a9--0x031c0 those last number are vendor and product IDs of your camera and for some unknown to me reason it all together with the busID (0 at the end of libusb0 string) are added to the device number field on libusb device enumeration field.

So, to recapitulate, please try the following commands:
ptpcam --bus=0 --dev=1 -l
ptpcam --bus=0 --dev=2 -l

Auch dies hatte jedoch leider nicht funktioniert. Daraufhin hatte mir Mariusz folgendes geschrieben:

That's odd. Where did you get that copy of ptpcam? I know there was some kind of fork for Canon cameras (Canon has broken ptp specification and implemented some additional features the wrong way, I never had a single Canon came - I worked with Nikons - and there was one guy that implemented it in ptpcanon or something like this based on my libptp2 code). Probably you are using this version.
Have you build it up from sources? I'm curious because my version never attempts to retry so it must have been modified.

If you compiled it from sources I could send you a series of patches to enable additional debug that could help me to identify what went wrong or try to recover.
Also you can try to use Linux if you're not heavily bound to Windows. Otherwise the problem cannot be solved without modifying and recompiling ptpcam as I verified in the sources that my code assumes that both bus and device are number while on Windows certainly they're not. The problem lays in find_device() function that first converts the string provided by usb subsystem to a number (blindly assuming that it's a number and that certainly is wrong) and then compares it to a number provided bu the user. Let me know if you could switch to Linux or you seek to fix the windows version.

Nun gut, ein switch-to-linux kam damals nicht in Frage und meinen kurzen Versuch, ptpcam neu zu kompilieren, hatte ich dann aufgegeben, weil mir jede Menge #includes <xxx.h> gefehlt hatten, die ich sonstwo hätte zusammentragen müssen.

Lange Rede kurzer Sinn: Falls Du, künftiger Leser dieses Posts aufgrund ähnlicher Probleme hier gelandet sein wirst, so wird Dir hier leider keine Lösung geboten worden sein. Ich habe mich damals entschieden, immer nur eine Kamera gleichzeitig am Rechner hängen zu haben... Herzlichen Gruß aus der Vergangenheit!

[rudi]

Hallo Karmaschinken,

durch Zufall hatte ich heute eine zweite A590 zur Verfügung. Eine Analyse der Auswertung der Gerätenummer in der ptpcam.exe unter Windows ergab folgendes.

Die Analyse:

• Die USB-Geräte werden nicht anhand ihrer Bezeichnung wie "\\.\libusb0-0002--...." erkannt. Damit ist der Aufruf "--dev=libusb0-0002-..." nutzlos.
• Die Erkennung läuft nur über die Gerätenummer. Im Beispiel "--dev=2".
• Die zum Vergleich benötigte Grätenummer wird allerdings aus der Gerätebezeichnung durch extrahieren des ersten numerischen Wertes gewonnen. Hier also die "0" von "\\.\libusb0-0002--....". Damit ist die Grätenummer zum Vergleich nicht richtig und es wird immer das erste gelistete Gerät angesprochen.

Die Lösung:
Zuerst sucht man das Trennzeichen und verwendet den folgenden numerischen Wert als Gerätenummer. Da das Verfahren unter Linux wohl korrekt arbeitet, habe ich die Änderungen nur für Windows durchgeführt.

Im Anhang befindet sich die geänderte ptpcam.exe, fünf CMD-Dateien und der Patch.
Zuerst kannst du mit "list_dev.cmd" dir alle verfügbaren Kameras anzeigen lassen. Die Dateien "chdk_devX.cmd" beinhalten eine Befehlsfolge zum setzen der LED 8. Bei der A590 ist das die blaue LED in der Print-Taste. Das "X" steht für die jeweilige Gerätenummer 1 bis 4. Der Ordnung halber habe ich die BUS-Nummer mit angegeben, was aber in meinen Tests nicht erforderlich war.

Die beiden A590 waren zusammen an einen USB-Hub angeschlossen. Die Gerätenummern wurden in der Einschaltreihenfolge vergeben, daher geht eine Kamera aus bekommt sie möglicherweise nicht die gleiche Gerätenummer wieder.

Hinweis: Die ptpcamGUI kann nur auf die erste Kamera zugreifen, da keine Parameterübergabe beim Erzeugen des DLL-Handles erfolgen kann.

Gruß rudi