ich habe einen Achsencontroller, der pullst fröhlich vor sich hin und
bedient einen Stepper Treiber wunderbar.
Ich habe zur Abzählung der Inkremente einen zweiten Arduino Nano auf der Hutschiene und möchte via "Falling-Edge" mitzählen, dazu habe ich den Interrupt Eingang Pin2 mit 10K gegen Masse gelegt, um frei Schwingungen zu unterdrücken. (in meiner Not).
Ob nun mit oder ohne widerstand , am Ende zählt der Lauscher immer ein paar Impulse zu viel , Beispiel satt 1999 macht er 2008 draus.
Der Lauscher ist zwar am Serial Port , sendet und empfängt aber während der Zählung kein RS232.
Wie kann ich den Katastrophalen miss-Zähler doch noch unter Kontrolle bringen ?
Die Motorwindungen erzeugen immer ein bissel Rauschen.
Wie wurde da die Masse angeklemmt? Ist das exakt das Signal, das der Arduino direkt an seinem Interruptpin sieht (also Masseklemme des Tastkopfes am Arduino-GND und Tastspitze am Arduino-Pin)?
Denn du hast sicher ein EMV-Problem, wenn du immer zu viele Pulse zählst.
Ich habe zur Abzählung der Inkremente einen zweiten Arduino Nano auf der
Hutschiene und möchte via "Falling-Edge" mitzählen, dazu habe ich den
Interrupt Eingang Pin2 mit 10K gegen Masse gelegt, um frei Schwingungen
zu unterdrücken. (in meiner Not).
Ganz ohne Kondensator bringt das sowieso nichts. Denn erst zusammen mit einem Kondensator wird das ein Tiefpass.
Laut meinem EMV-Spezi ist alles über 4kOhm ist aus EMV-Sicht quasi nicht vorhanden.
Aber warum nimmst du nicht grundsätzlich einen Zählereingang zum Mitzählen? Und davor dann eine halbweg vernünftige Filterung.
Hallo Danke der Antworten,
ja alles liegt auf Masse, auch die Hutschiene, das Netzteil, alles ist auf Ground gelegt, auch die Arduinos.
Das Signal ist scheinbar unsauber, werde am Eingang einen NF Tiefpass legen, 10K ist also zu hoch ? Also 4,7k gegen Masse parallel 10pf ?
Der gebende Arduino, bedient auch mit einem Zugriff mehrere BYTE -Register
so das alle Outputs zu einer Zeit stattfinden. Mal das Signal ansehen wenn der Treiber abgeklemmt ist.
Hallo, ich nutze die gleichen Motortreiber, habe aber die Stromversorgungen der Steuerung und der Leistungsseite einschließlich der Massen voneinander getrennt . Das läuft sehr gut. Ein Indikator kann auch die eine LED sein, die bei jedem Vollschritt leuchtet.
Gruß
Carsten
Als erste Debugmassnahme geht man mit dem Interrupt auf einen unbenutzten Pin. zB Beginn der Interruptroutine = pin hoch, Ende der Routine = Pin tief.
Dann kann man das mal auf dem Oszilloskop mit dem Erwarteten vergleichen
Da schafft ja offenbar noch nicht mal das Oszi einen sauberen Trigger.
Du guckst an der falschen Stelle. Das Oszi triggert sauber auf die steigende Flanke in der Mitte vom BS. Das, was du hier als "unsauberen Trigger" verkaufen willst, ist ein Jitter der Impulslänge.
Da schafft ja offenbar noch nicht mal das Oszi einen sauberen Trigger.
Wie soll das dann der wesentlich simpler gestrickte µC-Eingang
hinbekommen?
Keine Ahnung, was du mir sagen willst.
Ich wollte nur sagen, dass man mit Peak-Detect extrem kurze Störimpulse sehr gut finden kann. Ohne Peak-Detect sind kurze Impulse oft unsichtbar, wenn sie kürzer als 1 Pixel sind. Peak-Detect zeigt Pulse immer mit mindestens einem Pixel breite an, wenn sie in den Rohsampledaten vorhanden sind.
Hallo, wenn Du die Stromversorgung der Motore von Deiner Schaltung trennst, misst Du dann auch noch zu viele Impulse? Sind die Fehler gleich groß, wenn Du den Motor ein weiteres mal gleich ansteuerst? Wenn Du dir das Schaltbild von den Motortreibern anschaust, siehst Du, das die Eingänge auf Optokopplern enden. Wenn Du da sehr kurze Impulse oder ein „hohes Rauschen“ sendest, werden die einfach unterdrückt, wenn der Pegel stimmt. Suchst Du, weil Du einen Versatz hast, oder weil Du den Zählerstand vom Arduino nicht auslesen kannst? Treten die Fehler auch auf, wenn Du die steigende Flanke auswertest?
Gruß
Carsten
Das Oszi triggert sauber auf die steigende Flanke in der Mitte vom BS.
Das, was du hier als "unsauberen Trigger" verkaufen willst, ist ein
Jitter der Impulslänge.
Ich bin mir zu >99% sicher, dass das nicht der Jitter ist, sondern dass das Oszi da auf einen Spike getriggert hat. Jitter sieht anders aus.
Dir gar nichts. Ich sagte nur, was ich sagte: nicht einmal das Oszi kann dieses Signal ordentlich triggern. Da wundert mich nicht, dass (wie berichtet) der Interrupt auch zusätzlich ausgelöst wird und das unbekannte Programm dann weiterzählt.
Peak-Detect zeigt Pulse immer mit mindestens einem Pixel breite an,
wenn sie in den Rohsampledaten vorhanden sind.
Bei manchen Oszis ist es noch wilder: die Trigger-Unit ist hardwaremäßig unabhängig(!) vom Sampling. Es kann also passieren, dass das Ding zwar triggert, aber weil da in dieser ps grade nichts abgetastet wurde, ist kein Pixel zu sehen (oder ein zu "niedriger")
Und die augenscheinlich steilen Flanken des Signals enthalten dieses Rauschen und "Gezappel" natürlich auch. Dann ist so eine fallende Flanke auf einmal nicht mehr stetig, sondern hat 2 Flanken und triggert den Interrupt ggfs. auch 2 mal:
Danke der Hinweise,
ja Peaks werden direkt mitgezählt, ich erhalte inzwischen die richtige Anzahl, dazu musste ich den chinesischen Driver von der Hutschiene nehmen (Metall Kupplung) und auf Plastikböcke setzen, wie der eine Kollege schon sagte, den ganzen Treiber auf einen anderes Netzteil legen, der macht mächtig EMV für seine 25€.
Lasse ich die Micro-Controller trocken fahren, zählen sie sich gegenseitig genau , 20Khz sind kein Problem.
Also Elektro design, man kann diese Treiber nicht auf einer gemeinsamen Hutschiene haben.
Danke der Hinweise, wir forschen weiter.
Grüße aus Berlin
Karsten (www.FlexxVision.de)
Also Elektro design, man kann diese Treiber nicht auf einer gemeinsamen
Hutschiene haben.
Doch, kann man schon, man muss dann aber für eine passende Masseführung und Entkopplung sorgen. EMV-Geschichten eben...
Bei dem Aufbau vom ersten Bild wundert mich nicht, dass da was überkoppelt. Dafloaten die Hutschienen ja auch nur irgendwie in der Luft herum. Die gehören auf eine Metallplatte und die Metallplatte gehört an Erde und Erde gehört über einen Kondesator verbunden mit GND.
Naja die Schienen sind geerdet mit der Hutschienen -Erdungsklammer, es ist nicht gerade unbekannt was Störungen angeht nach 48 Jahren im Beruf.
Doch heute habe ich alles zerlegt, und erst wenn ich den Arduino mit einem Akku betreibe erhalte ich saubere Flanken, sowie mein PowerPC am Netz hängt , erzeugen die Flanken die langen Spikes die kommen über USB rein.
Das Rauschen auf der Flanke konnte ich abschalten durch entfernen des Hutschienennetzteils.
Fazit , Serial-Port am Rechner und am Micro-Controller, streut massig NF / HF ein, so das ich keine Impulse zählen kann, sondern Doppel Nasen-Spikes an jeder Flanke habe bis ich den Akku anstecke, und den PC abtrenne.
So habe ich das auch noch nicht gehabt. Und muss erstmal ne Kiste Netzfilter kaufen , schauen ob ich irgendwie klar komme, die Erde ist in der zweiten Etage einer Firma, wie kann ich testen ob die Erde überhaupt richtig angeschlossen ist, ich darf mich hier auch nicht lächerlich machen ^^
Inzwischen habe ich diese Spikes das Rauschen ist raus, und alle meine Filter RC(Glieder) sind gescheitert.
Ich muss wohl oder Übel Softwarefilter im Interrupt-hanlder haben.
einfach ne Member dort hochzählen reicht unter diesen Bedingungen nicht aus.
Am Ende habe ich ein rudimentäres warten auf 5 Mikro Sekunden im Empfänger integriert, und die Sache stimmt, solange man mehr Impulse hat ist man auf der grünen Seite. Also bei schlechter Netze muss ein Softwarefilter mit laufen. leider Gottes.
Und das vorgeschlagene RC-Glied wird nicht erforscht?
Ist wohl auch zu einfach und zu gut.
Hallo Mi N Max
hatte leider keine Ergebnisse erbracht, die Störungen kamen direkt vom USB des PC's ich habe jetzt eine bessere Verteilerdose mit 10m Kabel an einer anderen Steckdose, ich konnte so die Störungen um 50% reduzieren, und verwende nun einen Softwarefilter, um Doppelnasen zu übergehen.
Danke für deinen Filter, den werden wir in 100 Jahren noch als Referenz antreffen, als alter Funker weiß man sehr wohl die Filter zu Begehren.
Naja die Schienen sind geerdet mit der Hutschienen -Erdungsklammer
Wie gesagt: ich sehe in dem Foto absolut keine brauchbare Erdung, die irgendwie für oder gegen EMV helfen würde. Klammern und Anbindung über Kabel sind suboptimal. Solche Kabelverbindungen nennt der EMV-Profi abwertend "Pigtails": https://www.google.com/search?q=emv+pigtail
Ich muss wohl oder Übel Softwarefilter im Interrupt-hanlder haben.
Meine Prognose: du wirst mit derartigem Hinfrickeln trotzdem Verzähler haben.
Inzwischen habe ich diese Spikes das Rauschen ist raus
Wo ist dieses Signal gemessen? Wo ist die Masse angeklemmt? Wo ist die Tastkopfspitze aufgelegt?
Mal ein kleiner Tipp: miss in deinem System mal "Masse gegen Masse". Ja, richtig: Masseklemme an irgendeinen Massepunkt und Tastkopfspitze an irgendeinen (etwas weiter entfernten) anderen Masse punkt. Das sollte auf dem Oszi idealerwiese ja eine gerade Linie geben. Was siehst du?
nicht gerade unbekannt was Störungen angeht nach 48 Jahren im Beruf.
Hmmm... was soll man da noch sagen. Wenn du eh' schon weißt, woher das kommt und was dagegen hilft, warum fragst du dann noch?
Hallo, das Thema Probleme durch Erdung oder Masseschleifen hatten wir schon mehrfach. Es ist schlau, die 5V Versorgung entweder vom Rechner oder meinetwegen vom USB-Ladegerät o.Ä. zu versorgen. Die Masse vom Hutschienennetzteil muss nicht unbedingt mit der Masse vom Netzteil des Bedienrechners(oder Oszi)übereinstimmen. Die können ein paar Volt auseinander liegen. Auch der Spannungsabfall auf der gemeinsamen Minus- Leitung kann Probleme machen. Kann man leicht messen. Sternförmig sollte da verkabelt werden. Eine gemeinsame minus- Leitung des Arduinos und des Leistungsteils sollte man nicht machen. Da der Micro-Controller nicht prellen kann, halte ich ein RC-Glied nicht für sinnvoll. Es verzerrt nur die Flanken.
Viel Erfolg
Carsten
und alle meine
Filter RC(Glieder) sind gescheitert.
Du meinst die mit 10 pF? Das wäre wenig überraschend.
Wenn Du es garnicht anders gebacken bekommst, nimm einen Optokoppler zu Trennung oder sorge einfach für eine richtige Masseverbindung.
AVRs haben an den Eingängen Schmitttrigger. Die Optik der Flanken ist
wurscht.
Naja die sind nach 100 Jahren NPN Tatsächlich sehr robust. Aber Schalten durch wenn das Signal Nasig ist, leider habe ich am Ende und am Anfang je eine lange Nase , er zählt gerne einen mehr, nie weniger.
Optokoppler sind zu langsam, es gab mal welche die in 1Mikrosekunde durchschalten ich glaube die Din-Rail Version von Hirschmann Version hat 600€ gekostet.
Ich habe jetzt bei 1Million Impulse ca 20-100 Fehlzählungen, für eine Geldzählmaschine reicht es noch nicht ganz.
Hallo Carsten, genau, ich konnte die Flanken schön Biegen mit den RC-Gliedern, aber die Grundform der Nasenhaltigkeit blieb stehts erhalten, erst al ich den Nano mit dem Akku laufen lies sah alles gut aus. Die Störungen kommen vom PC über die USB Schirmung. Mantelkerne sind bereits oben und unten enthalten.
Die Fritzbox bietet an USB Geräte über Ethernet abzubilden, sehr witzig.
EMV ist ein Synonym, und wird breitbandig verwendet, wenn man sich auf kleinkarierte Floskeln begrenzt , ist man auf kleinkarierte Floskeln begrenzt, und wird diese nie im ganzen Leben überwinden können, das Thema ist nicht die Rechtschreibung. Diese windet sich im Grammatik Zirkel der entsprechenden Foren . Man weiß, wenn man guten Willens ist was man meint, nur darauf kommt es an, auf den guten Willen. Bösartige Kleinkariertheit hat noch niemals zu einem Ziel geführt, leider Gottes .
Kopf und Kragen EMV , Du bist ein Schnipsel Jäger und wie man sieht zum Thema hat so ein Kleinkarisma noch nie beigetragen, deine einzige Beschäftigung ist das Suchen Nach Digmenverbrecher.
Früher haben wir dann gesagt anstatt sich um den Kopf zu drehen, fuck you into the kneel.
Man weiß, wenn man guten Willens ist
was man meint
Mit der gleichen Argumentation kommen auch Studenten an... Ja, wahrscheinlich weiß der Prof, dass du MHz meinst, wenn du mhz schreibst. Falsch ist es trotzdem. Sind schon Raketen abgestürzt/explodiert, weil jemand Millimeter und Zoll verwechselt hat, oder Bindestrich statt Minus.
Im Bereich Technik ist kein Platz für "du weißt schon was ich meine".
Ich habe jetzt bei 1Million Impulse ca 20-100 Fehlzählungen
War mir klar, dass das nicht zuverlässig läuft.
Meine Maschinen müssen die ganze Nacht durchlaufen und dann muss der Zähler aufs Inkrement stimmen. Sonst habe ich noch einen Fehler drin. Mir graut vor Geräten, wo der Entwickler erkennbar so lange herumgefrickelt hat, bis es (ihm selbst) "gut genug" war.
wenn man sich auf kleinkarierte Floskeln begrenzt , ist man auf
kleinkarierte Floskeln begrenzt
Wenn man hohle Phrasen drischt kommen nur Worthülsen raus. Hast du die Messung mit "Masse gegen Masse" mal gemacht. Die bringt die so manchen auch nach 45 Jahren Erfahrung ins Grübeln.
Hallo, das mag hier so sein. Ich programmiere gerne in Assembler. Wenn ich den Aufwand sehe, den ich manchmal betreibe, um zeitkritische Aufgaben zu verwirklichen, erscheint es mir aber doch etwas befremdlich. Die digitalen Pegel sind ja in den Datenblättern veröffentlicht. Manchmal sind selbst Laufzeiten auf kurzen Leitungen kritisch. Da vermeide ich gerne unnötige Risiken durch flache Flanken.
Gruß
Carsten
Ich programmiere gerne in Assembler. Wenn
ich den Aufwand sehe, den ich manchmal betreibe, um zeitkritische
Aufgaben zu verwirklichen, erscheint es mir aber doch etwas befremdlich.
Manchmal regnet es.
Manchmal sind selbst Laufzeiten auf kurzen Leitungen kritisch. Da
vermeide ich gerne unnötige Risiken durch flache Flanken.
Und manchmal scheint die Sonne.
Du scheinst mir ein wenig ängstlich zu sein.
Da der Motor ja nicht beliebig schnell beschleunigt, verwirft du jede Flanke die ungewöhnlich kurz im Verhältnisse zu den langen Flanken ist. Also 50msek 5mSek 50mSek 5mSek. Jetzt ignorierst du die 5mSek Flanken da eine Abweichung um > x % eben nicht passt.
verwirft du jede Flanke die ungewöhnlich kurz im Verhältnisse zu den
langen Flanken ist. Also 50msek 5mSek 50mSek 5mSek.
was machst du dann bei 50ms-20ms-30ms-25ms-25ms-50ms?
das Ganze muss adaptiv erfolgen, denn wenn der Motor im "50ms-Takt" langsam läuft, dann dann kannst du schon die kurzen Pulse unter 5ms ignorieren. Aber wenn der Motor dann mal schneller im "5ms-Takt" läuft, dann wäre das Ignorieren von 5ms-Impulsen sehr ungünstig.
wir sind hier etwa 100 mal schneller unterwegs. Die Software, die die Beschleunigung "verfolgt", die Pulse bewertet und und laufend die Grenzen "adaptiert", muss also schon recht gut programmiert sein, denn das Ganze soll ja vermutlich auf einem Arduino Nano mit dem Arduino-Framework passieren.
Fazit: es ist immer besser, die Ursache des Problems zu beheben (zumal es ja bekannt ist), als hinterher einen wilden Würgaround in ein Softwarekonstrukt zu frickeln.