Hallo,
ich programmiere seit gut 2 Jahren Jetter, vielleicht kann ich ein bisschen Licht ins Dunkel bringen
Also, Jetter kocht wie alle anderen Hersteller auch nur mit Wasser, sprich STX hat durchaus stärken und schwaechen
- Jetter scheint die Programmiersprachen auf eine an Structured Text angelehnte Sprache zu reduzieren. „Hochsprachen“ haben in der SPS-Welt durchaus ihre unbestreitbare Berechtigung. Ich bin aber der Meinung, dass Grafiksprachen einer der großen Vorteile von SPS-Systemen sind. Gründe: - Durchgängige Handhabbarkeit vom Elektriker bis Ingenieur, Einfache Darstellung von Prozessen etc. Es erscheint mir ein sehr großer Nachteil, diese Möglichkeit einfach wegzulassen.
Ich habe früher In meinem alten Betrieb viel Zeit mit Beckhoff und S5 verbracht, dort aber als Instandhalter. Wir hatten Maschinen, die sowohl in ST, bzw. FUP und AWL programmiert waren. Ich gebe dir recht, Grafiksprachen wie FUP sind auf den ersten Blick bei kleineren Programmen uebersichtlicher, aber je groesser und komplexer das Programm wird, desto unuebersichtlicher kann es werden. Ich empfinde das weglassen von grafischen Programmiersprachen nicht unbedingt als Nachteil. Ich persoenlich war nie ein Fan von FUP und Konsorten.
- Man hat mir auf der Messe den Vorteil genannt, dass Eingänge nicht mehr zyklisch abgefragt werden, sondern nur noch nach Bedarf. Das halte ich erstmal fUer unwahrscheinlich. Als Bussystem z. B. Ethercat angeboten wird. Die Prozessdaten werden hier Zyklisch vom Master abgefragt.
Dazu kann ich leider nichts sagen.
- Der normale Programmablauf wird in einer freilaufenden Task abgearbeitet. Für regelungstechnische Vorgänge wird man entsprechend zyklische Tasks starten müssen. Die Art und Weise wie diese Programmiert werden, erinnerte mich an ein Echtzeitbetriebssystem auf einem uC. Da sehe ich ein großes Problem, den eine normale SPS versteckt die Komplexität eines Echtzeitbetriebsystems etwas. Umso mehr Tasks man starten muss, umso größer werden die Fallstricke (Was passiert, wenn die freilaufende Task durch eine Task mit höherer Prio unterbrochen wird, während Eingang A schon aktualisiert wurde aber Eingang B noch nicht?)
Task's mit hoehere Prioritaet unterbrechen nicht andere Task's. Sie werden nur oefters im Zyklus durchlaufen als niedrigere Tasks. Ich habe dies aber noch nie gebraucht.
Wenn man etwas regeln oder stAendig berechnen muss, wie zum Beispiel Achspositionen, muss man das in einem Task machen, der immer und läuget und niemals durch ein Delay/ When-Befehl unterbrochen werden darf, der muss also immer bei jedem Aufruf von Anfang bis Ende komplett durchlaufen werden.
Es gibt sowohl für uC mit Echtzeitbetriebssystem als auch für SPS Systeme gute Gründe (Google berät einen dazu). Dabei stellt Jetter nach meinem Empfinden eine Zwischenstufe dar. Programmierer, die aus dem Embedded-Bereich kommen werden sich mit Jetter vermutlich schneller zurechtfinden, da man sich nicht an das IEC61131-3 Ablaufmodell gewöhnen muss. Man muss sich dann denke ich fragen, ob man wirklich eine solche Zwischenstufe wählt oder gleich eine der beiden „traditionellen“ Ausprägungen. Für eine solche Entscheidungen wird dann auch die Qualität und den Preis von der Jetter Hardware und dem Service zum Tragen kommen.
Jetter ist eine richtige SPS und nicht mit einem qC-System zu vergleichen. Nur weil deren Programmierkonzept von dem der klassischen Sps abweicht, ist das keine Zwischenstufe.
Was ich persoenlich ziemlich gut bei Jetter finde, ist das ich wirklich mit Objekten programmmieren kann und das ziemlich nahe an die Hochsprachen rankommt. Dadurch lassen sich auch die Servo-Achsen von Jetter sehr leicht und schnell programmieren und Inbetriebnahme nehmen lassen.
Zudem kann task's anhalten, neustarten oder an der Stelle weiterlaufen lassen, an der man diese angehalten hat. Ist zum Beispiel im Not-Aus interessant.
Was ich nicht so toll finde, dass man so manchen lieb gewonnen Baustein (z.b. Ton) nicht gibt, und man gezwungen ist sich was eigenes zu basteln.
