-Menü

Beiträge anzeigen

Dieser Abschnitt erlaubt es Ihnen, alle Beiträge anzusehen, die von diesem Mitglied geschrieben wurden. Beachten Sie, dass Sie nur Beiträge sehen können, die in Teilen des Forums geschrieben wurden, auf die Sie aktuell Zugriff haben.

Beiträge anzeigen-Menü

Beiträge - Thomas_v2.1

#1
BECKHOFF / Re:Systemvorraussetzungen, Doku?
01. Februar 2011, 23:46:44
Hallo peewit,

stimmt, in der Doku beim IP_CONTROL steht es, da habe ich nicht genau genug hingesehen.
Ich habe aber nur die ersten Seiten durchgeblättert, und da steht was von "getestet mit BX9000" (imho ist der BX noch kein Windows-basierter Controller), also dürfte es auf diesem auch nicht laufen.

Klar, beim Übersetzen hagelt es Fehlermeldungen ohne Ende. Nur unter dem ganzen Meldungen findet man schwer woran es gelegen hat. Das ist jetzt aber kein oscat-Problem.
Mit einem C-Preprozessor kann ich mit sowas wie
#ifdef ARM32
  #error "Arm32 not supported yet"
#endif
den Übersetzungsvorgang abbrechen. Aber sowas bietet Codesys anscheinend nicht.

Auf den Beckhoff BC braucht man übrigens keine zusätzliche lib um TCP/UDP-Sockets aufzubauen.
#2
BECKHOFF / Systemvorraussetzungen, Doku?
31. Januar 2011, 21:37:28
Hallo,
warum stehen die Systemvorraussetzungen der Beckhoff Network lib nicht in der Dokumentation?
Ich habs nämlich gerade versucht für meinen BC zu übersetzen. Hab die Doku durchsucht und nichts gefunden, und man liest erst hier im Forum dass es mit diesem Controller garnicht kompatibel ist.

Vielleicht lässt sich ja auch irgendwie beim Übersetzen prüfen, ob das Target und die Versionen kompatibel sind, und dann eine eindeutige Fehlermeldung "Version oder Target ist nicht kompatibel" generieren?
Bei diversen C-Compilern gibt es solche Konstanten die man schon mit dem Pre-Prozessor abfragen kann. Evtl. bietet Twincat/Codesys sowas auch.


Ich hätte noch einen kleinen Baustein für die network-lib in petto  :o
Und zwar einen S7-GET bzw. S7-PUT. Mit diesem lassen sich Daten aus S7-Steuerungen über Netzwerk auslesen und schreiben. Ich habe mir dazu momentan einen eigenen (vereinfachten) IP_CONTROL Baustein für meinen BC geschrieben, aber ich weiß nicht ob mein Baustein mit dem IP_CONTROL aus der restlichen network-lib kompatibel ist.
#3
Wie du das abfangen kannst weiß ich nicht. Das ist auch nur eine Vermutung von mir.

Was auf jeden Fall problematisch in der Funktion STIME sein kann, ist, wenn die SPS neu gestartet wird.
Denn dann fängt TIME_TCK() wieder bei 0 an. STIME erkennt den Neustart und setzt den Vergleichszähler "last_time" auf 0.
Das Vorzeichenbit das in STIME manuell in tx "eingebaut" wird bleibt auf dem alten Zustand bestehen, stört aber auch nicht weiter.

Was aber jetzt in Bezug auf ACTUATOR_PUMP stört ist, dass sich dieser Baustein den letzten Zeitpunkt des Ein- oder Ausschalten des Antriebes merkt.
Mal angenommen seit die funktion run_every, also dass die Pumpe auch wenn nicht angefordert für eine bestimmte Zeit eingeschaltet wird.

Angenommen last_change steht auf der Zeit T#23D und es ist gerade der run_every-Zyklus aktiv, und ich mache einen SPS-Neustart. Dann wird tx auf T#0 (oder auf max. negativ je nach bit31 aus STIME) gesetzt. Ergebnis ist dass der Antrieb 23 Tage durchlaufen würde obwohl nicht angefordert, wegen:

tx - last_change >= run_every

eingesetzte Beispielwerte:
T#0S - T#23D >= T#10000M

Die Bedingung wäre also sehr lange gültig.

Ich kann mir vorstellen dass das auch noch für andere Bedingungen Auswirkungen haben könnte, z.B. bei der min.-Ausschaltzeit.

Hast du deine SPS in der Zeit mal neu gestartet? Wenn nicht dann wüsste ich auch nicht woran es liegen könnte.
#4
Das riecht zumindest beim Zeitbereich von "ein paar Wochen" nach einem Problem beim Auslesen der Systemzeit. Denn dort tritt bei 3 Wochen ein Überlauf auf (2147483647ms / 1000 / 86400 = 24 Tage).
#5
oscat.lib fuer Step 7 / Fehler in DEW_CON
22. November 2010, 15:41:42
Hallo,
mir ist heute ein kleiner Fehler im Baustein DEW_CON aufgefallen.
Einmal steht oben im Bausteinkommentar dass der Ausgang kg/m³ ist, jedoch scheint der in dieser Version (3.11) in g/m³ zu sein.
In der Dokumentation ist auch kein Temperaturbereich angegeben in dem der Baustein korrekte Werte liefert. In der Formel zur Berechnung des Sättigungsdampfdrucks sind bei der Magnus-Formel auch andere Werte als z.B. auf Wikipedia:
http://de.wikipedia.org/wiki/S%C3%A4ttigungsdampfdruck
eingetragen.

Desweiteren ist zu prüfen ob es so sinnvoll ist dem Rückgabewert der Funktion garkeinen Wert zuzuweisen wenn der Wert von RH <= 0.0 ist.
Mal angenommen ich verwende eine temporäre Variable als Zuweisungswert, behält diese in diesem Fall den vorherigen Wert. Und dieser kann bei Step7 eben uninitialisiert sein (zufälliger Wert).
#6
Hallo,
ich habe gerade einen Blick in die network lib geworfen.
Irgendwie fehlt in der Dokumentation jeglicher Hinweis auf:
- Systemvorausetzungen
- welche Platform, welche Controller
- welche weiteren Bibliotheken müssen eingebunden werden

Oder gibt es dazu eine zusätzliche Dokumentation die ich nur noch nicht finden konnte?

Gruß
Thomas