Betonmischer lässt RFID Leser abstürzen

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:
> 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.

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:
> 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

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.

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

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

● 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.

● J-A V. schrieb:
> "Betreten der Baustelle verboten
> Eltern haften für ihre Kinder"

Ein Richter wird dir was husten.