IR Empfänger für SPS

edison

Level-2
Beiträge
716
Reaktionspunkte
113
Zuviel Werbung?
-> Hier kostenlos registrieren
Grundidee des Ganzen ist, eine normale Infrarotfernbedienung mit einer SPS zu koppeln.

Sicherlich gibt es da schon fertige Dinge,- aber vor dem Hintergrund, das das ganze hinterher Privat eingesetzt werden soll spielt der Preis halt auch eine Rolle.
(IrTrans + CP340 kommen auf ca. 400,-€ => das ist mir der Spaß nicht wert)

Eigentlich gab das es da ein fertiges IC, das mir die RC5 Infrarotsignale decodiert und ausgangsseitig als Bits ausgibt.
Leider wird dieser Baustein (SAA3049) nichtmehr hergestellt.

Durch einen anderen Thread scheint mein vorhaben doch Realisierbar:
Zu dem IR-Empfänger der je in dem Beitrag off Topic ist kann man durchaus drüber nachdenken so was zu lösen. Ein ATmega8 mit Quarz, Spannungsregler und Co. + IR-Empfänger + Optokoppler um an die 24V der SPS zu kommen ist ja von der Hardware her nichts wildes. Man Braucht 5 Bit für die Adresse und 6 Bit für den Befehl.
Mach doch mal einen eigenen Thread auf und wir können dort über das Projekt weiter schreiben.

@automationLab
Genauso hatte ich mir das vorgestellt:ROFLMAO:
Nur leider hab ich von Atmegas keinen Plan.
Plan entwerfen und das Ganze auf Lochraster bringen krig ich wohl hin aber dann ist schluß.
 
Die Auswertung von RC5 mit einem ATmega ist sehr leicht im Internet zu finden. Also die Programmierung bzw. das zusammensetzen den Code Stücke und das Flashen von einem ATmega8 kann ich übernehmen. An einem ATmega32 habe ich einen IR-Empfänger schon laufen.

Hier noch zwei Links zum Thema:
http://www.roboternetz.de/wissen/index.php/RC5-Code
http://www.roboternetz.de/wissen/index.php/RC5-Decoder_für_ATMega

Die Grundschaltung des ATmega und das anschließen des Empfängers ist denke ich klar. Aber wie sollte man am besten die µC->SPS Schnittstelle realisieren?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Grundschaltung des ATmega und das anschließen des Empfängers ist denke ich klar. Aber wie sollte man am besten die µC->SPS Schnittstelle realisieren?

Ich hatte mir vorgestellt, einfach alle Bits des RC5 Codes auf SPS Eingänge zu legen.
Ist superschnell und finanziell noch vertretbar.
Alternativ könnte man natürlich auch seriell über einen Eingang die Daten an die SPS übergeben. Das wäre zwar langsamer aber eleganter und günstiger.
Die Übertragung der 14Bit RC5 nehmen ja eh schon 30ms in anspruch - da könnte man sich bei der Komminikation zu SPS wohl auch noch 100ms Zeit nehmen.

Oder wie wäre es, Dein InfoTextDisplay um die IR Funktion zu erweitern?
Zu den 8DO kämen dann noch 8DI von der SPS - noch 2-5 Taster dabei und fertig ist das HMI ... oder spinne ich jetzt rum:rolleyes:

Also die Programmierung bzw. das zusammensetzen den Code Stücke und das Flashen von einem ATmega8 kann ich übernehmen
Das wäre prima.
Dann zeiche ich einen Schaltplan und bringe das Ganze auf eine Lochstreifenplatine.
 
Ich würde dafür erstmal einen eigenen ATmega8 nehmen. Ich habe zurzeit beim InfoTextLCD nur noch vier I/O Pins frei.

Die Lösung mit den 11 Datenleitungen (5=Adresse, 6=Befehl) halte ich auch für die Praktikabelste. Als Schnittstelle würde ich auf drei PC847 Optokoppler zurück greifen. Die Spannungsversorgung sollte aus den 24V der SPS gesehen damit man kein Steckernetzteil oder so was braucht.

Morgen organisiere ich mir noch einen TSOP1736 IR-Empfänger. Dann kann ich auch schon am WE damit experimentieren.
 
Ich habe gestern Abend mal etwas mit dem IR-Empfänger an meinem ATmega32 gespielt. Die Auswertung klappt soweit auch.

Test mit der TV-Fernbedienung (Philips):
Geht prima nur bei der Taste-Null ist eben die Adresse und der Befehl auch Null. Was die erkennen auf der SPS Seite nur anhand der Adresse und des Befehls unmöglich macht. Zurzeit schalte ich die Ausgänge vom µC nach einer kurzen Zeit aus damit man in der SPS auswerten kann wie Lange in etwa die Fernbedienung betätigt ist. In µC habe ich aber die Information New Code die ich auf einem weiteren Port-Pin nach Außen führen könnte was bei der SPS allerdings auch einen Weiteren Eingang benötigen würde. Ich denke aber nicht das jemand eine TV Fernbedienung nehmen würde da diese ja auch die Fernseher mit beeinflussen würde.

Test mit der SAT-Fernbedienung (Grundig):
Das Verhalten ist unerwartet. Die sendet mit einer Taste abwechselnd verschiedene Adressen und Befehle.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke für die Links Oberchefe,

die Polloin FB hatte ich auch schon gefunden - leider nur 8 Kanäle.
Die Elektorschaltung ist nicht schlecht, nur wollte ich nicht den Artikel kaufen und anschließend für einen fertig Programmierten Prozessor bezahlen.
Factorydirekt ist mir neu - eigentlich genau das was ich gesucht hatte (davon abgesehen, das ich das min 25 IR Decoder hätte bestellen müssen).

Die angestrebte Lösung bietet den Vorteil, das hinterher jede FB die RC5 sendet komplett mit allen Tasten nutzbar ist.
Nebenher gibts die Bauteile gibts an jeder Ecke.
 
Zuletzt bearbeitet:
@ automationLab

sicherlich sendet die Grundig FB keinen RC5 code und daher kann das Programm nicht wirklich sinnvoll umwandeln.
 
Ich denke das die Grundig FB schon RC5 sendet da ich ja Adresse und Befehl auslesen kann. Es ist aber so das speziell bei dieser FB z.B. beim Betätigen einer Taste "1" Der Befehl 7 empfangen wird und die Adresse zwischen 1 und 9 hin und her Toogeld. Beim Loslassen der Taste wird zum Abschluss unter der Adresse 4 der Befehl 31 gesendet.
Ich denke das man dies auf der µC Seite einfach wegfiltern sollte. Um es auf der SPS-Seite verarbeiten zu können ist das Toggelnde Signal eh zu schnell. Wenn man eine solche FB zur Steuerung verwenden wollte würde das eh ein spezielles Programm erfordern. Für eine Standard RC5 FB würde es nur wenige ms Unterschied bedeuten wenn man erst das Zweite Signal auswerte.

Oder wie siehst Du das?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es wird wohl nicht möglich sein, einen Decoder für alle möglichen FBs zu programmieren.
Soweit ich mich eingelesen habe, halten sich selbst innerhalb von RC5 nicht alle Hersteller an die Vorgaben.
Ausreichend sollte sein, wenn eine Universalfernbedienung so programmiert werden kann, das alle Tasten sicher erkannt werden.
Dies sollte dann auch mit Handy oder PDA Fernbedienungsprogrammen möglich sein.

Je nach Anwendungsfall könnte man sich die Adresse an der SPS sparen, um weniger Eingänge zu benötigen - von einer FB können dann immernoch alle Tasten erkannt werden.
Sehr wichtig finde ich, die Tastendruckdauer auswerten zu können um z.B. eine Lampe zu Dimmen.
 
So, hab mir mal ein paar Schaltzeichen aus dem Netz für den Schaltplan kopiert.
Jetzt kommen da so ein paar Fragen auf:

Wird ein Quarz benötigt?
Welche Ausgangspins werden welches Bit schalten?
Hab mal in den Reichelt Katalog geschaut - 8 oder 16 MHz?
 
Mal aus dem holen Bauch raus würde ich so sagen:

Code:
PIN  Funktion
 1    Reset    
 2    RXD    Option
 3    TXD    Option
 4    IR     OUT vom TSOP1736
 5        
 6        
 7    5V    
 8    GND    
 9    Quarz (16MHz)    
10    Quarz (16MHz)    
11        
12        
13        
14    SPS 1    Taste Aktiv
15    SPS 2    Adresse 2^0
16    SPS 3    Adresse 2^1
17    SPS 4    Adresse 2^2 (MOSI)
18    SPS 5    Adresse 2^3 (MISO)
19    SPS 6    Adresse 2^4 (SCK)
20    5V    
21        
22    GND    
23    SPS 7    Befehl 2^0
24    SPS 8    Befehl 2^1
25    SPS 9    Befehl 2^2
26    SPS 10   Befehl 2^3
27    SPS 11   Befehl 2^4
28    SPS 12   Befehl 2^5
Auf den Adress Leitungen, würde noch der ISP landen. Also MOSI, MISO und SCK.
 
Ich habe gestern mal eine RC5-Auswertung auf meiner kleinen "IR-Strickplatiene" implementiert.

Ich habe mich nicht an die Belegung gehalten die ich in meinem letzten Post vorgeschlagen habe. Da es sich aber nur um die Bitzuordnung geht ändert sich deswegen recht nichts an der Hardware.

Hier die aktuelle Belegung:
Code:
PIN  Funktion
 1    Reset    
 2    RXD    Option
 3    TXD    Option
 4    IR     OUT vom TSOP1736
 5        
 6        
 7    5V    
 8    GND    
 9    Quarz (16MHz)    
10    Quarz (16MHz)    
11        
12        
13        
14    SPS 1    Befehl 2^0
15    SPS 2    Befehl 2^1
16    SPS 3    Befehl 2^2
17    SPS 4    Befehl 2^3 (MOSI)
18    SPS 5    Befehl 2^4 (MISO)
19    SPS 6    Befehl 2^5 (SCK)
20    5V    
21        
22    GND    
23    SPS 7    Adresse 2^0
24    SPS 8    Adresse 2^1
25    SPS 9    Adresse 2^2
26    SPS 10   Adresse 2^3
27    SPS 11   Adresse 2^4
28    SPS 12   Taste Aktiv
Bei meiner Platine habe ich die Ausgänge Low=aktiv verwendet.
Code:
      PortPin  ___   LED  +5V
            o-|___|--|<---o
               1k
Das würde in deiner Hardware eine Änderung an den Optokopplern nach sich ziehen.
Code:
      +5Vo
         |
        .-.
        | |
        | |
        '-'
         |     |
         |   |/
         V ->|
         -   |>
         |     |
         o
   PortPin
Die Ursprüngliche Aufgabe ist Software seitig realisiert. Im nächsten Schritt würde ich die RS232 Schnittstelle angehen und den Empfänger quasi lernbar machen. Damit man mit weniger als 12 I/Os an der SPS klar kommt. In dem man den Empfänger so konfiguriert das er nur die "gültigen" Codes an die SPS weiter gibt. Dann kann man entscheiden wie viele Eingänge man an der SPS verwenden will ich denke das 5 Eingänge also 31 (0 -> kein Befehl) verschiedene Befehle reichen.

Dazu müsste dann aber an die Hardware noch ein max232 + Kondensatoren gelötet werden. Was aber bei einer Lochrasterplatine nicht sonderlich schlimm wäre.

Übrigens war es bei mir nicht leicht RC5-FBs zu finden ich habe ca. einen Schuhkarton voll mit FBs und nur zwei davon senden in RC5. Aber es gibt ja kostengünstige universal FBs.

Ich habe mal ein Bild von der Platine gemacht (siehe Anhang). Zur Erklärung rote LEDs -> Befehl, grüne LEDs -> Adresse, gelbe LED -> Taste aktiv.
Die derzeitige Software ist als Hex-File im Anhang (txt zu hex umbennen).
 

Anhänge

  • IR2PLC.jpg
    IR2PLC.jpg
    536,6 KB · Aufrufe: 65
  • IR2PLC.txt
    1,6 KB · Aufrufe: 16
So, Ausgänge Low=aktiv habe ich umgesetzt - wenn ich Deine Zeichnung richtig verstanden habe.

Damit man mit weniger als 12 I/Os an der SPS klar kommt
Was hältst Du davon, die Daten Seriell über 2Bit zu übertragen (Takt/Daten) oder ein Nibble oder ein Byte?
Wäre alles besser als volle 12 I/O
Taktrate dann via 232 einstellbar.

Bin immernoch angetan von Deinem InfoTextDisplay, evtl. lässt sich das Ganze ja doch noch so zusammenstreichen, das beides zusammen realisierbar ist?

Edit:
Übrigens, Danke für Deine Mühen
 

Anhänge

  • 28_09_07#2.JPG
    28_09_07#2.JPG
    144,2 KB · Aufrufe: 45
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Was hältst Du davon, die Daten Seriell über 2Bit zu übertragen (Takt/Daten) oder ein Nibble oder ein Byte?
Davon halte ich nichts, da es zu langsam wird. Man müsste dann ja jedes Bit ungefähr die doppelte Zykluszeit der SPS anstehen lassen. Gerade bei SPSen mit einer geringe Performance und eine Variable Zykluszeit (also eine kleine von Siemens) wird das zu Problemen führen.
Aber noch wichtiger wäre an der Ecke das man ca. 14 Bit Übertragen müsste was wohl bei 28 SPS Zyklen landen würde. Dann noch ein "Taste aktiv" Auswertung zu machen kann bei langsamen SPSen unbrauchbar werden.

Bin immernoch angetan von Deinem InfoTextDisplay, evtl. lässt sich das Ganze ja doch noch so zusammenstreichen, das beides zusammen realisierbar ist?
Das höre ich doch gerne. Da gäbe es zwei Richtungen die man einschlagen könnte.

1. Anstelle eines ATmega8 einen ATmega32 verwenden. Der hat mehr I/Os.

2. Es gibt da einen Trick wie man die Datenleitungen vom LCD als Digital in benutzen kann. Somit hätten wir wieder 4 Pin mehr frei. Beim InfoTextLCD sind zurzeit 4 Pins frei und 4 kämen dazu einen brauchen wir für den IR-Empfänger. Wenn man jetzt via Hyperterminal eine Parametrierung vornehmen würde und 63 Wertepaare (Adresse + Befehl) könnte man über 6 I/Os einen Befehl an die SPS weitergeben solange der ansteht ist die Taste an der Fernbedienung gedrückt ansonsten wird Null ausgegeben.

Die Bauteile kosten ja nicht die Welt. Man kann es auch bei zwei separate Projekte beibehalten. Gerade bei dem IR2PLC könnte ich mir vorstellen das man default einfach die 12 Bits raus gibt und wer will kann mit dem Terminal den Empfänger auf eine RC5-Fernbedienung einlernen.

PS: Nichts zu Danken es ist ein Hobby.
 
Hallo edison,
Port Expander sind ja ganz nett. Aber es kommt weder preislich noch platzmäßig an einem ATmega32 heran. Zumal wenn man nur einen nimmt braucht "gewinnt" man ja gerade mal 6 I/O-Pins (8 - 2 (für den I²C)) und der ATmega32 hat gegenüber einem ATmega8, bei der Konfiguration wie wir es anstreben mit Quarz und ISP, ganze 12 I/O-Pins mehr. Dann noch mehr Programmspeicher usw. Also wenn bei dem ATmega32 die Pins nicht reichen würde ich zu den Port Expander greifen. Bei einem ATmega8 würde das IMHO nicht viel bringen. Nur zur Info man kann von dem Typ 8 Stück an einen I²C Bus hängen aber preislich ist es wohl erst interessant wenn der ATmega32 nicht mehr reicht.

Bleibt aber immer noch die Frage ob man eine größere oder lieber mehrere kleiner Applikationen baut.
 
Zurück
Oben