OSCAT Forum
oscat.lib => oscat.lib fuer TwinCAT/CoDeSys => Thema gestartet von: b.b. am 21. Oktober 2009, 10:40:38
-
Hallo!
Erst mal ein grosses Danke für die lib bzw. die Seite!!! Ich bin gerade dabei, die Haustechnik für unseren Neubau zu planen und stehe vor einem Problem für mein Proof-of-Concept.
Ich gerade dabei, intelligente UP-Dosen mit einem kleinen ATMega für Temp, Helligkeit, LED's usw. zu bauen, die dann mit der Wago kommunizieren können. Für die Übertragung scheiden Funk und Ethernet aus da zu teuer, ebenso eib/knx oder ähnlich.
Nun habe ich folgende Idee, da die Geschwindigkeit keine grosse Rolle spielt:
Ich möchte über einen digitalen Ausgang bzw. in die andere Richtung über einen digitalen Eingang serielle Daten übertragen. Dazu möchte ich das Signal Manchester codieren.
siehe hier --> http://de.wikipedia.org/wiki/Manchester_Code
Das codieren auf der Wago sollte ja kein Problem sein, da es eine einfache XOR Bedingung ist.
Schwieriger gestaltet sich da das decodieren. Dafür brauche ich, soweit ich das richtig verstanden habe, eine D-PLL um das Nutzsignal wieder vom Clock zu trennen.
Gibt es hier jemanden, der mir da helfen kann, bzw. einen Tip ob das funktioniert und wie?
Wie gesagt, Geschwindigkeit ist kein Thema, wenns 10 Bit/s sind dann passt das auch.....
Vielen Dank!
Martin
-
Kann mir da keiner helfen?
Wäre doch super, wenn man mit einem simplen digitalen Ausgang Daten übertragen kann...
Größtes Problem (für mich) ist die DPLL: Sehr schön beschrieben ists auf: http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/dpll.html für die DPLL.
Ist das überhaupt machbar auf einer SPS? (750-841 von Wago)
Danke!
-
Hallo Martin,
hast Du dir schon mal das DCF77 Signal angeschaut. Meiner Meinung nach ist das doch so ähnlich kodiert.
Schau dir mal den Baustein DCF77 an da ist schon mal die dekodierung dazu drin.
Gruss Daniel
-
den dcf77 hab ich selbst programmiert, und ja der ist sehr ähnlich, aber bitte bedenke das auf einer sps per softwaredekosdierung eines signals wie manchester codeierung mit 10ms zykluszeit in praktisch nicht mehr als 100 ms taktzeit und damit nur eine Datenrate von 10 Bits / sekunde möglich wären
bei extremen ausreizen sind es vielleicht 50 bits / sekunde.
denke das das auch für die langsamste Anwendung zu langsam sein sollte
-
Hallo Hugo, Daniel,
wenn ich 10Bytes in ein paar Sekunden übertragen kann, ist das völlig ausreichend!! (Temp, Helligkeit, Konfig Daten, KEINE Echtzeitkritischen Daten...)
Und es funktioniert mit Standard /EA's --> billig!
Aber den Zusammenhang zwischen DCF77 und Manchester kann ich nicht herstellen.
Bei der Manchester Codierung wird auf der Sender Seite das codierte Signal mittels Takt mit dem Nutzsignal via XOR erzeugt.
Auf der Empfängerseite brauche ich nun eine D-PLL (Phase Locked Loop) um aus dem codierten Signal den Takt herauszubekommen. Dann kann ich wiederum mittels XOR auf die Nutzdaten schliessen.
Auf der Seite 3 des Dokumentes aus meinem 2ten Post ist das beschrieben.
Die Haupt-CHallenge ist es, sich auf den Takt aufzusynchen. Dafür scheint die Präambel gut zu funktionieren.
Hat da wer eine Idee für mich wie das auf der SPS gehen kann?? Samplen via Interrupt?
Oder hat wer ne bessere Idee Daten über 2 Adern in 2 Richtungen übertragen....
Danke!!
-
nicht 10 bytes,
10 bist, für ein byte ebenötigst du mindestes 10 - 12 bist den du musst start / stop erkennen und eventuell noch einen parity.
das entspricht also eher 1 byte / sekunde.
ein schalter hätte dann bis zu 2 sekunden verzögerung und das denke ich wäre viel zu langsam
für taster benötigst du etwa 100ms reaktionszeit was aber nur mit zykluszeiten deutlich unter 1 ms zu realisieren wäre
-
Ich verwende das NICHT für echtzeitkritische Dinge wie Schalter!!
Die Performance wäre, wie gesagt, für mich ausreichend.
-
dann solltest du dir wirklich mal den dcf77 ansehen,
daraus solltest du dir eine dekoder für deine anwendung realisieren können.
du musst aber basierend auf dem manchester code noch einen datencode festlegen:
- start stop erkennung von zeichen.
- parity sicherung oder gar crc
erst dann kannst du sinnvoll arbeiten
-
Hi
Oder hat wer ne bessere Idee Daten über 2 Adern in 2 Richtungen übertragen....
http://de.wikipedia.org/wiki/1-wire
-
1-wire interface ist nur mit zusatzhardware an SPS anschliessbar,
die timing bedingungen sind bei 1 wire recht anspruchsvoll und können mit zykluszeiten > 100us bei SPS nicht erfüllt werden.
-
exakt, an meiner Idee gefällt mir, dass sie ohne zusätzl. HW auskommt
Werde ich mal etwas weiter behirnen...
-
Hi
1-wire interface ist nur mit zusatzhardware an SPS anschliessbar,
die timing bedingungen sind bei 1 wire recht anspruchsvoll und können mit zykluszeiten > 100us bei SPS nicht erfüllt werden.
Stimmt.
Serielle Klemme und das hier http://www.fuchs-shop.com/de/shop/17/1/13372015/
Somit KEINE Timing-Probleme.
Am 1-Wire werden nur 1-Wire-Bausteine die die Funktion von Analog-Input, Analog-Output, Temperaturmessung, Uhr, Digital-Input´bis 4 Kanal, Digital-Output angeschlossen.
(Also KEIN Atmel, AVR . . . notwendig)
Nur mal so als Info. ;D
-
Hmmmmm......
Das 1-wire Interface ist bei mir bis jetzt eigentlich wegen der hohen Kosten ausgeschieden.....
Und weil da ja einige Bauteile abgekündigt sind. (DS2408???)
Hat von euch jemand Erfahrung damit?? Kabellänge? Wieviele Teilnehmer am Bus? Reaktionszeit?
Die Preise bei Fuchs würden ja so schlecht nicht ausschauen....
Muss ich mich da doch noch mal einlesen.
-
Noch eine Idee,
bei http://www.horter.de/ (http://www.horter.de/) gibt es ein I2C-Modem und auch entsprechende Sensoren dazu, damit könntest Du über die Serielle-Schnittstelle der CPU I2C-ICS bzw. Sensoren abfragen. Funktioniert auch Problemlos über mehrere Meter mit entsprechenden Abschlusswiderständen. Wobei sich das 1-Wire auch ganz gut anhört.
Gruss Daniel
-
Hi
Das 1-wire Interface ist bei mir bis jetzt eigentlich wegen der hohen Kosten ausgeschieden.....
20 Euro Adapter, 50 Euro V24 von EBAY
Und weil da ja einige Bauteile abgekündigt sind. (DS2408???)
Nocht nichts davon gehört. Ist nach meiner Meinung im Aufwind.
Hat von euch jemand Erfahrung damit?? Kabellänge? Wieviele Teilnehmer am Bus?
300m Bis 500 Teilnehmern laut: http://de.wikipedia.org/wiki/1-Wire
Muss ich mich da doch noch mal einlesen.
Hältst du uns auf dem laufenden ?
-
Hi
Schau doch mal hier hin:
http://www.ip-symcon.de/forum/f24/
-
Hallo
Vielleicht ist das was für dich.
http://www.freebus.org/ (http://www.freebus.org/)
Ist KNX(EIB) aber alles im selbstbau und von Wago gibt es auch eine KNX Schnittstelle.
Gruß NetFritz
-
Hallo Leute!
Vielen Dank für die vielen Tips und Antworten!
Und so viele neue Fragen!!! :)
Also alles schön der Reihe nach:
@Daniel: I2C hab ich mir auch schon überleget und wäre eine gute Alternative, leider sind die Ausgangsmodule bei Wago keine open collector, somit lässt sich eine I2C Schaltung nicht realisieren. Und wieder eine serielle Schnittstelle ist mir eine zuviel, die RS232 Module sind ja auch nicht ganz billig....
@gravieren: Mit hohen Kosten habe ich eher die Teilnehmer gemeint. Ein 8IO Chip kostet so ca. 8 Euro... Da kann ich mir viele kleine ATMegas kaufen. Und der 8IO (DS2408) ist abgekündigt. Muss bei Fuchs mal nachfragen was die so sagen.
ip-symcon hab ich mir auch schon angesehen. Verwendet das jemand hier? Hab dort mal freundlich ein paar Dinge angefragt, aber eine sehr kühle Mail zurückbekommen. Ist halt wieder ein PC mehr...und vor allem hat er Windows drauf...werd ich mir für die Komfortebene noch etwas genauer anschauen.
@NetFritz: Danke für den Link! Vielleicht hab ich jetzt endlich einen Fingerprint Sensor gefunden.... (Sebury F1) Ansonsten hab ich mich (reine Geschmackssache) von Buslösungen verabschiedet. Ich werde alle Kabel und Leitungen in insg. 3 Verteiler ziehen und dort jeweils eine 750-841 einbauen. Ist dann zwar zwischen den Steuerungen auch ein Bus (Ethernet) aber von dort gehts dann sternförmig und ich hab dann (subjektiv) alles besser unter Kontrolle.
Werde mal meine Lösungsidee posten...
-
Hier eine schnelle Skizze, wie das ganze funktionieren soll:
Die Taster sind konventionell an Digital Input (DI) angeschlossen.
Sämtliche andere Sensoren und Aktoren werden via das serielle Protokoll bedient.
Über das serielle Protokoll wird:
- die Temperatur, Helligkeit, Feuchte übertragen
- LEDs angezündet bei Events (Türglocke, Alarm, sonstiger Event,...)
- Die LED's konfiguriert
- Sensorik konfiguriert
Damit habe ich die Taster ohne Verzögerung in quasiEchtzeit in der SPS und kann damit alles mögliche anstellen.
Und alles andere (und die Dinge, die mir noch einfallen :), kann ich über mein serielles Protokoll bedienen.
Und zum Thema Geschwindigkeit:
Über 2 verschiedene Telegrammtypen (Konfig & Steuern) übertrage ich einmal 2 Bytes (Steuern) und einmal 10 Bytes (Konfig)
Plus 2 Bytes Präambel zum Synchronisieren ergibt 4 bzw. 12 Bytes.
Wenn ich alle 40ms ein Bit übertrage, dann brauche ich für die 4 Bytes ca. 1,3 Sekunden und für die 12 Bytes ca. 4 Sekunden. (Mit vielleicht noch ein paar Paritätsbits)
Wie schnell das dann wirklich geht muss ich probieren. Senden kann ich ja schneller, da der Atmel ja viel schneller samplen kann als die SPS. Und empfangen geht via Interrupt, und da reicht die Geschwindigkeit für diese Art von Daten voll aus (Temp, Helligkeit, ...)
Hab auch schon eine Idee für das Protokoll...
[gelöscht durch Administrator]
-
Hallo b.b.
Ich habe etwas "Gegoogled".
Leider scheint I2C für dein "Vorhaben" nicht geeignet zu sein.
Schau dir doch mal das Thema Feldbusse an.
http://de.wikipedia.org/wiki/Feldbus
Ich würde an deiner Stelle mal den ModBus ASCI/RTU anschauen.
Von der "Physik" her eine RS232/V24.