Announcement: there is an English version of this forum on Hallo zusammen. An dieser Stelle ein Vorwort. Ich stelle hier im Forum nur eine Frage, wenn ich absolut nicht mehr weiter weis und alles versucht habe an die Informationen zu kommen die ich haben möchte. (Forenbeiträge,Goorakel,Youtube etc etc). Da zwischen den Überheblichen Arroganten Beleidigenden Usern, aber auch Kompetente Hilfsbereite Menschen sind, versuche ich es einfach mal. Zur Vorgeschichte: Ich habe meine Hausautomation bis vor 3 Monaten (Ja solange suche ich schon) in der Kombination Raspberry PI -> rs232 shield -> Conrad Relaisplatine betrieben ohne Probleme auch mit 10 Meter Kabel. Durch einen Dachschaden (NEIN nicht bei mir selbst ) kam es zu einem Wasserschaden am PI inc shield. Mit dem ersatz PI + neuem shield war keine Kommunikation zur Karte mehr möglich, Prüfung der Konfiguration ergab auf PI seite alles IO. Die Relaisplatine habe ich dann an einen älteren PC mit rs232 D-sub port angeschlossen, dort funktioniert sie bis heute. Es wurde dann ein USB <-> Rs232 "adapter" besorgt, der zwar funktioniert, aber nicht mit der Karte. (habe einen Forenbeitrag gefunden das andere das problem auch haben).Ich möchte diesen Alt PC aber nicht in Betrieb lassen, weil der ein bisschen mehr Strom verbraucht als z.b. ein PI.. Das zur Vorgeschichte damit man ein Bild hat. So, jetzt aber zur Frage: Da ich noch MAX232 Ics rumliegen habe, war meine Überlegung, warum nicht einfach die eine Seite mit der Relaisplatine verbinden, und die andere direkt an USB. Ich habe aber keine Informationen darüber gefunden und vermute das ist nicht möglich/vorgesehen. Warum geht das nicht? Wenn mir das jemand erklären könnte wäre das verdammt nett und sehr Hilfreich. Danke im Voraus.
ist es das "Shield" aus dem Anhang? Da ist kein FTDI drauf, sondern ein MAX3232, der macht nur Pegelwandlung. Anderer möglicher Fallstrick: Früher hatte Rasbian auf den seriellen Pins per default eine Login-Shell, das würde dir die Verbindung zur Relais-Karte verhageln. Ist evtl. per "raspi-config" abstellbar. Hab ich H. schrieb: > So, jetzt aber zur Frage: > Da ich noch MAX232 Ics rumliegen habe, war meine Überlegung, warum nicht > einfach die eine Seite mit der Relaisplatine verbinden, und die andere > direkt an USB. Ich habe aber keine Informationen darüber gefunden und > vermute das ist nicht möglich/vorgesehen. Warum geht das nicht? Aus demselben Grund warum Gardena auf CEE Adapter nicht funktionieren. Das sind einfach komplett unterschiedliche Schnittstellen. https://etel-tuning.eu/produkt/adapter-drehstrom-auf-gardena/
:
Bearbeitet durch User
Hab ich H. schrieb: > Ich stelle hier im Forum nur eine Frage, wenn ich absolut nicht mehr > weiter weis und alles versucht habe an die Informationen zu kommen die > ich haben möchte. ich auch :) Hab ich H. schrieb: > Da ich noch MAX232 Ics rumliegen habe, war meine Überlegung, warum nicht > einfach die eine Seite mit der Relaisplatine verbinden, und die andere > direkt an USB. Ich habe aber keine Informationen darüber gefunden und > vermute das ist nicht möglich/vorgesehen. Warum geht das nicht? Weil der Max 232 nur ein Pegelwandler für UART (RS232<->TTL) ist und keine USB-UART Brücke, wie diverse ICs von zB. FTDI
Hab ich H. schrieb: > Warum geht das nicht? Kurze Antwort: weil USB eben USB ist und keine einfache asynchrone serielle Datenübertragung wie bei RS-232. Das "S" in USB steht zwar auch für "serial", aber die gesamte Übertragung ist nicht nur physikalisch (differentielle Signale statt unipolar) sondern auch protokollmäßig komplett anders. USB benutzt paketorientierte Impulsfolgen, um Daten zu übertragen. RS-232 (bzw. dessen Variante mit einfachen Logikpegeln) benutzt einen sehr einfachen Rahmenaufbau aus Start-, Daten- und Stopbits, der letztlich vom früheren Protokoll der Fernschreiber abgeleitet worden ist. Du brauchst also irgendwas, was auf der einen Seite USB spricht und auf der anderen Seite RS-232. Wenn das, was du hast, das nicht vernünftig tut, könnte das an den verwendeten Pegeln auf RS-232-Seite liegen: dort wird normalerweise mit negativen und positiven Spannungen (so im Bereich ±(3…15) V) gearbeitet, der Bereich zwischen -3 und +3 V ist "verboten". Viele PC-seitige Empfänger werte(te)n Spannungen in diesem Bereich wie negative Spannungen, aber garantiert ist das nicht, und wenn dein Conrad-Teil das nicht akzeptiert, musst du dir einen Adapter suchen, der das ordentlich macht.
Εrnst B. schrieb: > ist es das "Shield" aus dem Anhang? > Da ist kein FTDI drauf, sondern ein MAX3232, der macht nur > Pegelwandlung. > > Anderer möglicher Fallstrick: Früher hatte Rasbian auf den seriellen > Pins per default eine Login-Shell, das würde dir die Verbindung zur > Relais-Karte verhageln. > Ist evtl. per "raspi-config" abstellbar. Ich bin Unvorbereitet -.- kann kein Foto machen :( Nein mein shield sieht anders aus, aber auf dem IC steht leider nichts. Der Pi ist korrekt konfiguriert das terminal abgeschaltet und mit brücke zwischen rx-tx klappt kommunikation. Also zum Verständniss : Es geht garnicht um die Pegel, sondern um das Protokoll ? Verstehe ich zwar nicht, nehme ich aber mal hin. Wäre eine Config like USB->Arbuino->max232->relaiskarte möglich ?
Jörg W. schrieb: > Du brauchst also irgendwas, was auf der einen Seite USB spricht und auf > der anderen Seite RS-232. Wenn das, was du hast, das nicht vernünftig Gut, Also USB spricht englisch und rs232 deutsch, so in etwa, ja ? Danke jetzt wird es klarer. Wie einen Beitrag höher, mösste ein Arduino dazwischen doch "Übersetzen" können ?
Εrnst B. schrieb: > Aus demselben Grund warum Gardena auf CEE Adapter nicht funktionieren. > Das sind einfach komplett unterschiedliche Schnittstellen. > > https://etel-tuning.eu/produkt/adapter-drehstrom-auf-gardena/ Hey ! den hab ich sogar, benutze den aber anders herum, mache Wasser zu Strom :)
Hab ich H. schrieb: > Wie einen Beitrag höher, mösste ein Arduino dazwischen doch "Übersetzen" > können ? Nein, kann der nicht. Auch wenn die üblichen Arduinos etwas ähnliches mit auf dem Board haben. Das, was sie haben, setzt aber auf TTL-Pegel um, du brauchst (so habe ich dich verstanden) RS-232-Pegel. Nicht nur, dass letztere negative und positive Spannungen benutzen, sie sind auch invertiert. Also, TTL-Pegel (auf dem Arduino, hinter dem USB-IC) +5 V erzeugt auf RS-232 dann -5 V, TTL-Pegel 0 V erzeugt auf RS-232 +5 V. Das ist übrigens, was ein MAX232 (und Verwandte) tut. Kauf dir irgendeinen brauchbaren USB-RS232-Wandler. Gibt's wie Sand am Meer. ps: > Also USB spricht englisch und rs232 deutsch, so in etwa, ja ? Eher chinesisch und deutsch, also absolut keine Ähnlichkeit zwischen beiden.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Kauf dir irgendeinen brauchbaren USB-RS232-Wandler. Gibt's wie Sand am > Meer. Habe bereits 2 gekauft, und beide funktionieren mit der conrad karte nicht, was scheinbar ein bekanntes problem ist. Ich werde also nicht umhinkommen entweder die conrad karte zu ersetzen(was ich nicht möchte), oder etwas eigenes zu bauen. Entweder habe ich dich mißverstanden, oder du hast etwas überlesen, ich fragte etwas höher ob die kombination USB->Arduino->MAX232->conrad karte ginge. Da hätte ich doch die übersetzung chinesisch->Deutsch, UND die Pegelwandlung von 0/5 Volt auf +-12 ? oder bin ich jetzt komplett falsch abgebogen ?
Theoretisch könnte das funktionieren. Du müsstest dann auf dem Arduino die beiden seriellen Datenströmen in beiden Richtungen in Software durchreichen, dafür musst du ein Programm schreiben. Warum damit aber die Conrad-Karte besser zurecht kommen sollte als mit einem direkten USB-RS232-Wandler, ist nicht klar. Oder mit anderen Worten: die Chancen, dass das nicht geht, sind genauso groß wie die, dass es direkt nicht geht.
Schreib doch mal, was für eine Karte das genau ist und vielleicht auch noch die Referenz, wo andere schon Probleme damit hatten. Vielleicht lässt sich da was machen.
Angehängte Dateien:
-
IMG_20221026_200432.jpg
180 KB
Wie viele schaltkontakte brauchst du denn? Warum nicht das ganze gedönse durch einen sonoff 4ch ersetzen? Den kannst du dann vom rapi per http ansteuern, oder noch besser den raspi fortwerfen ud die logik auf dem sonoff machen. Ich steuere meine heizung mit sowas.
Jörg W. schrieb: > chreib doch mal, was für eine Karte das genau ist und vielleicht auch > noch die Referenz, wo andere schon Probleme damit hatten. Vielleicht > lässt sich da was machen. also es handelt sich um diese Karte : https://www.conrad.de/de/p/conrad-components-197730-relaiskarte-baustein-12-v-dc-197730.html hier ist die Referenz die ich finden konnte : Beitrag "Programm zur billigen Relaisplatine 8FA" PS: Einen Arduino Programmieren, das er tut was ich will kann ich soweit.
Alt G. schrieb: > Wie viele schaltkontakte brauchst du denn? > Warum nicht das ganze gedönse durch einen sonoff 4ch ersetzen? > Den kannst du dann vom rapi per http ansteuern, oder noch besser den > raspi fortwerfen ud die logik auf dem sonoff machen. > > Ich steuere meine heizung mit sowas. Ja, sicher gibt es da modernere Lösungen als meine. Aber ich tausche Hardware nur aus wenn sie Irreparabel Kaputt ist, nicht weil sie alt ist :) Zumal ich mich selbst austauschen müsste dann.. hust Ich habe Relaisplatinen da, die ich direkt mit TTL Ansteuern kann. Aber siehe oben. Abgesehen davon lerne ich gerne dazu und mit der netten Hilfe der Teilnehmer hier gelingt mir das vielleicht auch, ohne wieder dutzende Euros auszugeben. Ich habe Linux da, ich habe Arduinos da, Ich habe PIs da ich habe Max232 da, da muss doch was gehen ? :) LG
Jörg W. schrieb: > Warum damit aber die Conrad-Karte besser zurecht kommen sollte als mit > einem direkten USB-RS232-Wandler, ist nicht klar. Oder mit anderen > Worten: die Chancen, dass das nicht geht, sind genauso groß wie die, > dass es direkt nicht geht. Das hatte ich vergessen anzufügen sorry für den halb-doppel-post. Das stimmt zwar, das das genauso nicht funktionieren könnte. Allerdings habe ich durch die aufdröselung in Einzelkompunenten im Gegensatz zum vergossenen Adapter 1.) die Möglichkeit mehr darüber zu lernen/messen und 2.) kann möglicherweise durch Anderungen an einzelnen Komponenten das ganze dazu bewegen doch zu funktionieren.
Hab ich H. schrieb: > hier ist die Referenz die ich finden konnte : > Beitrag "Programm zur billigen Relaisplatine 8FA" Da steht allerdings, dass er das Problem mit Software erschlagen konnte: Beitrag "Re: Programm zur billigen Relaisplatine 8FA" Das Timing ist halt bei Transport über USB etwas anders als direkt an einer Hardware-UART. Daran würde dann auch dein zwischengeschalteter Arduino nichts korrigieren können.
Jörg W. schrieb: > Da steht allerdings, dass er das Problem mit Software erschlagen konnte: Die Software die der Autor erwähnte hatte ich gar nicht mehr aufm Zettel! Falls die noch Verfügbar ist geb ich der mal ne Chance. Wo ich das Bild der Platine nochmal sehe gerade, die hat ja auch nen USB(B) Anschluss, eventuell schlucke ich die Kröte und kaufe mir den Baustein zum Apothekenpreis bei Conrad.
Hab ich H. schrieb: > Aber ich tausche Hardware nur aus wenn sie Irreparabel Kaputt ist, nicht > weil sie alt ist :) Das macht keinen sinn wenn die relaisplatine 3 mal so teuer ist wie ein sonoff 4ch und 10 mal so teuer wie ein arduino mit ttl relaiskarte. Lern was neues. Wenn fit den esp8266 proggen oder dann einen arduino und ttl relaiskarte dazu bringen das zu machen was deine 60 eur conrad karte gemacht hat. Sich mit timing problemem von uralt-karten rumzuschlagen ist nicht produktiv.
Alt G. schrieb: > Sich mit timing problemem von uralt-karten rumzuschlagen ist nicht > produktiv. Die Timing-Probleme waren ja wohl offenbar eher in der Software. Wenn man an einer UART was ausgibt, kann man kurz darauf die Antwort rücklesen (irgendso ein Protokoll scheint es da zu geben). Wenn ein USB dazwischen ist, muss man erstmal einen Moment warten, bis auf selbigem der Host die Daten vom Gerät abgeholt hat.
Alt G. schrieb: > Das macht keinen sinn wenn die relaisplatine 3 mal so teuer ist wie ein > sonoff 4ch und 10 mal so teuer wie ein arduino mit ttl relaiskarte. > > Lern was neues. Wenn fit den esp8266 proggen oder dann einen arduino und > ttl relaiskarte dazu bringen das zu machen was deine 60 eur conrad karte > gemacht hat. > > Sich mit timing problemem von uralt-karten rumzuschlagen ist nicht > produktiv. Deine Meinung in Ehren. Aber eine Karte die ich bereits besitze ( seit 10 Jahren) ist per se nicht 3x so teuer wie eine Karte/Gerät welches ich nicht besitze. sondern genau anders herum. Man könnte es auch Nachhaltig nennen wenn ich "uralt" Geräte benutze bis sie wirklich Kaputt sind. Du kannst das natürlich anders sehen, ich Akzeptiere das. Ich mache das aber eben so wie ich es für richtig halte. LG
Angehängte Dateien:
-
Conrad-8fach-Relais.png
62 KB
Du kannst die teure Karte ja "up-cyclen". Da ist ein Attiny2313 drauf, dem kannst du eine Alternativ-Software verpassen. Oder: du lötest den ganz raus, und bastelst direkt deinen Arduino vor den ULN2803.
Εrnst B. schrieb: > Du kannst die teure Karte ja "up-cyclen". > > Da ist ein Attiny2313 drauf, dem kannst du eine Alternativ-Software > verpassen. > Oder: du lötest den ganz raus, und bastelst direkt deinen Arduino vor > den ULN2803. Oha das klingt nicht nur Interessant, sondern auch Vielversprechend. Leider fürchte ich das meine Kenntnisse in der Elektronik für ein solches Projekt nicht ausreichen ohne konkrete Anleitung :( Ich bin nunmal Vollzeit Allround Mechaniker, und habe die Elektronik nur als Hobby/Ausgleich. Dinge die du mit verbundenen Augen machen kannst, stellen mich vor teils unlösbare Probleme. Aber vielen lieben Dank für diesen Lösungsweg! LG
Angehängte Dateien:
-
Clipboard01.jpg
72 KB
Εrnst B. schrieb: > du lötest den ganz raus, und bastelst direkt deinen Arduino vor > den ULN2803. Viel zu aufwendig. Neue relaiskarten gibts für lau.
Εrnst B. schrieb: > Da ist ein Attiny2313 drauf, dem kannst du eine Alternativ-Software > verpassen. > Oder: du lötest den ganz raus, und bastelst direkt deinen Arduino vor > den ULN2803. Oder den Pi direkt an den 2803.
Alt G. schrieb: > Εrnst B. schrieb: >> du lötest den ganz raus, und bastelst direkt deinen Arduino vor >> den ULN2803. > > Viel zu aufwendig. Neue relaiskarten gibts für lau. Der Müll taugt aber nicht für Netzspannung.
H. H. schrieb: > Der Müll taugt aber nicht für Netzspannung. Die optogekoppelten 250V relais taugen nicht für netzspannung ?
Ich habe zu den beiden IC's Youtube videos und datenblätter aufm Zettel und bin jetzt mal mit Weiterbildung beschäftigt. Vielen Lieben Dank an alle die mir weitergeholfen haben und Denkanstöße gegeben haben, Ich nehme Morgen wieder an dem Thema Teil. LG
Beitrag #7248059 wurde von einem Moderator gelöscht.
Hab ich H. schrieb: > Gut, Also USB spricht englisch und rs232 deutsch, so in etwa, ja ? Schlimmer. USB spricht Fachchinesisch und rs232 macht Uga-Aga Laute. Dazwischen liegen Welten, das kann man nicht einfach so übersetzen. > Wie einen Beitrag höher, mösste ein Arduino dazwischen > doch "Übersetzen" können ? Das ist die Aufgabe eines USB-UART Chips. Auf den meisten Arduino Boards befindet sich dafür ein separater Chip, oft ein FT232 von FTDI, ein CH340, oder ein ATmega8U2 mit entsprechender Firmware. Hab ich H. schrieb: > Da hätte ich doch die übersetzung chinesisch->Deutsch, UND die > Pegelwandlung von 0/5 Volt auf +-12 ? Hast du schon gekauft. In einem USB-RS232 Adapterkabel sind zwei Chips drin, ein USB-UART und ein Pegelwandler. Zum Beispiel FT232+MAX232.
Hab ich H. schrieb: > Es wurde dann ein USB <-> Rs232 "adapter" besorgt, der zwar > funktioniert, aber nicht mit der Karte. Vielleicht benötigt die Karte irgendwelche Hardwarehandshakeleitungen, die vom vom neuen Adapter nicht unterstützt werden - who knows.
Wolfgang schrieb: > Vielleicht Einfach den Rest des Threads lesen. Scheint ein Timing-Problem zu sein, welches man in der Ansteuersoftware berücksichtigen muss – zumindest haben andere (oben verlinkt) das so lösen können.
Soo also ich habe den Quellcode runtergeladen, compiled und festgestellt das das Programm auf der Leap 15.4 (opensuse) nicht läuft...grml. Allerdings auf dem Laptop mit der Tumbleweed version. Leider scheint zwar eine Art Kommunikation statt zu finden, allerdings nur Datenmüll. Heißt die Softwarelösung funktioniert bei mir nicht. Wäre ja auch ZU einfach gewesen. oh Moment ! jetzt wo ich diese Zeilen schreibe... Datenmüll ? habe ich die Baudrate geprüft ? nein natürlich nicht... Schade Baudrate stimmt. Tja jetzt bleibt mir nur noch die Hardware Lösung.
Hab ich H. schrieb: > Tja jetzt bleibt mir nur noch die Hardware Lösung. Oder das Problem zu analysieren … im anderen Thread hat das ja offenbar jemand geschafft.
Jörg W. schrieb: > Hab ich H. schrieb: >> Tja jetzt bleibt mir nur noch die Hardware Lösung. > > Oder das Problem zu analysieren … im anderen Thread hat das ja offenbar > jemand geschafft. Ja sicher, nur haben die Leute wesentlich mehr Ahnung als ich. Da ich den Vergossenen Adapter nicht Analysieren kann, wäre mein nächster Schritt jetzt wirklich die ganze Geschichte in seine einzelnen Bestandteile aufzudröseln. D.h. Ich werde die Anordnung PC->Arduino->MAX232->Platine mal aufbauen. Auch wenn ich kein Oszi habe, könnte ich möglicherweise ja an verschiedenen Stellen mal Messen und schauen ob mir etwas komisch vorkommt. LG
Hab ich H. schrieb: > Da ich den Vergossenen Adapter nicht Analysieren kann, wäre mein > nächster Schritt jetzt wirklich die ganze Geschichte in seine einzelnen > Bestandteile aufzudröseln. Wie wäre es mit einem Logic Analyzer? Achtung: Nicht jeder verträgt RS232 Pegel. Aber du kannst ja auf der 3,3V oder 5V Seite der RS232 Treiber des Relais-Boardes messen.
:
Bearbeitet durch User
Hab ich H. schrieb: > Da ich den Vergossenen Adapter nicht Analysieren kann, Der muss dich auch nicht interessieren. Die serielle Kommunikation kannst du genauso gut auf der Conrad-Platine mitmeißeln, wenn du das willst. Das Problem wird viel mehr im Timing irgendwo zu suchen sein. Ja, ein Logikanalysator wäre hilfreich. Einmal die Kommunikation mitschneiden, die funktioniert (am Computer mit der echten RS-232), danach die mit dem USB-Adapter, die nicht funktioniert.
Ein anderer Ansatz wäre vielleicht... die Platine hat ja einen USB(B) Anschluss, den man benutzen kann wenn man die mini Platine für teuer Geld kauft und in den vorhandenen Sockel setzt. Ich mache mal Fotos von der Platine, vielleicht hat ja jemand ne Idee was das shuttleboard da macht und ob man das einfach selbst bauen kann. Ein logic analyzer kostet halt auch wieder Geld, und bei einem Strompreis von 89 Cent spart man wo man kann :) LG
Hab ich H. schrieb: > Ein logic analyzer kostet halt auch wieder Geld Für das bisschen serielle Kommunikation wird es auch eine billiger chinesischer Clone tun *). Du kannst ja direkt hinter dem MAX232 (oder was auch immer auf dem Conrad-Teil ist) messen, nicht auf den RS-232-Leitungen mit ihren hohen (und negativen) Pegeln. *) Such bei ebay nach "Saleae". Die Varianten mit 24 MHz Abtastrate und 8 Kanälen genügen hier völlig.
Oh, da wär meine Vermutung komplett falsch. Für'n 10er wäre das vielleicht wirklich ein Werkzeug was man der Sammlung hinzufügen könnte :) Danke für die Hinweise. LG
Aus der Anleitung:
> Nullmodemkabel
Da sind die RXD- und TXD-Pins vertauscht.
Dann funktioniert ein direkt angeschlossener USB-RS232-Wandler natürlich
nicht.
STK500-Besitzer schrieb: > Dann funktioniert ein direkt angeschlossener USB-RS232-Wandler natürlich > nicht. Die meisten dieser Teile benehmen sich wie eine RS-232 am Computer (und haben auch männliche Stecker). Damit sollte das schon mit dem Nullmodemkabel gehen.
Jörg W. schrieb: > Damit sollte das schon mit dem > Nullmodemkabel gehen. Das ist mir schon klar. Nur hat der TO auch das Kabel verwendet?
Also das Kabel zwischen PC und Platine ist ein eigenbau. GND->GND RX->TX TX-RX Sollte doch am adapter genauso funktionieren oder nicht ?
Wenn's ein Eigenbau ist, kannst du doch mal RX und TX auf einer Seite teuschen, wenn du keinen Nullmodemstecker hast.
Hab ich H. schrieb: > Also das Kabel zwischen PC und Platine ist ein eigenbau. > GND->GND > RX->TX > TX-RX > > Sollte doch am adapter genauso funktionieren oder nicht ? das sieht eher nach einem 1:1-Kabel aus. Helmut -. schrieb: > Wenn's ein Eigenbau ist, kannst du doch mal RX und TX auf einer Seite > tauschen, wenn du keinen Nullmodemstecker hast. Gute Idee. Für solche Probleme habe ich mir einem RS232-Schnittstellentester gekauft (früher hatte ich einen Selbstbau).
Angehängte Dateien:
-
Stecker.png
9,7 KB
STK500-Besitzer schrieb: > Aus der Anleitung: >> Nullmodemkabel > Da sind die RXD- und TXD-Pins vertauscht. > Dann funktioniert ein direkt angeschlossener USB-RS232-Wandler natürlich > nicht. Oder man hängt noch so einen ser. Zwischenadapter (z.B. SUB D 9 Pol. m/w) dran. Hatte vor Jahren das gleiche Problem, aber nicht gewußt, daß diese Gender-Stecker wiederum Rx und Tx vertauschen. Die gibt es für wenig Geld in allen Variationen. Da hatte ich auch mal von 9pol auf 25pol bzw. umgekehrt geroutet. Was auch noch eine Ursache sein könnte (war bei mir damals so), daß der USB->SER. Wandler nichts taugt. Da hatte ich zuerst auch einen billigen mit einem Prolific - Chip. Der ging auch nicht. Als ich mir damals einen mit FTDI-Chip gekauft hatte (z.B. den Digitus), war das Problem behoben. Da war auch eine Conrad Relaiskarte mit im Spiel. Das ist mal meine Erfahrung damit.
:
Bearbeitet durch User
Heinz B. schrieb: > Oder man hängt noch so einen ser. Zwischenadapter (z.B. SUB D 9 Pol. > m/w) dran. Hatte vor Jahren das gleiche Problem, aber nicht gewußt, > daß diese Gender-Stecker wiederum Rx und Tx vertauschen. Die gibt > es für wenig Geld in allen Variationen. Da hatte ich auch mal von 9pol > auf 25pol bzw. umgekehrt geroutet. Das abgebildete Adapter ist ein Genderchanger. Nullmodem wechseln nicht das Steckgeschlecht.
Stimmt, die wechseln normalerweise nicht das Geschlecht. Ich habe einen Nullmodemstecker, der aber von 9pol. auf 25pol. geht. Es geht ja hier vielmehr um die Rx/Tx Leitungen. Und bei den Nullmodem Kabeln/Steckern gibt es auch noch Unterschiede. Die billigen sind oft nicht voll durchkontaktiert. Also nur Rx und Tx vertauscht. Da muß man halt manchmal probieren, wenn man sich nicht sicher ist.
:
Bearbeitet durch User
Heinz B. schrieb: > Was auch noch eine Ursache sein könnte (war bei mir damals so), daß > der USB->SER. Wandler nichts taugt. Da hatte ich zuerst auch einen > billigen mit einem Prolific - Chip. Der ging auch nicht. Als ich mir > damals einen mit FTDI-Chip gekauft hatte (z.B. den Digitus), war das > Problem behoben. Da war auch eine Conrad Relaiskarte mit im Spiel. > > Das ist mal meine Erfahrung damit. Ja genau den Hersteller habe ich auch Prolific mit einem PL2303. Unglücklicherweise 2 Stück davon. seufz Rx und Tx kann ich ja trotz dem mal testweise tauschen und schauen ob was passiert. Muss aber erst nachher mal die Kabel burchpiepsen da ich selbstverständlich nicht notiert habe was was ist :) Da meine Münzpresse kaputt ist, ist nun die Frage ob ich einen Logic Analyser oder einen anderen Adapter kaufe. :)
:
Bearbeitet durch User
Hab ich H. schrieb: > Ja genau den Hersteller habe ich auch Prolific mit einem PL2303. > Unglücklicherweise 2 Stück davon. seufz Ich glaube mich zu erinnern, daß das damals eine Treiber-Sache war. Mit der richtigen Treiberversion (genaues Datum) ging es dann. Das fand ich aber erst nachher raus.
Heinz B. schrieb: > Ich glaube mich zu erinnern, daß das damals eine Treiber-Sache war. > Mit der richtigen Treiberversion (genaues Datum) ging es dann. Ja. Download: http://stefanfrings.de/avr_tools/index.html#pl2303 Prolific unterstützt die alten Revisionen des Chips nicht mehr, seit sie in großen Stil gut funktionierend gefälscht werden.
:
Bearbeitet durch User
Stefan F. schrieb: > Ja. Download: http://stefanfrings.de/avr_tools/index.html#pl2303 > > Prolific unterstützt die alten Revisionen des Chips nicht mehr, seit sie > in großen Stil gut funktionierend gefälscht werden. Da finde ich aber nur Echsen und anderen Windows Kram. :) Ich schau mal ob ich woanders was finde. Edit: Also laut dem Goorakel haben wohl viele Probleme mit dem pl2303 Chip, ich schätze ich werde einer Version mit FTDI mal eine Chance geben. Einen billigen Logic Analyser werd ich aber ebenso mitbestellen, was solls. LG
:
Bearbeitet durch User
STK500-Besitzer schrieb: > Hab ich H. schrieb: > >> Also das Kabel zwischen PC und Platine ist ein eigenbau. >> GND->GND >> RX->TX >> TX-RX >> Sollte doch am adapter genauso funktionieren oder nicht ? > > das sieht eher nach einem 1:1-Kabel aus. Wenn er "Rx -> Tx" und "Tx -> Rx" schreibt meinst du, dass dies 1:1 sei? Dieser Logik kann ich nicht folgen. Außerdem hat er ja als Vergleich den PC mit der Hardware-UART, auf dem alles funktioniert. Das schließt dann das Kabel sowieso aus, und "Kauderwelsch" würde bei einem falschen Kabel auch nicht empfangen werden. Hab ich H. schrieb: > Also laut dem Goorakel haben wohl viele Probleme mit dem pl2303 Chip, Allerdings mehr unter Windows als unter anderen Systemen. > ich schätze ich werde einer Version mit FTDI mal eine Chance geben. Das ist eh immer eine gute Referenz. Wenn es damit auch nicht geht, dann liegt es am Timing, welches sich durch Zwischenschalten des USB halt notwendigerweise anders gestaltet. Ich kenne auch schrottige Software, die mit nichts anderem als einer über Hardware-UART angeschlossenem Gerät zurecht kommt (EPROM-Programmiergerät mit Closedsource-Software zum Ansteuern). Nur für dieses Teil liegt hier noch irgendwo ein Laptop mit Hardware-UART und einem Windows2000 drauf herum.
Hab ich H. schrieb: > Win 2K war garnicht sooooo schlecht. :) Aber auch nicht besonders gut … war aber nicht das Thema hier. ;-) Wenn es nicht für diesen UP2000-EPROMmer wäre, hätte ich den Laptop bestimmt schon längst verschrottet. Der hat eh das Problem, die Daten überhaupt hin und her zu bekommen: das uralte SMB-Protokoll aus dieser Zeit ist so unsicher, dass das heute keiner mehr freiwillig sprechen will. Brauchbares USB hat der Laptop nicht. HTTP/S geht auch nicht, weil das alte SSL, welches der Browser da spricht, wegen gravierender Sicherheitsmängel auch niemand mehr anbieten mag. Ein Diskettenlaufwerk wiederum hat sonst keiner mehr heutzutage … So, nun schau mal, wie du deinen Salat aufgedröselt bekommst.
Jörg W. schrieb: > Hab ich H. schrieb: >> Win 2K war garnicht sooooo schlecht. :) > > Aber auch nicht besonders gut … war aber nicht das Thema hier. ;-) > > Wenn es nicht für diesen UP2000-EPROMmer wäre, hätte ich den Laptop > bestimmt schon längst verschrottet. Der hat eh das Problem, die Daten > überhaupt hin und her zu bekommen: das uralte SMB-Protokoll aus dieser > Zeit ist so unsicher, dass das heute keiner mehr freiwillig sprechen > will. Brauchbares USB hat der Laptop nicht. HTTP/S geht auch nicht, weil > das alte SSL, welches der Browser da spricht, wegen gravierender > Sicherheitsmängel auch niemand mehr anbieten mag. Ein Diskettenlaufwerk > wiederum hat sonst keiner mehr heutzutage … > > So, nun schau mal, wie du deinen Salat aufgedröselt bekommst. Du könntest auf dem Ding Linux installieren, und dich wundern was das Teilnoch alles kann nach all der zeit :) Ja, Ich habe genut tips und Hinweise bekommen, die ich alle erst einmal Umsetzen muss. Danke dafür @all
Hab ich H. schrieb: > Du könntest auf dem Ding Linux installieren, und dich wundern was das > Teilnoch alles kann nach all der zeit :) Auf dem Ding lief seinerzeit bereits primär ein FreeBSD, und mit dem haben wir DVDs geguckt, ruckelfrei. Aber davon ist es nun schon lange entlastet. Vermutlich ist das alte FreeBSD sogar noch auf der Platte drauf, aber da der einzige Zweck der Kiste der Betrieb des UP2000 ist, wurde das wohl auch schon ein Jahrzehnt lang nicht mehr gebootet.
Es sollte auch nicht unerwähnt bleiben, dass USB zu RS232 nicht gleich USB zu RS232 ist. Die einen werden unter Linux (Raspbian) als /dev/ttyUSBn, die anderen als /dev/ttyACMn angesprochen (n = fortlaufende Nummer). Wenn der Adapter nicht identisch ist, kann dies die Ursache sein. Testweise kannst Du von Hand ein neues Device mit genau der Major und Minor ID des schon vorhandenen Devices aber mit genau der anderen Bezeichnung anlegen. Kommando dazu ist mknod.
1 | # ls -l /dev/ttyUSB0 |
2 | crw-rw-rw- 1 root dialout 188, 0 Nov 9 05:38 /dev/ttyUSB0 |
3 | # mknod --help |
4 | Usage: mknod [OPTION]... NAME TYPE [MAJOR MINOR] |
5 | [...] |
6 | # mknod /dev/ttyACM0 c 188 0 |
... oder umgekehrt. (ACM -> USB) Das machst Du natürlich als root (sieht man auch am #) und setzt dann auch gleich die Rechte entsprechend (chown bzw. chgrp). Sollte das der Fall sein, musst Du schauen, ob Dein System das so behält, oder ob der das nach eine reboot wegfegt. Dann müsstest Du die Regeln zur Erzeugung der devices ändern. Gruß Jobst
Jobst M. schrieb: > Die einen werden unter Linux (Raspbian) als /dev/ttyUSBn, die anderen > als /dev/ttyACMn angesprochen (n = fortlaufende Nummer). Wenn der > Adapter nicht identisch ist, kann dies die Ursache sein Das sind allerdings Treiberdetails, die auf API-Ebene keine Rolle mehr spielen sollten. Unter FreeBSD beispielsweise heißen die devices dann alle /dev/ttyU*, egal ob sie nun vom FTDI- oder anderen Treibern stammen. Auch unter Linux haben sowohl FTDI als auch PL2303 /dev/ttyUSB* als Namen. /dev/ttyACM* wird dort nur für CDC-Geräte (generische Modemgeräte gemäß USB-Standard statt irgendwelcher Hersteller-Spezifika) angelegt. Das Erzeugen von irgendwelchen device nodes mit der Hand war schon immer eine schlechte Idee. Weiß gar nicht, ob Linux das überhaupt noch zulässt, bei FreeBSDs device filesystem geht das eh nicht mehr. Summa summarum: daran liegt es ganz bestimmt nicht – zumal er ja auch über den PL2303 "irgendwie" kommunzieren kann, nur eben nicht so, wie die Relaiskarte da haben will.
Jörg W. schrieb: > Unter FreeBSD beispielsweise heißen die devices dann > alle /dev/ttyU*, egal ob sie nun vom FTDI- oder anderen Treibern > stammen. Auch unter Linux haben sowohl FTDI als auch PL2303 /dev/ttyUSB* > als Namen. /dev/ttyACM* wird dort nur für CDC-Geräte (generische > Modemgeräte gemäß USB-Standard statt irgendwelcher Hersteller-Spezifika) > angelegt. Trifft auf Raspbian nicht komplett zu. Jörg W. schrieb: > Das Erzeugen von irgendwelchen device nodes mit der Hand war schon immer > eine schlechte Idee. Weiß gar nicht, ob Linux das überhaupt noch > zulässt Um Fehler zu finden ist es legitim. Früher ging es gar nicht anders. Und natürlich lässt es das noch zu, da es immer wieder Situationen gibt in denen man dies benötigt. Gerade bei der Entwicklung und Fehlersuche. Jörg W. schrieb: > Summa summarum: daran liegt es ganz bestimmt nicht Naja, ich habe mich beruflich das letzte halbe Jahr u.a. damit beschäftigt und hatte genau hier 'Probleme'. Auf dem RasPi, mit /dev/ttyUSBn und /dev/ttyACMn. > – zumal er ja auch > über den PL2303 "irgendwie" kommunzieren kann, nur eben nicht so, wie > die Relaiskarte da haben will. Das spricht allerdings dafür, dass dies nicht sein Problem ist. Vielleicht sollte man mal schauen, was ankommt und was erwartet wird. Aber da ist man ja schon bei, wenn ich das richtig sehe. Was mir während meiner USB-Adapter Tests mit Python auf dem Pi aufgefallen ist, ist, dass sich die unterschiedlichen Chips unterschiedlich verhalten. Gerade was das senden der ersten Zeichen nach dem anstecken betrifft. Die bis zu 3 ersten Zeichen kommen z.T. nicht an. Bei der Suche nach Lösungen konnte ich zwar feststellen, dass ich mit dem Problem nicht alleine bin, aber eine Lösung habe ich dafür nicht finden können. Ob dies also seinen Ursprung im RasPi, Raspbian bzw. Kernel, Python oder dem Chip hat, kann ich daher nicht sagen. Sollte die Anwendung des TO unter Python laufen, wäre dies also auch noch eine Möglichkeit: Python up- oder downgrade. Unter c klappt es chipspezifisch aber immer gleich, so dass man sogar Zeiten nehmen kann, wann die Kommunikation einsetzt. (Was die von mir geschriebene Software u.a. tut. Und bevor Fragen dazu kommen: Die Software testet die Funktionalität der USB-Kommunikation unserer Produkte. Dazu zählt auch die Messung von Zeiten, auch wann die angeschlossene Sensorik über USB mit Spannung versorgt wird und antworten kann, nachdem sie gebootet hat. Notwendig ist dies, da die User-SW auf dem Host nach dem anstecken recht schnell Kommandos auf die Schnittstelle feuert und sich bei unbeantworteten Kommandos verheddert und den Sensor nicht erkennt. Aber das möchte man nicht ändern ... Die Argumente dafür kann ich z.T. allerdings auch verstehen. egal.) Gruß Jobst
Jobst M. schrieb: > Jörg W. schrieb: >> Unter FreeBSD beispielsweise heißen die devices dann >> alle /dev/ttyU*, egal ob sie nun vom FTDI- oder anderen Treibern >> stammen. Auch unter Linux haben sowohl FTDI als auch PL2303 /dev/ttyUSB* >> als Namen. /dev/ttyACM* wird dort nur für CDC-Geräte (generische >> Modemgeräte gemäß USB-Standard statt irgendwelcher Hersteller-Spezifika) >> angelegt. > > Trifft auf Raspbian nicht komplett zu. Was denn genau nicht? Das ACM stammt dabei aus dem USB-Standard. Für die direkten Chips haben sie halt USB als Namen benutzt. > Jörg W. schrieb: >> Das Erzeugen von irgendwelchen device nodes mit der Hand war schon immer >> eine schlechte Idee. Weiß gar nicht, ob Linux das überhaupt noch >> zulässt > > Um Fehler zu finden ist es legitim. In meinen Augen nicht. > Früher ging es gar nicht anders. Ja, aber jetzt haben wir device filesystems. > Und > natürlich lässt es das noch zu, da es immer wieder Situationen gibt in > denen man dies benötigt. Ich wüsste nicht wieso. Und wie schon geschrieben, unter FreeBSD geht's nichtmal mehr.
1 | root@uriah# ls -l /dev/ttyU2 |
2 | crw------- 1 root wheel 0x1bf Nov 12 14:20 /dev/ttyU2 |
3 | root@uriah# mknod /dev/ttyfoo c 0x1bf 0 |
4 | mknod: /dev/ttyfoo: No such file or directory |
Dass sich die einzelnen Chips unterschiedlich verhalten, verwundert mich nun wiederum nicht so sehr.
Ich möchte an dieser Stelle anmerken, das durch die Zerstörung des funktionierenden Ursprünglichen PIs und der Wechsel auf einen PC mit "echtem" COM Port. die Karte bis heute funktioniert. Der shield war auf dem PI ubrigens als /dev/ttyAMA0 gemeldet. Ich betreibe den Adapter jedoch nicht an an einen PI sondern an einem PC mit "echtem"COM port.(rs232) Der Hinweis mit den Treibern galt scheinbar nur für Windows da die Linuxer das Problem eher bemerkt/eher gefixt haben. Was ich die Tage mal machen werde ist einfach rx und tx auf der 232 seite des Adapters kurzschließen (meinetwegen mit nem widerstand) und schauen ob ich das was ich sende auch 1:1 zurück bekomme. Alles andere muss warten bis das Zeug was ich bestellt habe da ist. :) Folgenden Aufbau werde ich morgen mal versuchen : PC->Adapter->MAX232->Arduino-Nano-Brücke rx/tx und schaun was ich bekomme. LG
Hab ich H. schrieb: > Der shield war auf dem PI ubrigens als /dev/ttyAMA0 gemeldet. Das ist eine 'echte' UART des RasPis. Gruß Jobst
Kurzes Update. Habe am Adapter mittels Widerstand RX und TX kurzgeschlossen. Mit cutecom bekomme ich die Eingabe auch als Ausgabe bzw umgekehrt. Immerhin ist das Geraffel in der Lage mit sich selbst zu reden. :) Sowie ich einen der MAX232 wiedergefunden habe seufz mache ich da mal weiter. LG
Hab ich H. schrieb: > Immerhin ist das Geraffel in der Lage mit sich selbst zu reden. :) Das redet auch mit anderen, keine Sorge. Ich habe selbst auch mehrere PL2303 rumliegen, die hat hier im Forum mal jemand verschenkt, weil die Windowstreiber so miserabel sind. Unter Linux und FreeBSD gehen sie.
Ich habe vor kurzem von einem in diesem Forum verhassten österreichischen Shop einen USB TTL Adapter erhalten. Kein Problem mit den Treibern. Musst aber selber googlen, da alle Links, die auch nur den Name des Shop Betreibers enthalten sofort gelöscht werden. Google Stichwort: USB AUF UART TTL ADAPTER MIT CP2102 UND DTR AUSGANG
Redwik schrieb: > österreichischen Shop einen USB TTL Adapter erhalten. > Kein Problem mit den Treibern. Da im Loop Modus (rx,tx gebrückt) die Kommunikation Funktioniert, sowie die Relaiskarte an einem Hardware Com port Funktioniert, wird das Problem wie viele hier auch schon vermutet haben das timing sein. Ich habe vorhin mal ganz Frech die Relaisarte an den Adapter geklemmt und mich mit cutecom aufgeschaltet. Also ich kann zur Karte senden, und die antwortet auch etwas. Ich bekomme diversen Hexcode zurück. Es ist also Kommunikation da, nur eine Kleinigkeit passt nicht. Möglicherweise könnte ich im original Quellcode von Thomas Dohl ein delay einfügen und es damit mal testen..
Redwik schrieb: > USB AUF UART TTL ADAPTER MIT CP2102 Es geht hier bloß um einen PL2303 … Hab ich H. schrieb: > Möglicherweise könnte ich im original Quellcode von Thomas Dohl ein > delay einfügen und es damit mal testen.. Versuche mal zu verstehen, was da wie passiert, und pack dann gezielt ein Delay rein an einer Stelle, wo er auf eine Antwort wartet.
Gerade mal reingeschaut, ein bisschen seltsam ist das schon:
1 | int
|
2 | sndcmd (const int fd, const unsigned char command, const unsigned char addr, const unsigned char data) |
3 | {
|
4 | …
|
5 | usleep (200000L); /* 200 ms Pause, Pause für die Karte */ |
6 | i = write (fd, wbuf, 4); |
Er hat da 200 ms Wartezeit vor dem Senden des Kommandos – danach geht es aber sofort weiter. Ich würde auch danach mal 10 ms oder so warten.
Redwik schrieb: > Ich habe vor kurzem von einem in diesem Forum verhassten > österreichischen Shop einen USB TTL Adapter erhalten. > Kein Problem mit den Treibern. > Musst aber selber googlen, da alle Links, die auch nur den Name des Shop > Betreibers enthalten sofort gelöscht werden. Unsere tägliche Verschwörungstheorie gib' uns heute. Du lügst.
Jörg W. schrieb: > Er hat da 200 ms Wartezeit vor dem Senden des Kommandos – danach geht > es aber sofort weiter. > > Ich würde auch danach mal 10 ms oder so warten. Ich hab heute keine Zeit, ich werde das morgen mal testen und berichten. LG
Stefan F. schrieb: > Prolific unterstützt die alten Revisionen des Chips nicht mehr, seit sie > in großen Stil gut funktionierend gefälscht werden. Das Problem ist hauptsächlich Windows 10, was nach Installation des funktionierenden Treibers, den sofort wieder runterschmeißt und durch Müll ersetzt (Error Code 10). Hier gibt es eine Lösung: http://www.ifamilysoftware.com/Prolific_PL-2303_Code_10_Fix.html Warum sollte man einwandfreie Hardware wegschmeißen, nur weil Winzigweich es so will.
Die Verwirrung ist hauptsächlich dadurch entstanden, daß in der Maker-Szene USB-UART Konverter aufgetaucht sind, die kein RS232 sprechen. Ist der Ruhepegel -12V .. -3V, dann ist es RS232-Pegel und man benötigt zum MC einen Transceiver, z.B. MAX232. Ist der Ruhepegel +2,4V .. +5V, dann ist es TTL-Pegel, d.h. die nackten IO-Pins des USB-Chips. Die muß man dann direkt mit der UART des MC verbinden. Man kann noch zum Schutz Treiber dazwischen schalten, z.B. SN74LVC2G17. Die machen auch die Pegelwandlung 5V zu 3,3V, Live Insertion und Back-Drive Protection.
Peter D. schrieb: > daß in der Maker-Szene USB-UART Konverter aufgetaucht sind, die kein > RS232 sprechen. Von "Makern" hängt das nicht ab. Auch sonst ist sowas sinnvoll, wenn man einen Controller an USB bringen will. Dresden Elektronik hatte solche Teile schon vor mehr als 10 Jahren (wenngleich viel teurer als die heutigen Billigteile). OK, wäre natürlich die Frage, ob der TE aus Versehen sowas benutzt. Vielleicht kann er ja mal aufschreiben, was er genau hat.
:
Bearbeitet durch Moderator
Peter D. schrieb: > Das Problem ist hauptsächlich Windows 10, was nach Installation des > funktionierenden Treibers, den sofort wieder runterschmeißt und durch > Müll ersetzt (Error Code 10). > Hier gibt es eine Lösung: > http://www.ifamilysoftware.com/Prolific_PL-2303_Code_10_Fix.html > > Warum sollte man einwandfreie Hardware wegschmeißen, nur weil > Winzigweich es so will. Nicht ganz korrekt. Microsoft trägt nur den Treiber des Herstellers weiter. Dieser hat irgendwann entschieden, Hardware V1.3 (war es glaube ich) nicht mehr zu unterstützen. Da geht die Hardware dann nach einem Windowsupdate eben nicht mehr und der Windoser muss Ersatz kaufen. Ein Grund, diesen Hersteller zu meiden, denn auch aus klimatischen Gründen finde ich es eine Frechheit. Peter D. schrieb: > Die Verwirrung ist hauptsächlich dadurch entstanden, daß in der > Maker-Szene USB-UART Konverter aufgetaucht sind, die kein RS232 > sprechen. Die Verwirrung liegt aber nicht daran. Die Verwirrung ist bei denen schon eingebaut. Also bei den Makern. Die Konverter können nichts dafür - da ist alles eindeutig. Gruß Jobst
Jörg W. schrieb: > OK, wäre natürlich die Frage, ob der TE aus Versehen sowas benutzt. > Vielleicht kann er ja mal aufschreiben, was er genau hat. Also den Adapter/Konverter den ich benutze ist der hier : https://www.amazon.de/gp/product/B01LVYR1AB/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 Der andere liegt irgendwo in in der Krimskramskiste, den find ich so schnell nicht wieder :) Wie Angekündigt spiele ich heute mal mit dem Quellcode herum und berichte später das Ergebnis. LG Edit ich lese in der Produktbeschreibung gerade das das Teil 500GB Arbeitsspeicher hat, Krass. :)
:
Bearbeitet durch User
Hab ich H. schrieb: > Sowie ich einen der MAX232 wiedergefunden habe seufz mache ich da mal > weiter. viele 232 sind 5V Typen, am PI mehr als unglücklich, du willst dir keine weiteren Fehlerquellen einbauen, du willst Fehler finden, also beschaffe dir 3,3V Typen a la max3232 und versorge den MAX3232 aus 3.3V damit dem PI die Pegel schmecken! MAX3232 Vcc 3V to 5.5V max232 https://www.ti.com/lit/ds/symlink/max232.pdf Vcc min 4.5V ST232 https://datasheetspdf.com/datasheet/ST232.html SUPPLY VOLTAGE RANGE: 4.5 TO 5.5V
:
Bearbeitet durch User
Jörg W. schrieb: > int > sndcmd (const int fd, const unsigned char command, const unsigned char > addr, const unsigned char data) > { > … > usleep (200000L); /* 200 ms Pause, Pause für die Karte */ > i = write (fd, wbuf, 4); usleep (200000L); // 100 ms Pause, Pause für die Karte i = write (fd, wbuf, 4); tcdrain (fd); // wait till the output has been transmitted usleep (10000L); << eingefügt g_lli_time1 = get_time (NULL); // store send time if (4 == i) return (0); Es funktioniert! Schei.... die Sch... funktioniert ! Ich bin so froh ! Jetzt kommt Problem Nummer 2.Ich bin mir sicher da könnt Ihr mir auch weiterhelfen. Ich benutze nämlich nicht dieses Programm zum Ansteuern (zum testen war es aber einfacher, da ich den Quellcode zumindest Ansatzweise nachvollziehen kann.) Ich benutze das "Original" Programm von Thomas Dohl und Sorry Thomas :) bei dem Quellcode sehe ich nur Blonde,Brünette und Rothaarige.. Da seine Seite scheinbar nimmer Online ist, Häng ich das mal hier an. Vielleicht kann jemand darüber schauen und nun Tip geben wo da ein delay rein muss.
Hab ich H. schrieb: > Also den Adapter/Konverter den ich benutze ist der hier Das ist voller RS-232-Pegel. Das andere Programm guck ich mur heute Abend an.
Ich würde vor dem "return 1;" in der Funktion SENDEN() ein
1 | usleep(10000); |
einfügen. Das Programm hat allerdings arge Designschwächen. Insbesondere öffnet es den seriellen Port mehrmals, ohne ihn anschließend zu schließen. Wenn das mit dem einfachen Warten nicht funktioniert, würde ich das so umbauen, dass der Port nur noch ein einziges Mal pro Programmlauf geöffnet wird.
Jörg W. schrieb: > Ich würde vor dem "return 1;" in der Funktion SENDEN() ein > usleep(10000); > > einfügen. > > Das Programm hat allerdings arge Designschwächen. Insbesondere öffnet es > den seriellen Port mehrmals, ohne ihn anschließend zu schließen. Wenn > das mit dem einfachen Warten nicht funktioniert, würde ich das so > umbauen, dass der Port nur noch ein einziges Mal pro Programmlauf > geöffnet wird. Ich habe es mit usleep probiert, auch in den anderen Funktionen, leider ohne Erfolg. Als nächstes habe ich die fd=open.. alle bis auf den ersten Auskommentiert, leider hängt das Programm dann. ein fd=close... Akzeptiert der compiler nicht. Noch ne Idee? LG
Hab ich H. schrieb: > ein fd=close... Akzeptiert der compiler nicht. > Noch ne Idee? Vielleicht mal die Grundlagen von C lernen. Oder wenigstens die Doku der Befehle lesen, die man benutzt. Die open Funktion liefert ein Datei-handle zurück, das ist eine Zahl! Alle weiteren Zugriffe auf die Datei (bzw. den seriellen Port) müssen diese Nummer wieder benutze. Auch wenn man etwas schließt, muss man angeben, was man schließen will. https://man7.org/linux/man-pages/man2/close.2.html
Ist auch keine sinnvolle Strategie. Man sollte die Variable fd global machen und dann nur beim ersten Versuch öffnen. Das close(fd) kann man sich dann sparen, wird bei Programmende eh geschlossen. Der komplette Stil des Programms ist leider, naja, sagen wir mal arg gewöhnungsbedürftig. Es steht Code drin, der gar nicht benutzt wird, teils auskommentiert, teils einfach so. Sowas sollte man einer Versionsverwaltung überlassen. Inwiefern ein permanentes tcflush() vor jedem read() oder write() sinnvoll ist oder vielleicht zu den hier berichteten Problemen führt, ich hätte es jedenfalls in Verdacht. Auch sollte man O_NONBLOCK nach den Öffnen rücksetzen. Insgesamt ist mein Vertrauen in das Teil nicht sonderlich hoch. Warum muss es unbedingt das sein und nicht das andere, was bei dir schon funktioniert?
Jörg W. schrieb: > Insgesamt ist mein Vertrauen in das Teil nicht sonderlich hoch. Warum > muss es unbedingt das sein und nicht das andere, was bei dir schon > funktioniert? Nun, der Aufbau ist der, das ich mir für die Hausautomation eine GUI in Gambas geschrieben habe, die auf dem Hauptrechner läuft und dann mittels ssh das Relaisprogramm auf dem Steuer-PC anspricht, Parameter übergibt und ausliest. Nun wäre es nicht allzu schwierig die übergebenen Parameter an das funktionierende Programm anzupassen. Allerdings ist die Abfrage und Auswertung der eingelesenen Parameter bei beiden Relaisprogrammen komplett unterschiedlich. Während beim "status" Befehl von Thomas Dohl die Rückmeldung kommt : Relais 1 ist aus, Relais 2 ist an usw bekomme ich bei dem anderen nur einen Zahlencode von 0 bis 255.. Ich sehe noch keine Logik dahinter, und müsste halt einen ganzen Teil der GUI umschreiben und herausfinden was diese Zahlencodes bedeuten. Das möchte ich natürlich vermeiden da das viel Arbeit bedeuten würde. Vielleicht hat ja jemand die Lust und die Zeit sich der Sache Programmiertechnisch anzunehmen? Ich würde das natürlich belohnen. LG
:
Bearbeitet durch User
Hab ich H. schrieb: > bekomme ich bei dem anderen nur einen Zahlencode von 0 bis 255.. > Ich sehe noch keine Logik dahinter Naaaa, das ist bestimmt nur ein zufälliger Code, da lohnt es sich gar nicht erst Gedanken drüber zu machen .... +seufz+ Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > Naaaa, das ist bestimmt nur ein zufälliger Code, da lohnt es sich gar > nicht erst Gedanken drüber zu machen .... > > +seufz+ Einen Beitrag weiter oben schrieb ich das sich mir die Logik dahinter noch verschließt.. Das könnte man meinen sollte ein Indiz sein das ich mir Gedanken darüber mache was das zu Bedeuten hat, oder? Das der nicht Zufällig ist sollte klar sein, aber du darfst mich gerne Erhellen! LG
Hab ich H. schrieb: > bekomme ich bei dem anderen nur einen Zahlencode von 0 bis 255.. > Ich sehe noch keine Logik dahinter Lass mich raten: Relais 0 angezogen: 1, Relais 1 angezogen: 2, Relais 0 + 1 angezogen: 3, usw.?
Jörg W. schrieb: > Lass mich raten: Relais 0 angezogen: 1, Relais 1 angezogen: 2, Relais 0 > + 1 angezogen: 3, usw.? Wenn es SO einfach wäre, denke ich wär ich drauf gekommen. Ich habe nicht alle Stellungen durchgespielt.. Relais 3 + 5 ergibt den Code 20 Alle an ergibt 255 was noch Sinn ergibt. Ich werde morgen mal einige Kombinationen durchprobieren und die Ergebnisse hier Posten, vielleicht kommen wir ja zusammen drauf. :) LG
Hab ich H. schrieb: > Relais 3 + 5 ergibt den Code 20 Also 16 (Relais 5) plus 4 (Relais 3)? LG, Sebastian
Selbst, wenn du deine Ansteuerung nicht ändern willst, wäre es vermutlich einfacher, das funktionierende Programm dahin zu biegen, dass es die von dir gewünschten Ein-/Ausgaben handhabt, statt das andere Programm mit dem sehr undurchsichtigen Programmierstil, den es hat, jetzt auf Teufel komm raus zum Laufen bringen zu wollen.
Jörg W. schrieb: > Selbst, wenn du deine Ansteuerung nicht ändern willst, wäre es > vermutlich einfacher, das funktionierende Programm dahin zu biegen, dass > es die von dir gewünschten Ein-/Ausgaben handhabt, statt das andere > Programm mit dem sehr undurchsichtigen Programmierstil, den es hat, > jetzt auf Teufel komm raus zum Laufen bringen zu wollen. Da stimme ich dir 100% zu. Ich bin nur nicht in der Lage das zu tun. Fassen wir zusammen : Der funktionierende Sourcecode steht zur Verfügung. Der nicht funktionierende ebenso. Alles was jetzt getan werden muss, ist das jemand der C programmieren kann sich die Stunde ? 2 ? Zeit nimmt das zu machen weil ich es nicht kann. Wie ich bereits schrieb, ich gebe auch gerne Geld aus dafür. Ich stelle natürlich auch den Sourcecode der GUI zur Verfügung falls das notwendig ist. Ich denke 50,- ist ein faires Angebot. Bezahle ich auch in Kaffee oder Zigaretten :) LG
Geld braucht dafür keiner bzw. wenn man es kommerziell macht, willst du das nicht bezahlen. Folglich: beschreibe deine Anforderungen, möglichst exakt. Beschreibe, wie du (mit welchen Parametern und welchen Ergebnissen) du das bisherige Programm benutzt hast. Dann finde raus, wie du das gleiche mit dem neuen, funktionierenden Programm ausführen würdest. Je detaillierter du bist, um so wahrscheinlicher, dass sich jemand der Aufgabe annimmt.
Jörg W. schrieb: > Geld braucht dafür keiner bzw. wenn man es kommerziell macht, willst du > das nicht bezahlen. > > Folglich: beschreibe deine Anforderungen, möglichst exakt. Beschreibe, > wie du (mit welchen Parametern und welchen Ergebnissen) du das bisherige > Programm benutzt hast. Dann finde raus, wie du das gleiche mit dem > neuen, funktionierenden Programm ausführen würdest. > > Je detaillierter du bist, um so wahrscheinlicher, dass sich jemand der > Aufgabe annimmt. Vielen Dank für den Hinweis. Die Zusammenstellung wird allerdings einen Moment brauchen. Mindestens einen Kaffee schulde ich dir allerdings sowieso. :) Du hast nicht eine Donation Seite oder sowas ? LG
Nö, hab ich nicht. Mein Job ist ausreichend gut bezahlt, der Rest ist Hobby und darf mir Spaß machen.
Jörg W. schrieb: > Nö, hab ich nicht. Mein Job ist ausreichend gut bezahlt, der Rest ist > Hobby und darf mir Spaß machen. Schön. Solltest du Jemals ein Auto Besitzen, oder ein Boot oder eine Maschine die nicht fliegen kann, werde ich dir helfen wenn du Probleme damit hast. :) LG
Du darfst mir gern den Zylinder an meiner MZ wechseln. :-)) (Man muss den Motor halt ausbauen, da war ich bisher zu faul dazu.)
Jörg W. schrieb: > Du darfst mir gern den Zylinder an meiner MZ wechseln. :-)) > > (Man muss den Motor halt ausbauen, da war ich bisher zu faul dazu.) wenn du mir im Gegenzug ein Funktionierendes Programm lieferst, können wir ins Geschäft kommen :P LG
Ich Repariere seit knapp 35 Jahren Land,Bau,Industriemaschinen sowie PKW,LKW,Fahrräder,Motorräder sowie Boote und kleine Schiffe, Kettensägen und Rasenmäher. Ich habe von Amazone bis Zetor schon alles einmal in der Hand gehabt. Ich kann nach all der Zeit ein Fazit ziehen: Kaufe auf keinen Fall deutsche Maschinen! Die Qualität von vor 30 Jahren gibt es nicht mehr. Eine VW Werkstatt z.b. ist eine Lizenz zum Gelddrucken. Bosch,Metabo... Müll. Kommt alles aus China, und ist schlechter als das was die Chinesen selbst verkaufen. Schonmal in eine MIELE reingeschaut ? Nur noch zum Kotzen!
Hab ich H. schrieb: > Schonmal in eine MIELE reingeschaut ? Jo, selbst schon repariert (Waschmaschine), weil der Schaltnetzteil hochgeflogen war – und zwar nicht nur der Wandler-IC, sondern der hatte auch gleich noch den Trafo weggerissen. Den habe ich neu bewickelt (die Drähte der Sekundärwicklungen ließen sich natürlich wieder verwenden). Ansonsten durchaus solide und reparierbar aufgebaut.
Bei meiner letzten Bomann Waschmaschine hat sich ein Schlauch vom Einspülkasten gelöst. Der Wasserstrahl traf direkt auf die völlig ungeschützt Steuerplatine. Die Maschine war allerdings alt und billig, deswegen hat sich meine Enttäuschung in Grenzen gehalten. Davor hatten wir eine Miele, die machte einen deutlich robusteren Eindruck. Ich musste nur einmal den Propeller von der Abwasserpumpe erneuern. Aber sie stammte aus den 90er Jahren, da gab es scheinbar noch deutsche Wertarbeit.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Aber sie stammte aus den 90er Jahren, da gab es scheinbar noch > deutsche Wertarbeit. Ja, gilt im Grunde für alle Maschinen.. Ich hatte einen kleinen "Unfall", da ich auf dem eigentlichen Steuer-PC das Programm nicht compilen kann, und mein Nachbar mich zu echtem Thailändischen Schnaps eingeldaen hatte. Ich sag euch, das Zeug macht rm -r /brain! Ich hab keine Ahnung wie spaä dasist, aber da der PC mein Passwort akzeptiert hat bin ich wohl Zuhause- Ich schätze die einfachse Möglichkeit ist es die 64? möglichkeiten der reihe nachauszuprobieren, und mein Programm umzuschreiben. LG
Hab ich H. schrieb: > Ich schätze die einfachse Möglichkeit ist es die 64? möglichkeiten der > reihe nachauszuprobieren, und mein Programm umzuschreiben. Nein, das einfachste wäre es, wenn du ein "Lastenheft" erstellst, d.h. deine Anforderungen exakt aufschreibst. * was wird wie aufgerufen? * welche Reaktion wird erwartet? Danach ist es eine Kleinigkeit, das funktionierende Programm umzubauen. Solange du aber nur sagst "passt nicht zusammen", hat keiner eine Idee, was du eigentlich genau willst
Jörg W. schrieb: > Nein, das einfachste wäre es, wenn du ein "Lastenheft" erstellst, d.h. > deine Anforderungen exakt aufschreibst. > > * was wird wie aufgerufen? > * welche Reaktion wird erwartet? > > Danach ist es eine Kleinigkeit, das funktionierende Programm umzubauen. > Solange du aber nur sagst "passt nicht zusammen", hat keiner eine Idee, > was du eigentlich genau willst Nein nein nein :) das eine ist etwas anderes. Der Schnaps war da dem denken arg im weg.. Also du hast natürlich recht das ich genau Angeben muss was ich möchte. Das werde ich auch noch tun. Was ich eigentlich schreiben wollte, war das ich meine GUI erst einmal umschreiben kann, und kann die Platine dann mit dem Adapter z.b. an nem PI erst mal verwenden, ohne das halt immer der PC mit COM-Port laufen muss. Dazu muss ich aber wissen was die codes bedeuten die das Relais Programm zurückliefert. Das habe ich jetzt herausgefunden, ist einfach binär. Eine Zusammenstellung wie genau das "neue" Programm aussehen soll kann ich jetzt ohne Zeitdruck machen und liefere das die Tage nach. LG
Hab ich H. schrieb: > an nem PI erst mal verwenden, ohne das halt > immer der PC mit COM-Port laufen muss. Ich habe mir nicht den ganze Thread durchlesen ... Mit PC läuft deine Relaiskarte ! Warum deine Relaiskarte und dein PC haben die gleiche Schnittstell. (RS232 mit +/-12V Pegeln) Dein Raspi läuft nicht mit der Relaiskarte weil er nicht ab Werk die richtige Schnittstelle hat. Diese kann man aber nachrüsten. Möglichkeit 1) Einen USB zu RS232 Adapter (FTDI FT232, PL2303 oder andere) verwenden. Aufpassen, du brachst einen der auch wirklich RS232 Pegel (+/-12V) ausgibt. Oder es gibt welche die geben 0V bzw 5V Pegel aus und du schaltest noch einen MAX232 dahinter, der daraus die gewünschten +/-12V Pegel macht. Möglichkeit 2) Dein RasPi besitz aber auch eine Serielle Schnittstelle, die man auf der 40Pin GPIO Leiste findet. Da kommt ein Pegel von 0V/3,3V raus. Da kannst du dann einen MAX232 anschließen und du bekommst am Ausgang deine gewünschten +/-12V Pegel. > Das habe ich jetzt herausgefunden, ist einfach binär. Ganz genau wie alles in der digitalen Welt. Alles andere sind nur andere Darstellungen davon.
Martin schrieb: > Ich habe mir nicht den ganze Thread durchlesen ... Ja, das merkt man. Hättest du besser machen sollen. So ist deine Antwort wirklich völlig nutzlos.
Ok, dann schreibe ich nichts mehr in Threads mit mehr als 5 Beiträgen. ;-P Wo schreibt denn jemand etwas über den Seriellen Port des Raspi? Es geht doch immer nur über USB->Seriel. Sich bin ich mir trotzdem nicht ob "hab ich" das verstanden hat.
Er schrieb aber bereits im ersten Beitrag, dass er einen USB-RS232-Adapter benutzt, und im weiteren Verlauf des Threads hat sich gezeigt, dass zumindest eins der verwendeten Programme erfolgreich kommuniziert, wenn man nach dem Absenden des Kommandos 10 ms wartet.
Ich habe aber geschrieben, dass es am Raspi auch ohne den Umweg über USB gehen würde. Das hat noch keiner in Betracht gezogen.
Martin schrieb: > Ich habe aber geschrieben, dass es am Raspi auch ohne den Umweg über USB > gehen würde. Ja, wenn er sein MAX232-Board noch findet, wäre das vielleicht auch 'ne Variante. Wobei natürlich keiner weiß, ob so ein vom Timing her auf Kante genähtes Programm dann noch geht.
Martin schrieb: > Ich habe aber geschrieben, dass es am Raspi auch ohne den Umweg über USB > gehen würde. Das hat noch keiner in Betracht gezogen. Die Ursprünglich funktionierende Varianta war ja bis zum Wasserschaden auch RasPI->Shield->RS232->Platine Dort hat das Programm von Thomas Dohl funktioniert. Leider hat das Wasser nicht nur den PI sondern auch den Shield zerstört, und ein neuer PI mit neuem Shield, war nicht dazu zu überreden mit der Karte zu kommunizieren. Das Setzen der Parameter wurde dabei überprüft und auf das neuere PI Modell angepasst. Bevor wir uns jetzt in "aber da sind noch 753 andere Möglichkeiten" Verstricken.. ..Fasse ich kurz zusammen was wir bereits herausgefunden haben, damit ein "Ich habe nicht den ganzen Thread gelesen" - Mensch hier direkt alle Infos hat :) Das Relaisprogramm von Thomas Dohl kürze ich mit TD ab, das andere dessen Autor mir gerade nicht einfällt mit Alternativ Programm AP. Ursprünglich: PI->TD->Shield->232->Platine OK Neu: neu_Pi->TD->neu_shield->232->Platine NOK PC(COM port)->TD->Platine OK PC->TD->USB->232->Platine NOK PC->AP->USB->232->PLatine NOK PC->AP_delay-eingefügt->USB->232->Platine OK Ich Schreibe jetzt erst einmal die GUI um, ist zwar Aufwand aber ich habe eh Urlaub.. damit ich den USB/232 Adapter mit dem AP verwenden kann um den Stromfresser aus dem System zu haben. Dann mache ich eine Aufstellung was genau ich für ein Programm benötige, was es können soll und welche i/o ich erwarte. Zur Verfügung stelle ich die Quellcodes(Alle open source/gpl ) von TD sowie AP als auch von Conrad. LG
Jörg W. schrieb: > Ja, wenn er sein MAX232-Board noch findet, wäre das vielleicht auch 'ne > Variante. ist nicht sinnvoll weil wie ich schon zeigte die meisten 232 Chips mehr als 4.5V Vcc wollen Beitrag "Re: seriell FTDI TTL UART SUART ich blicke nicht mehr Durch!" am PI aber nur 3,3V genutzt werden sollte -> MAX3232
:
Bearbeitet durch User
Off Topic! Scheiss SSDs. mir ist Gestern eine gestorben, einfach so, keine smart errors keine Warnung - nichts, einfach nach einschalten tot. mit 210 stunden laut letztem smart Bericht. Also ein Datenspeicher der nach etwa 3.5 Jahren einfach so Kaputtgeht.. sorry die Ära SSD endet bei mir heute. Ich kaufe wieder drehenden Speicher solange ich noch welchen bekomme! LG Edit: Und bevor jetzt die Fanboys wieder aus ihrer Ecke kommen, die stats(gekürzt) der drehenden Speicher:
1 | Hitachi Deskstar 7K1000.D |
2 | 9 Power_On_Hours 0x0012 095 095 000 Old_age Always - 37712 |
3 | 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 |
4 | ---- |
5 | Hitachi Deskstar P7K500 |
6 | 9 Power_On_Hours 0x0012 092 092 000 Old_age Always - 56751 |
7 | 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 |
8 | ---- |
9 | Seagate Barracuda 7200.12 |
10 | 9 Power_On_Hours 0x0032 070 070 000 Old_age Always - 26680 |
11 | 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 |
12 | ---- |
13 | Toshiba 2.5" HDD MQ01ABD... |
14 | 9 Power_On_Hours 0x0032 043 043 000 Old_age Always - 23152 |
15 | 5 Reallocated_Sector_Ct 0x0033 100 100 050 Pre-fail Always - 0 |
sorry musste ich loswerden, bin grad etwas ange**** 230GB daten - weg. Nichts wichtiges, aber dennoch. LG
:
Bearbeitet durch Moderator
Hab ich H. schrieb: > sorry die Ära SSD endet bei mir heute Dann mal viel Spaß für die Zukunft … wird schwer werden, ohne SSDs auszukommen.
Jörg W. schrieb: > Dann mal viel Spaß für die Zukunft … wird schwer werden, ohne SSDs > auszukommen. Bevor ich wichtige Daten auf ner SSD speichere, druck ich die lieber aus! :P LG
Tja, wenn du meinst. Wichtige Daten haben ein Backup. Alles andere ist per Definition unwichtig. Ich habe jedenfalls bislang schon mehr kaputte HDDs als SSDs gesehen, auch welche, die von einen Tag auf den anderen gestorben sind. Das ist also kein Alleinstellungsmerkmal von SSDs …
Mein lieber Jörg. Ich verbaue seit über 35 Jahren Festplatten aller Hersteller. SCSI halten am längsten Jörg W. schrieb: > Wichtige Daten haben ein Backup. Alles andere ist per Definition > unwichtig. > > Ich habe jedenfalls bislang schon mehr kaputte HDDs als SSDs gesehen, > auch welche, die von einen Tag auf den anderen gestorben sind. Das ist > also kein Alleinstellungsmerkmal von SSDs … Wenns Western Digital oder Maxtor sind hast du recht. Ich habe allerdings noch nie eine Quantum wegen Defekt ausgemustert, sondern weil zu klein. Seagate ist so lala Hitachi derzeit mein Favourit, Toshiba auch. Excelstore war gut, gibt es aber glaube ich nicht mehr. LG
Jörg W. schrieb: > Ich habe jedenfalls bislang schon mehr kaputte HDDs als SSDs gesehen ich habe mehr kaputte flash Speicher gehabt als kaputte Magnetplatten, weil ich die Magnetplatten tausche wenn sie zu eng werden, ein eingerichteter Flash Speicher wird mir noch nie zu eng, kann ja noch werden, in meine neuen Laptops, dabei rumstehend bevorzuge ich Festplatten unterwegs lieber nichts mechanisch drehendes.
:
Bearbeitet durch User
Hab ich H. schrieb: > SCSI halten am längsten Insgesamt schon, weil es da praktisch nur noch Serverplatten gibt (mittlerweile halt SAS), keine Billigheimer. Habe ich auch lange als Arbeitstiere benutzt, bis sie zu klein waren, aber seither sind da zwei gespiegelte SSDs. >> Ich habe jedenfalls bislang schon mehr kaputte HDDs als SSDs gesehen, >> auch welche, die von einen Tag auf den anderen gestorben sind. Das ist >> also kein Alleinstellungsmerkmal von SSDs … > > Wenns Western Digital oder Maxtor sind hast du recht. WD habe ich nie groß in den Fingern gehabt. Maxtor war meine erste Gigabyte-Platte. Dass sie gestorben ist, dürfte an mangelnder Kühlung gelegen haben, war auch nicht von heute auf morgen, war trotzdem traurig. Hatte mal richtig viel Geld gekostet. > Ich habe allerdings noch nie eine Quantum wegen Defekt ausgemustert, Uff, Quantum hat zumindest eine Zeitlang ziemlichen Schrott gebaut. Da hatten sie versucht, SCSI-Lowend-Platten zu bauen (Fireball? Weiß nicht mehr). > Seagate ist so lala Hitachi derzeit mein > Favourit, Toshiba auch. Hitachi, Toshiba und Seagate haben schon immer recht gute Serverplatten gebaut. Aber gestorben sind auch die irgendwann, ist halt trotzdem Mechanik, die verschleißt.
Jörg W. schrieb: > Aber gestorben sind auch die irgendwann, ist halt trotzdem > Mechanik, die verschleißt. seit 2004 laufen bei mir Platten im NAS seit 2015 dazwischen sind mir im Raspi schon etliche flash µSD gestorben. Ja die werden kaputt geschrieben, es sei denn man setzt sie auf RO und lagert den Swap auf die Magnetplatte aus!
Jörg W. schrieb: > Hitachi, Toshiba und Seagate haben schon immer recht gute Serverplatten > gebaut. Aber gestorben sind auch die irgendwann, ist halt trotzdem > Mechanik, die verschleißt. Klar! Aber alle die FP sind gestorben nachdem sie (sofern fähig) smart errors gemeldet haben, gerade unter Linux mit aktivierten smartmontools bekommst du normalerweise ein Fenster geöffnet mit dem Hinweis backup your data - NOW! LG
Joachim B. schrieb: > Raspi schon etliche flash µSD gestorben Du meinst aber nicht etwa SD-Karten? Dass man eine SD-Karte im RPi kaputt nuddelt, ist nun schon lange kein Geheimnis mehr. Mit dem Verschleißverhalten einer ordentlichen SSD hat das aber ziemlich genau nichts gemeinsam. Noch schrottiger sind wohl nur USB-Sticks.
Joachim B. schrieb: > seit 2004 laufen bei mir Platten im NAS seit 2015 dazwischen sind mir im > Raspi schon etliche flash µSD gestorben. Ja die werden kaputt > geschrieben, es sei denn man setzt sie auf RO und lagert den Swap auf > die Magnetplatte aus! habs auf nen USB-stick ausgelagert, hat auch funktioniert :) LG
Hab ich H. schrieb: > Aber alle die FP sind gestorben nachdem sie (sofern fähig) smart errors > gemeldet haben Ich schrieb ja, auch dort ist spontanes Ableben möglich. Auch deren Elektronik ist nicht davor gefeit zu sterben.
Jörg W. schrieb: > Ich schrieb ja, auch dort ist spontanes Ableben möglich. Auch deren > Elektronik ist nicht davor gefeit zu sterben. Ja klar ! ist mir aber nie passiert. LG
Hab ich H. schrieb: > ist mir aber nie passiert Mir ist auch noch keine SSD gestorben (USB-Sticks und SD-Karten natürlich schon). So what? Shit happens, und niemand ist davor gefeit. Deshalb SSDs als grundlegend unzuverlässiger darzustellen als HDDs ist, naja, sehr voreingenommen. Wichtige Daten brauchen einen Backup, und wenn das Medium kaputt ist, muss man sie von da zurück holen.
Jörg W. schrieb: > Wichtige Daten brauchen einen Backup, und wenn das Medium kaputt ist, > muss man sie von da zurück holen. Absolut richtig! Bei drehenden Speichern denke ich so ab 12000 Betriebsstunden mal darüber nach ein Backup zu machen. VOR 12000 ist mir noch nie eine Platte verreckt. Aber ein sudden death mit 210 BS.. ? Hmmh. Ausserdem: Wer Backups macht ist feige :P LG
Hab ich H. schrieb: > VOR 12000 ist mir noch nie eine Platte verreckt. Nur, weil es dir noch nicht passiert ist, heißt das nicht, dass es nicht passieren kann. Wer sich jemals mit der "Badewannenkurve" befasst hat weiß, dass gerade die ersten Betriebsstunden eines jeden technischen Geräts ein großes Risiko beinhalten. Nicht umsonst gibt es das Konzept einer Gewährleistung/Garantie, weil es (außer in Spezialanwendungen wie Raumfahrt) niemand bezahlen will, dass der erste Teil der Badewannenkurve bereits durch einen Vorab-Betrieb ("Einbrennen") beim Hersteller durchlaufen wird.
Hab ich H. schrieb: > Aber ein sudden death mit 210 BS.. ? Hmmh. Es hilft dir vermutlich auch nicht viel, wenn ich dir schreibe, dass meine primären (gespiegelten) SSDs hier mit 46000 Betriebsstunden gerade einmal 3 % wear haben (also wear level im SMART 97).
Jörg W. schrieb: > Wer sich jemals mit der "Badewannenkurve" befasst hat weiß, dass gerade > die ersten Betriebsstunden eines jeden technischen Geräts ein großes > Risiko beinhalten. Nicht umsonst gibt es das Konzept einer > Gewährleistung/Garantie, weil es (außer in Spezialanwendungen wie > Raumfahrt) niemand bezahlen will, dass der erste Teil der > Badewannenkurve bereits durch einen Vorab-Betrieb ("Einbrennen") beim > Hersteller durchlaufen wird. Dann habe ich dich Miß Interpretiert/Mißverstanden. Entschuldige. LG
Hab ich H. schrieb: > Aber ein sudden death mit 210 BS.. ? Hmmh. Bedeutet vermutlich, dass du darauf auch noch Gewährleistung hast (wenn du sie nicht vor Inbetriebnahme ewig im Schrank liegen hattest).
Jörg W. schrieb: > Bedeutet vermutlich, dass du darauf auch noch Gewährleistung hast (wenn > du sie nicht vor Inbetriebnahme ewig im Schrank liegen hattest). Dazu muss man wissen, das spinning HDDS ihre Betriebsstunden zählen ab sie Angeschaltet sind. SSDs zählen nur wenn man darauf Zugreift. Heißt : eine Spinning HDD zählt ihre BS nach spinup egal ob du je daten auf sie schreibst, oder abrufst. SSDs funtionieren da anders. Die "Idlen" nicht. Die zählen BS nur wenn auch was passiert. Ja, siwe hat 210 BS in 3.5 Jahren gemacht.. wie lange ist noch Gewährleisung ? waren es 2 Jahre ? Umso Beschämender das die nach 210 BS ausgefallen ist. mMn sollten SSDs nicht nach Jahren sondern nach BS gewertet werden, das wäre fair. für drehende Platten gibt es ja eine Richtlinie von ich glaube 20000 BS, das sollte man auch auf SSDs anwenden. LG
:
Bearbeitet durch User
Hab ich H. schrieb: > SSDs zählen nur wenn man darauf Zugreift. Warum sollten meine dann 46000 h auf dem Buckel haben? Gut, es sind die Systemplatten.
1 | root@uriah:~ # smartctl -a /dev/ada2 |
2 | smartctl 6.6 2017-11-05 r4594 [FreeBSD 12.3-STABLE amd64] (local build) |
3 | Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org |
4 | |
5 | === START OF INFORMATION SECTION === |
6 | Model Family: Samsung based SSDs |
7 | Device Model: Samsung SSD 850 EVO 500GB |
8 | Serial Number: XXXXXXXXXXX |
9 | LU WWN Device Id: XXXXXXXXXXX |
10 | Firmware Version: EMT02B6Q |
11 | User Capacity: 500,107,862,016 bytes [500 GB] |
12 | Sector Size: 512 bytes logical/physical |
13 | Rotation Rate: Solid State Device |
14 | Form Factor: 2.5 inches |
15 | … |
16 | Vendor Specific SMART Attributes with Thresholds: |
17 | ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE |
18 | 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 |
19 | 9 Power_On_Hours 0x0032 090 090 000 Old_age Always - 46009 |
20 | 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 38 |
21 | 177 Wear_Leveling_Count 0x0013 097 097 000 Pre-fail Always - 47 |
22 | 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0 |
23 | 181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0 |
24 | 182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0 |
25 | 183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0 |
26 | 187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0 |
27 | 190 Airflow_Temperature_Cel 0x0032 065 044 000 Old_age Always - 35 |
28 | 195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0 |
29 | 199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 |
30 | 235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 23 |
31 | 241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 76037677598 |
32 | |
33 | SMART Error Log Version: 1 |
34 | No Errors Logged |
35 | … |
> Umso Beschämender das die nach 210 BS ausgefallen ist.
Frühausfall halt, Anfang der Badewannenkurve.
:
Bearbeitet durch Moderator
Hab ich H. schrieb: > sorry die Ära SSD endet bei mir heute Nicht so voreilig! Festplatten können ebenso spontan ausfallen, ist mir einmal passiert.
Jörg W. schrieb: > Warum sollten meine dann 46000 h auf dem Buckel haben? Leider werden diese ganzen SMART Werte bei jedem Produkt anders erfasst. Da gibt keinen vernünftigen Standard und vergleichbar sind sie deswegen leider auch nicht.
Das bedeutet dann allerdings, dass die SSD des TE wohl nicht nur 200 h gelaufen wäre.
Steve van de Grens schrieb: > Leider werden diese ganzen SMART Werte bei jedem Produkt anders erfasst. > Da gibt keinen vernünftigen Standard und vergleichbar sind sie deswegen > leider auch nicht. Jörg W. schrieb: > Das bedeutet dann allerdings, dass die SSD des TE wohl nicht nur 200 h > gelaufen wäre. Wenn das stimmt ist dieser ganze smart-kram aber doch Nutzlos ? wenn jeder es so interpretieren kann wie er gern möchte ? Naja kennt man ja. Aber zurück zum Topic. Ich wünschte ich wäre nicht zu blöd für C! So muss ich mich mit Gambas von einem syntax error zum anderen hangeln. Zum Glück bekommt den Code eh nie jemand zu sehen, so kann sich auch niemand darüber lustig machen :P Ich habe jetzt den Rückgabewert Erfolgreich wieder in den Status der Relais umgesetzt, und bin gerade dabei das in die GUI einzufügen. Ich denke heute Abend funktioniert alle wie es soll. Kleiner Funfact am Rande: Da ich über die GUI immer nur ein Relais zur zeit schalten kann, also nacheinander nicht gleichzeitig, ist mir der BUG nie aufgefallen. das Relaisprogramm kann über die Console natürlich alle Relais gleichzeitig setzen, setze ich Relais 1 und 5 gleichzeitig stürzt die Karte ab. LG
Hab ich H. schrieb: > Ich wünschte ich wäre nicht zu blöd für C Wenn du mal zwei Wochen Langeweile hast würde ich sie lernen. Denn obwohl die Sprache alt und hässlich ist, werden immer noch die meisten Mikrocontroller und PC Betriebssysteme in C geschrieben. Das stirbt so schnell nicht aus. Zudem beruhen viele andere Programmiersprachen auf C. Was du dabei lernst bleibt ganz sicher auch nach dem Tod von C nützlich. Auf einem PC lernt es sich einfacher, als auf einem Mikrocontroller. Ich empfehle dazu die Qt Creator IDE.
:
Bearbeitet durch User
Hab ich H. schrieb: > Wenn das stimmt ist dieser ganze smart-kram aber doch Nutzlos ? wenn > jeder es so interpretieren kann wie er gern möchte ? Zumindest muss man wissen, wie der Hersteller es implementiert. https://de.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology "Daher sind weder die Bedeutung der gespeicherten Werte noch deren Skalierung festgeschrieben" Normalerweise sollten allerdings die power-on hours die gesamte Zeit unter Spannung erfassen (Wikipedia nennt "standby-Zeit" als inkludiert), was gegen deine Behauptung spricht, SSDs würden da nur die aktive Zeit melden. Da du dich aber bislang über Hersteller und Modell der SSD ausschweigst, kann hier auch niemand was genaueres sagen. > Ich wünschte ich wäre nicht zu blöd für C! Wie schon geschrieben wurde, kann man das lernen. Aber ich hätte dir das abgenommen, wenn du eine brauchbare Spec stattdessen geschrieben hättest. Das hätte auch in Prosa sein können, ich hatte da kein C erwartet. ;-)
Jörg W. schrieb: > "Daher sind weder die Bedeutung der gespeicherten Werte noch deren > Skalierung festgeschrieben" Ich habe hier im Dienstrechner eine Samsung-NVMe-SSD, die meldet 291 als power-on "hours". Ich würde an der Stelle eher "days" vermuten – vielleicht ist das ja bei deinen 220 auch so, dass das Tage sind.
Mein Dienstrechner zeigt 1 Jahr und 2 Monate an, das kann hin kommen. Er ist ein paar Jahre alt.
Jörg W. schrieb: > Da du dich aber bislang über Hersteller und Modell der SSD ausschweigst, > kann hier auch niemand was genaueres sagen. Huch hatte ich das nicht? oh hatte ich nicht. Ist.. War eine Intenso 256GB Top. Da die letzte smart Ausgabe in der Console war habe ich kein log und nur die letzten BS im Kopf, sry. Jörg W. schrieb: > Wie schon geschrieben wurde, kann man das lernen. > > Aber ich hätte dir das abgenommen, wenn du eine brauchbare Spec > stattdessen geschrieben hättest. Das hätte auch in Prosa sein können, > ich hatte da kein C erwartet. ;-) Ja, kann man lernen, allerdings ist meine Frust Toleranz sehr gering, und wenn ich 3 stunden brauche um 17400 syntax error später ein "hallo welt!" auf den Bildschirm zu zaubern lasse ich das erst mal wieder monatelang liegen. Programmieren macht mir keinen Spaß, ich tue es nur wenn es Notwendig ist. Son bischen wie Abwaschen :) Ich versinke lieber bis zu den Ellenbögen in einem Getriebe. Das ist meine Obsession. LG
Bei Intenso findet man da leider nichts, nur "Produktdatenblätter". Trotzdem solltest du da noch Gewährleistung drauf haben.
Wo wir gerade beim Frustfaktor sind.. Da das alternativ Programm so komplett anders arbeitet wie das von TD, muss ich noch für jede einzelne Funktion eine if then abfrage schreiben, da ich die Relais nur an oder ausschalten kann, bei TD seinem Programm gab es die Option "lass das so wie es grad ist". Ich konnte also einfach die Sequenz schalte 4 an und lass alle andern so wie sie gerade sind benutzen. Wenn ich jetzt 4 anschalte, schalte ich automatisch alle anderen aus.. Boahhh. Das macht echt keinen Spaß. Hab für heute schon wieder keinen Bock mehr. .. LG
Nochmal: schreib eine Spec, was du haben willst. Das bringt doch nichts, wenn du wie wild mit unpassenden Schraubenschlüsseln im Getriebe rumfuchtelst und versuchst, die Zahnräder da umzuordnen. Beschreibe stattdessen, was das Getriebe genau machen soll und lass es andere nach dieser Beschreibung aufbauen.
Jörg W. schrieb: > Nochmal: schreib eine Spec, was du haben willst. > > Das bringt doch nichts, wenn du wie wild mit unpassenden > Schraubenschlüsseln im Getriebe rumfuchtelst und versuchst, die > Zahnräder da umzuordnen. Beschreibe stattdessen, was das Getriebe genau > machen soll und lass es andere nach dieser Beschreibung aufbauen. Der Vergleich ist Süß :) Aber du hast wie immer Recht. Also was möchte ich ? Ich möchte von beiden Programmen das Beste.. Ich möchte eine Ansteuerung der Relais in diesem Schema haben : Relaisprogramm.bin -d /dev/ttyS0 -i -r 1 -s xx1xxxxx" Also Auswahl des Device, Initialisierung, Kartennummer, setzen der Relais, wobei 0 AUS 1 AN und X let it so bedeutet. Das bedeutet durch das Ändern des Parameters von xx1xxxx auf 1xxxxxxx soll Relais 1 ANgeschaltet werden aber das Relais was bereits AN ist AN bleiben.(3 in diesem Beispiel) Das entspricht genau dem was das Programm von Thomas Dohl macht. Der Rückgabewert ist genau Betrachtet beim Alternativprogramm besser. Der Wert geht von 0 (alle aus) bis 255 ( alle an ) Binär also 00000000 bis 11111111 somit code 20 Relais 3+5 an wären usw. Bei einem Fehler soll das Programm einfach den Rückgabewert "Error" senden nur bei der Option programm -e soll Detailiert wiedergegeben werden was genau die Karte rückmeldet Da alle Sourcen frei sind häng ich die hier an. Weiß nicht wie ich es anders Beschreiben soll, sry. Wenn noch fragen sind - bin am Bildschirm. LG
Das alles nur am Stück zusammen zu hacken, war mir zu blöd. Hab's nach github geschoben: https://github.com/dl8dtl/conrad_8fa_relais/tree/new_option_handling Ein bissel was ist schon fertig, aber das ist noch work in progress.
So, jetzt denke ich, dass das soweit fertig ist. Kannst es mal ausprobieren. Bitte achte drauf, dass du den passenden Branch benutzt, nicht das main.
Jörg W. schrieb: > So, jetzt denke ich, dass das soweit fertig ist. Kannst es mal > ausprobieren. > > Bitte achte drauf, dass du den passenden Branch benutzt, nicht das main. Bin gerade beim testen, aber wie ich es auch drehe und wende, ich bekomme immer die Fehlermeldung : FAIL: card init failed (244 0 0 255). wenn ich das Programm Aufrufe : relais -d /dev/ttyUSB0 und dann egal welche Parameter habe einige Kombinationen durchprobiert. Ich habe mit dem alten Programm natürlich gegengecheckt ob die Karte damit Ansprechbar ist, ist sie. hast du einen Parameter eingebaut den ich Übersehen habe ? habe diesen Branch benutzt : https://github.com/dl8dtl/conrad_8fa_relais/tree/new_option_handling LG
Ich habe nochmal gegen deine Version oben aus dem tar-Archiv verglichen (die ist jetzt auch gleich noch auf einem Branch eingecheckt). Ich hatte das zweite delay zu tief eingebaut, das wurde schätzungsweise gar nicht ausgeführt. Probier bitte nochmal.
Sehr schön! Dann kannst du ja im nächsten Frühjahr mal herkommen, den Zylinder mit mir tauschen. ;-) Falls du nicht gerade hier in der Gegend wohnst, hat das natürlich rein gar keinen Sinn. Irgendeine nennenswerte Anfahrt dafür wäre Verschwendung.
Übrigens ist dieser Sourcecode bei weitem nicht so eigenwillig wie der von Thomas Dohl. Es sind ein paar Dinge drin, die ich so nicht gemacht hätte – zum Behandeln von Optionen gibt es halt seit Urzeiten getopt(), das muss man nicht selbst stricken, und warum er strncmp() statt strcmp() benutzt, obwohl er gar keine begrenzende Länge hat, erschließt sich mir nicht. Grundsätzlich war es aber einfach, sich da drin zu orientieren, auch wenn meine geschätzte halbe Stunde nicht ganz gereicht hat, um es nach deinem "Lastenheft" anzupassen.
Jörg W. schrieb: > Falls du nicht gerade hier in der Gegend wohnst, hat das natürlich rein > gar keinen Sinn. Irgendeine nennenswerte Anfahrt dafür wäre > Verschwendung. Bremen ist von mir etwa 35KM weg, Bremerhaven etwa 20. Jörg W. schrieb: > Übrigens ist dieser Sourcecode bei weitem nicht so eigenwillig wie der > von Thomas Dohl. Es sind ein paar Dinge drin, die ich so nicht gemacht > hätte – zum Behandeln von Optionen gibt es halt seit Urzeiten getopt(), > das muss man nicht selbst stricken, und warum er strncmp() statt > strcmp() benutzt, obwohl er gar keine begrenzende Länge hat, erschließt > sich mir nicht. Grundsätzlich war es aber einfach, sich da drin zu > orientieren, auch wenn meine geschätzte halbe Stunde nicht ganz gereicht > hat, um es nach deinem "Lastenheft" anzupassen. Dann funktionieren die Optionen auch so wie gewünscht ? Dann mach ich n Faß auf :) LG
Hab ich H. schrieb: > Bremen ist von mir etwa 35KM weg, Bremerhaven etwa 20. 500 km entfernt von hier, brauchen wir also nicht drüber nachzudenken. ;-) > Dann funktionieren die Optionen auch so wie gewünscht ? Dann mach ich n > Faß auf :) Das hoffe ich. Die Option -r cardnumber ist allerdings ein Dummy, weil das ursprüngliche Programm eh nur eine Karte unterstützt hat. Das Erkennen dieser Option habe ich also nur eingebaut, um deinem Lastenheft zu genügen. ;-) Man könnte auch sagen, damit es rückwärtskompatibel zum Programm von Thomas Dohl ist. ps: was nicht ganz so ist: Fehler, die eine Weiterführung des Programms unmöglich machen, werden immer gemeldet. Alle "Statusmeldungen" dagegen, die das ursprüngliche Programm gebracht hat, werden jetzt nur mit -e sichtbar.
:
Bearbeitet durch Moderator
Implizit dabei (und von deinem Lastenheft nicht extra spezifziert gewesen) ist, dass das Programm ohne -s relaisliste und ohne -e praktisch nichts ausgibt und nur die Verbindung zur Relaiskarte aktiviert. Die Daten werden zwar abgefragt, aber ohne -e nicht ausgegeben.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Implizit dabei (und von deinem Lastenheft nicht extra spezifziert > gewesen) ist, dass das Programm ohne -s relaisliste und ohne -e > praktisch nichts ausgibt und nur die Verbindung zur Relaiskarte > aktiviert. Die Daten werden zwar abgefragt, aber ohne -e nicht > ausgegeben. Sweit so gut. Ich teste gerade mit dem Programm herum, es funktioniert zwar aber ich kann die Relais immer noch nur an oder abschalten. Da ich aus dem Quellcode nicht richtig schlau werde, habe ich eventuell einen Parameter übersehen ? Ich hatte gehofft ich könnte mit dem Parameter -s 110000xx 2 Relais anschalten, 4 aus und 2 in dem Zustand lassen wie sie gerade sind. ..--- Das bedeutet durch das Ändern des Parameters von xx1xxxx auf 1xxxxxxx soll Relais 1 ANgeschaltet werden aber das Relais was bereits AN ist AN bleiben.(3 in diesem Beispiel) ---.. Wobei die Reihenfolge umgekehrt war, also 1xxxxxxx war Relais 8 bei Dohl seinem Programm. LG EDIT: die Version 2.1 ist doch die richtige ?
:
Bearbeitet durch User
Hab ich H. schrieb: > Ich hatte gehofft ich könnte mit dem Parameter -s 110000xx > 2 Relais anschalten, 4 aus und 2 in dem Zustand lassen wie sie gerade > sind. So sollte es sein, ja. Ruf's mal bitte mit -e auf, dann werden die alten Nachrichten aktiviert, die den Zustand davor und danach beschreiben. Die Zahlen, die da stehen, interessieren mich. (Ich kann das leider nicht ohne weiteres testen, ich müsste mir ansonsten extra noch einen Testmodus einbauen, der ohne reale Hardware funktioniert.)
Jörg W. schrieb: > Ruf's mal bitte mit -e auf, dann werden die alten Nachrichten aktiviert, > die den Zustand davor und danach beschreiben. Die Zahlen, die da stehen, > interessieren mich. (Ich kann das leider nicht ohne weiteres testen, ich > müsste mir ansonsten extra noch einen Testmodus einbauen, der ohne reale > Hardware funktioniert.) die Option -e löst ERROR: Wrong Parameter: -e, exiting. aus, sicher das ich die richtige Version ( 2.1 ) habe ? LG
Da das Wort "wrong" in meinem Sourcecode gar nicht vorkommt, bin ich mir sicher, dass du die falsche Version hast. ;-) https://github.com/dl8dtl/conrad_8fa_relais/tree/new_option_handling Ich merke gerade, dass ich die Hilfe-Ausgabe noch nicht aktualisiert habe. Kann ich noch tun, aber teste bitte erstmal, ob das mit dem -s jetzt so funktioniert, wie du es spezifiziert hast.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Da das Wort "wrong" in meinem Sourcecode gar nicht vorkommt, bin ich mir > sicher, dass du die falsche Version hast. ;-) also ich mache irgend etwas falsch. Ich habe extra den source von der github seite copy pastet und bekomme immer noch relais /dev/ttyUSB0 -e ERROR: Wrong Parameter: -e, exiting. gibt es da einen cache vom gcc den ich eventuell clearen muss ? hab da grad nur Fragezeichen. LG
Hast du dort den richtigen Branch ausgewählt? Ich müsste jetzt hier einen Raspberry Pi aus der Versenkung holen, um dir ein passendes Binary zu erzeugen …
Es muss übrigens auch
1 | ./relais -d /dev/ttyUSB0 |
heißen. Hattest du so spezifiziert …
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Es muss übrigens auch relais -d /dev/ttyUSB0 heißen. Hattest du so > spezifiziert … also irgend etwas läuft definitiv falsch. bei .. Es muss übrigens auch relais -d /dev/ttyUSB0 heißen. Hattest du so spezifiziert … bekomme ich : Cannot open -d Wie kann dir von dir Verlinkte version so anders sein als die, die ich dann als compilat erhalte ?! ist da doch was im cache irgend wo ? und der compiled immer nur das was da drinnliegt, also immer das selbe file ? LG
Hab ich H. schrieb: > ist da doch was im cache irgend wo ? Rufst du denn auch wirklich dein aktuelles Kompilat auf? Oder hast du noch eine Version installiert (in /usr/bin oder dergleichen) und nimmst die? Beachte das "./" in meinem Beispiel oben: das stellt sicher, dass du das Programm aus dem aktuellen Verzeichnis startest.
Jörg W. schrieb: > Rufst du denn auch wirklich dein aktuelles Kompilat auf? > > Oder hast du noch eine Version installiert (in /usr/bin oder > dergleichen) und nimmst die? Beachte das "./" in meinem Beispiel oben: > das stellt sicher, dass du das Programm aus dem aktuellen Verzeichnis > startest. OMG wie konnte mir das Entfallen ? Gnarf ! ja ./ vergessen hat natürlich einen Einfluss darauf, mann bin ich doof! ok ok ok jetzt ist es anders. ehhh es funktioniert. aber der parameter x schaltet das Relais aus. also relais -d /dev/ttyUSB0 -e -s xxxxxxxx schaltet alle aus, was nicht sein sollte. LG PS: wenn doofheit Strom erzeugen könnte, hätten wir keine Energiekrise :)
Gut, dann jetzt bitte nochmal mit -e. Habe ich vermutlich noch einen Denkfehler drin.
Jörg W. schrieb: > Gut, dann jetzt bitte nochmal mit -e. > > Habe ich vermutlich noch einen Denkfehler drin. ./relais -d /dev/ttyUSB0 -e -s xxxxxxxx liefert : OK, Aktuelle Kontaktstellung: 0 OK, Neue Kontaktstellung: 0 ./relais -d /dev/ttyUSB0 -e -s 11111111 liefert: OK, Aktuelle Kontaktstellung: 0 OK, Neue Kontaktstellung: 255 zurück zu ./relais -d /dev/ttyUSB0 -e -s xxxxxxxx Sollte OK, Aktuelle Kontaktstellung: 255 OK, Neue Kontaktstellung: 255 liefern, tut aber : OK, Aktuelle Kontaktstellung: 255 OK, Neue Kontaktstellung: 0 das x wird scheinbar als 0 interpretiert, nicht als NOP wie es müsste. LG Ich teste jetzt nochmal mit dem 2.1er branch, nicht das wir jetzt an einander vorbei-compilen :) nein scheint zu passen, die version die du mir verlinkt hast funktioniert, ( also bis das x scheinbar 0 ist ) der branch forumsversion hingegen nicht.
:
Bearbeitet durch User
Gut, seh ich mir nochmal an.
Hmm. Ich habe mir die Funktion, die den String hinter -s auswertet, mal in ein separates Testprogramm kopiert, um verschiedene vorher/nachher-Werte zu simulieren. Ich bin der Meinung, dass sich alles korrekt verhält.
1 | $ ./test -v 0x00 -s 11111111 |
2 | val: 0x00 s: 11111111, rval: 0xff |
3 | $ ./test -v 0x00 -s 1111xxxx |
4 | val: 0x00 s: 1111xxxx, rval: 0xf0 |
5 | $ ./test -v 0xff -s 0000xxxx |
6 | val: 0xff s: 0000xxxx, rval: 0x0f |
7 | $ ./test -v 0xff -s 0101x1x0 |
8 | val: 0xff s: 0101x1x0, rval: 0x5e |
Was in deinem Lastenheft nicht stand, ist die Bitreihenfolge des Strings hinter -s: ich habe die "normale" Reihenfolge für binäre Darstellung angenommen, also das Bit 7 (entspricht Relais 8) ganz links, Bit 0 (Relais 1) ganz rechts. An der Logik, wie die Relais aktiviert werden (Variable "rval") habe ich nichts geändert gehabt.
Jörg W. schrieb: > Was in deinem Lastenheft nicht stand, ist die Bitreihenfolge des Strings > hinter -s: ich habe die "normale" Reihenfolge für binäre Darstellung > angenommen, also das Bit 7 (entspricht Relais 8) ganz links, Bit 0 > (Relais 1) ganz rechts. > > An der Logik, wie die Relais aktiviert werden (Variable "rval") habe ich > nichts geändert gehabt. Stimmt, im Programm von Dohl war es so wie du angenommen hast, ganz links ist Relais 8 und rechts Relais 1. Ich habe es noch einmal getestet, und der Parameter x schaltet das entsprechende Relais aus. also ./relais -d /dev/ttyUSB0 -e -s xxxxxxxx liefert das gleiche Ergebniss wie ./relais -d /dev/ttyUSB0 -e -s 00000000 Wenn es dir Weiterhilft, kann ich dir ssh Zugang zum Laptop erlauben. Oder du fügst evtl die option -l logfile ein und ich lade das hier hoch. LG Wir sind fast am Ziel! :) EDIT: Auszug aus der Bedienungsanleitung:
1 | CMD Bedeutung Kommandorahmen Antwort |
2 | 0 NO OPERATION keine Aktion (NOP) 0 - Adr. - x - XOR 255 - Adr. - x - XOR |
3 | 1 SETUP Initialisierung 1 - Adr. - x - XOR 254 - Adr. - Info - XOR |
4 | 2 GET PORT Schaltzustände abfragen 2 - Adr. - x - XOR 253 - Adr. - Daten - XOR |
5 | 3 SET PORT Relais schalten 3 - Adr. - Daten - XOR 252 - Adr. - x - XOR |
6 | 4 GET OPTION Optionen abfragen 4 - Adr. - x - XOR 251 - Adr. - Opt. - XOR |
7 | 5 SET OPTION Optionen setzen 5 - Adr. - Opt. - XOR 250 - Adr. - x - XOR |
8 | 6 SET SINGLE 6 - Adr. - Daten - XOR 249 - Adr. - Daten - XOR |
9 | Relais einschalten ohne Änderung der restlichen Ausgänge |
10 | 7 DEL SINGLE 7 - Adr. - Daten - XOR 248 - Adr. - Daten - XOR |
11 | Relais ausschalten ohne Änderung der restlichen Ausgänge |
12 | 8 TOGGLE 8 - Adr. - Daten - XOR 247 - Adr. - Daten - XOR |
13 | Wechseln des Schaltzustands ohne Änderung der restlichen Ausgänge |
Vielleicht sind die Optionen 6,7,8 der Schlüssel ? [Edit: Tabelle formatiert]
:
Bearbeitet durch Moderator
Ich kann nochmal gucken, wie das bei Thomas Dohl gemacht worden ist.
Jörg W. schrieb: > Ich kann nochmal gucken, wie das bei Thomas Dohl gemacht worden ist. Ich glaube ich hab's: Ich habe den Sorce mal etwas verändert, und ein anderes Verhalten hinbekommen.
1 | /* Parameter auswerten */
|
2 | if (opt_s) |
3 | {
|
4 | rval = option_s(val); |
5 | sndcmd (g_fd, 8, 1, rval); |
6 | val = rcvstat (g_fd, &ans, &adr, &stat); |
7 | if ((val) or (ans != 247)) |
8 | {
|
9 | message ("FAIL: %d %d %d %d\n", ans, adr, stat, val); |
10 | goto err_end; |
11 | }
|
12 | message ("OK, Neue Kontaktstellung: %d\n", stat); |
13 | }
|
14 | close (g_fd); |
15 | exit (0); |
Es müsste so sein, das bei -s 1xxxxxxx ... sndcmd (g_fd, 6, 1, rval); übergeben wird und bei -s 0xxxxxxx ...sndcmd (g_fd, 7, 1, rval); wie das dann allerdings bei -s 0101xxxx funktioniert, ist mir zu hoch. EDIT: SET und DEL reagieren nur auf 1 nicht auf 0. 0 ist scheinbar wichtig für die Auswertung.
:
Bearbeitet durch User
12 KM Radfahren bei dem Wetter lüftet das Gehirn mal durch :) + 2 Tassen Kaffee, glaube ich zu wissen wie Thomas Dohl das gemacht hat. Er benutzt das Toggle commando (8). Wir haben den Status der Relais. Wir haben den Benutzerwunsch. Alles was jetzt noch fehlt ist der Vergleich, was will der Nutzer und welche Relais sind gerade an/aus. Dann machen wir ein Toggle command davon, und es passt. LG
Ich schau mir das spätestens morgen abend nochmal an. Hatte leider gerade anderes zu tun in den letzten Tagen.
Da die Funktion, die den String hinter -s zerlegt, bei mir sowieso abgetrennt ist, sollte das jetzt nicht so schwer sein, darin deine Logik unterzubringen.
Jörg W. schrieb: > Ich schau mir das spätestens morgen abend nochmal an. > > Hatte leider gerade anderes zu tun in den letzten Tagen. Nur nicht Hetzen. Ich warte seit einem Jahr auf ein neues Programm, da kommt es auf ein paar Tage nicht an :) Um den Faden weiter zu Spinnen: toggle(8) sendet nur x oder 1 get status = 00000001 benutzerwunsch : xxxxxx1x Komando an Karte : xxxxxx1x nur ein Komando, nur eine Prüfsumme. bzw getstatus 00000011 benutzerwunsch 1xxxxxx0 Kommando an Karte 1xxxxxx1 LG
Jörg W. schrieb: > Ich schau mir das spätestens morgen abend nochmal an. Habe ich geändert. Ich verstehe nach dem Lesen deiner Tabelle zwar immer noch nicht, warum es mit SET nicht funktioniert hat (es wurden ja alle die Bits, die schon gesetzt waren, erneut rüber gereicht), aber es auf XOR umzubauen, war jetzt nicht so schwer.
Jörg W. schrieb: > Habe ich geändert. > > Ich verstehe nach dem Lesen deiner Tabelle zwar immer noch nicht, warum > es mit SET nicht funktioniert hat (es wurden ja alle die Bits, die schon > gesetzt waren, erneut rüber gereicht), aber es auf XOR umzubauen, war > jetzt nicht so schwer. Weil SET eben nur einschalten kann. Zum ausschalten müsste dann DEL gesendet werden und eine Sequenz von xxx11100 würde ja das senden von SET + DEL erfordern. rval = option_s(val); sndcmd (g_fd, 8, 1, rval); val = rcvstat (g_fd, &ans, &adr, &stat); if ((val) or (ans != 252)) <<<hätte 247 sein müssen. aber das habe ich alleine hinbekommen :) Und soll ich dir was sagen ? Es funktioniert FAST wie es soll!! Du bist mein Held. Nur eine Kleinigkeit noch wenn es geht. Die 0 muss noch Interpretiert werden. Weil zum jetzigen Zeitpunkt 2x Einschalten = Ausschalten ist. Sequenz 1 : xxxxxxx1 = Relais 1 anschalten, alle anderen so lassen. Sequenz 2: xxxxxxx0 = Abfrage status, ist Relais 1 an, dann sende 1 (toggle) und schalte aus. Ist Relais 1 aus sende x . LG
Bitte nochmal mit -e und die Ausgabe posten. Eigentlich sollte nämlich die 0 auch funktionieren (und eben ein toggle-Bit setzen). Wenn das immer noch nicht geht, lassen wir den Kram mit dem XOR und generieren halt separate Befehle zum Setzen und Löschen.
Jörg W. schrieb: > Bitte nochmal mit -e und die Ausgabe posten. Eigentlich sollte nämlich > die 0 auch funktionieren (und eben ein toggle-Bit setzen). Sequenz 1 : ./relais -e -d /dev/ttyUSB0 -s xxxxxxxx got file descriptor fd=3 Firmware-Version 11 OK, Aktuelle Kontaktstellung: 0 OK, Neue Kontaktstellung: 0 Sequenz 2 : ./relais -e -d /dev/ttyUSB0 -s xxxxxxx1 got file descriptor fd=3 Firmware-Version 11 OK, Aktuelle Kontaktstellung: 0 OK, Neue Kontaktstellung: 1 Sequenz 3 : ./relais -e -d /dev/ttyUSB0 -s xxxxxxx0 got file descriptor fd=3 Firmware-Version 11 OK, Aktuelle Kontaktstellung: 1 OK, Neue Kontaktstellung: 1 Die Null sollte aber eigentlich nr1 abschalten.. LG
Hallo, das wären meine 3 Grundfunktionen.
1 | #include "myToolbox.h" |
2 | |
3 | uint8_t relaisPort; // Port Zustand irgendwo Lib intern gespeichert |
4 | |
5 | void portBitSet (const uint8_t pos) |
6 | {
|
7 | relaisPort = relaisPort | _BV(pos); |
8 | }
|
9 | |
10 | void portBitDel (const uint8_t pos) |
11 | {
|
12 | relaisPort = relaisPort & ~_BV(pos); |
13 | }
|
14 | |
15 | void portBitToggle (const uint8_t pos) |
16 | {
|
17 | relaisPort = relaisPort ^ _BV(pos); |
18 | }
|
19 | |
20 | void setup (void) |
21 | {
|
22 | Serial.begin(9600); |
23 | |
24 | Serial.println("\nset"); |
25 | for (uint8_t i=0; i<8; i++) |
26 | {
|
27 | portBitSet(i); |
28 | formatBINln(Serial, relaisPort); |
29 | }
|
30 | |
31 | Serial.println("\ntoggle"); |
32 | for (uint8_t i=0; i<8; i++) |
33 | {
|
34 | portBitToggle(i); |
35 | formatBINln(Serial, relaisPort); |
36 | }
|
37 | |
38 | Serial.println("\ntoggle"); |
39 | for (uint8_t i=0; i<8; i++) |
40 | {
|
41 | portBitToggle(i); |
42 | formatBINln(Serial, relaisPort); |
43 | }
|
44 | |
45 | Serial.println("\ndelete"); |
46 | for (uint8_t i=0; i<8; i++) |
47 | {
|
48 | portBitDel(i); |
49 | formatBINln(Serial, relaisPort); |
50 | }
|
51 | }
|
52 | |
53 | void loop (void) |
54 | {
|
55 | |
56 | }
|
Ausgabe
1 | set
|
2 | 0b00000001 |
3 | 0b00000011 |
4 | 0b00000111 |
5 | 0b00001111 |
6 | 0b00011111 |
7 | 0b00111111 |
8 | 0b01111111 |
9 | 0b11111111 |
10 | |
11 | toggle
|
12 | 0b11111110 |
13 | 0b11111100 |
14 | 0b11111000 |
15 | 0b11110000 |
16 | 0b11100000 |
17 | 0b11000000 |
18 | 0b10000000 |
19 | 0b00000000 |
20 | |
21 | toggle
|
22 | 0b00000001 |
23 | 0b00000011 |
24 | 0b00000111 |
25 | 0b00001111 |
26 | 0b00011111 |
27 | 0b00111111 |
28 | 0b01111111 |
29 | 0b11111111 |
30 | |
31 | delete
|
32 | 0b11111110 |
33 | 0b11111100 |
34 | 0b11111000 |
35 | 0b11110000 |
36 | 0b11100000 |
37 | 0b11000000 |
38 | 0b10000000 |
39 | 0b00000000 |
Meine Überlegung sagt mir, wenn man nur 1 oder 0 als gewünschten übermittelbaren Zustand zulässt, dann kann man nicht unterscheiden ob getoggelt oder der Zustand beibehalten werden soll. Es würde einen zusätzlichen Befehl erfordern das wirklich getoggelt werden soll. Ansonsten IST '1' Zustand beibehalten wenn SOLL auch '1' übermittelt wird. Es geht doch sicherlich um die Zeilen 473 bis 481 in der relais.c ? https://github.com/dl8dtl/conrad_8fa_relais/tree/new_option_handling Wenn in beiden Fällen immer verODERt wird kann kein Bit gelöscht werden.
:
Bearbeitet durch User
Hallo, wenn es wirklich um die besagten Zeilen geht mit dem switch case, dann könnte man das bestimmt vereinfachen. Das extrahierte c, der gewünschte Bit Zustand am Port, ist an dem Punkt schon im switch(c) mit 0 oder 1 ermittelt wurden. Würde für mich bedeuten man kann im case 1 gnadenlos die aktuelle BitPosition verodern/setzen und im case 0 gnadenlos die aktuelle Bitposition löschen. Der vorherige Vergleich könnte weg. Soweit meine Überlegungen.
:
Bearbeitet durch User
Veit D. schrieb: > Hallo, > > wenn es wirklich um die besagten Zeilen geht mit dem switch case, dann > könnte man das bestimmt vereinfachen. Das extrahierte c, der gewünschte > Bit Zustand am Port, ist an dem Punkt schon im switch(c) mit 0 oder 1 > ermittelt wurden. Würde für mich bedeuten man kann im case 1 gnadenlos > die aktuelle BitPosition verodern/setzen und im case 0 gnadenlos die > aktuelle Bitposition löschen. Der vorherige Vergleich könnte weg. > Soweit meine Überlegungen. Hallo. Im Ursprünglichen Programm sah die Benutzereingabe etwa so aus : xxx1xxx0 also schalte Relais 1(rechts) aus Relais 5 an und lasse alle anderen so wie sie sind. nun versteht die Karte aber keine 0 deswegen muss das Programm auslesen welchen zustand das angesprochene Relais hat und es dann togglen oder so lassen wie es ist. wenn ich also xxx1xxx0 erneut aufrufe soll das Programm feststellen : 5 ist bereits an, sende x 1 ist bereits aus sende x (aka nix ) bei der Eingabe xxx0xxxx stellt das Programm fest 5 ist an soll aber aus und sendet dann 1. die eingabe von 0 des benutzers muss entsprechend interpretiert werden also entweder als 1 wenn das Relais an ist, oder x wenn es eh aus ist. Puuuh ich hoffe das war einigermaßen verständlich. LG
Hallo, aha, also die Relaiskarte selbst ist etwas dumm und kann nur toggeln wenn an die Karte eine '1' sendet wird? Das Programm hier muss dann auf Grund der Nutzervorgabe 0/1 entscheiden ob es toggeln zulässt oder nicht um den gewünschten Schaltzustand zu erreichen? Das Programm muss entscheiden ob eine '1' zum toggeln oder 0 bzw. nichts an die Karte gesendet wird? Korrekt erfasst? Dann sieht das anders aus.
Veit D. schrieb: > Hallo, > > aha, also die Relaiskarte selbst ist etwas dumm und kann nur toggeln > wenn an die Karte eine '1' sendet wird? Das Programm hier muss dann auf > Grund der Nutzervorgabe 0/1 entscheiden ob es toggeln zulässt oder nicht > um den gewünschten Schaltzustand zu erreichen? Das Programm muss > entscheiden ob eine '1' zum toggeln oder 0 bzw. nichts an die Karte > gesendet wird? Korrekt erfasst? Dann sieht das anders aus. Ja, und nein :) Die Karte Versteht 3 Schaltbefehle, SET,DEL + TOGGLE. mMn ist Toggle aber am einfachsten umzusetzen, weil SET nur einschalten und DEL nur ausschalten kann. Das kann ich nicht in einem Befehl senden denke ich. > Grund der Nutzervorgabe 0/1 entscheiden ob es toggeln zulässt oder nicht > um den gewünschten Schaltzustand zu erreichen? Das Programm muss > entscheiden ob eine '1' zum toggeln oder 0 bzw. nichts an die Karte > gesendet wird? Korrekt erfasst? Dann sieht das anders aus. Exakt! Nutzervorgabe ist 1 0 und x. LG
Hallo, weil die Links zur Karte nicht gehen, muss ich nochmal nachfragen. Die Karte versteht SET, DEL und TOGGLE. Warum möchtest du TOGGLE wenn SET und DEL einfacher ist? Sturr SET oder sturr DEL, nichts einfacher als das. Das ist wie 1 oder 0 senden. Bei 1 sende SET und bei 0 sende DEL.
Veit D. schrieb: > Warum möchtest du TOGGLE wenn SET und DEL einfacher ist? Weil man dann mit einem Befehl zur Karte alles erledigen könnte. Wenn das aber nicht funktioniert, werde ich das in SET und DEL aufteilen.
Hallo, habe die Beschreibung gelesen. SET_SINGLE und DEL_SINGLE sind erstmal am Einfachsten. Auf Schaltgeschwindigkeit kommt es bei Relais im Grunde nicht an. :-) Wenn es TOGGLE unbedingt sein soll mach ich mir Gedanken. Sollte man doch hinbekommen. :-)
Nee, TOGGLE erschien mir nur am einfachsten. Aber das auf SET und DEL umzubauen, sollte jetzt auch nicht der Akt sein. Habe halt nur die Karte nicht hier, insofern kann ich das nicht selbst testen, was wie funktioniert damit. Irgendwie scheint die Firmware schon ein wenig mimosenhaft zu sein, anfangs haben wir ja SET PORT benutzt, aber das hatte auch nicht den gewünschten Erfolg.
:
Bearbeitet durch Moderator
Hallo, ich denke ich habs, musste zum simulieren einen Datensatz anlegen. Ich hoffe das Prinzip ist dennoch erkennbar. Der aktuelle Portzustand wird ja wenn ich das richtig verstanden habe vor Änderung eingelesen. Das ist bei mir 'port.ist'. Der neue Zustand den die Relais haben sollen ist bei mir 'port.soll'. Die Idee ist jetzt, wenn getoggelt werden soll muss man nur auf Unterschied zwischen IST und SOLL abfragen. Wenn verschieden kommt an die Bitstelle eine '1' sonst bleibt 0. Man sendet nur die Differenz mit '1' markiert an die Karte die dann toggelt.
1 | #include "myToolbox.h" |
2 | |
3 | struct PortDaten |
4 | {
|
5 | uint8_t ist = 0; // ausgelesener Portzustand |
6 | uint8_t soll = 0; // gewünschter Portzustand |
7 | uint8_t data = 0; // data Wert für TOGGLE Übertragung an Karte |
8 | };
|
9 | PortDaten relaisPort; |
10 | |
11 | void sendPortToggle (PortDaten &port) |
12 | {
|
13 | uint8_t mask = 1; // ein Hilfs-Bit wird geschoben zum Vergleich in Schleife |
14 | port.data = 0; |
15 | |
16 | for (uint8_t i=0; i<8; i++) |
17 | {
|
18 | // wenn Bit unterschiedlich Position mit '1' markieren
|
19 | if ((port.ist & mask) != (port.soll & mask) ) |
20 | {
|
21 | port.data = port.data | mask; |
22 | port.ist = port.ist ^ mask; // neuen IST Zustand merken für Simulation |
23 | |
24 | }
|
25 | formatBINln(Serial, port.data); |
26 | mask = mask << 1; |
27 | }
|
28 | }
|
29 | |
30 | void ausgabe (PortDaten &port) |
31 | {
|
32 | Serial.println(); |
33 | Serial.print("alter IST Zustand: "); formatBINln(Serial, port.ist); |
34 | Serial.print("neuer SOLL Zustand: "); formatBINln(Serial, port.soll); |
35 | sendPortToggle(port); |
36 | Serial.print("mit TOGGLE gesendet wird: "); formatBINln(Serial, port.data); |
37 | }
|
38 | |
39 | void setup (void) |
40 | {
|
41 | Serial.begin(9600); |
42 | |
43 | relaisPort.soll = 0; |
44 | ausgabe(relaisPort); |
45 | |
46 | relaisPort.soll = 0b00000110; |
47 | ausgabe(relaisPort); |
48 | |
49 | relaisPort.soll = 0b01100000; |
50 | ausgabe(relaisPort); |
51 | |
52 | relaisPort.soll = 0b01100000; // nochmal ob es unverändert bleibt |
53 | ausgabe(relaisPort); |
54 | |
55 | relaisPort.soll = 0b10101010; |
56 | ausgabe(relaisPort); |
57 | }
|
58 | |
59 | void loop (void) |
60 | { } |
Testasugabe
1 | alter IST Zustand: 0b00000000 |
2 | neuer SOLL Zustand: 0b00000000 |
3 | 0b00000000 |
4 | 0b00000000 |
5 | 0b00000000 |
6 | 0b00000000 |
7 | 0b00000000 |
8 | 0b00000000 |
9 | 0b00000000 |
10 | 0b00000000 |
11 | mit TOGGLE gesendet wird: 0b00000000 |
12 | |
13 | alter IST Zustand: 0b00000000 |
14 | neuer SOLL Zustand: 0b00000110 |
15 | 0b00000000 |
16 | 0b00000010 |
17 | 0b00000110 |
18 | 0b00000110 |
19 | 0b00000110 |
20 | 0b00000110 |
21 | 0b00000110 |
22 | 0b00000110 |
23 | mit TOGGLE gesendet wird: 0b00000110 |
24 | |
25 | alter IST Zustand: 0b00000110 |
26 | neuer SOLL Zustand: 0b01100000 |
27 | 0b00000000 |
28 | 0b00000010 |
29 | 0b00000110 |
30 | 0b00000110 |
31 | 0b00000110 |
32 | 0b00100110 |
33 | 0b01100110 |
34 | 0b01100110 |
35 | mit TOGGLE gesendet wird: 0b01100110 |
36 | |
37 | alter IST Zustand: 0b01100000 |
38 | neuer SOLL Zustand: 0b01100000 |
39 | 0b00000000 |
40 | 0b00000000 |
41 | 0b00000000 |
42 | 0b00000000 |
43 | 0b00000000 |
44 | 0b00000000 |
45 | 0b00000000 |
46 | 0b00000000 |
47 | mit TOGGLE gesendet wird: 0b00000000 |
48 | |
49 | alter IST Zustand: 0b01100000 |
50 | neuer SOLL Zustand: 0b10101010 |
51 | 0b00000000 |
52 | 0b00000010 |
53 | 0b00000010 |
54 | 0b00001010 |
55 | 0b00001010 |
56 | 0b00001010 |
57 | 0b01001010 |
58 | 0b11001010 |
59 | mit TOGGLE gesendet wird: 0b11001010 |
Hallo, die Variable 'port.data' wäre dann der Rückgabewert an die Sendefunktion mit Toggle aus meiner Sicht.
Veit D. schrieb: > Die Idee ist jetzt, wenn getoggelt werden soll muss man nur auf > Unterschied zwischen IST und SOLL abfragen. Wenn verschieden kommt an > die Bitstelle eine '1' sonst bleibt 0. Ja Veit – genau das habe ich gemacht. Die Karte verhält sich nur nicht so …
Habe es noch auf SET SINGLE und DEL SINGLE umgebaut. Es gibt jetzt bei -e auch noch Messages dafür, was er genau zur Karte schickt.
Hallo, kann es sein das die Bitmaske und die Bitpos. gegenläufig verglichen werden? Habe nur die Variablennamen lesbarer gemacht. optlen wird runtergezählt damit Index nach rechts versetzt und die Bitmaske wird links geschoben und damit "hochgezählt". Sollten die nicht in die gleiche Richtung zählen bzw. schieben für den Vergleich auf gleicher Bitposition?
1 | / /Könnte man nicht für |
2 | char c = opt_s[optlen]; |
3 | |
4 | // lieber den Index i verwenden?
|
5 | char c = opt_s[i]; |
1 | unsigned option_s (unsigned ist) |
2 | {
|
3 | // decode -s string
|
4 | // format: 01xx10 where
|
5 | // 0: clear bit
|
6 | // 1: set bit
|
7 | // x: ignore
|
8 | |
9 | // The resulting value is suitable for the XOR operation.
|
10 | |
11 | unsigned toggleData = 0; |
12 | unsigned maske = 1; |
13 | |
14 | size_t optlen = strlen(opt_s); |
15 | for (int i = 0; i < 8; i++) |
16 | {
|
17 | if (optlen == 0) |
18 | break; |
19 | optlen--; |
20 | char c = opt_s[optlen]; |
21 | switch (c) |
22 | {
|
23 | case '1': // Soll Bit Zustand 1 |
24 | if ((ist & maske) == 0) |
25 | toggleData |= maske; |
26 | break; |
27 | |
28 | case '0': // Soll Bit Zustand 0 |
29 | if ((ist & maske) != 0) |
30 | toggleData |= maske; |
31 | break; |
32 | |
33 | case 'x': |
34 | // do nothing here, just shift
|
35 | break; |
36 | |
37 | default:
|
38 | fprintf (stderr, "ERROR: unknown character in -s option: %c\n", c); |
39 | }
|
40 | maske <<= 1; |
41 | }
|
42 | if (optlen > 0) |
43 | fprintf (stderr, "WARNING: -s option string too long\n"); |
44 | |
45 | return toggleData; |
46 | }
|
:
Bearbeitet durch User
Nein, ich hatte doch weiter oben schon die Ergebnisse der (naja) Simulation gezeigt. Die Bitmaske passt schon soweit. Nur der Relais-Controller scheint nicht so ganz genau das zu tun, was beschrieben ist. Mit den expliziten SET- und DEL-Aufrufen gibt es jetzt aber auch (mit -e) Mitteilungen auf dem Terminal, was zur Karte geschickt wird. Die gab's vorher nicht.
Hallo, okay, dann weiß auch nicht weiter. Der TO müßte der Reihe nach jede Bitstelle nacheinander vor und zurück durchtesten und mitteilen was sich wie geändert bzw. nicht geändert hat. Wenn die Simulation nicht zur Wirklichkeit passt. ;-) Vielleicht gibts ein Muster. Bsp. gesendet: 0000.0001 Relaiszustand: 0000.0001 gesendet: 0000.0011 Relaiszustand: 0000.0011 gesendet: 0000.0111 Relaiszustand: 0000.0111 usw. und rückwärts und dann nochmal Einzelbits gesendet: 0000.0001 Relaiszustand: 0000.0001 gesendet: 0000.0010 Relaiszustand: 0000.0010 gesendet: 0000.0100 Relaiszustand: 0000.0100 usw. und rückwärts
:
Bearbeitet durch User
Hallo Jörg, habe mal nach deinen Testdaten geschaut. Beitrag "Re: seriell FTDI TTL UART SUART ich blicke nicht mehr Durch!" Bsp. val: 0xff s: 0101x1x0, rval: 0x5e IST-Wert: 0xFF = 1111.1111 SOLL-WERT: 0101.x1x0 TOGGLE: 0x5e = 0101.1110 Kann irgendwie nicht stimmen. 1 & 1 oder 1 & x darf nicht 1 sein. 1 & 0 muss 1 werden. Schau dir bitte nochmal die gegenläufigen Richtungen der Bitschieberreien an.
Veit D. schrieb: > habe mal nach deinen Testdaten geschaut. Die waren noch für den SET PORT Befehl, der ja alle Bits auf einmal setzen sollte. Weiß nicht, wenn man den Flash des AVRs, der da auf der Steuerung ist, auslesen könnte, könnte ich mir hier einen Simulator bauen … so ist das irgendwie ein Fischen im Trüben.
Thread beobachten
Seitenaufteilung abschalten