SFC14 im OB35 - Aktualisierungszeit ?

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe vor, mit einer C7-633-DP über eine Beckhoff-Busanschaltung BK3150 und dem RINCK-electronic Multiplexer MUX-U16 Temperaturwerte ein zu lesen. An und für sich ist das ja kein Problem. Ich setze die jeweilige Adresse und nach Ablauf einer gewissen Zeit Wandlungszeit lese ich den entsprechenden Wert ein.

1. Nun habe ich eine kleine Unklarheit mit der MUX-Frequenz. Im Datenblatt steht "max. 100 Hz, (0,5 - 10 sec.)". Was ist mit 0,5..10s gemeint? Ich sehe keinen Zusammenhang mit den 100Hz. Die Wandlungszeit meiner anvisierten Analogeingsklemmen liegt zwischen 1ms und 4ms. Je nachdem ob ich mich für eine Ein- oder Vierkanalklemme entscheide.

2. Da ich die Temperaturwerte zu Regelungszwecken verwende, möchte ich (wenn's denn geht) in jedem OB35-Aufruf den jeweils adressierten Kanal möglichst aktuell einlesen. Beim OB35-Aufruf "n" setze ich die Adresse und beim Aufruf "n+1" lese ich den entsprechenden Analogwert. Etwas unsicher bin ich mir eigentlich nur, da das ganze über Profibus abläuft. Kann ich im OB35 die SFC14/15 verwenden? Stellt mir die SFC14 die Daten sofort nach Aufruf komplett zur Verfügung oder benötigt sie dafür mehrere Zyklen? Kann ich diesen einen Analogwert auch ohne die SFC14 konsistent lesen? Ich strebe einen OB35-Zyklus von 100ms an, könnte aber auch mit etwas mehr als 100ms leben (schätzungsweise bis 200..300ms). Kann ich sicher sein dass ich nach 100ms den richtigen Kanal einlese? Oder könnte es vorkommen, dass die Ausgänge (MUX-Adressen) durch irgendwelche Verzugszeiten nicht schnell genug an der DP-Peripherie gesetzt werden und ich den Wert der vorherigen Adresse lese?

Ausprobieren kann ich noch nichts, sind erst mal nur Vorüberlegungen. Vielleicht hat ja jemand einen Tipp für mich?


Gruss, Onkel

Nachtrag zur Vervollständigung:
Der Messverstärker LC-MV-1xPT1000 wird wie in dieser Anwendung eingesetzt, jedoch nur mit einem MUX. Das muss ich bei der Wandlungszeit natürlich berücksichtigen.

21.06.2005
Links aktualisiert

 

[volker]

Etwas unsicher bin ich mir eigentlich nur, da das ganze über Profibus abläuft. Kann ich im OB35 die SFC14/15 verwenden? Stellt mir die SFC14 die Daten sofort nach Aufruf komplett zur Verfügung oder benötigt sie dafür mehrere Zyklen? Kann ich diesen einen Analogwert auch ohne die SFC14 konsistent lesen?Gruss, Onkel

ich denke schon, dass du den sfc14 im 0b35 aufrufen kannst. soweit ich das weiss arbeitet der sfc14 konsistent. alarm ob's unterbrechen den sfc14 glaub ich. aber das kannst du ja vor dem aufruf des sfc14 abschalten. weiss im mom den sfc dafür nicht.
ein problem wäre es, denke ich, wenn du den ob35 öfter aufrufen würdest als der sfc14 für seine verarbeitung braucht.

konsitent ist das bis zu einem L dbdX auf jeden fall. alles was darüber ist nicht.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Volker,

danke für deine schnelle Antwort. Demnach kann ich also im OB35 die SFC14 aufrufen und unmittelbar danach u.a. auf meinen aktuellen Analogwert zugreifen, gut . Ausser dem OB35 verwende ich keine weiteren Alarm-OBs.

Dann bleibt noch die Frage, ob 100ms vom Aktualisieren der DP-Ausgänge über die SFC15 bis zum Einlesen des DP-Analogwertes über die SFC14 ausreichen? Auch wenn man diese Frage vielleicht nicht mit ja oder nein beantworten kann, wäre mir mit eurer Meinung schon etwas geholfen. Der ein oder andere hat sicherlich etwas feeling für diese Problematik.


Gruss, Onkel

 

[Zottel]

Ich habe selbst BECKHOFF analog E/A laufen in einer Anwendung, wo ich Folgeantriebe regele. Benutze allerdings nicht den OB35, sondern lese meine Werte im OB1 ein. Die Zykluszeit ist 18 bis 19.5 Millisekunden. Ich bekomme in jedem Zyklus einen neuen Wert.

Profibus-Konfiguration:
3 BKs, einer mit 10 DE, einer mit 8AE, 4AA, 10DE, einer mit 8AA,4AE. 12MBit/s.

Ich habe so getestet: 50Hz an den Eingang gelegt, pro Zyklus den Wert zuammen mit den Milisekunden der DATE_TIME des OB Aufrufs in einen DB geschreiben, Werte aus DB in Excel übertragen, Diagramm erstellt. Jeder Wert muß ein anderer sein. Werte müssen auf einer Sinuskurve liegen. Verzögerungen machen sich durch Verschiebung schnell bemerkbar.

Wenn es zeitkritisch ist, würde ich auch darüber nachdenken, einen BC einzusetzen, und die Regelung von dem erledigen zu lassen.

 

[Onkel Dagobert]

Hallo Zottel,

auch dir besten Dank für deine sehr überzeugende Hilfe.
Die Regelungen selbst sind eigentlich nicht zeitkritisch. Ich möchte nur das Multiplexen optimal und kostengünstig ausreizen (ohne BC). Da ich meine Temperaturregler ohnehin im OB35 über einen Aufrufverteiler bearbeite, möchte ich das Multiplexen gleich mit dem Regleraufruf kanalrichtig verbinden. Also über den Aufrufverteiler den zum Regler gehörenden Istwert einlesen und anschließend die Adresse für den nächsten Kanal setzen. Ich denke, es könnte so gehen.

Die Wandlungszeit der Busklemme kann ich in den Skat drücken. Jetzt beschränkt sich mein Augenmerk nur noch auf die Wandlungszeit des RINCK-Wandlers und auf die Frequenz des MUX. Aber dazu wird mir Herr Rinck am Montag gerne Auskunft geben.


Gruss, Onkel

..und schönes Rest-WE

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Den SFC14 kannst du im OB35 verwenden. Das habe ich vor 4 Wochen für eine Sevoregelung gemacht. Allerdings hole ich da immer genau den gleichen Datenbereich vom Servo und übertrage genau denselben Datenbereich zum Servo. Wenn du die Parameter am SFC14 änderst, ist evtl. nicht gesichert, ob die Daten noch im selben OB35-Zyklus zur Verfügung stehen. In der Hilf steht:

Mit der SFC 14 "DPRD_DAT" (read consistent data of a DP-normslave) lesen Sie konsistente Daten eines DP-Normslaves/PROFINET IO-Devices aus, wobei für die Maximallänge folgendes gilt: Die Maximallänge entnehmen Sie für die S7-300-CPUs den Handbüchern Automatisierungssystem S7-300: Aufbauen, ET 200S Interfacemodul IM151-7 CPU oder Basismodul BM147CPU. Bei den S7-400-CPUs beträgt die Maximallänge 32 Bytes. Falls bei der Datenübertragung kein Fehler auftrat, werden die gelesenen Daten in den durch RECORD aufgespannten Zielbereich eingetragen.

Wenn also wirklich eine direkte Datenübertagung mit dem Slave durchgeführt wird, dauert die bei ca. 2-5ms Bus-Zykluszeit länger. als dein OB35 offen ist, die Daten liegen evtl. erst beim nächsten Mal im Record, das solte man zumindest einmal in der Praxis überprüfen.

 

[Onkel Dagobert]

Hallo Ralle,

danke. Wenn es bei dir im OB35 geklappt hat, müsste es bei mir auch funktionieren. Ich ändere nicht die Parameter der SFCs, mein Analogwert liegt immer auf der selben Adresse, überträgt jedoch nacheinander verschiedene Werte. Falls es dennoch Probleme gibt, dann setze ich im OB35 lediglich meine MUX-Adresse im DB und mache die SFC-Aufrufe wie gewohnt im OB1 (ca. 20ms). Zum Testen oder Überwachen beschalte ich dann sicherheitshalber einen ungenutzen MUX-Kanal mit einem Festwiderstand. Wenn ich dann noch die Fehlerinformation der SFCs auswerte, habe ich glaube alles getan. Ich muss halt sicherstellen können, dass meine Temperaturwerte nicht durcheinander geraten, das wäre fatal. Bis das Projekt aktuell wird, werden noch Monate vergehen.


Bis dahin, Onkel Dagobert

 

[Ralle]

Wie bekommst du mit, welcher Wert dir zurückgeliefert wird, das Beste wäre, wenn im gleichen Record mit dem Temperaturwert auch der "Muxwert" zurückgegeben wird, dann bist du aus dem Schneider. Ansonsten weißt du nicht genau, wann der neue Wert wirklich anliegt.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mahlzeit,

daran dachte ich auch schon. Ich könnte die Adressausgänge der Peripherie zurückvertrahten auf Eingänge und diese dann gemeinsam mit dem Analogwert übertragen und auf ihre Richtigkeit überprüfen. Andererseits erscheint mir das allerdings ein wenig übertrieben. Na, mal sehen wie's läuft.

Wenn ich Kanal 0 (0000) und Kanal 16 (1111) mit einem Festwiderstand beschalte und deren Werte überwache, sollten eigentlich alle Fehlerquellen hinreichend abgedeckt sein, einschliesslich die des MUX.


Gruss, Onkel

 

[Onkel Dagobert]

10.07.2005

Hallo Leute,

die Realisierung des Projekts steht bevor. Der Umfang der Anlage hat sich inzwischen verdoppelt und die Hardwareauswahl hat sich etwas geändert. Wir verwenden eine VIPA314(DP-Master), ein OP7 (ein OP17 wäre ideal) und eine Beckhoff-Busanschaltung sowie zwei Multiplexer von RINCK ELECTRONIC. Auf den o.g. PT1000-Wander (1s Wandlungszeit) habe ich verzichtet und stattdessen eine KL3202-0028 (250ms Wandlungszeit) verwendet.

Meine ursprünglichen Bedenken wegen der SFC's im OB35 haben sich erübrigt. Das Multiplexen funktioniert prinzipiell sehr gut. Die Schaltverzögerung des Multiplexers kann man in den Skat drücken. Nach Herstellerangaben liegt die Durchschaltzeit bei 25us. Die Schwachstelle bei der ganzen Geschichte ist die Filterzeit bei der PT1000-Wandlung. Diese Funktion übernimmt die KL3202-0028, ich denke, das ist eine gute Wahl. Dennoch habe ich ein Problem damit.

Kennt sich jemand mit dieser Klemme aus? Mein derzeitiges Problem liegt bei der Umparametrierung der Filterkonstante. In der Default-Einstellung (250ms :?: ) komme ich auf eine Abtastrate von 600ms. Bei 16 Kanälen hätte ich dann nur alle 9,6s einen aktuellen Messwert pro Kanal. Wenn ich per Registerkommunikation die Filterkonstante (R37) aktiviere und im Register 37 0x0000 (250ms) eintrage, komme ich bereits auf eine Abtastrate von 375ms. Wenn ich dann allerdings die Filterkonstante nach Handbuch KL320xd.pdf verändere, ändert sich zunächst erst einmal garnichts. Erst nach Spannungswiederkehr (steht nicht im Handbuch) wird die Filterkonstante aktiv. Bei einer somit eingestellten Wandlungszeit von bis zu 65ms komme ich mit meiner Abtastrate auf 125ms. Damit könnte ich sehr gut leben, wenn denn mein Messwert noch stimmen würde. Er ist immer noch sehr stabil, liegt jedoch völlig abseits der Realität. Erst ein Zurückstellen der Filterkonstante auf 0x0000 und Netzwiederkehr ermöglicht den richtigen Messwert, dann jedoch wieder bei 375ms.

Kennt jemand dieses Problem?

Laut Angaben des Beckhoff-Supports gilt das Handbuch der KL3202 ebenso für die Sonderklemme KL3202-0028.


Gruss, Onkel


"Meine Abtastrate":
Experimentell ermittelte Multiplexer-Frequenz, bei der sich die Messwerte der Kanäle noch sauber trennen lassen. Beim Probieren habe ich einen SPS-Analyzer zu schätzen gelernt. Durch das Überlagern des internen, freilaufenden Multiplexers der KL3202 und meiner zwei 16-kanaligen RINCK-Multiplexer ergeben sich interessante Effekte.

 

[Onkel Dagobert]

Hallo, falls es jemanden interessiert,

Beckhoff bastelt (hoffentlich) gerade an der der Firmware der Klemme. Die KL3203-0028 ist eine Sonderklemme, RTD im Klimabereich [0,01°C]. Das Handbuch der Standard-KL3202 trifft, entgegen den Aussagen des Supports, nicht 100% auf die KL3202-0028 zu. Hardwareabgleich nach Angaben im Handbuch ist definitiv nicht möglich. Beim Verstellen der Filterkonstante kommt es zu verfälschten Messwerten. Ich hoffe, die Entwickler bekommen das schnell in den Griff.

Bei all meinem "Filter-Übel", die Genauigkeit und die Auflösung der Klemme ist hervorragend!


Gruss, Onkel


Nachtrag, 17.07.2005
- Attachment: Grafik Änderung der PT1000-Kennlinie als Funktion der Filterkonstante

Legende:
PT1000= Kennlinie PT1000
0x0000 = Filterzeit 250ms (Standard)
0x50 = Filterzeit 65ms, o.a.