Beachten Sie, dass Ihr eingesetztes →Zielsystem die Verwendung von logi.CAD 3 in folgenden Aspekten beeinflussen kann:

Dieser Artikel behandelt Zielsysteme, auf die Sie Anwendungen in allen Varianten von logi.CAD 3 laden können. Daher ist es möglich, dass hier angeführte Zielsysteme nicht notwendigerweise für Ihre Ausbaustufe von logi.CAD 3 unterstützt werden.

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. Die se 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. Die se 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/LREAL-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.

Beispiel für ST-Code

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⁽¹⁾
Windows NT/X86	1	max. 32	beliebig⁽¹⁾
Linux-basierte Zielsysteme: →phyBOARD-Regor, →phyBOARD-Wega, →Raspberry Pi, →Revolution Pi und bei Verwendung der Plattform `LinuxX86`	1	max. 32	beliebig⁽¹⁾
→Controllino oder →Arduino Nano	1	1	1

Hinweis:

⁽¹⁾ = 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⁽¹⁾
→Laufzeitsystem für Windows	10 kHz	100 us
Linux-basierte Zielsysteme: →phyBOARD-Regor, →phyBOARD-Wega, →Raspberry Pi, →Revolution Pi und bei Verwendung der Plattform `LinuxX86`	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 Plattform `LinuxX86`	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 von TIME#3ms.
TIME#3.25ms für einen Raspberry Pi – Die Zyklen der Anwendung beginnen also bei einem Vielfachen von TIME#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