Eine Betonmischer soll durch RFID-Leser an einem Arduino eingeschaltet werden. Für einen ersten Test benutze ich diesen Aufbau: https://www.makerblog.at/2017/11/rfid-transponder-mit-dem-mfrc-522-card-reader-am-arduino-auslesen/ Hält man den RFID vor den Leser, so geben die Funktion mfrc522.PICC_IsNewCardPresent() und mfrc522.PICC_ReadCardSerial() ein High ab. Wenn ich den Aufbau in der Nähe des Mischers halte und einmal dessen Schütz eingeschaltet hat, bleibt ab dann dieses High Signal aus, wenn ich den RFID vor den Leser halte, wie man mit der Serial.print Funktion herausfindet. Es funktioniert auch nicht wieder, wenn man die Schaltung wieder aus der Nähe des Schützes entfernt. Erst nach Drücken der Resettaste des Arduino geht es wieder. Es scheint also, als ob die Hardware des Lesers beim Schalten des Schützes abstürzt und/oder die Funktionen aus den Librarys. Wenn der Leser also schon in der Nähe des Schützes nicht ordentlich funktioniert, kann ich ihn dieses nicht schalten lassen, indem ich ihn an dessen Schaltkasten anschließe. Ich habe schon drei verschiedene Arduinos (Original und Clone) und Leser verwendet. Der Fehler bleibt. Im Programm kann ich mit Serial.print herausfinden, welche Variablen welche Zustände haben. Das möchte ich jetzt auch mit den Befehlen aus den Librarys <SPI.h> und <MFRC522.h> machen, die in das Programm included sind. Dazu müsste ich diese aber als Funktionen direkt ins Programm kopieren. Dazu bräuchte ich den Programmtext. Wie komme ich daran? Gibt es eine Befehlsübersicht für die beiden Librarys <SPI.h> und <MFRC522.h> und was genau diese Befehle auslösen sollen? Möglicherweise gibt es in den Librarys Befehle, die im RFID Leser dasselbe auslösen, wie ein Reset per Arduino Taste und somit nach jedem Schalten des Schützes den Absturz im Leser wieder beheben. Man könnte es mit abgeschirmten Leitungen versuchen. Hat vielleicht jemand andere Tips, wie ich dem Absturz zuleibe rücken kann?
Tja... Bastlerhardware verträgt sich halt nicht mit Baumaschinen! Wahrscheinlich wird der unzureichend entsörte Arduino durch den Motor selbst und durch den Stromstoß beim Schalten des Schützes gestört. Hier hilft nur eine ordentliche, enstörte Leiterplatte in einem Metallgehäuse. Als Stecker benutzt man dann am besten industrielle, wasserdichte Stecker aus Metall und geschirmtes Kabel, dies muss dafür geignet sein, also kein CAT Kabel. LG
Bei dem RFID Modul aus dem verlinkten Artikel sehe ich keine Schutzvorrichtung, die den Chip vor Überspannung durch die Antenne schützt. Da ist nur das übliche Anpassungsnetzwerk zwischen Chip und Antenne. Vermutlich bekommt dein PN522 durch das Feld des Betonmischers beim Einschalten so heftig einen auf die Mütze, das er abstürzt. Intern werkelt da schließlich auch nur ein kleiner Microcontroller. Einem guten industrietauglichem RFID Leser wird das nicht passieren, aber der kostet halt.
Bertie schrieb: > Es scheint also Ich würde jetzt erst mal feststellen, ob die Störung über die (Versorgungs)leitung oder durch die Luft kommt. Hilfreich bei der Fehlersuche ist ein Oszilloskop. Hast du sowas? Bertie schrieb: > Schalten des Schützes Ist schon ein Snubber über den Schützkontakten installiert?
Bertie schrieb: > Der Fehler bleibt. Tjoa - wenn schon grundlegendste EMV-Maßnahmen nicht berücksichtigt wurden, darf es wohl kaum verwundern, wenn eine ziemliche EMV-Seuche bzw. ein ordentlicher Störer (Schütz) nicht nur das speziell zur Empfindlichkeit gegenüber elektromagnetischer Strahlung optimierte Bauteil (RFID-Reader) außer Tritt bringt, sondern gleich den ganzen µC-Verhau. => Mit ordentlichem, durchdachtem Aufbau inkl. EMV-Konzept geht das sicherlich, aber offenkundig nicht mit Deiner Versuchsanordnung. Mehr lässt sich in Ermangelung eines Schaltplans Deines Aufbaus und entsprechender Fotos nicht sagen. Bertie schrieb: > Dazu bräuchte ich den Programmtext. Wie komme ich > daran? a) Google b) Wenn Du die Bibliotheken benutzt, hast Du sie ja schon auf dem System - die Dokumentation in den .h-Files reicht aus welchen Gründen nicht? > Gibt es eine Befehlsübersicht für die beiden Librarys <SPI.h> und > <MFRC522.h> und was genau diese Befehle auslösen sollen? s. o. - für die MFRC522-Lib gibt es zusätzlich zum Quellcode noch Doku in Word und PDF im Github-Repository.
Arno K. schrieb: > Wahrscheinlich wird der unzureichend entsörte Arduino durch den Motor > selbst und durch den Stromstoß beim Schalten des Schützes gestört. > Hier hilft nur eine ordentliche, enstörte Leiterplatte in einem > Metallgehäuse. Wie ich schon schrieb, ist der Fehler mit größter Wahrscheinlichkeit auf der Leserplatine und somit nicht im Arduino. Denn der Arduino liefert immer noch über Serial.print die Analysesignale. Ich habe testweise zusätzlich noch vier BlinkOhneDelay draufgepielt. Und die laufen im Fehlerfall anstandslos weiter. Ich habe die Versorgungspannung des abstürzenden Lesers auch schon mit einem zusätzlichen Kondensator versehen. Den kann man nicht in ein Metallgehäuse einbauen, weil er dann nicht funktioniert. Im Gegenteil muss der Leser elektromagnetisch so "offen" wie möglich sein.
Bertie schrieb: > Dazu bräuchte ich den Programmtext. Wie komme ich > daran? https://www.arduinolibraries.info/libraries/mfrc522 Benutzt man das HW-SPI, muß der /SS-Pin als Ausgang definiert werden und zwar vor dem SPI-Init.
Toni Tester schrieb: > b) Wenn Du die Bibliotheken benutzt, hast Du sie ja schon auf dem System > - die Dokumentation in den .h-Files reicht aus welchen Gründen nicht? Deshalb poste ich ja hier. Ich habe bisher vergeblich in der Arduino Software gesucht, wo ich die Librarys sichtbar machen kann, um deren Funktionen in den Programmtext zu kopieren, damit ich sie direkt im Programm aufrufen und mit Serial.print analysieren kann, anstatt aus der unzugänglichen Library. > für die MFRC522-Lib gibt es zusätzlich zum Quellcode noch Doku > in Word und PDF im Github-Repository. An diesem Github habe ich mich schon versucht. Das ist für mich ein Buch mit sieben Siegeln. Ich habe keine Ahnung, wozu das ganze Verzeichnis- und Dateiengewusel gut sein soll. Da sind jede Menge Dateiendungen, die ich nicht kenne. Wie kann ich dort das Richtige heraus destillieren?
Bertie schrieb: > vergeblich in der Arduino Software gesucht Das ist zum jetztigen Zeitpunkt auch die falsche Stelle. Da dockerst du nur an Symptomen herum. Erste Aufgabe ist, die Ursache zu finden und dort anzugreifen...
Bertie schrieb: > Arno K. schrieb: >> Wahrscheinlich wird der unzureichend entsörte Arduino durch den Motor >> selbst und durch den Stromstoß beim Schalten des Schützes gestört. >> Hier hilft nur eine ordentliche, enstörte Leiterplatte in einem >> Metallgehäuse. > > Wie ich schon schrieb, ist der Fehler mit größter Wahrscheinlichkeit auf > der Leserplatine und somit nicht im Arduino. Denn der Arduino liefert > immer noch über Serial.print die Analysesignale. Ich habe testweise > zusätzlich noch vier BlinkOhneDelay draufgepielt. Und die laufen im > Fehlerfall anstandslos weiter. > > Ich habe die Versorgungspannung des abstürzenden Lesers auch schon mit > einem zusätzlichen Kondensator versehen. Den kann man nicht in ein > Metallgehäuse einbauen, weil er dann nicht funktioniert. Im Gegenteil > muss der Leser elektromagnetisch so "offen" wie möglich sein. Naja...eigentlich muss nur die Empfangsspule offen sein, der RFID Leser muss aber trotzdem ordentlich entwickelt worden sein, das geht schon. Ich empfehle das Buch: "Trilogie der induktiven Bauelemente" von Würth! Entgegen der Weisheiten mancher, kann ein Kondensator an der Stelle XY sogra schädlich; nicht nützlich sein. Helfen wird hier nur eine Eigenentwicklung eines RFID Leser nach EMV Gesichtspunkten. LG
Du könntest als Würg-Around den Reset Pin des Lesers nicht auf den Reset des Arduino legen sondern an einen Portpin und dann alle xx Sekunden einen Reset auslösen. Eventuell kannst du den hängenden Leser auch an "nicht antworten" auf eine Status Abfrage erkennen und dann Gegenmaßnahmen ergreifen.
Im Ordner src findest Du die Library, getrennt in Header .h und c++-Programm .cpp Im Ordner doc ist die Dokumentation als Word-Datei .doc und als PDF. In https://www.nxp.com/docs/en/data-sheet/MFRC522.pdf findest DU alle Angaben, wenn Du den Leser direkt ansprechen willst. Schwer war das jetzt nicht wirklich.
Bertie schrieb: > Ich habe keine Ahnung, wozu das ganze Verzeichnis- > und Dateiengewusel gut sein soll. doc = Doku src = Sourcen examples = Beispiele Bertie schrieb: > Da sind jede Menge Dateiendungen, die > ich nicht kenne. .cpp = .ino also C++ Files. .h, .pdf, .png sollten bekannt sein.
Arno K. schrieb: > Hier hilft nur eine ordentliche, enstörte Leiterplatte in einem > Metallgehäuse. > Als Stecker benutzt man dann am besten industrielle, wasserdichte > Stecker aus Metall und geschirmtes Kabel, dies muss dafür geignet sein, > also kein CAT Kabel. Dieser Rundumschlag nach der Holzhammermethode ist nur selten zielführend. Zuerst muß man ermitteln, welche Hardware oder Routine gestört wird. Erst dann kann man gezielte Maßnahmen ergreifen.
Peter D. schrieb: > Arno K. schrieb: >> Hier hilft nur eine ordentliche, enstörte Leiterplatte in einem >> Metallgehäuse. >> Als Stecker benutzt man dann am besten industrielle, wasserdichte >> Stecker aus Metall und geschirmtes Kabel, dies muss dafür geignet sein, >> also kein CAT Kabel. > > Dieser Rundumschlag nach der Holzhammermethode ist nur selten > zielführend. > Zuerst muß man ermitteln, welche Hardware oder Routine gestört wird. > Erst dann kann man gezielte Maßnahmen ergreifen. Was hat das mit Rundumschlag zu tun? Wenn man schon richtig beginnt treten solche Fehler erst gar nicht auf! Überhaupt fragt man sich, warum ein Betonmischer eine RFID Steruerung braucht? Auf einer Baustelle ist das ja denkbar schlecht, dann doch lieber ein Schlüsselschalter. LG
Horst schrieb: > Im Ordner src findest Du die Library, getrennt in Header .h und > c++-Programm .cpp Danke, dass Du das bestätigst. Denn so weit war ich auch schon einmal. Ich bin aber davon ausgegangen, dass es die falschen Dateien sind. Denn über das Menü "Datei - Öffnen" und dann Aufsuchen von Arduino\libraries\MFRC522\src und Klicken der Dateien kommt bei beiden die Fehlermeldung: "Arduino kann nur seine eigenen Sketche und andere Dateien mit den Erweiterungen .ino und .pne öffnen". Möglicherweise ist meine Arduino Software falsch konfiguriert oder ich finde im Menü nicht die richtige Stelle, wo man diese Dateien öffnet.
Bertie schrieb: > Möglicherweise ist meine Arduino Software falsch konfiguriert oder ich > finde im Menü nicht die richtige Stelle, wo man diese Dateien öffnet. Nein! Die Arduino IDE kann das so einfach nicht. A: Du kopierst die Dateien in dein Projektverzeichnis, da wo auch die *.ino liegt. Dann öffnet die IDE *.ino *.pde *.c *.cpp *.S und *.h Dateien B: Du nutzt einen externen Editor, um dir die Dateien in dem libraries Verzeichnis anzuschauen. z.B. Notepad++, pspad, oder irgendeinen anderen. C: Die meisten Dateien finden sich auch auf Github. Die haben dort einen brauchbaren Quelltext Syntax Erleuchter, Quellcode Betrachter.
LOL. Ein *uino fuer eine Baumaschin. Wenn das die BG sieht, kriegt das BG-Maennchen einen Herzkasper.
... schrieb: > LOL. Ein *uino fuer eine Baumaschin. > Wenn das die BG sieht, kriegt das BG-Maennchen einen Herzkasper. Ageh, als ob man das auf einer fertigen Platine sieht, wie der Atmga programmiert wurde?!? So wie in dem verlinktem Artikel gehts sowieso nicht.
... schrieb: > LOL. Ein *uino fuer eine Baumaschin. > Wenn das die BG sieht, kriegt das BG-Maennchen einen Herzkasper. Nunja, im 230V Teil wird lediglich zusätzlich ein Kontakt in Reihe zur Schützspule des Mischers eingeschleift. Wenn man den überbrückt, hat man denselben Zustand wie jetzt ohne Arduino. Und dauerndes Überbrücken dieses vom Arduino gesteuerten Kontaktes ist das Schlimmste, was er anstellen könnte. Er könnte also in keinem Falle durch Defekt etwas einschalten sondern höchstens ausschalten. Wenn der Mischer ausgeschaltet wird, trennt das auch das Hutschienen Netzteil für den Arduino vom Strom. Alle vorhandenen Sicherheitseinrichtungen bleiben erhalten.
Vielleicht haben es noch nicht genug Leute geschrieben, dass du es ernst nimmst: Wir könnten Dir helfen, wenn du vollständige Schaltpläne und reichlich Fotos vom Aufbau liefern würdest. Ich habe jedenfalls keine Lust, über mögliche Fehlerursachen abstrakt zu phantasieren.
Stefanus F. schrieb: > Vielleicht haben es noch nicht genug Leute geschrieben, dass du es ernst > nimmst: > > Wir könnten Dir helfen, wenn du vollständige Schaltpläne und reichlich > Fotos vom Aufbau liefern würdest. Witzig, dass das gerade hier steht, wo der Aufbau mit einem ausführlichen Video unter dem Link in der dritten Zeile des ursprünglichen Postings dokumentiert ist. Das Video besteht aus zehntausenden Frames sprich Fotos. Da bleibt wirklich keine Frage zum Aufbau offen. Ein Foto vom Schütz des Betonmischers kann ich derzeit nicht liefern, da der nicht im Zugriff ist. Aber ein Schütz, das einen Motor schaltet, können sich die meisten hier vorstellen. Das Schütz hatte keine Funkentstörung. Die würde ich auch nicht dranbauen, da bei deren Versagen die Schützkontakte überbrückt werden könnten. Es ging mir bei dem Posting auch nicht primär um direkte Hinweise auf die Fehlerursache. Denn die wird bei zig Möglichkeiten per Ferndiagnose kaum jemand stellen können. Primär ging es um (inzwischen beantwortete) Fragen zum Zugang zur Library, mit deren Hilfe ich womöglich den Fehler einkreisen kann. Auch Hinweise auf andere Methoden, sich dem Fehler zu nähern, hatte ich angedacht. Als Workaraound derzeit resette ich den Prozessor und somit den RFID Leser nach dem Schalten des Schützes. Ich hoffe aber, eine noch befiedigendere Lösung zu finden, die die eigentliche Absturzursache eliminiert.
> wo der Aufbau mit einem ausführlichen Video unter dem Link in der > dritten Zeile des ursprünglichen Postings dokumentiert ist. Video sind keine Baupläne. Und dieses Video dokumentiert nicht deinen Aufbau. > Primär ging es um (inzwischen beantwortete) Fragen zum Zugang zur > Library, mit deren Hilfe ich womöglich den Fehler einkreisen kann. Vermutlich wirst du mit Messgeräten und Analyse des aktuellen Aufbaus eher weiter kommen. generell kannst du davon ausgehen, dass Mikrocontroller zuverlässig funktionieren, wenn die Betriebsbedingungen dem im Datenblatt genannten Rahmen entsprechen. Ob das der Fall ist, würde ich zuerst prüfen. Erst wenn die Hardware und die Betriebsbedingungen in Ordnung sind, macht es meiner Meinung nach Sinn, fremde erprobte Libraries auseinander zu nehmen. Zu jeder Header Datei (in deinem Fall SPI.h und MFRC522.h) gibt es in der Regel eine Gleichnamige *.cpp Datei im selben Verzeichnis. Da kannst du ja mal reinschauen.
Schau...du verstehst es nicht ganz! Wenn die Hardware ordentlich ist, treten Software Probleme meistens nicht auf! Wenn das Gerät am Labortisch funktioniert, am Mischer aber nicht, kann es eigentlich nur an der HW liegen. Zuerst muss die HW ordentlich vorhanden sein, dann kann man Fremde libs auseinanderbauen. LG
Angehängte Dateien:
-
DIL_0A_M_Schuetz_1.jpg
290 KB
Bertie schrieb: > Es scheint also, > als ob die Hardware des Lesers beim Schalten des Schützes abstürzt Hi, so ein Schütz, wie im Bild? Herzlichen Glückwunsch. Schau Dir doch mal die Spule des Schützes an. Da macht es ein Streufeld, bevor der Anker nicht voll angezogen, das nicht von Pappe ist. Damit habe ich früher immer Tonbänder gelöscht. ciao gustav
Bertie schrieb: > Eine Betonmischer soll durch RFID-Leser an einem Arduino eingeschaltet > werden. Für einen ersten Test benutze ich diesen Aufbau: > https://www.makerblog.at/2017/11/rfid-transponder-mit-dem-mfrc-522-card-reader-am-arduino-auslesen/ Ich hatte vorgestern genau dasselbe Problem, Arduino Nano mit MFRC 522. Bei mir lag es an der Spannungsversorgung; ein angeschlossenes Servo hat die +5V derart runtergezogen, dass der MFRC gecrasht ist. Für Deinen Fall: Du könntest den PCB vom RFID Leser mit einem Dremel trennen, dann fürhst Du nur die Antenne raus und versorgst den Rest in einem Metall Gehäuse. Auf dem PCB sind es nur wenige Anschlüsse. Alternativ wickelst Du die Antenne selber.
:
Bearbeitet durch User
Philipp G. schrieb: > Ich hatte vorgestern genau dasselbe Problem, Arduino Nano mit MFRC 522. > Bei mir lag es an der Spannungsversorgung; ein angeschlossenes Servo hat > die +5V derart runtergezogen, dass der MFRC gecrasht ist. Ja mei... Wie viel Threads gibt es wohl schon weltweit über Themen wie zB. abstürzende SIM800 oder eben RFID Leser? Es ist immer das selbe, lausiges Layout, lausiger Aufbau, keine Enstörmaßnahmen und immer ist die Software eines Anderen (!) schuld. Bei den Sim800 ist es zu 90% die Stromversorgung -das Ding zieht halt 2.5A Spitzen- und hier ist es wahrscheinlich das selbe. Aber sobald man darauf hinweist heißt es nur: Es ist ein Hobbyprojekt, EMV gilt da nicht, überhaupt sind Ferrite sinnloses Marketing. Ich gebs auf..... LG
Es wurde weiter oben schon mal erwähnt, ist aber wohl untergegangen: Nach Ansicht des TO ist der RFID-Leser das Teil, welches abstürzt. Und es ist auch ganz genau bekannt, wann das passiert: Immer dann, wenn ein Schaltvorgang ausgeführt wird. Neben allgemeinen Verbesserungen im Aufbau würde ich das Problem pragmatisch lösen: Den Reader jeweils resetten bzw. neu initialisieren oder im schlimmsten Fall gar von der Stromversorgung trennen (Reed-Relais). Vlt. kennt die API des Readers ja auch sowas wie Powerdown- oder Offline-Modus, während deren er weniger sensibel auf EM-Impulse reagiert (falls die über die Spule kommen). Das kann man entweder tun, bevor man den Schaltvorgang auslöst, wenn man Glück hat, dauert der Start des Controllers bzw. dessen Selbsttest lange genug ... oder danach, falls er dann noch ansprechbar ist ...
:
Bearbeitet durch User
Ich hab bis jetzt noch nicht so ganz verstanden, warum der Betonmischer nicht einfach nur mit dem Schalter eingeschaltet werden kann.
● J-A V. schrieb: > Ich hab bis jetzt noch nicht so ganz verstanden, > warum der Betonmischer nicht einfach nur mit dem Schalter > eingeschaltet werden kann. Vielleicht soll nur ein Befugter (TO) die Mühle bedienen dürfen? Ohne Schaltplan vom Aufbau dürfte der Drops hier gelutscht sein. Ein paar offene Eingänge reichen ja meist.
Dr.Who schrieb: > ● J-A V. schrieb: >> Ich hab bis jetzt noch nicht so ganz verstanden, >> warum der Betonmischer nicht einfach nur mit dem Schalter >> eingeschaltet werden kann. > > Vielleicht soll nur ein Befugter (TO) die Mühle bedienen dürfen? 'sgibt Schilder. "Betreten der Baustelle verboten Eltern haften für ihre Kinder" weissu?
● J-A V. schrieb: > "Betreten der Baustelle verboten > Eltern haften für ihre Kinder" Ein Richter wird dir was husten.
Dr.Who schrieb: > ● J-A V. schrieb: >> "Betreten der Baustelle verboten >> Eltern haften für ihre Kinder" > > Ein Richter wird dir was husten. ich wusste, dass das kommt. Nur dass das soviele Tage gebraucht hat, wundert mich
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.