Handhabung & Technik El Fueradoro - Funkzündanlage mit Interface

Für den Atmega ist es kein Problem, aber zumindest von meiner Seite aus wird es in absehbarer Zeit keine 32-Kanal-Version geben.

Da die Pläne und Codes aber komplett offen liegen, kann man sich natürlich daran versuchen, das Teil zu erweitern. Zwei weitere Schieberegister, einen zusätzlichen DM13A, sechzehn IRF3708 und die entsprechenden Leitungen + Softwareanpassungen wird man brauchen.

 

Eine Sache, die mich an den Zündboxen von Anfang an gestört hat, war eine fehlende Sicherung* - speziell für die Zuleitung von Akku zu Modul. Ich hab das für meine Module jetzt gelöst und möchte euch das nicht vorenthalten.

Benötigtes Material

- Gehäuse (GEH KS 50 - Reichelt)
- 4,8mm Flachsteckhülsen (braucht man sowieso)
- Kfz-Sicherungshalter (260 450 - Pollin)
- zum Kabeldurchmesser passende Kabeldurchführungen (bei mir Amazon B07798BSDB)

Der kleine 1,2Ah Akku passt wunderbar in das kleine Gehäuse, das bei El Fueradoro eigentlich für den PC-Transmitter gedacht ist. Man muss lediglich am Boden die sechs Befestigungsnippel rausbrechen. Eventuell noch mit ein bisschen Schleifpapier glätten. Die Kabelverschraubung ist "wasserdicht", schützt das Kabel und hat den Vorteil, dass sie gleich eine Zugentlastung herstellt.





Und so sieht das ganze dann fertig aus:



*Über Sinn und Unsinn der Maßnahme kann man sicher streiten.Okay, 1,2 Ah sind relativ schnell leer. Aber der Teufel ist ein Eichhörnchen. Wenn die Zuleitung oder die Zündbox, aus welchem Grund auch immer, einen Kurzschluss produziert, ist da nichts, was den Akku vor hohen Strömen schützt. Das ist im besten Fall schlecht für den Akku - im schlimmsten Fall führt es zu einem Brand.

 

Den Akku braucht man vor relativ wenig zu schützen, eher den Rest vor dem Akku : Bei meinem Stepper Fuoco Step haben es zwei Leute geschafft, die beiden Klemmen des Ladegeräts bei angeschlossenem Akku kurzzuschließen, dadurch wurde relativ eindrucksvoll dokumentiert, dass die Sollbruchstelle nicht im Kabel oder den Steckverbindungen liegt, sondern bei einer immerhin 2,54mm breiten Leiterbahn auf der Platine. Das Kupfer hat sich innerhalb von ein paar Sekunden in Rauch aufgelöst und den Stromkreis dadurch geöffnet. Der Akku zuckt bei solchen Strömen nicht einmal mit der Wimper.

 

Aus dem anderen Thread von @Zamm:

Da das Fehlerbild mir nicht ganz klar wird, hätte ich noch ein paar Fragen:
Welcher Programmer wird verwendet? Ist die Zielplatine voll bestückt, also mit Quarz und passenden Kapazitäten? Verstehe ich richtig, dass vor dem Flashen via Raspberry Pi der Zugriff mit Atmel Studio auf den Controller funktioniert hat? Einen Blick auf die Konsolenausgabe beim Raspi hast du nicht zufällig werfen können?

Nachtrag: Der erste Nachtrag war Quatsch .

 

Erstmal danke für die rasche Antwort
Habe einen Fehler gefunden zwar habe ich den Elko nr. c14 mit der Polarität vertauscht

EDIT:

Hab den elko neu eingelötet und leider noch keinen erfolg gleiches endergebnis
Hab die Platine mehrmals durchgeschaut ob alles richtig sitzt und verlötet ist.
der Atmega wurde einwandfrei von AtmelStudio erkannt habe aber auch beim flashen über den Raspberry keine Benachrichtigung erhalten ob Erfolg oder Fehlschlag es hat nur der Avrisp rot geblinkt danach blau durchgehend

 

Da hilft dann nur noch die gute alte Kommandozeile. Also Windowstaste+R drücken und dann "cmd" eingeben und bestätigen (Enter oder OK).

Nun in das Verzeichnis navigieren, in dem die BOOTLOAD.HEX liegt, also z.B. C:\Pyro\Hexfiles\Bootloader. Für diejenigen, die nur mit Windows groß geworden sind: Verzeichnisse wechselt man mit dem Befehl "cd" (current directory). Mit "cd \" kommt man ins Hauptverzeichnis der aktuellen Festplatte, von dort kann man dann mit "cd Pyro\Hexfiles\Bootloader" ins fragliche Verzeichnis springen. Muss man die Festplatte wechseln, gibt man den Laufwerksbuchstabe gefolgt von einem ":" ein - hach ja, die gute alte Zeit!

Im entsprechenden Verzeichnis angekommen, dann mal folgenden Befehl ausführen:

.\tools\avrdude.exe -pm328p -cavrispmkII -Pusb -B 50 -Uflash:w:bootload_m328p_9830400.hex:a -U eeprom:w:std_eep.eep:a -Ulfuse:w:0xf7:m
-Uhfuse:w:0xd6:m -Uefuse:w:0xfd:m -v

Die anschließend erscheinende Ausgabe auf der Konsole kannst du dann hier posten oder mir schicken, dann sollte etwas klarer werden, was das Problem ist.

 

avrdude.exe: stk500v2_command(): command failed
avrdude.exe: stk500v2_program_enable(): bad AVRISPmkII connection status: Target reverse inserted
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.


avrdude.exe done. Thank you.

Anders herum eingesteckt kommt dann die Ansage:
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "bootload_m328p_9830400.hex"
avrdude.exe: input file bootload_m328p_9830400.hex auto detected as Intel Hex
avrdude.exe: writing flash (32768 bytes):

Writing | ################################################## | 100% 0.01s

avrdude.exe: 32768 bytes of flash written
avrdude.exe: verifying flash memory against bootload_m328p_9830400.hex:
avrdude.exe: load data flash data from input file bootload_m328p_9830400.hex:
avrdude.exe: input file bootload_m328p_9830400.hex auto detected as Intel Hex
avrdude.exe: input file bootload_m328p_9830400.hex contains 32768 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.01s

avrdude.exe: verifying ...
avrdude.exe: 32768 bytes of flash verified
avrdude.exe: reading input file "std_eep.eep"
avrdude.exe: input file std_eep.eep auto detected as Intel Hex
avrdude.exe: writing eeprom (128 bytes):

Writing | ################################################## | 100% 0.51s

avrdude.exe: 128 bytes of eeprom written
avrdude.exe: verifying eeprom memory against std_eep.eep:
avrdude.exe: load data eeprom data from input file std_eep.eep:
avrdude.exe: input file std_eep.eep auto detected as Intel Hex
avrdude.exe: input file std_eep.eep contains 128 bytes
avrdude.exe: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.37s

avrdude.exe: verifying ...
avrdude.exe: 128 bytes of eeprom verified
avrdude.exe: reading input file "0xf7"
avrdude.exe: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xf7:
avrdude.exe: load data lfuse data from input file 0xf7:
avrdude.exe: input file 0xf7 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified

avrdude.exe: safemode: Fuses OK (E:FF, H9, L:F7)

avrdude.exe done. Thank you.

Ist es das schon gewesen?

 

Ja, alles wunderbar. Damit hast du den Bootloader erfolgreich auf den Controller gebrannt. Jetzt kannst du dann mit der UpdateLoader-Oberfläche über die serielle Schnittstelle die eigentliche Software aufspielen.

Korrektur: Ich sehe gerade, dass offenbar nur den Teil des Befehls gelaufen ist, der hier im Forum in der ersten Zeile gelandet ist. Das Schreiben der HFuse und der EFuse fehlt, damit ist dann z.B. der für die Datensicherheit recht wichtige Brown-Out-Detektor bei Unterspannung nicht aktiv. Also bitte noch einmal den Bootloader per ISP aufspielen und den kompletten Befehl in einer Zeile ausführen.

 

Na endlich, warum hab ich denn nicht schon eher gefragt
Vielen Dank dir für die rasche Hilfe. Vielleicht wäre es ja eine Idee diesen Teil mit der Kommandozeile so in die Anleitung einzufügen, außer man will natürlich, dass man sich hier alles durchließt, was meiner Meinung von Vorteil ist, da es mir dann doch ein paar Fehler ersparen lassen hat.

 

In der neuesten Handbuchversion (Kompilierdatum 16.10.2019) steht der Flashbefehl auf Seite 115, die Bedienung der Kommandozeile kann man anderweitig nachschlagen. Das Handbuch hat sowieso schon Ausmaße angenommen, die vermutlich eher abschreckend als einladend wirken, da will ich dann nicht auch noch mit solchen Exkursen in über 30 Jahre alte Betriebssysteme langweilen.

 

Da hier auch öfter Verwirrung auftritt, was für einen Programmer man nehmen kann und ob das schon auch alles passt, was man tut: Ein USBasp V2 für unter 10€ tut es voll und ganz, so einen habe ich nämlich verwendet

Genauer den hier (man muss halt einfach nach demselben Produkt schauen, das Angebot hier ist grade weg): https://www.ebay.de/itm/USBASP-V2-USBISP-USB-ASP-Programmierer-blau-für-KK2-SimonK-Arduino-AVR-Atmel-PIC/173902711060

 

Hat jemand noch eine funktionierende PyroIgnitionControl 1.4.5? Ich hab wohl meine Pyrotronic.dll "verlegt". 1.7.2 akzeptiert meine zpl aus 1.4.5 nicht. Und die Pyrotronic.dll aus 1.7.2 ist nicht mit 1.4.5 kompatibel

Wäre echt bitter wenn ich den gesamten Plan (124 Cues) in 1.7.2 neu schreiben müsste. Zumal die keine Datenbank hat.

 

Meinst Du dieses hier ?

 

Danke! Keine fünf Minuten! Du bist der Beste!

Trotzdem ist irgendwie der Wurm drin. "Falsche Plugin Version. Benötigt 1.5". In meiner alten 1.4.5 sagt er sogar "Benötigt 1.4"

 

Habe Dir mal alle Versionen die Ich habe in einen ZIP Ordner gepackt
https://pyro-inferno.de/feuerwerk.zip

Bitte nach dem Download bescheid geben damit ich es wieder offline nehmen kann

 

Hoffe es ist was dabei das klappt

 

Ja, ich hab jetzt eine 1.4.1, die sich i, Funktionsumfang auf den ersten Blick nicht von 1.4.5 unterscheidet. Aber sie funktioniert mit meinem PC-Transmitter. Keine Ahnung was da los war.

Jetzt kann ich jedenfalls wieder testen.

 

Ein paar Neuigkeiten.

Meine neun Module mit PC-Transmitter hatten am Wochenende ihre Feuertaufe unter den Bedingungen, die wir auch Silvester haben. Also gab es ein improvisiertes F1 Feuerwerk. Dabei ist so ziemlich alles schiefgegangen, was schiefgehen konnte, aber ich habe ein paar wichtige Erfahrungen gemacht. Und genau darum ging es...

Zunächst haben wir von jedem Modul vier Kanäle (einer pro Reihe) getestet. 8x Erfolg. Ein Modul hat die Kanäle 9-16 überhaupt nicht gezündet. RX kam an der Box an, aber kein Output. Der gemeinsame Nenner, das zugehörige Schieberegister, war mir relativ schnell klar, der zugehörige Fehler dann aber doch etwas überraschend



Uuuups... Bei neun Zündboxen kann einem sowas ja mal durch die Lappen gehen

Viel schlimmer war das Problem, dass der PC-Transmitter plötzlich auch Probleme mit kurzen Zündintervallen entwickelte. Bei zwei Zündungen im Abstand von 100ms blieb er plötzlich hängen, die Serial-LED blieb dauerhaft an. PyroIgnitionControl (1.4.1) lief munter weiter, der Transmitter bekam aber keine neuen Befehle mehr mit, wahrscheinlich weil die serielle Verbindung noch offen war. Mit minimal größerem Abstand (110ms) lief es dann durch. Das Verhalten war auch reproduzierbar.
Hier war die Fehlersuche dann schon schwerer. Ich bin nach dem Ausschlussprinzip vorgegangen. Hab gedacht, es könnte am neuen Laptop liegen - nein, der große Rechner zuhause macht das gleiche. Falsche PIC Version? Nein, auch mit anderen Versionen gleiches Verhalten. Eventuell die Kälte? Nein, nach einer Nacht im Warmen immer noch das selbe. Letzte Chance, bevor ich mir Rat von Felix hole: Firmware neu aufspielen. Zack... Treffer. Keine Ahnung, woran es jetzt lag, aber seitdem funktionierts wieder. Ich werde trotzdem noch ein bisschen weiter testen, gerade was die Temperaturen angeht...

In zwei oder drei Wochen geht es dann mit der RaspEasyFire auf den Platz, gleiches Spiel. Danach entscheide ich, welche Anlage ich Silvester benutze.

Ach ja... wenn jemand noch eine funktionierende PyroIgnitionControl mit funktionierender Pyrotronic.dll hat, bitte her damit! Die 1.4.1 ist zwar auf den ersten Blick identisch, aber ich würde lieber mit der 1.4.5 arbeiten. Die ist vielleicht etwas stabiler...

 

Aus solchen Gründen ist es immer ratsam, sich vorher ausgiebig mit den Sachen vertraut zu machen - finde ich einen sehr vernünftigen Ansatz.

Die PyroIgnitionControl, die ich verwende, gibt es HIER.

Ganz persönlich würde ich zur Verwendung des raspEasyFire raten, da es dort zwar zu minimalen Verzögerungen kommen kann, in den letzten Tests mit dem neuen Image, aber ein Stehenbleiben der Show ausgeschlossen ist. Hier gilt dann der umgekehrte Christian Lindner: "Lieber später zünden als gar nicht zünden."

 

Danke! Ich überlasse dieses Jahr nichts dem Zufall. Wären die Fehler von gestern erst Silvester bemerkt worden, käme noch der Stressfaktor dazu... So war das gestern zwar ernüchternd, aber auch unheimlich hilfreich - ohne dass eine ganze Show auf der Kippe stand.

Ich würde den raspEasyFire auch vorziehen, schon allein weil er wesentlich handlicher und einfacher in der Bedienung ist. Wenn ich allein daran denke, wie oft ich schon vergessen hab, über PuTTy den Transmitter zu armen...

 

Hi zusammen,
ich bekomme derzeit folgenden Fehler, wenn ich nach einer Slave-Suche die Box versuche anzuwählen. Habe zuvor das aktuelle Image (von raspeasyfire.newan.de) und aktuelle Firmware geflasht.
Hat sich die Bennenung der Kivy Screens geändert?

Spoiler: Traceback

Traceback (most recent call last):
File "main.py", line 755, in <module>
MainApp().run()
File "/usr/local/lib/python3.6/site-packages/kivy/app.py", line 855, in run
runTouchApp()
File "/usr/local/lib/python3.6/site-packages/kivy/base.py", line 504, in runTouchApp
EventLoop.window.mainloop()
File "/usr/local/lib/python3.6/site-packages/kivy/core/window/window_egl_rpi.py", line 94, in mainloop
self._mainloop()
File "/usr/local/lib/python3.6/site-packages/kivy/core/window/window_egl_rpi.py", line 89, in _mainloop
EventLoop.idle()
File "/usr/local/lib/python3.6/site-packages/kivy/base.py", line 342, in idle
self.dispatch_input()
File "/usr/local/lib/python3.6/site-packages/kivy/base.py", line 327, in dispatch_input
post_dispatch_input(*pop(0))
File "/usr/local/lib/python3.6/site-packages/kivy/base.py", line 233, in post_dispatch_input
listener.dispatch('on_motion', etype, me)
File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
File "/usr/local/lib/python3.6/site-packages/kivy/core/window/__init__.py", line 1406, in on_motion
self.dispatch('on_touch_up', me)
File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
File "/usr/local/lib/python3.6/site-packages/kivy/core/window/__init__.py", line 1442, in on_touch_up
if w.dispatch('on_touch_up', touch):
File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
File "/usr/local/lib/python3.6/site-packages/kivy/uix/screenmanager.py", line 1201, in on_touch_up
return super(ScreenManager, self).on_touch_up(touch)
File "/usr/local/lib/python3.6/site-packages/kivy/uix/widget.py", line 571, in on_touch_up
if child.dispatch('on_touch_up', touch):
File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
File "/usr/local/lib/python3.6/site-packages/kivy/uix/relativelayout.py", line 304, in on_touch_up
ret = super(RelativeLayout, self).on_touch_up(touch)
File "/usr/local/lib/python3.6/site-packages/kivy/uix/widget.py", line 571, in on_touch_up
if child.dispatch('on_touch_up', touch):
File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
File "/usr/local/lib/python3.6/site-packages/kivy/uix/scrollview.py", line 895, in on_touch_up
if self.dispatch('on_scroll_stop', touch):
File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
File "/usr/local/lib/python3.6/site-packages/kivy/uix/scrollview.py", line 934, in on_scroll_stop
self.simulate_touch_down(touch)
File "/usr/local/lib/python3.6/site-packages/kivy/uix/scrollview.py", line 642, in simulate_touch_down
ret = super(ScrollView, self).on_touch_down(touch)
File "/usr/local/lib/python3.6/site-packages/kivy/uix/widget.py", line 549, in on_touch_down
if child.dispatch('on_touch_down', touch):
File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
File "/usr/local/lib/python3.6/site-packages/kivy/uix/widget.py", line 549, in on_touch_down
if child.dispatch('on_touch_down', touch):
File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
File "/usr/local/lib/python3.6/site-packages/kivy/uix/behaviors/button.py", line 151, in on_touch_down
self.dispatch('on_press')
File "kivy/_event.pyx", line 703, in kivy._event.EventDispatcher.dispatch
File "kivy/_event.pyx", line 1214, in kivy._event.EventObservers.dispatch
File "kivy/_event.pyx", line 1138, in kivy._event.EventObservers._dispatch
File "/home/pi/raspEasyFire3/module/RaspEasyFireStartScreen.py", line 344, in btShowImpedances
self.objMain.getImpedances(uniqueid, slaveid)
File "main.py", line 739, in getImpedances
self.objMyScreenManager.current = 'ImpedanceLister'
File "kivy/properties.pyx", line 497, in kivy.properties.Property.__set__
File "kivy/properties.pyx", line 544, in kivy.properties.Property.set
File "kivy/properties.pyx", line 599, in kivy.properties.Property.dispatch
File "kivy/_event.pyx", line 1214, in kivy._event.EventObservers.dispatch
File "kivy/_event.pyx", line 1120, in kivy._event.EventObservers._dispatch
File "/usr/local/lib/python3.6/site-packages/kivy/uix/screenmanager.py", line 1038, in on_current
screen = self.get_screen(value)
File "/usr/local/lib/python3.6/site-packages/kivy/uix/screenmanager.py", line 1064, in get_screen
raise ScreenManagerException('No Screen with name "%s".' % name)
kivy.uix.screenmanager.ScreenManagerException: No Screen with name "ImpedanceLister".

PS: Könnt ihr mir noch ein Ladegerät für die Bleiakkus empfehlen?

 

Ich habe ein H-TRONIC AL 800, das ist schön leicht und tut seit Jahren seinen Dienst. Aufpassen, dass der Schalter auf der Rückseite auf 12 V steht.

Ja, der Screen heißt jetzt "impedancelister" und daher gibt es den Fehler; wird in der Software geändert.

 

Änderung in der Software für raspEasyFire ist durchgeführt und auch die Firmware für die Zündboxen hat sich in Vorbereitung auf die angekündigte 32-Kanal-Version geändert. Bei der Impedanzliste muss die Zündbox nun die Info mitliefern, ob 16 oder 32 Kanäle, dafür musste das Übertragungsprotokoll angepasst werden und auch die maximale Übertragungslänge musste ich auf 40 erhöhen, da 32 Kanäle (plus Overhead) die bisherige Maximalgröße von 30 Bytes sprengen werden.

Es gibt daher eine Abhängigkeit der neuesten Änderungen im raspEasyFire-Repository mit der neuesten El-Fueradoro-Firmware. Damit alles nach Plan funktionieren kann, muss man beides auf den neuesten Stand bringen.

 

Auch ich habe meine Hausarbeiten gemacht und Morgen gegen 17 Uhr schicke Ich das 32 Modul zur Prüfung ...... Hoffe es ist alles richtig und man kann die ersten Platinen bestellen.........

 

die 32 Kanal Version zieht sicherlich einen kompletten Neubau Nachsich oder?