# OSCAT-Hilfe



## CBRA (3 Oktober 2007)

Hallo zusammen,

zwar hab ich das Forum schon durchsucht und auch schon Hilfe won einem von euch zu einem Teilproblem erhalten. Jetzt hab ich doch noch ein Problem mit diesen CRC_GEN und CRC_Check Bausteinen aus OSCAT.
Der Generierungsbaustein funktioniert, aber es kommen nicht die Werte die ich denke zu bekommen. Auch ist es mir nicht möglich berechnete Hi- und Lo-Bytes anschließend zum I-DB zu schicken.

Kann sich jemand mal das DING anschauen und ggf. auch darin rumwusseln.

Wäre euch sehr dankbar dafür.
Übrigens ist die OSCAT_LIB sehr zu empfehlen, hab schon viele Teile angewendet. Die haben auch geklappt.

Ich hab als Anlage mal das Projekt (S7-Format) angehangen.


----------



## gravieren (3 Oktober 2007)

Hi

Also nur mal so kurz, was mir auf die schnelle aufgefallen ist:

DW#16#98309 ist NICHT das Polynom für CRC-16-IBM

Willst du die Eingabe in Hex machen --> 8005


----------



## gravieren (3 Oktober 2007)

Achso noch was.



> verschiebe MB8 nach DB1.Dbx6.0
> Klappt nicht. Warum?


 
Probiere doch mal:
MB8 --> db1.dbb6


----------



## CBRA (3 Oktober 2007)

*Danke*

Hallo Karl,

schön das du Zeit hast, dir das DING mal anzuschauen.

Das mit DW#16#00018005 hab ich eingegeben. Leider wurde zwar was berechnet, aber nicht das was ich erwartet hab. Raus kommt DW#16#00340004, schade. Was kann da falsch sein?

Ich hab da ein kleines Programm, mit dem ich das ganze austesten kann. Liegt in der Anlage. Das verwende ich auf Arbeit.

Beispiel:
Mein zu berechnendes Telegramm besteht aus drei Bytes (0Dh 00h 01h), dann erwarte ich ein hi-Byte mit C3h und ein Lo-Byte mit 21h. Somit lautet das zu sendende Telegramm 0Dh 00h 01h C3h 21h.


----------



## dalbi (3 Oktober 2007)

hallo leute,

ihr habt recht der baustein crc_gen generiert falsche werte, bin auch gerade am testen. in dieser woche noch wird es die oscat lib 21 für die s7 geben in dieser wird dann der korrekt funktionierende baustein vorhanden sein.

mfg
daniel


----------



## gravieren (3 Oktober 2007)

Hi D. Albinus



Schau doch mal in den OSCAT-Entwicklerbereich rein.
Thema: "CRC unter Step 7"


Danke für die Info.


----------



## gravieren (7 Oktober 2007)

Hi CBRA

Es muss zusätzlich eine Initialisierungsvariable mit in deinem Code 
(Hex FFFF) programiert werden.

Anbei ein Hardcopy eines Links mit dessen Vorbesetzungen.


----------



## gravieren (7 Oktober 2007)

Hi

Gerade ist mein Kumpel da.

Er sagt, das Protokoll ist das für den MODBUS.

16 bit, Polynom 8005, Initwert FFFF, Check 4B37


----------



## CBRA (8 Oktober 2007)

Hallo gravieren,

danke erstmal für die Information.

Leider ist mir unbekannt wo ich diesen Initialisierungswert eintragen muss.

Hast du eine Idee???


----------



## gravieren (8 Oktober 2007)

Hi



> Leider ist mir unbekannt wo ich diesen Initialisierungswert eintragen muss.


Mir auch   

Momentan gibt es KEINE Möglichkeit dafür.
(Modbus benötigt das jedoch)

Ich werde mich mal darum kümmern, jedoch ist das KEINE verbindliche Zusage.

Ich werde mich bis Mittwoch bei dir rühren.


----------



## Oberchefe (8 Oktober 2007)

Also mein CRC für Modbus (auf Codesys) sieht so aus:


```
FUNCTION CRC16a : WORD        (* Bildet die CRC16-Summe von einem Byte-Array      *)
VAR_INPUT
 ptabInput: POINTER TO ARRAY[0..20] OF BYTE;  (* Zeiger auf das Array, von dem die Checksumme gebildet werden soll *)
 byteLen: BYTE;          (* Anzahl der Bytes, von denen die Checksumme gebildet werden soll *)
 bSwap: BOOL;          (* Wenn wahr dann werden die Bytes im Ergebnis vertauscht    *)
END_VAR
VAR
 XorConstant: WORD := 16#A001;
 n: INT;
 o: INT;
END_VAR
```
 


```
CRC16a:=16#FFFF;
FOR n:= 0 TO byteLen-1 DO
CRC16a:=CRC16a XOR ptabInput^[n];
 FOR o:= 1 TO 8 DO
  IF CRC16a.0 THEN
  CRC16a:=XorConstant XOR (SHR(CRC16a,1));
  CRC16a.15:= XorConstant.15;
  ELSE
  CRC16a:=SHR(CRC16a,1);
  END_IF
 END_FOR
END_FOR
IF bSwap THEN
CRC16a:=SHR(CRC16a,8) OR SHL(CRC16a,8);
END_IF
```
 
Das bSwap kann ggf.auch entfallen, kommt drauf an wie die Bytes vom Ergebnis im weiteren Programm verwendet werden.


----------



## CBRA (11 Oktober 2007)

Hallo Obercheffe,

danke für deine Informationen zum Thema.

Jetzt habe ich einen Ansatz, um mein Problem lösen zu können. Jedoch besteht nun noch ein weiteres Problemchen für mich. Ich arbeite nicht mit Codesys und bin auch nicht mit der Hochsprachenprogrammierung vertraut. Derzeit arbeite ich mit WINPLC7 bzw. Step7 und das in FUP bzw. KOP. Bei AWL komme ich langsam rein. Nun werde ich versuchen dein Skript in FUP umzusetzen und es testen.

Die Eingangsparameter und die Temp-Parameter lassen sich sicherlich leicht in den Deklarationsbereich einsetzen. Beim Umsetzen des Ablauf in deiner unteren Tabelle sehe ich da Schwierigkeiten auf mich zukommen. 

Frage an dich, hast du das Skript auch in FUP bzw. KOP?

Bin auch jetzt erstmal eine weile (bis nächsten Mittwoch) nicht online, da rüber nach Berlin arbeiten.

Danke nochmals für deine Mühen und deine Hilfestellung.


----------



## Oberchefe (12 Oktober 2007)

also das macht Codesys bei Umwandlung in AWL draus:


```
LD  65535
ST  CRC16a
LD  0
ST  n
for1_0:
LD  n
GT(  byteLen
SUB  1
)
JMPC  endfor1_0
LD  CRC16a
XOR  [n]
ST  CRC16a
LD  1
ST  o
for2_0:
LD  o
GT  8
JMPC  endfor2_0
LD  CRC16a.0
NOT
JMPC  else3_0
LD  XorConstant
XOR(  CRC16a
SHR  1
)
ST  CRC16a
LD  XorConstant.15
ST  CRC16a.15
JMP  end3_0
else3_0:
LD  CRC16a
SHR  1
ST  CRC16a
end3_0:
LD  o
ADD  1
ST  o
JMP  for2_0
endfor2_0:
LD  n
ADD  1
ST  n
JMP  for1_0
endfor1_0:
LDN  bSwap
JMPC  else4_0
LD  CRC16a
SHR  8
OR(  CRC16a
SHL  8
)
ST  CRC16a
else4_0:
end4_0:
```
 
ist mit Sicherheit nicht schön, FUP dürfte noch schlimmer sein.


----------



## gravieren (13 Oktober 2007)

Hi




> Frage an dich, hast du das Skript auch in FUP bzw. KOP?


Ich würde das unter SCL machen.


----------



## dalbi (14 Oktober 2007)

Hallo CBRA,

wir haben die Bausteine CRC_CHECK u. CRC_GEN noch etwas angepasst.
Anbei ein kleines Beispiel Projekt zum testen.

Der Baustein liefert jetzt die selben Ergebnisse wie der CRC Generator unter
folgender URL: http://www.zorc.breitbandkatze.de/crc.html


MfG
Daniel


----------



## andi-g (20 Oktober 2007)

*OSCAT Ltime Systemfehler*

Hallo ! ich habe Schwierigkeiten beim implementieren
von OSCAT Bausteinen in mein S7 Programm. 

Folgende Module wollte ich implementieren:
Ltime, Holiday,Sun_time

Habe die Bausteine in einem FC1 zusammengefasst
& auch die entsprechenden Instanz DB's erstellt.
Auch die entsprechenden Eingangssignale sind projektiert:
DATE_AND_TIME/TOD/DATE etc... soweit kein problem.

Nach dem Download in die CPU geht die Steuerung in SF.
Egal welches der OSCAT Module ich aktiviere.

Ich habe SCL nicht installiert. Kann das der Grund sein ?

Vielen Dank ! Andreas.


----------



## dalbi (20 Oktober 2007)

Hallo Andreas,

die Funktionen nutzen intern noch folgende Bausteine:

Ltime
oscat/Time&Date/DST
oscat/Time&Date/weekday
S7/Standard Library/IEC Function Blocks/DT_DATE
S7/Standard Library/IEC Function Blocks/DT_TOD

holiday
oscat/Time&Date/year
oscat/Time&Date/month
oscat/Time&Date/set_Date
oscat/Time&Date/date_add
oscat/Time&Date/weekday
oscat/Time&Date/day_of_month
S7/Standard Library/IEC Function Blocks/D_TOD_DT
S7/Standard Library/IEC Function Blocks/DT_DATE

sun_time
oscat/Time&Date/hour_to_tod
oscat/Time&Date/day_of_year
S7/Standard Library/IEC Function Blocks/D_TOD_DT
S7/Standard Library/IEC Function Blocks/DT_DATE

das steht jeweils auch im Bausteinkommentar
-> Rechts klick auf Baustein/Objekteigenschaften
     hier dann der Reiter "Allgemein - Teil 1" Kommentar

MfG
Daniel


----------



## andi-g (20 Oktober 2007)

*hmmmm...*

Hi Daniel,
Herzlichen Dank für das schnelle Feedback.

ich muss wohl irgendetwas grundsätzliches falsch machen.

ich habe mich mal auf Ltime konzentriert & alle erforderlichen
Bausteine in den OB1 geschoben. d.h.:
READ_CLK funktioniert
DT_TOD funktioniert
DT_DATE funktioniert
DST, Weekday, Ltime: sobald irgendeiner dieser Bausteine enabeld
wird kommt ein SF & die CPU geht in stop. CPU315 Vers. 1AF02 OABO

D.h. alle Bausteine lassen sich in die SPS dowloaden, aber sobald
ein Zugriff auf einen der OSCAT Bausteine über das Programm erfolgt, 
geht die CPU in Störung.

Noch mal Herzlichen Dank ! Andreas.


----------



## dalbi (20 Oktober 2007)

Hallo,

mail mir einfach mal Dein Programm.

MfG
Daniel


----------



## andi-g (20 Oktober 2007)

*;-)*

Gerne !

S7-programm(1) zeigt den Test mit Ltime
S7-programm(2) ist das eigentliche Anwenderprogramm,
wie es nachher eingesetzt werden soll.

Herzlichen Dank im Vorraus !!! Andreas.


----------



## dalbi (20 Oktober 2007)

Hallo Andreas,

habe noch mal nachgeschaut durch die interne Funktion DST
werden allerdings noch mehr Funktionen benötigt.
Hier die komplette Liste:

oscat/Time&Date/DST
oscat/Time&Date/weekday
oscat/Time&Date/year
oscat/Time&Date/day_of_month
oscat/Time&Date/day_of_year
oscat/Time&Date/leap_of_Date
oscat/Time&Date/leap_year
oscat/Time&Date/set_Date
S7/Standard Library/IEC Function Blocks/DT_DATE
S7/Standard Library/IEC Function Blocks/DT_TOD
S7/Standard Library/IEC Function Blocks/AD_DT_TM
S7/Standard Library/IEC Function Blocks/D_TOD_DT

diese Bausteine müssen alle mit in das Projekt kopiert werden.

MfG
Daniel


----------



## dalbi (20 Oktober 2007)

Hallo Andreas,

habe mir das Programm mal angesehen.
Anbei die Datei. (habe die fehlenden Bausteine eingefügt und FC1 in FC9 umbenannt).

MfG
Daniel


----------



## andi-g (20 Oktober 2007)

Besten Dank !
leider habe ich die Geschichte noch immer nicht am Start...

FB101
FC102
FC106
FC112
FC129

lassen sich nicht in die CPU downloaden. Der Kopiervorgang wird mit folgender Meldung abgebrochen:

Laden (33:53888)

(D280) Fehler bei der Übersetzung eines Bausteins in
S7-300 CPU.

Ich habe keine Ahnung ! Ist meine CPU315 doch schon ein
wenig zu alt ?

Grüße ! Andreas.


----------



## andi-g (20 Oktober 2007)

Könnte es hiermit zusammenhängen ?

http://support.automation.siemens.com/WW/view/de/15206209


LG. Andreas.


----------



## dalbi (20 Oktober 2007)

Hallo,

schau mal bitte "online" in Baugruppenzustand
hier der Reiter Leistungsdaten.
"Drucken" und als PDF posten.

Ich finde leider keine Beschreibung mehr zur CPU315 1AF02
Leistungsdaten wären interessant.

MfG
Daniel


----------



## andi-g (20 Oktober 2007)

*leistungsdaten*

gerne !

LG. Andreas.


----------



## dalbi (20 Oktober 2007)

Hallo Andreas,

aha die CPU kann maximal nur 128 FC und 128 FB daher Bausteinnummern größer 127 (0..127) können nicht geladen werden.


MfG
Daniel


----------



## andi-g (20 Oktober 2007)

*!!! Solved !!!*

Hi Daniel,
1000x Danke ! es funktioniert & ich bin was schlauer.

für alle anderen (hoffe ich habe es richtig verstanden)
1. verschiedene OSCAT Funktionen benötigen andere
    Unterfunktionen, die im Projektmanager mit eingefügt
    werden müssen.
2. alle zusammenhängenden Funktionen müssen ordnungsgemäß
    eingerichtet sein. (in meinem Bsp. konnte ein FC129 nicht geladen
    werden, da die CPU nur max. 127 FC's unterstützt)
    in der Folge können auch andere FB, oder FC's die sich auf FC129
    beziehen nicht geladen werden. Die CPU geht in SF.
    FC umbennen, dann geht's

Daniel, stimmt meine Annahme ? Danke Dir nocheinmal herzlichst
& wünsche  Dir ein schönes WOE !!! LG. Andreas.
*wo ist dein spendenkonto ?*


----------



## dalbi (20 Oktober 2007)

Hallo Andreas,

genau. In der nächsten Release v2.2 der lib werden die Bausteinnummern alle unter 127 sein. Daran hatte ich noch gar nicht gedacht, das es deswegen Probleme geben könnte. Naja halt Siemens.

MfG
Daniel


----------



## Ralle (21 Oktober 2007)

D. Albinus schrieb:


> Hallo Andreas,
> 
> genau. In der nächsten Release v2.2 der lib werden die Bausteinnummern alle unter 127 sein. Daran hatte ich noch gar nicht gedacht, das es deswegen Probleme geben könnte. Naja halt Siemens.
> 
> ...



Ein Hinweis darauf würde auch genügen, da man i.d.R. die Bausteine mit neuen Nummern versehen muß, da sie nicht in das eigene Bausteinschema passen. Die neueren CPU können ja, Gott sei Dank, mehr Bausteine adressieren.


----------



## dalbi (21 Oktober 2007)

Hallo,

das Problem dabei ist nur dann, nicht jeder hat wahrscheinlich SCL oder Step 7 Prof. Hier müsste man die Adressierung der Bausteine auf "Symbol hat Vorrang/Bei allen Zugriffen" umstellen. Da viele Bausteine intern andere Funktionen der Lib nutzen.

MfG
Daniel


----------



## Ralle (21 Oktober 2007)

D. Albinus schrieb:


> Hallo,
> 
> das Problem dabei ist nur dann, nicht jeder hat wahrscheinlich SCL oder Step 7 Prof. Hier müsste man die Adressierung der Bausteine auf "Symbol hat Vorrang/Bei allen Zugriffen" umstellen. Da viele Bausteine intern andere Funktionen der Lib nutzen.
> 
> ...



Ich hab das noch nie probiert, aber das wird doch nichts nützen oder?
Wenn man auf "Symbol hat Vorrang/Bei allen Zugriffen" umstellt, hilft das auch nur, wenn man von SCL aus übersetzt. Oder man ändert in einer "Hilfsbibliothek" die FB-Nummern in der Symbolik und fährt dann eine Konsistenzprüfung und einen Übersetzungsvorgang. Das zumindest sollte gehen, wird aber Neulinge auch eher überfordern. 

Insofern wäre es dann doch ganz gut, die Bausteine alle in den Bereich unter 127 zu legen, da können die Anwender im Notfall ihre eigenen Bausteine "umverlegen".


----------



## dalbi (21 Oktober 2007)

Hallo,

habe es mal ausprobiert, geht nicht. Also doch alle Bausteinnummern unter 127 legen.

MfG
Daniel


----------



## CBRA (24 Oktober 2007)

*OSCAT.lib 2.1 für step7*

Hallo Leute ,

erstmal Danke an alle die mir beim FB crc_gen bzw. crc_check von OSCAT geholfen haben.
Sagt mal, ist bei eurer Sortierung etwas durcheinander geraten? Die Symboltabelle in LogicOthers zeigt auf den FB101 (CRC_GEN) und auf FB102 (CRC_CHECK) leider liegt im Verzeichnis kein FB zum CRC sondern einer für Aktuators. Gefunden habe ich den CRC_GEN-FB und CRC_CHECK-FB im Verzeichnis CONVERSION. Ist das so gewollt.
Mein Vorschlag gebt doch in der OSCAT_Library_Reference einfach im Text den Speicherort mit an, dann sucht man auch nicht soviel. Na ja man findet´es ja.


----------



## gravieren (25 Oktober 2007)

Hi CBRA

Zur Richtigstellung.

Das FC / FB - Kaos kommt von Siemens.

Leider erfolgt der Zugriff mit Angabe der FC/FB-Nummern.


Unter CodeSys ist das KEIN Problem, das die Funktions-Name verwendet werden können.


----------



## Raik (16 November 2007)

*DCF77 SCL-Quelle übersetzen*

Hallo,

ich möchte gern mit einer S7 das DCF77-Signal decodieren. Ich habe mir dazu das Empfangsmodul vom Versandhaus mit dem C besorgt und einen Treiberbaustein auf 24V zusammengelötet.

Leider benötigt der Baustein FB77 von Siemens noch einige zusätzliche Eingangssignale, die ich mit meiner Schaltung nicht zur Verfügung stellen kann.

Deshalb habe ich versucht, die SCL-Quelle aus der Oscat-Bibliothek zu nutzen. Leider vergebens, da bei der Übersetzung mehrere Fehler angezeigt werden. Meine Kenntnisse in SCL reichen aber nicht aus, um diese zu beseitigen. 

Kann jemand weiterhelfen, oder hat jemand schon den SCL- Code erfolgreich mit einbinden können?

Grüße
Raik


----------



## dalbi (16 November 2007)

Hallo Raik,

genau einer von zwei Bausteinen die ich in der S7-Lib noch nicht angepasst habe, habe gedacht das braucht keiner, aber naja.

Werde mal schauen ob ich es über das Wochenende gebacken kriege.


MfG
Daniel


----------



## dalbi (16 November 2007)

Hallo Raik,

ging ja doch ganz einfach, bitte probiere mal das Projekt bzw. Baustein (DCF77) aus, da ich leider keinen DCF Empfänger zur Hand habe.

Danke!!!

MfG
Daniel


----------



## Raik (18 November 2007)

*Dcf77*

Hallo Daniel,

erst einmal danke für Deine schnelle Reaktion.

Gestern habe ich dann mal das Programm auf meine S7 geladen, den Eingang REC mit dem DCF77-Eingangspin verknüpft und die entsprecehnden Werte online beobachtet.

Nach einer halben Stunde Laufzeit hatte die S7 die ankommenden Signale an REC noch nicht decodieren können. Der Fehlerausgang Error blieb immer noch auf 1 gesetzt. Alle anderen Ausgänge waren 0. Nur Msec wurde ständig hochgezählt.

In der nächsten Woche werde ich mir dann mal noch das DCF77-Signal an dem Treiberausgang für 24V mit einem Oszi ansehen. Nicht das die Signale durch den Treiber sehr verschliffen werden.

Grüße
Raik


----------



## gravieren (18 November 2007)

HI

@aik


> In der nächsten Woche werde ich mir dann mal noch das DCF77-Signal an dem Treiberausgang für 24V mit einem Oszi ansehen.


Oszi.



> Nicht das die Signale durch den Treiber sehr verschliffen werden.


Kontrolle per Trace-Modus ( b.z.w. Aufzeichnung) in der Steuerung.


----------



## Oberchefe (20 November 2007)

> und einen Treiberbaustein auf 24V zusammengelötet.



Eingang vielleicht negiert?


----------



## hugo (20 November 2007)

die meisten empfänger haben einen low aktiven ausgnag probiers mal indem du den ausgang des empfängers invertierst und dann auf den dcff77 dekoder legst.


----------



## Raik (30 November 2007)

*Dcf77*

Hallo Daniel,

ich habe den Test Deines Programms noch nicht vergessen. Leider hat sich mittlerweile herausgestellt, daß meine Treiberstufe nicht in jedem Fall den geforderten H-Pegel der SPS-Eingangsbaugruppe erreicht. Außerdem kommt es immer noch zu Empfangsproblemen des DCF77- Signals -> Empfänger setzt für einige Zeit immer mal aus. Wenn ich weitere Ergebnisse habe, so werde ich diese berichten.

Grüße
Raik


----------



## hugo (2 Dezember 2007)

hallo raik dein dcf77 empfänger setzt von zeit zu zeit aus.
das liegt höchstwahrscheinlich daran das er zu nahe an einer sps oder netzteil ist.
die empfänger sind sehr empfindlich und werden von cpus und schaltnetzteilen gestört.
enfach den empfänger ein paar meter von allem anderen wegsetzen.


----------



## Raik (3 Dezember 2007)

*Dcf77*

Hallo Hugo,
die Probleme mit der Treiberschaltung konnte ich jetzt lösen. Ich habe noch einmal die komplette Schaltung auf einer neuen Leiterplatte zusammengelötet. Dabei habe ich darauf geachtet, daß der Spannungsregler 7805 möglichst weit vom eigentlichen Empfänger entfernt platziert ist und habe noch einmal die Kollektorwiderstände der Treiberstufe auf 1,2 kOhm verändert. Damit läuft die Schaltung jetzt stabil und habe jetzt einen H-Pegel von ca. 18V (7mA Eingangsstrom an der SPS-Karte).

@Daniel
leider konnte aber die SPS mit Deinem Programm nach jeweils einer Stunde Laufzeit das DCF77- Signal weder am invertierten noch am nicht invertierten Ausgang des Empfängers decodieren.

Ich bleibe aber auf jeden Fall dran. Wenn Ihr noch ein paar Tipps hättet....

Grüße
Raik


----------



## dalbi (3 Dezember 2007)

Hallo Raik,

wie schnell kommen die Signale (Bits) nacheinander?


MfG
Daniel


----------



## Raik (4 Dezember 2007)

*Dcf77*

Hallo Daniel,
die Pulse kommen alle im Abstand (erste Flanke) von 1s mit unterschiedlicher Länge mit einer Pause (59'te Sekunde) pro Minute.

Grüße
Raik


----------



## dalbi (5 Dezember 2007)

hallo,

habe mir bei Conrad so ein DCF Empfänger besorgt, könntest Du mir vielleicht die Schaltung Deiner Treiberstufe noch schicken.

MfG
Daniel


----------



## Raik (7 Dezember 2007)

*Dcf77*

Hallo,

hier noch die Treiberschaltung für das DCF77-Modul von Conrad. Alle Bauteilen waren noch aus meiner Bastelkiste.

Grüße
Raik


----------



## dalbi (7 Dezember 2007)

Hallo Raik,

so habe mir einen Simulator für das DCF Signal geschrieben und einige Fehler im Code gefunden. Schau mal ob es jetzt funktioniert, zumindest sollte jetzt unter RTC die richtige Zeit u. Datum rauskommen. Das Signal hierzu muss folgendermassen ausschauen, die 100ms und 200ms Signale müssen low Pegel haben.

MfG
Daniel


----------



## Raik (8 Dezember 2007)

*Dcf77*

Hallo Daniel,
leider funktioniert der Code zur Dekodierung bei mir noch nicht. Vieleicht solltest Du zu Testzwecken mal noch einen Ausgang in der Funktion für die Erkennung des Minutenübertrages (200ms- Pause) vorsehen, der sich nach einer gewissen Zeit selbst zurücksetzt.

Hat das eigentlich mit dem Nachbau der Treiberschaltung funktioniert?

Grüße
Raik


----------



## dalbi (8 Dezember 2007)

hallo, was genau geht nicht? Hast Du denn Instanz-DB schon mal online angeschaut was steht unter MEZ. Die Schaltung habe ich leider noch nicht zusammengebaut. Werde ich aber in diesem Wochenende noch machen.

MfG
Daniel


----------



## dalbi (15 Dezember 2007)

Hallo Raik,

so habe jetzt das Programm an einer S7-313C getestet. Funktioniert!
Das Ende des Minutenübertrags ist an der Statischen Variable state (Status) erkennbar diese muss zur erfolgreichen Zeitübertragung von 0-59 durchlaufen.

Anbei die von mir verwendete Schaltung da ich leider in meiner Bastelkiste nicht denn gleichen Transistortyp gefunden habe. Die Antenne sollte möglichst Richtung Frankfurt ausgerichtet werden. Dies ist sehr gut an der Variable state erkennbar.

MfG
Daniel


----------



## Raik (17 Dezember 2007)

*Dcf77*

Hallo Daniel,

auch bei mir funktioniert jetzt die Decodierung des DCF77- Signals. Das Problem waren wahrscheinlich doch noch einige Störquellen im Raum. Nach dem ich das Empfangsteil im Freien aufgestellt hatte, konnte sich die S7 ohne Probleme synchronisieren.

Nochmals vielen Dank für die Umsetzung der Decodierung in einen S7- FB. :sm2: 

Ein Problem habe ich aber doch noch. Am Ausgang RTC liegt die richtige UTC-Zeit an. Nur am Ausgang RTC1 (Lokalzeit) werden keine plausiblen Werte angezeigt. Innerhalb des DB1 werden aber beide Zeiten korrekt als statische Daten (MEZ/UTC) dargestellt.

Weiterhin habe ich noch eine Frage zum Ausgang TP. Dieser soll Pulse abgeben, um nachgeschaltete Uhren zu steuern. Ich konnte bisher nur feststellen, daß der Ausgang bei erfolgreicher Synchronisation auf 1 gesetzt wird. Ist das so ok?

MfG
Raik


----------



## dalbi (19 Dezember 2007)

Hallo Raik,



> auch bei mir funktioniert jetzt die Decodierung des DCF77- Signals. Das Problem waren wahrscheinlich doch noch einige Störquellen im Raum. Nach dem ich das Empfangsteil im Freien aufgestellt hatte, konnte sich die S7 ohne Probleme synchronisieren.


Ich habe denn DCF Empfänger an ca. 5 Meter Kabel (Geschirmt) in eine Feuchtraumdose eingebaut und in Fensternähe plaziert. Funktioniert so Super.



> Ein Problem habe ich aber doch noch. Am Ausgang RTC liegt die richtige UTC-Zeit an. Nur am Ausgang RTC1 (Lokalzeit) werden keine plausiblen Werte angezeigt. Innerhalb des DB1 werden aber beide Zeiten korrekt als statische Daten (MEZ/UTC) dargestellt.


Siehe Anhang!



> Weiterhin habe ich noch eine Frage zum Ausgang TP. Dieser soll Pulse abgeben, um nachgeschaltete Uhren zu steuern. Ich konnte bisher nur feststellen, daß der Ausgang bei erfolgreicher Synchronisation auf 1 gesetzt wird. Ist das so ok?


Ja der Impuls kommt bei jeder 60. Minute sprich Stat = 0 und error = 0.


MfG
Daniel


----------



## dalbi (19 Dezember 2007)

Hallo,

anbei der fertige Funktionsbaustein, funktioniert jetzt alles so wie es soll.
Ich hatte nur bei denn Prüfbits einen Denkfehler gehabt, und habe mich da in irgend etwas verrannt.

MfG
Daniel


----------



## frodob10 (3 Juni 2008)

Hallo,

ich versuche derzeit mit dem Siemens DCF77-Modul meine CPU 312C zu synchronisieren. Hab es schon mit dem FB77 von Siemens versucht da geht die CPU nach einer Weile in Störung. Kann ich für den Siemensempfänger auch den beschriebenen Baustein nutzen? Gibt es eine Möglichkeit um die Empfangsqualität zu testen?

Gruß

Mario


----------



## dalbi (4 Juni 2008)

Hallo Mario,

wenn dazu nur ein Eingang (Digital) verwendet wird, ja.
Die Empfangsqualität lässt sich eigentlich nur richtig mit einem Oszilloskop testen, es ist allerdings auch halbwegs gut an der LED der Baugruppe zu sehen die LED muss hierzu in der Minute 59 mal blinken.

MfG
Daniel


----------

