Hallo liebes Forum, ich grübel gerade über etwas. Ich weiß, es gibt so viel über Porterweiterungen, aber dieses Thema ist vielleicht neu - und wenn nicht, seit nicht böse sondern gebt mir nen Link... Nehmen wir an, ich bräuchte 128 Eingänge und 64 Ausgänge. Nun nehme ich einen Atmega32 oder Raspberry GPIO. Dahinter kaskadiere ich OUT mit (von mir aus 74HC595) und kaskadiere IN (vielleicht über 74HC165). Stellen wir uns folgendes vor, nur zum Problem: Wir haben 64 Tasten und 64 Lampen. Wenn ich eine oder mehrere Tasten berühre, dann gehen die entsprechenden Lampen an. Aber die gehen nur an, wenn gewisse Tasten zusammen gedrückt und andere nicht gedrückt sind, also: Logikcheck. Ich möchte aber wissen, zum Beispiel, ob die Lampe überhaupt angehen konnte, weil OUT da war, also koppel ich zurück auf 64 IN, Sicherheitscheck. Jetzt zum Algorithmus: 0. Systemzustand checken 1. Eingänge checken 2. Eingänge logisch bearbeiten 3. Ausgänge belegen 4. Ausgänge checken 5. zurück zu 0. Dies erscheint mir sehr logisch vom Ablauf her. Aber wenn ich mir meine leider geringe Praxis anschaue, bin Neuling... Mir grummelt da der Bauch, das kann nur schief gehen... von Zustand 2. bis 4. ist 1. unbeobachtet. Nur so aus Spaß habe ich versucht, 2 Tasten zu kontrollieren, und dachte, juhu, mit Raspberry nutze ich den Interrupt. Aber das kann man ja wohl knicken bei sehr vielen IN OUT. Zuerst: Wie würdet ihr dieses Problem in den Griff bekommen? Bevor... ... ich euch mit meiner Idee überfahre, die mir im wahrsten Sinne des Wortes logisch vorkommt... wie wäre es, wenn man alle "Tasteneingänge" mit einem logischen Baustein verbindet, der sich die "Tastendrücke" merkt, anstelle des direkten Kontaktes mit der z.B. 74HC165? Dann in Ablauf 0. werden die Dinger einfach resettet? Danke für Eure Gedanken! LG, Jens
Für so etwas wie viele LEDs und Tasten kann man ggf. eine Matrixschaltung nutzen. Da kann man etwa über 3 mal 8 IO Ports 64 LED Schaltung und 64 Tasten einlesen. So etwas wie Tasten ließt man in der Regel periodisch ein (z.B. im Timer Interrupt) - das gibt einem dann auch gleich die Entprellung.
Ich würde über die I²C-Schnittstelle gehen. Es gibt Bausteine mit, soweit mir bekannt, bis zu 16 I/O-Ports. Das ist relativ Komfortabel zu behandeln und kaskadierbar.
Danke aber nein, es geht um etwas wirklich großes. Ein System, was besteuert und gelesen wird. Das System als solches ist nicht relevant, es könnte sich um eine komplette Haussicherung handeln. Es geht um das Prinzip. LG, Jens
Sebastian S. schrieb: > Ich würde über die I²C-Schnittstelle gehen. > Es gibt Bausteine mit, soweit mir bekannt, bis zu 16 I/O-Ports. > Das ist relativ Komfortabel zu behandeln und kaskadierbar. Danke aber ich brauche viel viel mehr! LG, Jens
Dann nimm kein Spielzeug sondern eine richtige Lösung. Es gibt genug MCUs mit 144 Pins.
> Danke aber ich brauche viel viel mehr!
Die Teile kann man wie bereits gesagt kaskadieren und wenn Dir 128
Dingsbümser nicht reichen - der Bus ist relativ einfach gestrickt -
verdopple ihn einfach (ein el. Schalter mit einer Richtung und einer mit
zweien).
J. W. schrieb: > Danke aber nein, es geht um etwas wirklich großes. Ein System, was > besteuert und gelesen wird. bei vielen IOs ist Matrixansteuerung absolut gängig, weil sehr effizient. Erkläre genau warum das bei Dir nicht gehen soll.
hört sich nach ner guten Anwendung für einen FPGA an. Und sollte sich auch gut als Anfängerprojekt eignen. Einer in einem 144 Pin TQFP dürfte aber wohl zu klein sein und die mit mehr sind dann alle BGAs. Aber evtl findet sich ein passendes, fertiges Board, welches genügend Anschlüssen nach Außen geführt hat. Dann ist auch Spannungsversorgung etc. schon fertig und (sollte) funktionieren. Natürlich kann man in einem 144 Pinner auch noch einfach eine Matrixansteuerung mit rein Implementieren.
:
Bearbeitet durch User
J. W. schrieb: > 0. Systemzustand checken > 1. Eingänge checken > 2. Eingänge logisch bearbeiten > 3. Ausgänge belegen > 4. Ausgänge checken > 5. zurück zu 0. > > Dies erscheint mir sehr logisch vom Ablauf her. Sicher. SPS arbeiten so ähnlich. Kann man natürlich so oft neu erfinden, wie man will.
Wo genau ist denn jetzt das Problem? Die Frequenz des seriellen Busses muss halt entsprechend hoch sein, damit du zuverlässig deine Tasten erkennen kannst. Was meinst du mit "Out checken"? Willst du alle Ausgänge nochmals separat einlesen? Also am einfachsten macht man das wirklich mit einem Controller der einfach ein paar mehr GPIOs hat (z.B. STM32F407 auf dem STM32F4Discovery, welcher schon 140 nutzbare IOs hat), dann musst du auch kein Grab an Schieberegister dranhängen. Ansonsten einfach schnell genug schieben, aber ich glaube ich hab dein Problem nicht verstanden
Gerd E. schrieb: > J. W. schrieb: >> Danke aber nein, es geht um etwas wirklich großes. Ein System, was >> besteuert und gelesen wird. > > bei vielen IOs ist Matrixansteuerung absolut gängig, weil sehr > effizient. > > Erkläre genau warum das bei Dir nicht gehen soll. Nein, bitte umgekehrt: Wie kann ich den oben angegebenen Algorhitmus durchführen? Ich brauche 2n Eingänge, es können auch 256 sein, aber davon sind nur 128 "parallel" und müssen registriert werden, während diese dann logisch verarbeitet werden müssen, wonach die Outputs logisch geschaltet werden, wonach die Outputs geprüft werden... Ich kenne mich da nicht aus, das ist für mich doch keine Matrix sondern völlig getrennte Vektoren: Input1, Output, Input2?
Was ist denn dein Problem? Das ganze funktioniert doch ganz einfach: Am Eingang 2^n mal schieben/takten bis alle deine Daten Eingänge gelesen sind. Deine Logik ausführen und dann 2^m schieben und ausgeben. Das ganze sollte eben so schnell sein, dass du alle 20ms neue Daten hast damit deine Taster noch entprellen kannst... Wenn du unbedingt einen definierten Zeitpunkt für das Erfassen der Eingänge haben möchtest nimmst du eben den 74HC597, welcher im Gegensatz zum 74HC165 D-FlipFlops an den Eingängen hat
:
Bearbeitet durch User
J. W. schrieb: > das ist für mich doch keine Matrix sondern > völlig getrennte Vektoren: Input1, Output, Input2? Was genau soll Input2 sein? Musst du die Ausgänge physikalisch zurücklesen über Eingänge, ob sie auch so geschaltet haben wie Output vorgibt? Und was soll passieren, wenn das einmal nicht der Fall ist? Georg
Matthias K. schrieb: > Das ganze > sollte eben so schnell sein, dass du alle 20ms neue Daten hast damit > deine Taster noch entprellen kannst... Es kann auch 200 ms sein, dann bekommt man das Prellen gar nicht mit. O.K. ganz eilige könnten sich beschweren, dass das ding nicht reagiert. Ein Schieberegister geht bis einige MHz, bei 128 bit und 20 ms kommt man auf 6,4 kHz das schaft ein AVR locker
Man legt sich die Ports intern im RAM als Schattenregister an. Und per DMA werden dann alle 10ms die Ausgänge rausgeschrieben und gleichzeitig die Eingänge eingelesen. Die ganze Verarbeitungslogik erfolgt dann in den Schattenregistern.
J. W. schrieb: > Gerd E. schrieb: >> J. W. schrieb: >>> Danke aber nein, es geht um etwas wirklich großes. Ein System, was >>> besteuert und gelesen wird. >> >> bei vielen IOs ist Matrixansteuerung absolut gängig, weil sehr >> effizient. >> >> Erkläre genau warum das bei Dir nicht gehen soll. > > Nein, bitte umgekehrt: Wie kann ich den oben angegebenen Algorhitmus > durchführen? Ich brauche 2n Eingänge, es können auch 256 sein, aber > davon sind nur 128 "parallel" und müssen registriert werden, während > diese dann logisch verarbeitet werden müssen, wonach die Outputs logisch > geschaltet werden, wonach die Outputs geprüft werden... Ja. Und? > Ich kenne mich da nicht aus, das ist für mich doch keine Matrix sondern > völlig getrennte Vektoren: Input1, Output, Input2? Du vermischst hier die logische und die physikalische Ebene. Die Tasten deiner Tastatur sind z.B. auch als Matrix verschaltet. Trotzdem "sieht" der Tastaturcontroller die Tasten logisch als einen langen Vektor von Bits. Auf der Programmseite wird sowas typischerweise dadurch gelöst, daß man die logischen Zustände in geeignete Datenstrukturen stopft (z.B. C structs) und Ein- und Ausgabe in Funktionen packt. Der logische Kern des Programms operiert ausschließlich auf den Datenstrukturen. Die Funktionen für Ein- und Ausgabe müssen natürlich auf die real vorhandene Hardware angepaßt werden. Für eine Matrix-Tastatur würde die Eingabefunktion dann die Matrix einmal abscannen und den Zustand jeder einzelnen Taste in der entsprechenden Datenstruktur ablegen.
Possetitjel schrieb: >> Dies erscheint mir sehr logisch vom Ablauf her. > > Sicher. SPS arbeiten so ähnlich. > > Kann man natürlich so oft neu erfinden, wie man will. Ja, Du hast es, nur ist SPS nicht gerade billig und ich möchte halt gerne mit einem Raspberry arbeiten.
Matthias K. schrieb: > Was ist denn dein Problem? > > Das ganze funktioniert doch ganz einfach: > > Am Eingang 2^n mal schieben/takten bis alle deine Daten Eingänge gelesen > sind. > Deine Logik ausführen und dann 2^m schieben und ausgeben. Das ganze > sollte eben so schnell sein, dass du alle 20ms neue Daten hast damit > deine Taster noch entprellen kannst... > > Wenn du unbedingt einen definierten Zeitpunkt für das Erfassen der > Eingänge haben möchtest nimmst du eben den 74HC597, welcher im Gegensatz > zum 74HC165 D-FlipFlops an den Eingängen hat Ja, aber genau das verstehe ich nicht: Nehmen wir an, ich nehme einen 74HC165, wenn ich die Eingänge prüfe, also parallel die Eingänge habe und nun seriell die Werte abarbeite, ist das dann beim 74HC165 der in genau diesem Moment der Abfrage vorliegende Spannungswert? Also muss ich softwaremäßig mehrmals abfragen um zu entprellen? Wenn ich stattdessen den mir sehr sympathischen 597er nehme, dann habe ich die D-FlipFlops. Sehr symphatisch, weil - und ich habe halt keine Erfahrung - ich irgendwelche Tasten drücke, der 597er sich das merkt, und ich völlig entspannt in meiner Gänseblümchenwelt die Ports abfrage. Also, nochmal, sorry für meine Anfängerfragen und wenn ich einige eurer Antworten nicht verstehe, aber: Ist das denn nun von Vorteil? Wann schaltet der 597er? Wenn mal irgnendein winziges Signal auf IN liegt? Oder ist das "automatische Entprellung"? Ich suche fertige Platinen für den Raspberry Pi. Es gibt eine für serial in parallel out mit 595ern, ein Kumpel könnte die umlöten für serial out parallel in mit 597er. Kostet 9 Euro die Platine plus 4 * 597er, ein Witz. Ich kümmer mich um die Programmierung und auch ich möchte das angeblich unmögliche Max-Max-Prinzip: Maximal preiswert, maximal einfach... Danke und ich bitte um Geduld!
:
Bearbeitet durch User
J. W. schrieb: > Ich kümmer mich um die Programmierung und auch ich möchte das angeblich > unmögliche Max-Max-Prinzip: Maximal preiswert, maximal einfach... "Das kannste schon so machen, aber dann wirds halt Scheisse"
J. W. schrieb: > Wann schaltet der 597er? Für den Anwender ist der 597 völlig gleich mit dem 165. Der einzige Unterschied, den 597 kann man schon neu laden, wärend er die Daten noch seriell rausschiebt. Beim 165 muß das Schieben beendet sein vor dem Laden. In der Praxis hat dieser Unterschied keinerlei Auswirkungen.
Peter D. schrieb: > J. W. schrieb: >> Wann schaltet der 597er? > > Für den Anwender ist der 597 völlig gleich mit dem 165. > Der einzige Unterschied, den 597 kann man schon neu laden, wärend er die > Daten noch seriell rausschiebt. Beim 165 muß das Schieben beendet sein > vor dem Laden. In der Praxis hat dieser Unterschied keinerlei > Auswirkungen. Oh shit. Das ist ja ein Flipflop. Das heißt er wabbelt trotzdem zwischen den Zuständen, der ist ja bi-stabil, der rastet ja gar nicht ein auf "Taste gedrückt", richtig? Der rastet zwar ein aber das ist nichts anderes als ein Zwischenspeicher...
Aber wie wäre es mit einem Parallel In Serial Out der automatisch entprellt? Also, gibt es einen günstigen Gänseblümchen 165er Ersatz, der bei "zappel" Schwankungen nicht schaltet, sondern erst bei stabilen Spannungen reagiert? Und zwar ein Schieberegister? Nur so aus Neugierde, ohne vorgeschaltete ICs oder Analogtechnik? Klar, jetzt kann das Argument kommen, Moment mal, was ist normal, das ist doch Definitionssache, aber ich meine einen miesen Taster. Schwierig zu definieren, klar....
Dein Problem ist leider nicht gerade leicht verständlich formuliert. Es wäre schön, wenn du dein Anliegen besser strukturierst und einen klareren Kontext gibst, wo du die Probleme bei der Umsetzung siehst. Dir ist wahrscheinlich nicht klar, dass das Lesen der Eingänge und das Setzen der Ausgänge über SPI sehr schnell geht. Wenn sich in der kurzen Zeit zwischen dem Erfassen der Eingänge und dem Setzen der Ausgänge etwas ändert, wird das natürlich nicht sofort erfasst, sondern erst beim nächsten Zyklus. Das ist aber unwahrscheinlich, da das Auslesen und Setzen wirklich sehr schnell abläuft. Von einer Matrixschaltung rate ich dir ab. Das macht man zwar so, aber du scheinst schon mit deutlich einfacheren Dingen Schwierigkeiten zu haben, da muss man die Sache nicht unnötig verkomplizieren. Ein 8-Bit-Schieberegister kostet um die 30 cent, für die Ausgänge brauchst du 8 Stück, für die Eingänge brauchst du 16 Stück. Das sind 7.20 Euro, das ist verschmerzbar. Natürlich kann man das auch für unter einen Euro hinkriegen, dann bist du aber damit beschäftigt, das Programm so anzupassen, dass auch alles richtig ausgelesen und gesetzt wird. Falls möglich, nimm zwei SPI-Busse, einen für die Eingangs- und einen für die Ausgangsregister. Dann kannst du beim Eingangsbus den Status einlesen und beim Ausgangsbus den Status rausschreiben, ohne dich um andere Dinge kümmern zu müssen.
Ich glaube, der TO weiss noch nicht, wie das mit der Matrix gemeint ist. Siehe: https://upload.wikimedia.org/wikipedia/commons/0/0e/FunctionalCircuitDiagramOfKeyboardNumPadScanningProcedure.gif Mit 16 IOs kannst du eine 8x8 Matrix aufbauen, mit der du ohne grossen Aufwand 256 Taster einlesen kannst (beliebig skalierbar). Ich rate zu Schieberegistern. Die kosten zwar was, aber die Umsetzung ist dafür einfacher als bei einer Matrix. Einfach Bitstream rein/raus und fertig.
someone schrieb: > Dein Problem ist leider nicht gerade leicht verständlich formuliert. > Es wäre schön, wenn du dein Anliegen besser strukturierst und einen > klareren Kontext gibst, wo du die Probleme bei der Umsetzung siehst. > Ich habe es absichtilich so abstrakt formuliert, damit keine Ideen-Spirale entsteht, wie dann wohl wann was belastet wird. Das System liefert mir Informationen. Ganz einfache Impulse. Ich habe den Verlauf doch dargestellt. Ich benutze doch gerade deshalb Abstraktion, damit klargestellt ist: Das System muss nichts anderes tun als Signale korrekt zu verwerten und auszugeben. > Dir ist wahrscheinlich nicht klar, dass das Lesen der Eingänge und das > Setzen der Ausgänge über SPI sehr schnell geht. Wenn sich in der > kurzen Zeit zwischen dem Erfassen der Eingänge und dem Setzen der > Ausgänge etwas ändert, wird das natürlich nicht sofort erfasst, sondern > erst beim nächsten Zyklus. Das ist aber unwahrscheinlich, da das > Auslesen und Setzen wirklich sehr schnell abläuft. > Da hast Du recht, das ist mir nicht klar. Aber ich will halt möglichst viel Sicherheit im System. Ich möchte halt Schrottsignale per hardware filtern, dann Sicherheit per Softwareentprellung, und dann kommt das Feedback der Komponenten. Das ist Standard bei SPS, auf die ein Kommentator hier verwies. > Von einer Matrixschaltung rate ich dir ab. Das macht man zwar so, aber > du scheinst schon mit deutlich einfacheren Dingen Schwierigkeiten zu > haben, da muss man die Sache nicht unnötig verkomplizieren. Ich weiß nicht, wie ich das interpretieren soll, aber scheinbar ist die Matrix ominös. > Ein 8-Bit-Schieberegister kostet um die 30 cent, für die Ausgänge > brauchst du 8 Stück, für die Eingänge brauchst du 16 Stück. Das sind > 7.20 Euro, das ist verschmerzbar. Ein Output-Board für den Rasperry-Pi kostet 9 Euro, 32 Pins kaskadierbar. Ich brauche eins für den Input.
J. W. schrieb: > Ich möchte halt Schrottsignale per hardware > filtern, Dann bau dir 128 Hardwarefilter vor die 128 Eingänge, die das filtern, was du als Schrott definierst. J. W. schrieb: > dann Sicherheit per Softwareentprellung, Dann schreib eine Softwareentprellung in deine Software. J. W. schrieb: > und dann kommt das > Feedback der Komponenten. Genau. Um die schon mehrfach geäußerte Frage zu wiederholen: Wo ist das Problem? Und bevor du hier weiter an Problemen herumtheoretisierst, die es gar nicht gibt (und dafür die noch gar nicht kennst, die kommen werden), fang doch einfach an. Denn J. W. schrieb: > bin Neuling... ist ja nichts schlimmes, aber alleine durch theoretisieren ohne Hintergrund wird sich das nicht ändern. Nimm dir deinen Raspi, häng zwei Tasten dran, eine Lampe, und die zurück an eine feedback-Eingang, und dann schreib einfach mal ein Programm, bei dem die Lampe nur angeht, wenn beide Tasten gerückt sind. Oliver
Oliver S. schrieb: > J. W. schrieb: > > Um die schon mehrfach geäußerte Frage zu wiederholen: > Wo ist das Problem? Es geht mir als Theoritker, hast Recht, darum, den Problemkreis quasi erst einmal zu sondieren, zu studieren. > Und bevor du hier weiter an Problemen herumtheoretisierst, die es gar > nicht gibt (und dafür die noch gar nicht kennst, die kommen werden), > fang doch einfach an. Ich bin halt Theoretiker, ja, aber das hat auch Vorteile, finde ich. > Nimm dir deinen Raspi, häng zwei Tasten dran, eine Lampe, und die zurück > an eine feedback-Eingang, und dann schreib einfach mal ein Programm, bei > dem die Lampe nur angeht, wenn beide Tasten gerückt sind. > Wie definierst Du, das beide Tasten gleichzeitig gedrückt sind? Wenn du dich mit annähernd Lichtgeschwindigkeit an den Tasten vorbeibewegst... ach egal ;) Alles gut, ich jammer schon früh genug.
J. W. schrieb: > Ich habe es absichtilich so abstrakt formuliert, damit keine > Ideen-Spirale entsteht, wie dann wohl wann was belastet wird. Das System > liefert mir Informationen. Ganz einfache Impulse. Ich habe den Verlauf > doch dargestellt. Ich benutze doch gerade deshalb Abstraktion, damit > klargestellt ist: Das System muss nichts anderes tun als Signale korrekt > zu verwerten und auszugeben. Die Frage ist wie schnell und wie sauber sind die Impulse. Daraus ergibt sich, wie viel Aufwand man treiben muss. Werden die "Taster" durch Menschen gedrückt? Dann ist der RPI schnell genug, dass zu machen. Kommen die Signale mit deutlich höherer Frequenz geht es irgendwann nicht mehr. Du hast irgendwie noch nicht verstanden, wie schnell so eine Datenübertragung stattfindet. Du hast angst davor, dass wenn man seriel einließt das Signal sich schon geändert hat, bevor alle Daten gelesen wurden. Mit deinen Fingern kannst du aber gar nicht so schnell drücken, wie der RPI lesen kann. Ob du wirklich einen Hardwarefilter bauen möchtest, solltest du nochmal überlegen. Auch ob es wirklich notwendig ist, die Ausgänge zu überwachen. Wenn du davon ausgehst, dass das sicherheitsrelevant ist, solltest du bei deinem Kenntnisstand die Finger davon lassen und eine SPS nehmen. Das ist noch ein bisschen mehr drin, als du denkst.
J. W. schrieb: > Wie definierst Du, das beide Tasten gleichzeitig gedrückt sind? Wenn du > dich mit annähernd Lichtgeschwindigkeit an den Tasten vorbeibewegst... > ach egal ;) Genau dass macht ein µC. Er guckt für einen Takt ob Spannung am Eingang anliegt (Strom vließt mit annähernd Lichtgeschwindigkeit) und schreibt das Ergebnis in ein Register. Damit kannst du dann weiterarbeiten.
J. W. schrieb: > Wie definierst Du, das beide Tasten gleichzeitig gedrückt sind? Ich? Gar nicht. Das ist dein Projekt, nur du kennst die Anforderungen, also wirst du das definieren müssen. Und die Definition dann in Software umsetzen. Das bringt dich unweigerlich zur nächsten Frage: Wann ist EINE Taste gedrückt ? Sich vorab Gedanken zu machen ist prima. Aber selbstausgedachte Probleme zu lösen bringt dich nicht weiter. Fang lieber an, und löse die aufkommenden Probleme. Das ist bei deinem Kenntnisstand zielführender. Oliver
Karl schrieb: > Ob du wirklich einen Hardwarefilter bauen möchtest, solltest du nochmal > überlegen. Auch ob es wirklich notwendig ist, die Ausgänge zu > überwachen. Wenn du davon ausgehst, dass das sicherheitsrelevant ist, > solltest du bei deinem Kenntnisstand die Finger davon lassen und eine > SPS nehmen. Das ist noch ein bisschen mehr drin, als du denkst. Danke für die Warnung, aber es geht mir doch gerade darum abzuschätzen, wie weit ich mit dem System kommen kann. Mit ziemlicher Sicherheit wird eine SPS eingebaut. Und nun? Ja, meine Kenntnisse sind nicht überwätigend, aber es geht um simple Logik. Diverse Bauteile werden ein "GO!" liefern oder ein "FAIL!". Ich prüfe gerade für mich, wie das zum Beispiel mit dem Rasp möglich ist. Ich habe doch, glaube ich, estra betont, dass das gerade die Basis für ein Experiment liefert. Das ist Theorie! In der Erprobung werde ich schon noch genug jammern! LG
Du hast immer noch nicht gesagt, wie schnell es den nun sein soll. Damit hat sich alles weitere erübrigt. J. W. schrieb: > Diverse Bauteile werden ein > "GO!" liefern oder ein "FAIL!". Ich prüfe gerade für mich, wie das zum > Beispiel mit dem Rasp möglich ist. So lange niemand weis wie ein "GO!" oder "FAIL!" aussehen soll, wird dir auch keiner helfen können. Anstatt mit Bullshit-Bingo solltest du dich mal mit Fachwörtern beschäftigen. Das fängt schon beim Titel des Threads an. "Massive IO Porterweiterung - Stabilität des IO" Wenn es massiv werden soll, würde ich Blei empfehlen, dass ist ziemlich massiv. Wenn die Stabilität nicht ausreicht, kann man Stahl nehmen, der lässt sich aber nicht so gut Verarbeiten. Damit wäre deine Frage geklärt. Für ein mikrocontroller.net Thread wurdest du ziemlich lange ziemlich nett behandelt.
J. W. schrieb: > Wenn ich eine oder mehrere Tasten berühre, dann gehen die > entsprechenden Lampen an. Aber die gehen nur an, wenn gewisse Tasten > zusammen gedrückt und andere nicht gedrückt sind Das soll wohl heißen, Du hast ein Hardwareproblem. Die SPI-Leitungen sind sehr störempfindlich, weil die HC-Logik sehr schnell ist (>20MHz). SPI-Leitungen sollte die Platine nicht verlassen und GND-Plane, Abblock-Cs sind Pflicht. Falls SPI die Platine doch verlassen soll, dann differentiell (RS-485 Transceiver). Alles andere kann funktionieren, ist aber trotzdem Pfusch. Ich hab schon mehrere SPI-Implementierungen hinter mir, die neueren laufen alle rock-solid. Die ersten Versuche wollen wir lieber vergessen. Auch die Würg-Arounds mit RC-Gliedern und Schmitt-Trigger.
Ich empfehle dir, dein Problem nochmal zu überdenken. J. W. schrieb: > someone schrieb: >> Dein Problem ist leider nicht gerade leicht verständlich formuliert. >> Es wäre schön, wenn du dein Anliegen besser strukturierst und einen >> klareren Kontext gibst, wo du die Probleme bei der Umsetzung siehst. >> > Ich habe es absichtilich so abstrakt formuliert, damit keine > Ideen-Spirale entsteht, wie dann wohl wann was belastet wird. Das System > liefert mir Informationen. Ganz einfache Impulse. Ich habe den Verlauf > doch dargestellt. Ich benutze doch gerade deshalb Abstraktion, damit > klargestellt ist: Das System muss nichts anderes tun als Signale korrekt > zu verwerten und auszugeben. Abstraktion ist schön und gut, aber du musst dich mit der konkreten Sache gut genug auskennen, um sinnvoll abstrahieren zu können. Du denkst, dass du abstrahierst, leider gehen dabei bei dir wichtige Informationen verloren, die man zur Bewertung deines Problems und möglicher Lösungsansätze bräuchte. Dass du darüberhinaus auch noch fest auf irgendeine Art der Lösung eingefahren bist, die du uns aber nicht verraten willst, macht die Sache nicht einfacher. Es ist kein Problem, wenn du dich nicht auskennst, aber dann sei bitte so gut und entscheide dich: Willst du vernünftige Hilfe bei Bauteilauswahl und Implementierung, so konkretisiere dein Problem. Willst du wissen, ob dein abstraktes Problem mit deiner Auswahl von Bauteilen funktioniert, teile uns die Bauteilauswahl und Verschaltung mit. Du hast übrigens wichtige Daten zu den "ganz einfachen Impulsen" nicht genannt. Wie schnell, wie häufig, wie lang? Daran sieht man leider schon, dass du ziemlich wenig Ahnung hast. Das ist kein Problem und viele Leute helfen gerne, aber dann tu bitte nicht so, als hättest du das alles gar nicht nötig. >> Dir ist wahrscheinlich nicht klar, dass das Lesen der Eingänge und das >> Setzen der Ausgänge über SPI sehr schnell geht. Wenn sich in der >> kurzen Zeit zwischen dem Erfassen der Eingänge und dem Setzen der >> Ausgänge etwas ändert, wird das natürlich nicht sofort erfasst, sondern >> erst beim nächsten Zyklus. Das ist aber unwahrscheinlich, da das >> Auslesen und Setzen wirklich sehr schnell abläuft. >> > Da hast Du recht, das ist mir nicht klar. Aber ich will halt möglichst > viel Sicherheit im System. Ich möchte halt Schrottsignale per hardware > filtern, dann Sicherheit per Softwareentprellung, und dann kommt das > Feedback der Komponenten. Das ist Standard bei SPS, auf die ein > Kommentator hier verwies. Was ist ein Schrottsignal? Was heißt Sicherheit im Kontext deiner Anwendung? Was sind die Fehlersituationen, die du abfangen willst? Und nein, "ich will, dass der Pin schaltet, wenn ich ihm das sage" ist keine sinnvolle Spezifikation. Was passiert bei Ausfall einer Komponente? Was passiert bei Softwareabsturz? Herrschen für Einschalten andere Timing-Vorgaben als für Ausschalten? >> Von einer Matrixschaltung rate ich dir ab. Das macht man zwar so, aber >> du scheinst schon mit deutlich einfacheren Dingen Schwierigkeiten zu >> haben, da muss man die Sache nicht unnötig verkomplizieren. > > Ich weiß nicht, wie ich das interpretieren soll, aber scheinbar ist die > Matrix ominös. Eine Matrix für Ein- und Ausgänge ist die offensichtliche Lösung. Sie ist kostengünstig, erweiterbar und bewährt. Leider benötigt man dafür etwas Hirnschmalz, um die Ansteuerung der Zeilen- und Spaltentreiber zu programmieren und nachher die Signalauswertung umzusetzen. Aufgrund deiner bisherigen Beiträge kann dir davon nur abgeraten werden, da du nicht den Eindruck machst, irgendeinen Teil des Projekts bereits durchdrungen zu haben: Weder bei Hardware noch bei Software habe ich das Gefühl, dass du genau weißt, was du tust. Daher empfehle ich die möglichst einfache Lösung, wenngleich diese teurer ist als notwendig. >> Ein 8-Bit-Schieberegister kostet um die 30 cent, für die Ausgänge >> brauchst du 8 Stück, für die Eingänge brauchst du 16 Stück. Das sind >> 7.20 Euro, das ist verschmerzbar. > Ein Output-Board für den Rasperry-Pi kostet 9 Euro, 32 Pins > kaskadierbar. Ich brauche eins für den Input. Ich dachte, du hast 128 Eingänge? Dann brauchst du halt 5 Stück und kannst dir nicht aussuchen, welche Komponenten darauf verbaut sind.
J. W. schrieb: > > Jetzt zum Algorithmus: > 0. Systemzustand checken > 1. Eingänge checken > 2. Eingänge logisch bearbeiten > 3. Ausgänge belegen > 4. Ausgänge checken > 5. zurück zu 0. > > Mir grummelt da der Bauch, das kann nur schief gehen... von Zustand 2. > bis 4. ist 1. unbeobachtet. Da musst du ein FPGA nehmen. Mit einem MC funktioniert das nicht.
J. W. schrieb: > Zuerst: Wie würdet ihr dieses Problem in den Griff bekommen? Ich kann da keinerlei "Problem" erkennen. Viele Eingänge mit vielen Ausgängen zu verknüpfen ist seit vielen Jahren ganz problemlos lösbar. Man nimmt eine SPS. J. W. schrieb: > Ich prüfe gerade für mich, wie das zum Beispiel mit dem Rasp möglich ist. Es ist auch mit einem RPi sicher möglich, so eine SPS aufzubauen. Man muss sich nur ein wenig um das "Echtzeitverhalten" kümmern. J. W. schrieb: > Ja, aber genau das verstehe ich nicht: Nehmen wir an, ich nehme einen > 74HC165, wenn ich die Eingänge prüfe, also parallel die Eingänge habe > und nun seriell die Werte abarbeite, ist das dann beim 74HC165 der in > genau diesem Moment der Abfrage vorliegende Spannungswert? Also muss ich > softwaremäßig mehrmals abfragen um zu entprellen? Du verknotest da mehrere Abstraktionsebenen und willst die alle "in einem Rutsch" erledigen. Das wird sicher schief gehen. Du brauchst einen anderen Ansatz, der dein "Monsterproblem" in kleinere Teilprobleme aufgliedert. Und dann ist das erste davon: die Hardware. Wie bekommst du betriebssicher die Eingänge eingelesen? Die nächste ist : die Signalkonditionierung. Das ist Entprellen, Entfernen von Glitches usw. Das passiert in der Software, denn die kann man leicht updaten. Danach kommt: die Auswertung. Jetzt kannst du deine "logischen Verknüpfungen" mit den aufbereiteten und verlässlichen Signalen auswerten. Und das passiert am Einfachsten ohne Race-Conditions indem du (wie weltweit in zigmillionen SPSen) zyklisch erst alle Eingänge einliest und dann mit diesem statischen "Eingangsabbild" deine Logik ausführst und dann das Ergebnis auf die Ausgänge schreibst. Danach beginnt dieser Zyklus wieder von vorn. Auf keinen Fall(!!!) solltest du im Verlauf des Programms direkt Eingänge abfragen. Bei manchen Geräten, die sich "ab und zu" seltsam verhalten, sehe ich solche Programmierfehler direkt vor mir...
:
Bearbeitet durch Moderator
Ich verweisse mal auf ein anderes Forum... http://www.sps-forum.de/codesys-und-iec61131/68431-codesys-auf-dem-raspberry-pi-jetzt-verfuegbar.html Wobei ich denke, der TO ist auch da etwas überfordert...
> Ich möchte aber wissen, zum Beispiel, ob die Lampe überhaupt angehen > konnte, weil OUT da war, also koppel ich zurück auf 64 IN, > Sicherheitscheck. Moment mal, da die Steuerung darüber entscheidet, wann die Lampen and bzw. aus gehen, kann sie zu jeder Zeit wissen, in welchem Status sich die Lampen-Ausgänge befinden (es sei denn, sie sind defekt). > weil OUT da war Was soll das heissen? Willst du die Existenz eines Anschlusses kontrollieren? Unabhängig davon, kannst du relativ einfach hunderte I/O Anschlüsse mit Hilfe von Schieberegistern realisieren, oder über I2C Bus mit entsprechenden Chips. 8x PCF8574 + 8x PCF8574A ergibt 128 I/O Leitungen. Und mit Hilfe mehrerer I2C Busse (notfalls per Software emuliert) kannst du das beliebig vervielfachen. Um die Stabilität mach Dir mal keine Sorgen. Wenn die Schaltung nicht zuverlässig funktioniert, ist siefehlerhaft. Auf korrekte Schaltungen kannst du dich 99,99999999% verlassen.
Lothar M. schrieb: > J. W. schrieb: >> Zuerst: Wie würdet ihr dieses Problem in den Griff bekommen? > Ich kann da keinerlei "Problem" erkennen. Viele Eingänge mit vielen > Ausgängen zu verknüpfen ist seit vielen Jahren ganz problemlos lösbar. > Man nimmt eine SPS. > > J. W. schrieb: >> Ich prüfe gerade für mich, wie das zum Beispiel mit dem Rasp möglich ist. > Es ist auch mit einem RPi sicher möglich, so eine SPS aufzubauen. Man > muss sich nur ein wenig um das "Echtzeitverhalten" kümmern. > > J. W. schrieb: >> > Du verknotest da mehrere Abstraktionsebenen und willst die alle "in > einem Rutsch" erledigen. Das wird sicher schief gehen. Du brauchst einen > anderen Ansatz, der dein "Monsterproblem" in kleinere Teilprobleme > aufgliedert. > Und dann ist das erste davon: die Hardware. Wie bekommst du > betriebssicher die Eingänge eingelesen? Exakt! Das ist aber nicht mein Problem, dafür wird gesorgt. Ich bekomme ein sicheres "1" für okay und "0" für no-go. > Die nächste ist : die Signalkonditionierung. Das ist Entprellen, > Entfernen von Glitches usw. Das passiert in der Software, denn die kann > man leicht updaten. Das wird mich sicher noch beschäftigen, denn optimal hätte die Hardware natürlich keine Glitches usw. > Danach kommt: die Auswertung. Jetzt kannst du deine "logischen > Verknüpfungen" mit den aufbereiteten und verlässlichen Signalen > auswerten. Und das passiert am Einfachsten ohne Race-Conditions indem du > (wie weltweit in zigmillionen SPSen) zyklisch erst alle Eingänge > einliest und dann mit diesem statischen "Eingangsabbild" deine Logik > ausführst und dann das Ergebnis auf die Ausgänge schreibst. Danach > beginnt dieser Zyklus wieder von vorn. Exakt das möchte ich. > > Auf keinen Fall(!!!) solltest du im Verlauf des Programms direkt > Eingänge abfragen. Bei manchen Geräten, die sich "ab und zu" seltsam > verhalten, sehe ich solche Programmierfehler direkt vor mir... Habe ich nicht vor, auf keinen Fall. Entschuldigung für meine Unkenntnis, an alle, und danke für die Geduld. Du bringst es denke ich auf den Punkt. Wie es schon in anderen produktiven Beiträgen genannt wurde: Es ist im Prinzip die Logik einer SPS. Von der ich zwar auch nicht viel weiß, aber Fakt ist, dass ersichtlich dort extreme Zuverlässigkeit herrscht. Da ich schon mehrmals dafür kritisiert wurde, dass ich nicht konkret genug bin: Es geht um die Ansteuerung eines Verstärkers, mit diversen Endstufen etc. Wenn zum Beispiel eine Endstufe hochgefahren wird (Röhrentechnik), dann bekomme ich erst GO nachdem die Endstufe betriebsbereit ist. Wenn ein Bauteil ausfällt oder von miraus ein Temperaturmelder sagt, hier ist was im Argen!!, dann reagiert mein System. Das ist aber ein elektronisches Ding, um das ich mich nicht kümmer. Es geht um kein Echtzeit-System, da habe ich mich ersichtlich falsch ausgedrückt. Mir geht es nur um viele Inputs und viele Outputs. Gerne dazu weitere Kritik, aber was haltet ihr von Boards mit SPI und zum Beispiel 165 über Optokoppler am Input und dergleichen zum Beispiel über Relais im Output? Die Schaltung, die mir vorschwebt, ist ja im Alghoritmus oben wiedergegeben, ich sehe da erst einmal kein technisches Problem, und die Abfrage kann auch gerne gemäß der Anwendung "recht lange" dauern, genaueres muss ich noch prüfen.. der Teufel steckt im Detail, wie immer... Dennoch, eine grundsätzliche Frage: Einige favorisieren I2C, andere sagen SPI... gibt es da Erfahrungswerte in diesem Bereich, viele In- und Outputs? Mein möglicherweise falsches Grundgefühl sagt mir: Ich kaskadiere einfach mit SPI durch mehrere Bausteine, halt zum Beispiel 4 16bit Input-Platinen... oder was ist nun der Vorteil von I2C? Danke und sorry nochmal!
J. W. schrieb: > Da ich schon mehrmals dafür kritisiert wurde, dass ich nicht konkret > genug bin: Es geht um die Ansteuerung eines Verstärkers, mit diversen > Endstufen etc. Wenn zum Beispiel eine Endstufe hochgefahren wird > (Röhrentechnik), dann bekomme ich erst GO nachdem die Endstufe > betriebsbereit ist. > Wenn ein Bauteil ausfällt oder von miraus ein Temperaturmelder sagt, > hier ist was im Argen!!, dann reagiert mein System. Aha. So ein Blödsinn Was soll denn das für eine Monster-Installation sein, wo du zur Steuerung "eines Verstärkers" 128 Eingänge und 64 Ausgänge brauchst? Warum würde man Dinge wie die Notabschaltung bei Übertemperatur oder Gleichspannung am Ausgang überhaupt über eine zentrale Steuerung machen wollen? Das kann man doch alles (besser) autark machen und bestenfalls den Status an eine Zentrale melden. > Gerne dazu weitere Kritik, aber was haltet ihr von Boards mit SPI und > zum Beispiel 165 über Optokoppler am Input und dergleichen zum Beispiel > über Relais im Output? Vollkommen unsinnig. Potentialtrennung über Optokoppler und Relais macht man dann (und nur dann) wenn man es braucht. Andererseits schreibst du oben "Röhrentechnik". Deine Zielgruppe sind also anscheinend Leute mit wenig Ahnung aber desto mehr Geld. Und dann beruhigt es natürlich dein Gewissen, wenn du ihnen mit Optokopplern wenigstens eine gewissen Gegenwert lieferst. > Die Schaltung, die mir vorschwebt, ist ja im Alghoritmus oben > wiedergegeben Abu Dscha'far Muhammad ibn Musa al-Chwarizmi würde sich im Grabe herumdrehen, wenn er lesen müßte daß du dein Geschwafel oben als "Algorithmus" bezeichnest. > ... eine grundsätzliche Frage: Einige favorisieren I2C, andere > sagen SPI... gibt es da Erfahrungswerte in diesem Bereich, viele In- und > Outputs? SPI ist tendenziell schneller und mit weniger Problemen ausbaubar (keine Beschränkung durch den Adreßraum). Aber in deinem Fall wäre beides Perlen vor die Säue geworfen.
Axel S. schrieb: > J. W. schrieb: > > Aha. *So ein Blödsinn* > Vollkommen unsinnig. Potentialtrennung über Optokoppler und Relais macht > man dann (und nur dann) wenn man es braucht. Andererseits schreibst du > oben "Röhrentechnik". Deine Zielgruppe sind also anscheinend Leute mit > wenig Ahnung aber desto mehr Geld. Und dann beruhigt es natürlich dein > Gewissen, wenn du ihnen mit Optokopplern wenigstens eine gewissen > Gegenwert lieferst. > > > SPI ist tendenziell schneller und mit weniger Problemen ausbaubar (keine > Beschränkung durch den Adreßraum). Danke! > Aber in deinem Fall wäre beides > Perlen vor die Säue geworfen. Immerhin haben Sie in Ihrem Gepöbel eine brauchbare Information geäußert. Genau wegen disem Ihrem peinlichen Gepöbel halte ich es lieber abstrakt, da ansonsten so wie bei Ihnen gleich Bewertungen erfolgen, die aber dem Ziel nicht dienlich sind. Auf Ihre Perlen kann ich aber in Zukunft verzichten. Danke.
Axel S. schrieb: > Aha. So ein Blödsinn Ich kann ja mittlerweile irgendwie schon verstehen, dass Leute ihre Probleme nicht vernünftig beschreiben wollen, wenn sofort nachdem sie es gemacht haben irgendeiner kommt und gleich das Problem niedermacht. Es spielt keine Rolle, ob du es für sinnvoll findest, das Problem zu lösen oder nicht. Der Threadersteller will sich damit beschäftigen, dabei kannst du ihm entweder helfen oder es eben lassen. Zum Problem an sich: Mir ist leider immer noch nicht so ganz klar, um was es nun geht. Schalten über Relais und Rückmeldung über Optokoppler ist sicher, aber natürlich auch sehr langsam. Relais schalten nicht besonders schnell. Außerdem ist die gesamte Beschaltung natürlich auch aufwendig, da du Spulentreiber etc. benötigst. Als Sicherheitsmaßnahme würde ich eher zu Bauteilen raten, die von sich aus die Sicherheit herstellen und keine Softwarelösung benötigen. Software ist immer anfällig. Wenn Überhitzungsgefahr besteht, lieber zusätzlich noch eine Temperatursicherung einbauen als sich 100% auf die Software verlassen. Zur Porterweiterung: I2C-Porterweiterungen sind langsamer, aber flexibler und brauchen nicht die Menge an Anschlüssen. Man kann sie einzeln adressieren und muss daher nicht immer alle auslesen. Für deine Anwendung ist das aber ziemlich egal. Du willst ja immer alles auslesen und (potentiell) alles schalten. Wie bereits erwähnt, empfehle ich dir Schieberegister für den Ausgang und Schieberegister für den Eingang, die dann kaskadiert werden. Dafür brauchst du keine überteuerte Platine mit Porterweiterungen, ein Schieberegister kostet um die 30 cent. Du solltest in der Lage sein, die richtig anzuschließen, ansonsten rate ich dir davon ab, ein Projekt zu entwickeln, bei dem Dinge überwacht werden sollen, die bei fehlerhafter Überwachung zerstört werden können. Denn dann fehlt es einfach an Grundlagen, die später sehr problematisch werden können. Die Schieberegister kannst du dann jeweils komplett auslesen bzw. die Ausgänge in einem Rutsch setzen und per Software in einzelne Variablen zerlegen, so wie du es brauchst.
someone schrieb: > Axel S. schrieb: >> Aha. So ein Blödsinn > > Ich kann ja mittlerweile irgendwie schon verstehen, dass Leute ihre > Probleme nicht vernünftig beschreiben wollen, wenn sofort nachdem sie es > gemacht haben irgendeiner kommt und gleich das Problem niedermacht. > Es spielt keine Rolle, ob du es für sinnvoll findest, das Problem zu > lösen oder nicht. Der Threadersteller will sich damit beschäftigen, > dabei kannst du ihm entweder helfen oder es eben lassen. > > > Zum Problem an sich: Mir ist leider immer noch nicht so ganz klar, um > was es nun geht. Schalten über Relais und Rückmeldung über Optokoppler > ist sicher, aber natürlich auch sehr langsam. Relais schalten nicht > besonders schnell. Außerdem ist die gesamte Beschaltung natürlich auch > aufwendig, da du Spulentreiber etc. benötigst. Ersteinmal kein Problem. > Als Sicherheitsmaßnahme würde ich eher zu Bauteilen raten, die von sich > aus die Sicherheit herstellen und keine Softwarelösung benötigen. > Software ist immer anfällig. Wenn Überhitzungsgefahr besteht, lieber > zusätzlich noch eine Temperatursicherung einbauen als sich 100% auf die > Software verlassen. Natürlich gibt es interne Mechanismen, aber das ist nicht mein Job. Ich brauche nur Rückmeldungen, die werde ich bekommen. > > Zur Porterweiterung: I2C-Porterweiterungen sind langsamer, aber > flexibler und brauchen nicht die Menge an Anschlüssen. Man kann sie > einzeln adressieren und muss daher nicht immer alle auslesen. > Für deine Anwendung ist das aber ziemlich egal. Du willst ja immer alles > auslesen und (potentiell) alles schalten. Korrekt. > Wie bereits erwähnt, empfehle ich dir Schieberegister für den Ausgang > und Schieberegister für den Eingang, die dann kaskadiert werden. Dafür > brauchst du keine überteuerte Platine mit Porterweiterungen, ein > Schieberegister kostet um die 30 cent. Hier mein Veto... ja eines kostet 30 Cent, ja und? Vorschlag... > Du solltest in der Lage sein, die richtig anzuschließen, ansonsten rate > ich dir davon ab, ein Projekt zu entwickeln, bei dem Dinge überwacht > werden sollen, die bei fehlerhafter Überwachung zerstört werden können. > Denn dann fehlt es einfach an Grundlagen, die später sehr problematisch > werden können. Also, das Risiko trage natürlich ich, aber wo ist das Problem mit einer "überteuerten Platine", das verstehe ich nicht. Für welchen Preis baust Du mir eine Platine mit zum Beispiel 16 Eingängen, Optokoppler, eigene Spannungsversorgung, kaskadierbar? Der Aufbau ist nicht so komplex, aber wozu soll ich das selber machen? Nenn mir Deinen Preis! Wenn ich dafür 20 Euro oder so zahle, ist das so horrend? Lieferst Du billiger? Es geht nicht um Massenproduktion, sondern darum, dass es fertig ist, zum probieren. > > Die Schieberegister kannst du dann jeweils komplett auslesen bzw. die > Ausgänge in einem Rutsch setzen und per Software in einzelne Variablen > zerlegen, so wie du es brauchst. Ja genau, das will ich. Und was kostet mich die Outputplatine bei Dir? Optokoppler und Relais? Ich denke, Du weißt, was ich meine. Aber danke! PS: Gerade noch einmal diesen Beitrag lesend, ich meine das "Danke" als wirkliches danke. Ich meine nur, dass es doch wirklich Zeitverschwendung ist, eine Platine dergestalt selbst zu fummeln... wenn Du sowas aber machst, gerne, ich bin gespannt!
:
Bearbeitet durch User
> Das wird mich sicher noch beschäftigen, denn optimal hätte die > Hardware natürlich keine Glitches usw. Ganz Recht. Finanziell lohnt es sich oft, die Hardware etwas einfacher zu gestalten und deren Mängel per Software auszugleichen.
J. W. schrieb: > Dennoch, eine grundsätzliche Frage: Einige favorisieren I2C, andere > sagen SPI... Innerhalb eines Gerätes ist das ziemlich egal, I2C ist teurer. Zwischen Geräten würde ich CAN, RS-485 oder Ethernet nehmen. J. W. schrieb: > Wenn zum Beispiel eine Endstufe hochgefahren wird > (Röhrentechnik), dann bekomme ich erst GO nachdem die Endstufe > betriebsbereit ist. Ich weiß ja nicht, wo und wie Du ein solches Signal abgreifen willst. Warum kann der Steuer-MC nicht einfach die Zeit abwarten? Axel S. schrieb: > Vollkommen unsinnig. Potentialtrennung über Optokoppler und Relais macht > man dann (und nur dann) wenn man es braucht. Na klar und die Leute, die SPS bauen, sind alles Idioten. Gerade in größeren Geräten und Systemen kann man die Erdschleifen nur schwer beherrschen. Daher ist es bewährte Technik, Erdschleifen gar nicht erst entstehen zu lassen. So ein Optokoppler ist doch kein Kostenpunkt. Ich habe viele Optokoppler, wo auf beiden Seiten quasi GND ist, aber eben von anderen Modulen herangeführt. Der Lohn ist eine bessere Störfestigkeit und Zuverlässigkeit. Und besonders in NF-Anlagen möchte man auf keinen Fall digitales Gezwitscher im Hintergrund mithören.
Das rauscht und fiiept am Ende, trotzdem natürlich viel Erfolg. Mach es einfach so, wie Du oben die vier Punkte angeführt hast. Du denkst im Moment einfach noch zu langsam. Du kannst Dir halt eben noch nicht vorstellen, wie schnell das im Inneren eigentlich abläuft. Verstärker - hmm. ich hatte bei Diener Beschreibung auf Modellbaueisenbahnanlage getippt. ( mich würde jetzt - völlig frei der Wertung - auch interssieren, wie sich die immense Anzahl IOs zusammensetzt ) Viel Spaß beim Projekt, nochmal viel Erfolg! Axelr. DG1RTO
Axelr. schrieb: > Du kannst Dir halt eben noch > nicht vorstellen, wie schnell das im Inneren eigentlich abläuft. Ja, wie gesagt, mal schaun. > ( mich würde jetzt - völlig frei der Wertung - auch interssieren, wie > sich die immense Anzahl IOs zusammensetzt ) Nur soviel: Es geht um eine immense Anzahl von Röhren und Leistung, hiermmit verbunden, alleine durch die Röhren, üble Spannungen. Es soll also mit Priorität kein Schaden an Leib und Leben entstehen, und sekundär, kein Schaden an den Bauteilen. Die Hauptaufgabe trägt die Hardware (zum Beispiel Schadensmeldung bis Selbstabschaltung). Die Software stößt Prozesse an, die kontrolliert werden. Treten Probleme auf, werden diese registriert und bewertet und danach gehandelt. Im Prinzip eine Modelleisenbahn! ;-) > Viel Spaß beim Projekt, nochmal viel Erfolg! Danke Axel und ganz besonders auch an alle anderen positiv kritischen Kommentatoren (ganz besonders peda). Ich werde schon noch früh genug rumheulen ;-)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.