Zielsystem-spezifische Eigenschaften und Einschränkungen
Beachten Sie, dass Ihr eingesetztes →Zielsystem die Verwendung von logi.CAD 3 in folgenden Aspekten beeinflussen kann:
Aufrufpriorität von POE
Laut der →IEC-Norm kann die Priorität eines Tasks zur Steuerung von unterbrechenden Aufrufen von →POE ("preemptive scheduling") oder nicht-unterbrechenden Aufrufen von POE ("non-preemptive scheduling") verwendet werden. Die von logi.CAD 3 unterstützten Zielsystem ermöglichen nur den unterbrechenden Aufruf. Dabei kann eine auszuführende POE eine POE mit niederer Priorität in der gleichen Ressource unterbrechen, d.h. die Ausführung der Einheit mit der niedrigeren Priorität kann aufgeschoben werden, bis die Ausführung der Einheit mit der höheren Priorität vollendet ist. Eine POE darf die Ausführung einer anderen Einheit nicht unterbrechen, die eine gleiche oder höhere Priorität besitzt.
Informieren Sie sich unter Mehrere Tasks im SPS-Objekt deklarieren, wie die Priorität für unterschiedliche Tasks vergeben werden.
Controllino und Arduino Nano ermöglichen nur den nicht-unterbrechenden Aufruf. Dieser Fakt ist jedoch nicht weiter relevant, da nur ein Task für Controllino und Arduino Nano unterstützt wird (siehe unten).
Einfluss der Aufrufpriorität auf Linux-basierten Zielsystemen
Linux-basierte Zielsysteme sind: →phyBOARD-Regor, →phyBOARD-Wega, →Raspberry Pi, →Revolution Pi und bei Verwendung der Plattform LinuxX86
Diese Zielsysteme unterstützen unterschiedliche Arten von →Tasks:
- Echtzeitfähige Tasks (Tasks = Threads; siehe nachfolgender Hinweis) – Solche Tasks dürfen nur nur eine kurze Laufzeit haben. Diese Laufzeit ist natürlich abhängig vom Inhalt des zugehörigen Programms.
Falls diese Laufzeit den vom Betriebssystem vorgegebenen Wert überschreitet, unterbricht das Betriebssystem die Ausführung aller echtzeitfähigen Tasks automatisch. Dieser Mechanismus ist auch als "Real-Time Throttling" bekannt. Aufgrund der Unterbrechung ist die Echtzeitfähigkeit der Tasks nicht mehr gewährleistet.
Eine übliche Einstellung für das "Real-Time Throttling" ist eine Unterbrechung von 50 ms in einer Sekunde. - Nicht echtzeitfähige Tasks
Hinweis: Die in logi.CAD 3 erstellten Tasks werden üblicherweise als echtzeitfähige Betriebssystem-Threads angelegt. Ausnahme sind Tasks, die mit der niedrigsten Priorität 65535
erstellt werden. Diese Tasks werden als nicht-echtzeitfähige Betriebssystem-Threads angelegt.
Endian-Format der Daten
Alle von logi.CAD 3 unterstützten Zielsysteme speichern die Daten im Little-→Endian-Format. Falls Sie Daten im Big-Endian-Format benötigen, verwenden Sie die entsprechenden Convert-Funktionen.
Genauigkeit der mathematischen Funktionen
Genauigkeit und Verhalten von mathematischen Funktionen
Mathematische Funktionen, die Gleitkommazahlen (REAL
, LREAL
) verarbeiten, können unterschiedliche Ergebnisse auf den unterschiedlichen Zielsystem liefern – vor allem, wenn das Ergebnis der Funktion im Grenzbereich des Datentyps liegt. Diese unterschiedliche Genauigkeit der mathematischen Funktionen wird durch die folgenden Faktoren verursacht:
- das →Zielsystem selbst,
- der dafür verwendete Compiler und
- die konfigurierten Optimierungseinstellungen des Compilers.
Bausteine/Variablen mit LREAL nicht für Controllino oder Arduino Nano verwenden
Falls Sie eine Anwendung für einen →Controllino oder →Arduino Nano erstellen, vermeiden Sie die Verwendung von Bausteinen/Variablen, die LREAL
-Werte verarbeiten/liefern. Die Verwendung solcher Bausteine/Variablen ist zwar möglich, die LREAL
-Werte werden jedoch mit der Genauigkeit von REAL
-Werten abgearbeitet.
Beachten Sie, dass der DIV_TIME-Baustein intern immer mit LREAL
-Werten arbeitet.
Verhalten von Konvertierungsbausteinen bei nicht-übereinstimmendem Wertbereich
TRUNC
-Bausteine und andere Konvertierungsbausteine mit einem REAL
/LREAL
-Eingang können ebenfalls unterschiedliche Ergebnisse für unterschiedliche Compiler auf den unterschiedlichen Zielsystemen liefern, wenn der anliegende Wert nicht im gemeinsamen Wertbereich des Eingangsdatentyps und des Datentyps für den Ergebniswert liegt. Diese unterschiedliche Ergebnisse werden durch die folgenden Faktoren verursacht:
- der für das Zielsystem verwendete Compiler und
- das →Zielsystem selbst
Geben Sie deshalb Code in Ihrer Anwendung ein (z.B. IF
-Anweisungen im ST-Code), mit denen so ein nicht-übereinstimmender Wertbereich erkannt wird. Informieren Sie sich unter "Convert-Funktionen" und "ConvertEnh-Funktionen" nach, welche der Konvertierungsbausteine einen REAL
/LREA
L-Eingangsdatentyp unterstützen.
Bekannte Beispiele:
Zielsystem | Ergebnis der mathematischen Funktion TRUNC_DINT(REAL#3.402823466e+38); |
---|---|
→Laufzeitsystem für Windows | -2147483648 |
→Raspberry Pi | 2147483647 |
RTOS32-Compiler | -2147483648 |
Der RTOS32-Compiler meldet einen Fehler, wenn die Anwendung eine bestimmte Division enthält.
Falls Sie den RTOS32-Compiler verwenden, vermeiden Sie eine bestimmte Division (siehe das folgende Beispiel) in der Anwendung.
PROGRAM Program1 DIV(DINT#-2_147_483_648, DINT#-1); END_PROGRAM
Beim Erstellen der Anwendung melden die Compiler die erwartete Warnung overflow in constant division, undefined behavior
. Der RTOS32-Compiler meldet jedoch auch einen Fehler divide or mod by zero
. Andere Compiler akzeptieren den Code – nur die erwähnte Warnung wird gemeldet. Damit der Fehler beim RTOS32-Compiler nicht gemeldet wird, dürfen Sie eine Division mit den oben erwähnten negativen Integers nicht in der Anwendung verwenden.
Ressourcen, Tasks, Programminstanzen: Maximale Anzahl
Zielsystem | Elemente in einem SPS-Objekt | ||
---|---|---|---|
→Ressourcen | →Tasks | Programm→instanzen | |
Integrierte SPS | 1 | max. 32 | beliebig (1) |
Windows NT/X86 | 1 | max. 32 | beliebig (1) |
Linux-basierte Zielsysteme: | 1 | max. 32 | beliebig (1) |
→Controllino oder →Arduino Nano | 1 | 1 | 1 |
Hinweis:
(1) = durch die Speicherkapazität der SPS beschränkt
Speicher für STRING-Werte
Der Speicher, der für STRING
-Werte zur Verfügung steht, ist auf 1.024 Bytes beschränkt. Ausnahme: Bei Controllino oder Arduino Nano ist er auf 64 Bytes beschränkt.
Diese Einschränkung wirkt sich auf Bausteine mit STRING
-Werten (z.B. String-Bausteine) aus, falls diese verschachtelt in der Anwendung verwendet werden. Beachten Sie, dass 1 Byte vom Speicher für interne Zwecke verwendet wird. Unter "Wie kann der Ergebniswert bei verschachtelten String-Bausteinen vollständig abgebildet werden?" finden Sie mehr Informationen und Beispiele dazu.
Konsequenz: Bei einem Controllino und Arduino Nano ist es möglich, dass der Ausgang ENO
dieser Bausteine "früher" auf den Wert FALSE
(oder eine Entsprechung) gesetzt wird – im Vergleich zu den anderen Zielsystemen.
Zeitdauer-Literal
→Zeitdauer-Literale (z.B. TIME#14ms
) werden korrekt auf der →SPS abgebildet, sofern diese innerhalb der entsprechenden Timer-Frequenz liegen, die für die SPS gilt.
Zielsystem | Timer-Frequenz | kleinstmögliche Angabe in Zeitdauer-Literal (1) |
---|---|---|
→Laufzeitsystem für Windows | 10 kHz | 100 us |
Linux-basierte Zielsysteme: | 1 MHz | 1 us |
Controllino | 1 kHz | 1 ms |
Arduino Nano | 1 kHz | 1 ms |
Andere Angaben für Zeitdauer-Literalen und Variablenwerte (z.B. im ST-Editor) sind in logi.CAD 3 möglich, sie werden aber das nächste Vielfache der kleinstmöglichen Angabe abgerundet. Die Angaben werden dementsprechend in der Sicht Variablenwerte dargestellt.
Beispiel: Das Zeitdauer-Literal t#12h4m34ms230us400ns
wird bei logi.RTS für Windows auf t#12h4m34ms200us
abgerundet und so verarbeitet.
Zeitliterale
logi.RTS speichert die Datentypen TIME
, DATE
, TIME_OF_DAY
und DATE_AND_TIME
in einem vorzeichenbehafteten 64-Bit-langen Ganzzahl-Datentyp in Form von "Ticks". Die Zahl der Ticks pro Zeiteinheit (1 Sekunde) ist von der Timer-Frequenz der Zielsystemplattform abhängig (siehe die vorhergehende Tabelle). Dadurch liegen die Wertebereiche für die Datentypen TIME
, DATE
, TIME_OF_DAY
und DATE_AND_TIME
auf der SPS außerhalb der durch logi.CAD 3 verarbeitbaren Grenzen. Wenn Sie →Zeitliterale in logi.CAD 3 verwenden, gelten somit die Unter- und Obergrenzen für logi.CAD 3 (siehe Unterstützte Datentypen).
Zeitverhalten der Zielsysteme
Eine Anwendung wird periodisch aufgrund des definierten Zeitdauer-Literals für den Task (= Zykluszeit) ausgeführt. Das eingesetzte Zielsystem beeinflusst die Ausführung so:
Für die Ausführung wird die Zykluszeit auf ein Vielfaches der Standard-Timer-Auflösung abgerundet. Dieser gerundete Wert wird als Intervall für die Ausführung verwendet. Beachten Sie, dass die Zyklen der Anwendung bei einem Vielfachen der Standard-Timer-Auflösung beginnen. Die Standard-Timer-Auflösung entspricht der minimalen Zykluszeit.
Die Standard-Timer-Auflösung ist abhängig vom Zielsystem:Zielsystem Standard-Timer-Auflösung logi.RTS für Windows
1 ms
Arduino Nano 1 ms Controllino 1 ms Linux-basierte Zielsysteme:
→phyBOARD-Regor, →phyBOARD-Wega, →Raspberry Pi, →Revolution Pi und bei Verwendung der PlattformLinuxX86
500 us Beispiel: Bei einer definierten Zykluszeit
TIME#3.3ms
beträgt das Intervall für die Ausführung:TIME#3ms
für einen Windows-Rechner – Die Zyklen der Anwendung beginnen also bei einem Vielfachen vonTIME#3ms
.TIME#3.25ms
für einen Raspberry Pi – Die Zyklen der Anwendung beginnen also bei einem Vielfachen vonTIME#3.25ms
.
Falls eine Anwendung so lange ausgeführt wird (siehe "3. Ausführung" in den folgenden Abbildungen), dass das nächste Intervall bereits begonnen hat, beeinflusst das Zielsystem den Startzeitpunkt der nächsten Ausführung.
Bei den folgenden Zielsystemen startet die nächste Ausführung erst, wenn das Intervall danach beginnt (siehe "4. Ausführung"). Ein Intervall wird also übersprungen. Nachfolgende Intervalle und Ausführungen (siehe "5. Ausführung") verschieben sich nicht.
- logi.RTS für Windows
- logi.RTS für Linux x86
- Arduino Nano
- Controllino
- Raspberry Pi
- Revolution Pi