Infrarot Protokoll eines 3D- Tasters erkennen / entschlüsseln

Hesse

Level-3
Beiträge
1.064
Reaktionspunkte
270
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
bevor ich des Doppelposten beschuldigt werde :

Ja, aber technisch ist das wohl zu speziell für:
https://forum.zerspanungsbude.net/viewtopic.php?f=11&t=85040

Wer erkennt das Protokoll ?

Mindestens drei Bit müssten da drinnen stecken:

Betriebsbereit
Batterie leer
Taststab betätigt

Hintergrund :
Ich habe keinen Originalempfänger welcher >500€ gebaucht kostet.
Ich würde den aber gern an meiner Kunzmann verwenden und dort an die „visulesta 4 aktiv“
anbinden.


gesamt Timing
Ges_Timing_1.JPG

Frame x_0_x ist nichtbetätigt


ein_Frame_0__1.JPGein_Frame_0__2.JPGein_Frame_0__3.JPG

Frame x_1_x ist betätigt


ein_Frame_1__4.JPGein_Frame_1__5.JPGein_Frame_1__6.JPG
 
Woher weißt du das es sich um bestätigt und unbestätigt handelt, wenn du den Empfänger nicht hast zum decodieren?

In diesen Bereich werden auch gerne proprietäre Protokolle benutzt, man will nicht zufällig mit einer Radiofernbedienung ein „Taststab betätigt“ senden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
bestätigt und unbestätigt handelt,
Nicht: bestätigt & unbestätigt sondern :
Betätigt und nicht Betätigt

also ob der Messstab eine Berührung verspürt ...
und das mach ich testweise von Hand

die ersten drei Bilder zeigen das gesendete bei "NICHT" betätigtem Stab
die zweiten drei Bilder zeigen das gesendete bei betätigtem Stab
 
Nicht: bestätigt & unbestätigt sondern :
Betätigt und nicht Betätigt

also ob der Messstab eine Berührung verspürt ...
und das mach ich testweise von Hand

die ersten drei Bilder zeigen das gesendete bei "NICHT" betätigtem Stab
die zweiten drei Bilder zeigen das gesendete bei betätigtem Stab

Man findet etwas in den vielen PDFs


Wenn ich das richtig verstanden habe, dann muss der Empfänger erst ein Einschaltbefehl an den Messkopf senden. Wie realisierst du das?
Leider habe ich zum IRP25.00 keine PDF gefunden.
 

Anhänge

  • IMG_3281.png
    IMG_3281.png
    311,1 KB · Aufrufe: 9
Die PDF ist von einem anderen viel moderneren Tastkopf
der Anhang ist die Belegung oder Schaltbeschreibung des Empfängers zu dem IRR61...
Genau so ein Empfänger (nur für25.xx )will ich nachbauen und dazu das IR Protokoll verstehen...


Wenn ich das richtig verstanden habe, dann muss der Empfänger erst ein Einschaltbefehl an den Messkopf senden. Wie realisierst du das?

Eingeschaltet wir der mechanisch über die Anzugsspindel.
Eingeschaltet ist er bei mir ja , er sendet und die Kontrolle led geht auch beim betätigen auf Dauerlicht.
Die Kommunikationsrichtung ist bei dem alten 25.xx nur in eine Richtung.
3d-Kopf ---- > Empfänger
Leider habe ich zum IRP25.00 keine PDF gefunden.
Das ist ja mein Problem, selbst vom Hersteller keine Antwort auf meine freundliche Anfrage erhalten :-(
außerdem wir in der Beschreibung bestimmt auch nicht das Protokoll offengelegt sein ...

Könnt aber sein das ich ein schritt weiter bin :
Bei einem anderen Protokoll das man einstellen kann scheint das Signal über die
Puls --- Pausen Signal übertragen zu werden
Das muss ich nochmals testen

2,75us Ein ____ 37,5us Aus__2,75us Ein 16ms Pause (von Vorne) ----> Unbetätigt
3us Ein ____ 29,25us Aus__3us Ein 16ms Pause (von Vorne) ----> betätigt
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Könnt aber sein das ich ein schritt weiter bin :
Bei einem anderen Protokoll das man einstellen kann scheint das Signal über die
Puls --- Pausen Signal übertragen zu werden
Das muss ich nochmals testen

2,75us Ein ____ 37,5us Aus__2,75us Ein 16ms Pause (von Vorne) ----> Unbetätigt
3us Ein ____ 29,25us Aus__3us Ein 16ms Pause (von Vorne) ----> betätigt

Ich denke du bist auf dem richtigen Weg mit der Methode reengineering, außer du findest jemanden der genau das Gleiche schon gemacht hat.

Vielleicht hier versuchen

 
Ich habe unter den vielen einzustellenden Protokollen ein "Eindeutigeres" gefunden

Betätigt :
Betaetigt_edit.jpg

nicht Betätigt :
nicht_Betaetigt_edit.jpg


Das jetzt in einem arduino auszuwerten ist kein Problem.

sollte aber doch auch direkt in der SPS (s7-12xx) möglich sein

5V Eingang auf das Signal Board 6ES7223-3AD30-0XB0

Jetzt die Frage an die SPS Programmiere des letzten Bit's

Wie auswerten :
1. Schneller Zähler (Betätigt ist ja ein ganzer Impuls mehr)
2. Baustein in SCL mit direktem Hardware Zugriff
3. RS232 Modul (kann nur 115,2 kBit/s,) musste aber doppelt so schnell sein)

Ich bräuchte die Auswertung nur mal auf Kommando nicht ständig im Hintergrund
Ich sag mal, ein Aufruf, der prüft 3 Frames, ist in <15ms Fertig setzt direkt ein Ausgang wenn betätigt.
Zykluszeit ist dann halt mal 15ms länger

Danke für Ideen...
 
Ich habe unter den vielen einzustellenden Protokollen ein "Eindeutigeres" gefunden

Betätigt :
Anhang anzeigen 87998

nicht Betätigt :
Anhang anzeigen 87999

Das jetzt in einem arduino auszuwerten ist kein Problem.

Das sieht sehr gut aus und mittels MC sehr leicht zu lösen.

Was stellst du dir mit dem schnellen Zähler vor? Wenn aller 15ms 9 Impulse kommen ist das quasi bestätigt?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was stellst du dir mit dem schnellen Zähler vor? Wenn aller 15ms 9 Impulse kommen ist das quasi bestätigt?
(BETÄTIGT ! nicht bestätigt)

zum beispiel eine möglichkeit .

Ich dacht evtl:
Zähler laufen, lassen per Interrupt bei übersteigen eines bestimmten Wertes ---"ALARM"
diesen Zähler alle zb.10ms auf Null setzen (Watchdog Prinzip)



Ich höffe noch auf gute vorschläge wie das gut zu lösen ist.
 
(BETÄTIGT ! nicht bestätigt)

zum beispiel eine möglichkeit .

Ich dacht evtl:
Zähler laufen, lassen per Interrupt bei übersteigen eines bestimmten Wertes ---"ALARM"
diesen Zähler alle zb.10ms auf Null setzen (Watchdog Prinzip)



Ich höffe noch auf gute vorschläge wie das gut zu lösen ist.
Willst du nicht auswerten was für Signale kommen? Zwischen Start und Stopbit könnten sich durchaus auch zwei Bits befinden oder nur eins an der zweiten Stelle.
Wie viel Erfahrung hast du allgemein mit Protokolle?
 
Ich höffe noch auf gute vorschläge wie das gut zu lösen ist.
TLDR: mit dem Arduino. Keine Ahnung wie detailliert die Auswertung werden soll, aber für den ersten Wurf würd ich mit:
  • >1ms Signal HIGH -> neues Frame,
  • nach Startbit 15μs die Daten aufzeichnen (zB im 1μs Raster) und
  • außerhalb der ISR auswerten.
ins Rennen gehen. Idealerweise mit den Portbefehlen ohne Arduino-Overhead, dann könnte das doch klappen.

Ich weiß auch nicht, ob wir bei dem Mitschnitt das gleiche sehen:
mir kommts vor, als siehst du "langer grüner 1 Level: nicht betätigt, kurzer grüner 1 Level: betätigt.", zumindest schließe ich das aus den verwendeten Farben.
Für mich sieht das aus, als müsste auch im zweiten Bild der blaue Puls lila sein und alles was im zweiten Bild grün ist, ist ein Datenbereich, in dem "betätigt" (und eventuell Batterie Warnung) als 3µs Pulse übertragen werden. Gelb könnte ein Startbit sein, bei Lila bin ich mir nicht sicher, ob Daten- oder Stopbit, aber wenn ich raten müsste, würde ich sagen Stopbit aufgrund der "unrunden" Länge.
"Betriebsbereit" könnte sich daraus ergeben, ob der Empfänger in den letzten X (Milli-)Sekunden mindestens Y gültige Frames empfangen hat.



Was mir bei der SPS ein wenig Bauchschmerzen bereiten würde ist die Abtastrate von dem Signalboard:
1748709113381.png

Wenn man davon ausgeht, dass du das kritische 3µs lange Bit erkennen musst und dafür schon mindestens 1 / (3*(10^-6)) = 333.3 kHz (und nach Nyquist, eigentlich >x2, also >666.6 kHz) nötig wären, könnte es schlimmstenfalls vorkommen, dass du das Bit auch bei 3 Frames verpasst. 200 kHz (alle 5µs eine Abtastung) sind hier meiner Meinung nach zu wenig und wie gut das in der 1200er mit allen Laufzeiten umzusetzen ist, sei auch mal dahingestellt. Aber selbst wenn es ging, wär es wahrscheinlich noch eine ziemliche Hack-Lösung.
Das ist aber ehrlicherweise auch keine typische Anwendung für eine (Klein-)SPS. Ein 16 MHz Micro ist da, denke ich, die bessere Wahl.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für mich sieht das aus, als müsste auch im zweiten Bild der blaue Puls lila sein und alles was im zweiten Bild grün ist, ist ein Datenbereich, in dem "betätigt" (und eventuell Batterie Warnung) als 3µs Pulse übertragen werden. Gelb könnte ein Startbit sein, bei Lila bin ich mir nicht sicher, ob Daten- oder Stopbit,
Ja, sehe ich auch so . Sorry da habe ich mir bei der Wahl der Farben nur bedingt Gedanken gemacht

, kurzer grüner 1 Level: betätigt."
bedingt --> das vorhanden sein des 3us blauen 0 Level ist für mich das Signal betätigt.

Den Datenbereich sehe ich auch zwischen Start und Stoppbit ...
da müsst ich nochmal weiter simulieren (Batterie Warnung & Betriebsbereit )
die Signale sind aber für mich zur "schön zu haben" und nicht zwingend notwendig.

Wenn man davon ausgeht, dass du das kritische 3µs lange Bit erkennen musst und dafür schon mindestens 1 / (3*(10^-6)) = 333.3 kHz (und nach Nyquist, eigentlich >x2, also >666.6 kHz) nötig wären, könnte es schlimmstenfalls vorkommen, dass du das Bit auch bei 3 Frames verpasst. 200 kHz (alle 5µs eine Abtastung) sind hier meiner Meinung nach zu wenig und wie gut das in der 1200er mit allen Laufzeiten umzusetzen ist, sei auch mal dahingestellt.
Berechtigter Einwand ...
ich bin aber jetzt erstmal naiv davon ausgegangen :
Wenn das Board auch als schneller Zählereingang gedacht (verwendbar) ist .
Muss doch die Hardware auf Impulse (Pegelwechsel ) reagier und nicht an eine Abtastrate gebunden sein.
Aufgrund der extra Hardware /(Zähler)auch unabhängig vom CPU Zyklus ist.
Wenn man den sonst als Zählereingang verwendet ist das Takt/Pause Verhältnis auch nicht 1:1
(Beispiel Schwungscheibe mit einem Ini und einem Impuls pro Umdrehung)

Auswertung in der SPS ist nicht zwingen ... aber die ist nun mal da
Eine uC ist immer so ein "Bastellösung" und das Blickt später mal keiner mehr ....


"Betriebsbereit" könnte sich daraus ergeben, ob der Empfänger in den letzten X (Milli-)Sekunden mindestens Y gültige Frames empfangen hat.

Interessanter Ansatz.
Du meinst "Betriebsbereit" entsteht nur im Empfänger und steckt gar nicht im Protokoll ?
 
Zuletzt bearbeitet:
Berechtigter Einwand ...
ich bin aber jetzt erstmal naiv davon ausgegangen :
Wenn das Board auch als schneller Zählereingang gedacht (verwendbar) ist .
Muss doch die Hardware auf Impulse (Pegelwechsel ) reagier und nicht an eine Abtastrate gebunden sein.
Aufgrund der extra Hardware /(Zähler)auch unabhängig vom CPU Zyklus ist.
Wenn man den sonst als Zählereingang verwendet ist das Takt/Pause Verhältnis auch nicht 1:1
(Beispiel Schwungscheibe mit einem Ini und einem Impuls pro Umdrehung)
Ich fürchte, auch das Signalboard wird einen µC an Bord haben, der irgendwo limitiert ist (Eingang filtern, Kommunikation zur SPS, ... )
Eingangsfrequenz finde ich ad-hoc leider keine zu dem Gerät, überall ist nur von 200 kHz die Rede, was aber für eine 1200er eh schon eine Menge ist - der Standardzähleingang der 1200er hat "nur" 100 kHz. Hier hat es einer geschafft, mit der Karte mit Interrupts sage und schreibe 2.8 kHz abzutasten und wenn du die Karte mal als Zählerkarte parametrierst, sagt dir TIA auch gleich was Phase ist:
1748801359475.png

Unabhängig dessen, ist mMn ein Zähler hier auch Fehl am Platz, da du nicht nur die Anzahl der Pulse wissen musst, sondern auch die Position. Falls neben dem "Betätigt" auch noch eine Batteriewarnung vorhanden ist, kommst du da in ziemliche Kalamitäten.



Auswertung in der SPS ist nicht zwingen ... aber die ist nun mal da
Eine uC ist immer so ein "Bastellösung" und das Blickt später mal keiner mehr ....
Ich wünsche dir echt nix Böses, aber ich denk nicht, dass das mit der 1200er was wird.

"Bastellösung" ist immer relativ; ich fänds z.B. gebastelt, anhand der Anzahl Pulse die Auswertung zu machen - vorallem, wenn die Karte um Faktor 3 zu langsam ist. So unsauber ist es jetzt auch nicht, die Empfangsdekodierung in einem autarken Gerät zu machen.
Klar, Online beobachten geht nicht und Software Upload geht auch nicht, aber ich denk nicht, dass da ein Weg vorbeiführt.

Hab nur kurz mal recherchiert: Beckhoff bietet 1 MHz Klemmen an (wobei ich jetzt nicht weiß, ob das rein für Encoder ist, oder ob die auch Interrupts kann), da wirst du aber fürchte ich auch deine PLC upgraden müssen und Siemens bietet ein TM FAST als Huckepack-FPGA an, aber ich denke, dass du da preislich jenseits von Gut und Böse bist.



Interessanter Ansatz.
Du meinst "Betriebsbereit" entsteht nur im Empfänger und steckt gar nicht im Protokoll ?
Naja, was hat denn der Messtaster realistisch noch für Signale, außer den Kontakt für "betätigt" und evtl. die Batteriewarnung?
Es würde in meinen Augen schon Sinn machen, den Kommunikationsweg auch auszuwerten.
 
Zuletzt bearbeitet:
Hab nur kurz mal recherchiert: Beckhoff bietet 1 MHz Klemmen an (wobei ich jetzt nicht weiß, ob das rein für Encoder ist, oder ob die auch Interrupts kann), da wirst du aber fürchte ich auch deine PLC upgraden müssen und Siemens bietet ein TM FAST als Huckepack-FPGA an, aber ich denke, dass du da preislich jenseits von Gut und Böse bist.
Da kann ich auch nur zustimmen. Respekt an @revve für die Recherche.

Für 3,5€ bekommst du schon ein PiPico, ist zwar mit Kanone auf Spatzen, aber fast Plug and Play.
 
Zurück
Oben