Hi, ich bin gerade dabei eine "Mini-SPS" auf Basis einer STM32F4 CPU zu schreiben hier der Link mit einer kurzen Beschreibung und einem lauffähigen HEX-File für das STM32F4-Discovery-Board (oder sonst einem Board mit STM32F4) http://mikrocontroller.bplaced.net/wordpress/?page_id=3566 Auf der CPU läuft ein Parser und ein Interpreter. Das bedeutet man kann ein SPS-File (Sprache = AWL von der Siemens S5/S7) als Textfile per UART zur CPU senden und dieses wird dann ausgeführt. das ganze ist noch in einer sehr frühen Phase und ich bin im Moment noch am überlegen welche "AWL-Befehle" als "Basis-Wortschatz" anzusehen sind, die ich auf jeden Fall implementieren müsste. Wenn von euch jemand in SPS fit ist, kann er mit ja vlt ein paar Tips geben was für Mindestanforderungen die Software erfüllen müsste um als "SPS" durchzugehen (es soll natürlich kein Vollwertiger Ersatz von einer S7 werden :-) Gruss Uwe
:
Bearbeitet durch User
Ich glaube, für 'mini-SPS' ist der F4 zu sehr 'maxi'. Interessant wären ja die Möglichkeiten bezüglich Timer, Quadraturdekoder, PWM, ADC und DAC. Aber dazu müßte man zunächst festlegen, wieviel man davon verwenden will und auf welchen Pins. Geschockterwiese gibt es ja nicht ein oder zwei Ports, die von 0-15 zählend ihre IO-Pins anbieten; hingegen ist Alles über alle Ports verstreut. (Der Tippfehler gefällt mir irgendwie :-) Oder man baut sich digitale IO-Pins mit Schieberegistern auf (16xIN und 16xOUT) und aktualisiert diese im 10kHz Takt (z.B.), um nicht direkt mit PA0 und PD12 konfrontiert zu werden. Um IN-OUT zweckmäßig zu verwenden, wären (halbwegs) passende Eingangs- und Ausgangsstufen für 24V notwendig oder man verwendet dazu Module eines anderen Herstellers. Damit der F4 auch noch ein wenig gefordert wird, würde ich ihm ein einfaches (W)QVGA-TFT mit Touch-Funktion zur Bedienung und Statusanzeige spendieren, welches mit dem internen RAM auskommt. Das Ganze dann als fertiges Modul könnte sich SPS nennen. Das ist meine Spinnerei dazu, aber vielleicht sprengt das schon den von Dir angedachten Rahmen.
m.n. schrieb: > Geschockterwiese gibt es ja nicht ein oder zwei Ports, die von 0-15 > zählend ihre IO-Pins anbieten; hingegen ist Alles über alle Ports > verstreut. wenn man die reine CPU betrachtet schon, mein Kumpel hat eine STAMP (nur mit CPU und ser.Schnittstelle) die er als "SPS" benutzen will er lötet sich die Pegel-Anpassung für die Ein/Ausgänge selber drann will also nur die reine Ablaufsteuerung von mir Ein Display braucht er gar nicht (er hat ja auch keine Eingabemöglichkeit) Das "SPS-Programm" wird am PC editiert und auf der SPS solange getestet bis alles läuft, zum Schluss wird das Textfile einfach mit in den Flash gepackt und fertig. (event. könnte man da auch eine SD-Karte vorsehen, braucht er aber auch nicht) Mir ging es mit der Frage nur darum welche "Bausteine" wie (FlipFlop, Zähler, Timer usw) in einem SPS-Programm am häufigsten verwendet werden. Gruss Uwe
:
Bearbeitet durch User
Uwe B. schrieb: > mein Kumpel hat eine STAMP (nur mit CPU und ser.Schnittstelle) die er > als "SPS" benutzen will Dann sollte Dein Kumpel auch sagen können, was er braucht :-) Schon zehn Jahre alt, aber ich hoffe, Du hast diesen Beitrag schon gesehen? Beitrag "SPS Betriebssytem"
Super Projekt. So etwas ähnliches habe ich auch schon mal entwickelt. Allerdings ohne Parser usw. Nur Blockorientiert.
Wenn du mal auf ldmicro.bplaced.net schaust, da gibt es einen SPS editor. Es gibt auch output Module fuer Arduino und STM32, welche die C Ausgabe benutzen und diese dann anpassen. Es gibt aber auch Bytecode interpreter inkl. ADC. Ev. könnte es fuer dich interessant sein, darauf aufzubauen, bzw zusammen damit was zu machen oder die Entwicklung in diese Richtung zu lenken.
m.n. schrieb: > Schon zehn Jahre alt, aber ich hoffe, Du hast diesen Beitrag schon > gesehen? ja, den kenne ich Chris schrieb: > Wenn du mal auf ldmicro.bplaced.net schaust, da gibt es einen SPS > editor. das Programm hab ich auch schon gesehen, und ausprobiert ich hab im Moment nur Wenig Zeit, habe aber gerade eine neue Version hochgeladen (mit XOR, RS-FlipFlop und Counter) Gruss Uwe
Hallo, ich habe auch schon mal eine SPS entwickelt (für ATmega8/16/32): Beitrag "MySPS: SPS mit ATmega8/16/32" Max. 30 Ein- oder Ausgänge Ein-/Ausgänge können flexibel definiert werden (Ein-/Ausgang, Positive bzw.Negierte Logik, Interner Pullup) 48 Merkerbytes 16 Zähler (0-255) 16 Timer max. 6 Analogeingänge (Wertebereich 0-255) Gruß Stefan
stefan schrieb: > ich habe auch schon mal eine SPS entwickelt (für ATmega8/16/32): > > Beitrag "MySPS: SPS mit ATmega8/16/32" Mit .NET-Geraffel (Ausschlusskriterium).
.Net ist auch auf Linux lauffähig !!! (Mono) Ausserdem kommt man damit schnell zum Ziel !!! Ich programmiere gerne damit. Darum währen die Sourcen sehr interresant. Auf der SPS wird wahrscheindlich nur mehr ein riesiger "switch" ausgeführt, der den Bytecode ausführt. Darum muss der Parser und Interpreter am PC das Hirn besitzen !!!
>(Sprache = AWL von der Siemens S5/S7) Omg.. >das ganze ist noch in einer sehr frühen Phase und ich bin im Moment noch >am überlegen welche "AWL-Befehle" als "Basis-Wortschatz" anzusehen sind, >die ich auf jeden Fall implementieren müsste. Warum denn an diesem alten Zeug festkleben? Wenn Du aktuell was tust, warum dann nicht mindestens Strukturierter Text? Sogar bei SPS bleibt die Welt nicht stehen. Mach mal in AWL eine Schleife oder ein Case als Vergleich...
Matthias Lipinsky schrieb: > Wenn Du aktuell was tust, > warum dann nicht mindestens Strukturierter Text? 1. weil ein Parser für AWL um einiges leichter zu implementieren ist 2. weil meinem Kumpel (für den das ganze ist) egal ist ob FUP, ST, AWL, KOP zur Info für alle die es interessiert : die erste Beta ist online, mein Kumpel testet das ganze und wenn er damit zurechtkommt und keine Fehler mehr auftauchen lade ich das ganze als Source hoch
Herrrr mit den Sourcen. Das ist sehr interresant für mich. So was ähnliches suche ich schon lange.
Wie bereits erwähnt, habe ich schon mal so was ähmliches, nur Blockorientiert erstellt. Hier der originale Beitrag: www.mikrocontroller.net/topic/290163 Und hier meine "Befehlsreferenz" : Generell: Das Programm wird nach den Blocknummern von 1 bis 65280 abgearbeitet. Block 65281 bis 65535 sind Systemblöcke und dürfen nicht verwendet werden. Die Blockanzahl wird meist nur durch dem im Zielsystem verfügbaren Speicher begrenzt. In der Hardware wird nur mehr durch einen grossen Select Case Zweig der Code abgearbeitet. Die "Bausteinsequenz" kann von einem Speichermedium wie I2C EEPROM,SRAM,... abgearbeitet werden. Es ist egal, wann ein Block abgearbeitet wird. Es gibt immer einen Zielblock und einen Quellblock. Der Zielblock gibt den Block an, in dem das Ergebnis geschrieben wird. Der Quellblock gibt an, von welchem Block der Zustand/ Wert für die aktuell anstehende Verarbeitung/Berechnung genommen wird. Die Anschlussnummer des Quellblockes gibt an, von welchen Anschluss des Quellblockes der Wert genommen wird. Dadurch sind auch Blöcke mit mehreren Ausgängen möglich (Schieberegister,...) Es gibt Operationsblöcke und Ein/Ausgabeblöcke Operationsblöcke können Aufgaben ausführen (logische Verknüpfungen, Mathematische Funktionen,...) Ein/Ausgabeblöcke könne hardwaremässig verfügbare Hardware benutzen (z.b. LCD,I2C read,...) Ein Operationsblock ist IMMER gleich aufgebaut. Dadurch entfällt die Unterscheidung zwischen verschiedenen Blockarten. Es gibt keinen Unterschied von Mathematischen/Werte bezogenen zu Booleschen Operationen. Die Prüfung für die korrekte Verknüpfung muss das Editor Programm übernehmen. Ein Block kann auch als eine Anweisung angesehen werden. Ein Operationsblock ist immer 20 Bytes lang. Aufbau eines Operationsblockes: 0.Byte: Befehl High 1.Byte: Befehl Low 2.Byte: Zielblock Adresse High 3.Byte: Zielblock Adresse Low 4.Byte: Aktueller Zustand Ausgang Highest 5.Byte: Aktueller Zustand Ausgang Higher 6.Byte: Aktueller Zustand Ausgang High 7.Byte: Aktueller Zustand Ausgang Low 8.Byte: Nummer Quellblock 1 Adresse High 9.Byte: Nummer Quellblock 1 Adresse Low 10.Byte: Anschluss Quellblock 1 11.Byte: Nummer Quellblock 2 Adresse High 12.Byte: Nummer Quellblock 2 Adresse Low 13.Byte: Anschluss Quellblock 1 14.Byte: Nummer Quellblock 3 Adresse High 15.Byte: Nummer Quellblock 3 Adresse Low 16.Byte: Anschluss Quellblock 1 17.Byte: Nummer Quellblock 4 Adresse High 18.Byte: Nummer Quellblock 4 Adresse Low 19.Byte: Anschluss Quellblock 1 20.Byte: Remanenz Byte0/1: Der Befehl. Der Befehl ist immer 2 Byte lang. Es gibt also 65535 verschiedene Befehle. Das erste Byte ist der High Anteil. Der Zweite der LOW Anteil. Byte 2/3: Der Zielblock Die Zielbausteine hat immer eine 2 Byte Adressierung Das erste Byte ist der High Anteil. Der Zweite der LOW Anteil. z.B. Blockname: 1234 = 2.Byte: 4 3.Byte = 210 DEZ 1234 = 2.Byte: 4 3.Byte = D2 HEX Es stehen 65281 Blöcke zur Verfügung der Rest ist Reserve (Maximale Adresse:FF00,65280) Der erste Block ist Blocknummer 1 Byte 4/5/6/7 Der aktuelle/letzte Zustand des Zielblockes (-> Nur ein Ausgang) Bei mathematischen Funktionen: (Add,Sub,...) 4.Byte: Aktueller Zustand des Zielblockausganges Highest Byte 5.Byte: Aktueller Zustand des Zielblockausganges Higher Byte 6.Byte: Aktueller Zustand des Zielblockausganges High Byte 7.Byte: Aktueller Zustand des Zielblockausganges Low Byte Bei einfachen binären Funktionen: (AND,OR,Flanken,... -> Nur ein Ausgang) 4.Byte: Der Zustand des Zielblockausganges vor der aktuellen Operation (letzter Zyklus) 5.Byte: Der Zustand des Zielblockausganges nach der aktuellen Operation(aktueller Zyklus) 6.Byte: Nicht benutzt 7.Byte: Nicht benutzt Bei komplexeren binären Funktionen: (Schieberegister) 4.Byte: Zustände der (möglichen) 256 Ausgänge im Byte Format (im vorhergehenden Zyklus) 5.Byte: Zustände der (möglichen) 256 Ausgänge im Byte Format (im aktuellen Zyklus) 6.Byte: Nicht benutzt 7.Byte: Nicht benutzt Byte 8/9/10/11/12/13/14/15/16/17/18/19 Der zu verarbeitende Wert des Quellblockes Gibt den Quellblock und dessen Ausgang an, von welchem der Zustand zur Verabeitung hergenommen werden soll. 8.Byte: Quellblock 1 Adresse High 9.Byte: Quellblock 1 Adresse Low 10.Byte: Anschluss Quellblock 1 11.Byte: Quellblock 2Adresse High 12.Byte: Quellblock 2 Adresse Low 13.Byte: Anschluss Quellblock 2 14.Byte: Quellblock 3 Adresse High 15.Byte: Quellblock 3 Adresse Low 16.Byte: Anschluss Quellblock 3 17.Byte: Quellblock 4 Adresse High 18.Byte: Quellblock 4 Adresse Low 19.Byte: Anschluss Quellblock 4 Byte 20: Remanenz Byte 20 Zustand 0: Der Zustand des Zielblock ist nicht remanent Byte 21: Zustand 1: Der Zustand des Zielblock ist remanent Ist die Remanenz gewählt, so wird der aktuelle Zustand beim Stromlos schalten der Steuerung in einem EEPROM oder ähnlichen gesichert. Vor dem ersten Zyklus werden die gespeicherten Zustände wieder zurückgesichert. (Ist bei einigen Operationen nicht sinnvoll. Muss vom Editor ausgewertet werden) Standartblocknamen (Reserviert. Dürfen nicht verwendet werden): Immer 1 : Block FF FF = 255 255 Immer 0 : Block FF FE = 255 254 Ich hoffe, dir damit geholfen zu haben. Fallst du die Sourcen meines "Interpreters" willst, einfach melden.
Wurde übrigends hier so ähnlich gemacht: http://www.mikrocontroller.net/topic/177356 Leider ist der Author nicht mehr ereichbar :-(
SPSer schrieb: > Herrrr mit den Sourcen. ab heute online : http://mikrocontroller.bplaced.net/wordpress/?page_id=3566 UB
:
Bearbeitet durch User
Harrr Harrr. Genausowas suche ich. Werde mal eine Oberfläche zaubern, welche KOP in AWL wandelt. Dies sollte nicht so schwierig sein.
Warum zum Geier soll man sich sowas antun? Die Syntax ist ja grausam. Da ist ja BASIC noch besser.
Hi ich hab eine SPS auf Basis des STM32F427 entwickelt und suche eigentlich jetzt eine AWL / FUP Software die auf meine Hardware angepasst werden könnte. Die Hardware wurde sogar CE zertifiziert. 9 E/A (8 relais ausgänge + 1 NPN 0,5V), CAN, Ethernet, Profibus, RS485, RS232 alles isoliert, ein Display. Vielleicht könnten wir ja da eine Synergie bilden?
:
Bearbeitet durch User
Hodenklemme schrieb: > Warum zum Geier soll man sich sowas antun? Die Syntax ist ja grausam. Da > ist ja BASIC noch besser. Ich finde eigentlich nur dein Kommentar grausam. An die Anderen: Schoenes Projekt!
:
Bearbeitet durch User
Eine Oberfläche, welche KOP oder FUP kann, währe ein mächtiges Tool. AWL ist doch schon in die Jahre gekommen.
Sepp schrieb: > Eine Oberfläche, welche KOP oder FUP kann, währe ein mächtiges Tool. > AWL ist doch schon in die Jahre gekommen. Das stimmt wohl. Hier tummeln sich aber leider mehr Leute, die nah an der HW arbeiten und ungerne GUI Programme schreiben. Also ich werde mich nicht freiwillig dafuer melden...
Ich hab eine kleine Fup Gui in QT geschrieben. Ich würds aber gerne Webbasiert machen.
Du kannst es hier downloaden: http://mikrodev.com/mikrodev-plc.html ganz unten runterscrollen und das Zip downloaden. (leider türkisch) Ich will eine Opensource version mit webinterface machen so bisschen mbed /Plattform like.
:
Bearbeitet durch User
Ersan G. schrieb: > Ich hab eine kleine Fup Gui in QT geschrieben. Ich würds aber gerne > Webbasiert machen. klein ist da aber richtig untertrieben :-) sieht super aus, in wie weit darf man diese PC Version benutzen ? So wie ich gesehen habe, kann die Schaltung als XML-File exportiert werden. Damit ließe sich bestimmt was anfangen (für alle die genügend Zeit dafür opfern wollen) Aber auch der Simulationsmode ist spitze Gruss
Danke :) Die Software wird eigentlich als Freeware zur Steuerung mitgeliefert. Du kannst Sie aber für deine eigenen nicht-kommerziellen Testzwecke verwenden. Ich denke das mit dem webbasierten Interface, kann ich nicht das gleiche erreichen aber mal sehen. Gibt auch schon eine neuere version: http://www.argeport.com Gruß
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.