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 zum 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:  →Econ 100, →MICA, →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 (= Threads) – 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 (= Threads)

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 

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. 

Bekannte Beispiele

Ressourcen, Tasks, Programminstanzen: Maximale Anzahl

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.
Konsequenz: Falls Sie z.B String-Bausteine verwenden, ist es bei Controllino und Arduino Nano 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. 

Kleinere Angaben in Zeitdauer-Literalen (z.B. im ST-Editor) sind in logi.CAD 3 möglich, sie werden aber auf dem Zielsystem nicht verarbeitet. Die Angaben werden so in der Sicht Variablenwerte dargestellt, wie sie vom Zielsystem verarbeitet werden.
Beispiel: Das Zeitdauer-Literal t#12h4m34ms230us400ns wird von logi.RTS für Windows als t#12h4m34ms200us 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: →Econ 100, →MICA, →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
  • Econ 100
  • MICA
  • Raspberry Pi
  • Revolution Pi