Zündkoffer

moin

tja silvester war grad erst und da ist ein freund und ich auf die idee gekommen einen zündkoffer für feuerwerk zu baun der per pc gesteuert werden kann. dabei übernimmt er das bauen von dem teil (elektrotechnik student ) und ich die programmierung ( technische informatik student aber halt noch ganz am anfang ^^). da ich sowas noch nie gemacht habe hab ich da erstmal zwei fragen 😉

1. ist c# dafür überhaupt geeignet oder sollte ich doch lieber c++ verwenden ?

2. welche schnittstelle ist dafür am besten ? also ich denk zb usb hat heute jeder mensch aber ist das auch für sowas geeignet ?

hallo

habt ihr euch denn bereits überlegt, welche art kommunikation ihr anstrebt? soll sie uni- oder bidirektional sein (d.h. die zündbox gibt antwort)?

um einfach ein paar pegel high oder low zu schalten empfehle ich dir die verwendung der parallelen schnittstelle (wenns sowas überhaupt noch gibt an deinem pc)...

eine einfache serielle kommunikation würde die rs232-schnittstelle anbieten, wobei ich mir ziemlich sicher bin, dass die beim 1.1 vergessen wurde und erst in der 2.0 enthalten ist... es gibt aber bestimmt klassenbibliotheken zu diesem thema...

wenns ein wenig anspruchsvoller sein soll empfehle ich dir eine ethernet-kommunikation, da gibts in c# fertige klassen für... auf der hw-seite müsste dann allerdings auch ein ethernet-controller verbaut werden...

mit usb habe ich noch nichts gebaut, ich denke aber, dass der aufwand hierfür eher hoch ist. realtime-anwendungen sind mit beiden (ethernet und usb) nicht möglich d.h. mit ethernet mittlerweile schon, aber dies sind kommerzielle projekte und da kommt man nicht so leicht ran...

gruss

Ethernet, Usb, Seriell... Warum nicht wireless per Bluetooth? Braucht halt weng Einarbeitungszeit aber das ist ja bei allem so.

Zu 1. C# ist schon geeignet, dein System soll ja schließlich keine hohe Performance anstreben oder?

Zu 2. Also wie schon gesagt schlage ich Bluetooth vor. Nen stick für den PC bekommt man ja schon für ca 8 euro bei eBay

Ob C# oder C++ spielt wohl keine Rolle, aber ich denke Windows ist für die Aufgabe nicht geeignet. Bei professionellem Feuerwerk muss die Genauigkeit der Zündvorgänge wohl deutlich höher sein (schätze mal 10 ms), als das was Windwos bringen kann. Da braucht ihr ein Echtzeitbetriebssystem.

10/1000 Sekunden Genauigkeit sollte auch für win kein Problem sein.
Für MicroSekunden(nicht Millisekunden) und feste Interrupt und Antwortzeiten sollte man ein Echtzeitbetriebssystem nehmen. Verlässlichkeit(im Timing) ist dort oft wichtiger!

Hallo Quallo,

10/1000 Sekunden Genauigkeit sollte auch für win kein Problem sein.

Da würde ich aber Svenson recht geben. Es geht ja nicht darum, dass Windows nicht in solchen Zeitintervallen arbeitet, das tut es. Es geht aber darum, dass genau nach 'Befehl absenden' und Pegel hoch reißen an der Schnittstelle nur maximal solch ein Intervall vergehen darf.

Und das tut es bei Windows in den seltensten Fällen 😉 Da macht Windows immer irgendwas zwischendrin...

Ciao
Norman-Timo

Schlimmer, in Windows NT+ sind die Latenzzeiten generell unbeschränkt. Ein Hardwareinterrupt (z.B. von einer Netzwerkkarte) kann zu einer beliebig langen Zeit führen, in der kein Prozesswechsel stattfindet (das Verhalten kennt jeder Windows-Nutzer, manchmal "steht" Windows für spürbare Zeit). In dieser Zeit kann natürlich auch keine Steuerung stattfindet. Das kann man nicht einmal dadurch beheben, dass man die Funktion in den Kernel-Mode verlegt.

Generell gilt:

1. Die Zykluszeit ist im Schnitt jenseits der 20 ms Marke (typischerweise zwischen 5 und 150 ms).

2. Man kann nicht davon ausgehen, dass es eine Mindestzeit gibt, in der ein Prozess drankommen MUSS.

Damit disqualifiziert sich Windows sogar für "weiche Echtzeit".

Bestenfalls kann man statistische Aussagen machen wie: "Zu 99% wird dieses Ereignis im Zeitraster X ausgelöst."

Merke: Ohne Echtzeit-Erweiterung ist Windows für Steuerungsaufgaben völlig ungeeignet (es sei denn, auf Zuverlässigkeit wird keinen Wert gelegt).

Man sollte dann besser auf Systeme wie Windows CE, QNX oder eben Echtzeit-Erweiterungen für Windows ausweichen, die die Steuerung völlig seperat von WIndows ablaufen lassen. Der Vorteil ist hier, dass man wenigstens die Oberfläche noch mit Windows machen kann.

Vor einiger Zeit kam mal so nen Vertreter von so nem Osziloskophersteller bei uns auf Arbeit vorbei und wollt neue Geräte vorstellen. Er stellt des Ding auf, macht es an und es bootet erstmal WinXP Embedded 😁

Wir haben schon bissle ungläubisch geschaut, aber wie Svenson schon gesagt hatte. Das ganze Messen findet in Hardware statt, Windows stellts nur dar.

Aber jederzeit wieder, des Ding war so geil von der Bedienung, konntest per Touchscreen Hüllkurven für den Trigger zeichen, also komfortabler gehts kaum.
Hatte selbst für nen Durchschnittspc ne ganz ordentliche Ausstattung, haben sogar ne Runde Solitär drauf gezockt 😉

Und zum eigentlichen Projekt. Für mich hörte es sich eher so an als wenn es darum geht, überhaupt vom PC aus gesteuert Feuerwer abzuschießen. Nicht um ein großes Effektfeuerwerk was großartig getimt werden muss. Und wenn die Anforderungen wirklich nicht so hoch sind, ist die Schnittstelle ja fast egal und es bietet sich die Möglichkeit auch mit .Net zu arbeiten.

Okay, in deinen weiteren Ausführungen gebe ich dir natürlich recht.
Nur wenn ich mal schaue, dass ich problemlos Daten mit ping im 1 ms bereich versenden kann, muss es meines Erachtens möglich sein, dass das Ansprechen eines seriellen Ports fast(!!!) immer in einer geringen Zeit klappt, nur halt nicht zu 100 % zuverlässig.

Aber ohne Programme im Hintergrund sollte das klappen.

Weiß jemand, wie das mit Mono unter Linux oder mac aussieht?

Grüße, Christoph

danke für die große beteiligung 😉 und wie talla schon geschrieben hat geht es wirklich nur um ein kleines feuerwerk für private zwecke 😉 die idee mit dem bluetooth gefällt mir sehr gut und werden uns das auf alle fälle näher anschaun.