Hi ! Habe wie versprochen ein SPS Betriebssystem für die AVRs programmiert. Funktioniert super. Stromstoßschalter, Wischer ,Timer alles da. Schöne Grüße Josef
Hallo Josef! Ich freue mich riesig darüber, dass jemand die Idee hatte, eine SPS mit einem AVR zu realisieren. Ich kenne mich mit der S5 ganz gut aus; leider nicht mit der Sprache C. Deshalb meine Frage: Wie kann ich Dein PRG zum Bleistift verwenden, um etwa UE0.1 = A1.0 zu realisieren? MfG paul
Ich finde diese Idee sehr interessant! Ich würde gerne an dem Sourcecode (mit) weiterentwickeln und evtl. auch gerne eine kleine Standard-Leiterkarte mit ein paar In/Outs erstellen... Interesse? Gruß, Patrick...
Danke Jungs ! Die Idee hat mich auch fasziniert und sie funktioniert auch sehr gut. $ Paul: Habe deine Frage nicht ganz verstanden. Der Code lautet LE (E0,1); SA (A1,0); Schöne Grüße Josef
Patrik - mach es. Du kannst noch Analogverarbeitung, Counter, mehrere Aus /Eingänge , Netzwerkfähigkeit über RS485, schnelle Counter usw. programmieren. Helfe dir gerne. Schöne Grüße Josef
Hallo Josef! Offenbar ist das für die S7 Syntax geschrieben. Ich war auf S5 geeicht. Meine Frage: Soll ich meinen SPS- Code in Deinen Quellcode einbinden, statt dem Code, den Du eingetragen hast und dann den C-Code mit einem C-Compiler durchschnaggeln, um ein HEX-File zu kriegen, das ich in den MC übertragen kann? Und noch eine Frage: Da ich mich mit C nicht auskenne: Gibt es kostenlose C-Compiler zum Download? MfG Paul
Hallo Josef! .....noch etwas vergessen: Von welcher SPS stammt die Syntax oder hast Du eine "eigene Sprache" für Deine "AVR SPS" kreiert? Das Schlimme ist, dass ich nur mit der S5 von Siemens gut umgehen kann. MfG Paul
Die SPS Syntax ist - Macrobedingt - von mir. Aber angelehnt an Simatic. Paul du hast recht. Den Code einfach statt dem meinen eintragen und compilieren. Das Hexfile direkt vom Codevision Compiler in das STK200 oä brennen. Den Compiler gibts (eingeschränkt) gratis im Netz. SG Josef
@Josef Danke für den Link zu dem Compiler. Ich habe schnell mal ein "Minimalsystem" auf einem Stück Uniplatte zusammengeschmolzen und ein PRG ausprobiert: ICH BIN ENTZÜCKT!! Endlich mit einer vernünftigen Umgebung kleinere Steuerungsaufgaben lösen zu können ist prima! Wenn man weiss, was industrielle SPS en kosten, ist das eine feine Alte-Naive. :-))) Mach es gut. Paul
Danke Paul für die Lorbeeren. Freut mich, daß dein Progr.funktioniert. Man glaubt es kaum, wie leistungsfähig das System sein kann und wie leicht man es selbst erweitern kann. Viel Spaß noch Josef
kleine idee...wie wärs den controller als interpreter arbeiten zu lassen und das eigentliche programm rennt von z.b einem seriellen eeprom... dauernd compilieren macht keinen spass... man müsste dann zwar einen "compiler" machne der aus deiner syntax einen bytecode macht aber das wär das geringere übel... man könnte dann das ganze auf nem mega128 bei 16Mhz rennen lassn und dann ginge die post ab ;) 73 de oe6jwf
Hallo Hans! Ich finde das gut, wie es der Josef angegangen ist. Das Compilieren ist doch nicht so schlimm und wenn Du die Aufgabe Deiner Maschine nicht immerzu ändern musst, geht es doch auch so gut. Man kann ja den MC auf eine Fassung setzen und tauschen, wenn das PRG anders aussehen soll. Maschinensteuerungen müssen im Normalfall auch nicht so flink sein, dass der Professor sich überschlägt. ....ist aber nur eine Meinung. MfG Paul
Interpretierter Code ist wesentlich langsamer. Zusätzlich brauchst du noch eine Software, die deinen Text in Token übersetzt und diese mußt du wiederum ins EE bringen - wähh.. Das Compilieren finde ich nicht so schlimm. Mittels ISP ist das PRG schnell im Controller. Mann kann auch, wie es auch Paul schrieb, eine aufsteckbare Controllerplatine zum Programmtausch verwenden (zB. Dil 24 - Format mit Atmega 8). SG Josef
@an alle haste das mal gesehen? wer sps preiswert lernen will: bestens! http://www.muff-electronic.ch/ chip kaufen genügt, wer platinen bauen kann. mfg stromi
Hoi@all, ich muss hier im Praktikum SPS mit Source Insight 3.5 programmieren. Leider kenn ich den Quellcode nicht und ich soll es mir nun selber beibringen, blos wie ??? Hat jemand von euch eine deutsche Anleitung. bin am verzweifeln suche nun schon seit 3 tagen und nur schrott bis jetzt gefunden ... plz hlp
Hallo, ich kenne mich mit SPS kein bischen aus und blicke noch nicht ganz durch. Haisst das, daß Du nun einen Erstatz einer solchen hast ? inwieweit ist das kompatible ? Könnte man dies als vollwertiges Replacement für eine in einer Maschine eingebauten S7 verwenden?
@OldBug Ja, finde ich ne gute Idee das etwas zu vertiefen und Leitplatten amchen zu lassen.
@an alle jetzt sogar mit Uhr, I2C, und LCD-Display wer sps preiswert lernen will: bestens! http://www.muff-electronic.ch/ chip kaufen genügt, wer platinen bauen kann. mfg stromi
Hallo, mal ne ganz blöde Frage, aber ich blicks einfach nicht. Was macht eine SPS zu einer SPS. Ich meine, warum verwendet man SPSs für Steuerungsaufgaben, was hat ist der Unterschied zu einem "reinen" uC? Gruß, doofer
@doofer Eine SPS, ala Siemens S5, soll einen normal sterblichen Menschen, meist Elektriker genannt, in die Lage versetzen einen Steuerung zu programmieren, ohne das er Assembler oder C-Programmiere sein muss. Soll so sein.....
@stromi ich denke mal, es ist in Assembler ziemlich unübersichtlich, wenn nicht sogar für einen normal Sterblichen unmöglich, eine Steuerung mit über 1000 Ein-/Ausgängen so zu programmieren. Geschweige denn, eine Fehlersuche bei auftretenden Fehlern bei Inbetriebnahme oder im späteren Betrieb zu lokalisieren. Bei Siemens hast du ja die Möglichkeit in AWL zu programmieren (oder von FUP in AWL und zurück umzuwandeln), was einem Assembler ja schon recht nahe kommt. Man kann so zwar schneller Programme schreiben, aber der Übersichtlichkeit ist das meist nicht sonderlich zuträglich. Vor allem, weil bei SPSen meist der Quellcode an den Kunden mitgeliefert wird. Und viele Kunden haben im Pflichtenheft die Forderung nach grafischen Funktionsplan stehen. Thomas
Hallo Josef. Ist das Projekt noch aktuell? der Threat ist leider sehr unübersichtlich geworden, finde dass aber auch sehr interessant
Das von Josef ist echt gut. Wird das weiterentwickelt ? Habe unsere ganze Firmensteuerung damit programmiert. Un es läuft und läuft.. Hans
Hallo Leute Ich hab mich mal mit Josef in verbindung gesetzt und hab mir seine erlaubniss geholt, den Code weiter zu entwickeln. Was bisher schon geht: - ATmega8 statt einen Tiny2313 - GCC (ich muss die Timer noch weiter anpassen) - Ergänzung um RS232 Funktionalität Was noch versucht wird / geplant wird zu implementieren - CAN via MCP2515 - HW PWM der AVR`s - ADC`s auslesen - Lesen eines SPS-Programms von einem I2C eeprom (24cXX) - mehr IO`s durch Porterweiterungen (z.B. I2C oder SPI) - Status-LED`s (Damit man auch was zu sehn bekommt ;-) - ... Gerne nehme ich noch wünsche auf! Ich kann aber noch nicht sagen, wann ich Zeit finde weiter zu arbeiten!
Ok, hab mir das gerade nochmal durch den Kopf gehen lassen und bin zu folgendem Entschluss gekommen! MCU: ATmega32-16 DIP mit 16MHz Quarz Inputs: 16 Stück (durch 2x 74HC595)ggf mit Optok. Outputs: 16 Stück (durch 2x 74HC165)ggf mit Optok. ADC: 8 ADC`s (die des AVR`s) PWM: 2 CAN: MCP2515 RS232: MAX232 oder RS485: MAX485 (z.B. mit SNAP-Protokoll) EEPROM: 24CXX (für späteres SPS-Programm (wichtiges ToDo)) mfg KoF
grafische Sps. Vieleicht kann ja die gleiche Platine verwendet werden? http://mikrocontroller.cco-ev.de/de/SPS-ctrl.php
Hallo zusammen, weiter oben im Tread wurde die Frage gestellt, was eine SPS von einem µC-System unterscheidet. Ein Teil der Antwort wurde oben schon gegeben: Die einfachere Programmierung durch "Programmierlaien" und die mittlerweile standardisierte "Programmiersprache" mit unter anderem Anweisungsliste und Funktionsplan (In DIN/IEC schlachmichtot gibt es noch andere Varianten). Der andere Teil, der eine SPS zu einer "richtigen" SPS macht ist der, daß es auf der Hardwareseite fertige Bausteine oder Module gibt, an die man nur die Betriebsspannung(en) anlegt und die Ein-/Ausgänge für die zu erwartenden Spannungen ausgelegt und (meistens)entsprechend geschützt sind. z.B. Relaisausgänge, NPN/PNP Aus- und Eingänge usw. Das heisst, man gibt auf den Eingang die vorhandenen 24VDC oder auch 230VAC und bekommt am Ausgang eben auch die erforderlichen Spannungen heraus, ohne daß man sich um Ein- oder Ausgangsbeschaltungen kümmern muss. Ich für meinen Teil finde die Idee mit der SPS-Programmierung eines µC ist eine gute Idee. Dann muss ich nicht immer umdenken, wenn ich mal einen programmieren will ;-) Frank
Hmm... also 24V Pegel für IO, ich dachte 12! Aber Ok, dann muss ich mir noch etwas einfallen lassen. Wie Josef oben schon einmal erwähnt hat, so ist der Syntax an Simatic angelehnt, aber Macrobedingt ein klein wenig verändert (zumindest bislang). Vielleicht bekomme ich den original Syntax zustande, wenn es mir möglich wird, einen "mini-AWL-Parser" in meinem uC zu implementieren, so das ich das Programm nicht mit in den AVR Flashen muss, sondern es in ein externes EEProm (wie die I2C EEproms 24C64) drücken kann. @123 Nein, die Platine ist 1. Komerziell und keine Codeveröffentlichung 2. Meine Ideen lassen sich nicht mit ihr umsetzen (16x In, 16x Out) 3. soweit ich sehe ist diese nicht für 24V ausgelegt 4. Wo ist denn da der Spass... Selber machen :-)
Hallöchen, hab gerade auf der ELEKTOR Webseite eine kleine mini SPS für den Gameboy entdeckt. (http://www.elektor.de/Default.aspx?tabid=28&year=2006&month=7&art=5550776) Da werden wohl die Logikprogramme auch über I²C in nen EEprom gepackt, so das man frei Programmieren kann, sogar im Gameboy selbst, wie es aussieht. (unter www.rk-tech.org gibt es die Sources zum Download) Das schöne ist die SMS Funktion, man soll über ein angeschlossenes Handy SMS versenden können, auf Zustände der SPS Logik. Rainer
Das von Josef ist irre gut ! Kof ich hoffe dass du da weitermachst. Falls du Hilfe brauchst melde dich bitte. SG Jakob
Momentan hab ich etwas Zeitprobleme! Aber schick mir mal ne Mail! (King_of_Freaks(AT)ist-einmalig.de) Ich melde mich bei dir...
So... damit Ihr was am Wochenende zum spielen habt, hier eine einfache Erweiterung des Codes. Änderungen: 1. Auf den avr-gcc portiert (bei mir 3.4.3) 2. Für Mega8 3. UART-Funktionen (senden von Zeichen, Strings, Ints & Floats (falls man es brauchen sollte)) 4. 2 PWM`s in Hardware 5. Zähler (ähnlich wie in der Simatic S7-AWL (ZV ZR jeweils von 0 - 999)) ------ Ich habe einfach zu selten Zeit, etwas zu machen, daher bitte ich um Geduld mit weiteren Funktionen! Auch ist die Software noch nicht fertig und auch ungetestet!!! Fehler und Erweiterungen (auch Wünsche) bitte posten (und bitte nicht mailen) Falls jemand eventuell die Zeit über hat, und mir eine Platine machen könnte,(Layout & ätzen) so würde ich mich Freuen, wenn er sich bei mir meldet! Ach ja, mal so eine kleine Bitte... ich würde gerne mal sehen, was Ihr so damit bastelt! Programm(beschreibung), Bilder,... machen bestimmt auch ein paar andere Leute darauf aufmerksam. Ein Schönes Wochenende noch.
Hallo, super, was Ihr so bastelt. Das Thema SPS interessiert mich auch schon länger. Die o.g. Links sind mir auch nicht fremd. Was ich am GameBoy Ansatz super finde, ist die Trennung von Steuerung und I/O via I²C. Universeller geht es kaum, jeder steckt das ran, was er gerade braucht. Die einzige Hürde sind die Preise der I²C Käfer. War nur so eine Idee (Wunschtraum), dann spar ich mir die Portierung ;o)). Grüßle und weiter so !!! Lothar
Lothar: "Die einzige Hürde sind die Preise der I²C Käfer." Im Prinzip könnte man jene 'Käfer' durch einen Satz fertiger I2C Codeteile ersetzen. Per 2313 oder ATMega8 könnte man dann sich die 'Käfer' selbst zusammenstellen. Ein ATMega8 kann locker 2* 8 Bit Port abbilden, einen SRAM-Baustein, eine 7-Segmentansteuerung u.s.w. Also nicht ein Mikrocontroller und 'dumme' oder teure Spezialchips, sondern einfach je nach Bedarf programnmiert.
Hallo Leute, super Sache sowas suche ich schon seit längerem. Hab nur wenig Ahnung von dem Microzeug. Wo bekomme ich einen Schaltplan, für entsprechend Hardware ? Was muß ich mir für einen "Brenner" zulegen, um den AVR beschreiben zu können ? Wieviel Eingänge Ausgänge hat das Ding ? Oder ist das vom Controller Abhängig ? Gruß Michael
Hi zusammen, bin gerade auf den Thread gestoßen und muss sagen, daß mich das auch interessiert. Leider hab ich noch nie mit AWL programmier... das muss ich mir erstmal anschauen. Noch viel Erfolg beim programmieren und großes LOB für das Programm. @Michael, Die entsprechende Hardware musst du dir wahrscheinlich selbst bauen. Wenn ich in den nächsten paar Wochen mal Zeit finde, dann werde ich mich mal an ein Layout setzen... das würde meinen Chef auch interessieren. Kann aber etwas dauern. Die Anzahl der Eingänge und Ausgänge hängt vom verwendeten Controller ab... Ich werd wahrscheinlich den ATtiny2313 oder den ATmega8 verwenden. Zum "beschreiben" der AVRs benötigst du einen ganz einfachen Programmer. Ein paar Widerstände reichen für den Anfang schon aus, besser ist aber ein Programmer mit Treiberbausteinen. Gruß, SIGINT
Hallo leute, bin leider erst heute auf diesen Beitrag gestossen. Da mich das Thema auch interessiert möchte eben auch gerne mal meinen Senf dazugeben. Also ich finde den Vorschlag von KoF nicht schlecht. Vielleicht hat jemand von euch das letzte Elektor Sonderheft gelesen. Dort wurde eine kleine SPS auf Basis des ATmega32 vorgestellt. Alledings ist die Software anscheinend closed Source. Aber mit der Hardwarebasis kann man schon was anfangen. Die Idee das ganze über Eagle zu Programmieren fand ich erst mal auch nicht schlecht nach ain bischen rumprobieren musste ich dann aber feststellen dass es zu viel mehr als ein bischen ein-aus in der praxias nicht taugt (finde ich wenigstens). So ein bischen C-programmieren kann ich zwar aber der absolute Crack bin ich nicht. Wer weiss vielleicht kriegen wir ja zusammen was auf die Beine. Ein schönes WoE.
Hallo zusammen... Wer den Artikel aus der Elektor nicht kennt, hier mal das ganze, ohne die (meiner Meinung nach überteuerte) Zeitschrift zu kaufen: http://www.microsps.com Dirk
Wie schon am 16.06.2007 von KoF geschrieben: kommt nicht in Frage, da 1. -4. Hinzu kam bei mir noch: 5. ausschliesslich mit Windows programmierbar. Matthias
>>Wie schon am 16.06.2007 von KoF geschrieben: >>kommt nicht in Frage, da Herr Docktor, Herr Docktor!!! Ich kann in die Zukunft sehen!!! Interessant! Wann hat das angefangen? Nächten Donnerstag :-P
Kof wrote: >>>Wie schon am 16.06.2007 von KoF geschrieben: >>>kommt nicht in Frage, da > > Herr Docktor, Herr Docktor!!! > Ich kann in die Zukunft sehen!!! > > Interessant! Wann hat das angefangen? > > Nächten Donnerstag :-P Stimmt. 1:0 Aber der Inhalt bleibt trotzdem aktuell. Matthias
Hab ich das bezweifelt? :-) So, zurück zum Thema! Hat jemand eventuell serielle FRAM`s die er mir zur verfügung stellen kann? Ich versuche einen Interpreter(mal sehen wie langsam das ganze dann wird) zu schreiben und da könnte ich ja den Code zwischenlagern... by the way... hier hat noch niemand mal gepostet, was er so schönes mit der sps gebaut hat. hab zwar immernoch immer wenig zeit, aber ich denke die entwicklung kann ich langsam nebenbei - häpchen für häpchen - machen ;-)
Kann man nicht genausogut den FLASH-Speicher im AVR verwenden? Egal ob externer FRAM/EEPROM oder interner Flash: Routinen insbesondere zum Speicher beschreiben (z.B. upload via RS232) braucht man doch im jeden Fall. Und den Speicherbereich kann man doch sicher durch ein großes Array (am hinteren Ende des Flash's per Linkeranweisung festgenagelt) realisieren?
Nein, extern ist viel einfacher. Speziell serielle Speicher (SPI oder IIC-gekoppelter EEPROM oder FRAM) werden einfach beschrieben und man muß evtl. auf den Abschluß warten. Der interne Flash muß über gesonderte Routinen beschrieben werden, und (im Normalfall) braucht man wenigstens zwei unabhängige Blöcke, weil der gerade beschriebene Flash während des kompletten Vorganges (Schreiben oder Löschen) keinerlei Lesezugriffe zuläßt - das darf also nicht der Programmspeicher sein. In aktuellen Megas kann man den Bootblock für die Schreibroutine mißbrauchen. Martin
Hallo Leute, Ich hatte mal ne sps auf den 8048 realisiert. Damals programierte ich das Teil in S5 AWL bzw FUP. Der Editor war in quickbasic geschrieben hatte mächtig arbeit gemacht. Aber es funzte. Das Projekt htte ich aber angesichts der dann später in vielfalt auf dem Markt kommenden SPSen in FI-SChaltergröße eingestampft. Wünsch euch viel Spaß noch ;-) nette Grüße...
Andreas schrieb: Ich hatte mal ne sps auf den 8048 realisiert. Damals programierte ich das Teil in S5 AWL bzw FUP. Der Editor war in quickbasic geschrieben hatte mächtig arbeit gemacht. Aber es funzte. Ist der Basic-Code noch verfügbar, würde mich interessieren, wie so etwas in Basic gemacht wird. Ich kann nur Basic....heul....
Hallo, gerade diesen Thread gefunden bei meiner Suche nach einem in C programmierten Interpreter für AWL.... KoF schrieb am 15.03.2007 dass er an sowas arbeitet... gibt es das schon ? Ich möchte diesen Interpreter mit meinem webeib Server kombinieren um meinem EIB Server Logik-Funktionen, flexible Zeitsteuerung und eben alles, was eine SPS so kann beizubringen. Bisher kann mein Server "nur" die Kommunikation mit dem EIB-Bus, die Speicherung der aktuellen Werte, die Präsentation als Webseite und ein wenig Datenloggen mit Grafikausgabe... es fehlt halt die Logik. Achja: mein Server läuft auf einem Mini-Rechner mit 300 MHz Prozessor aber wenig RAM und fast noch weniger solid-state Disk unter Debian Linux.
ich habe sehr schnell bemerkt, das ein echter awl-interpreter mit einem speicherinterface für awl-quellen und und und... für einen 8 biter echt problematisch wird. den original ansatz von josef ging ja den weg, das der awl-artige code zur compilierung des programmcodes übersetzt wird. ich habe aber die idee, einen echten interpreter zu schreiben, der den awlcode aus einer externen quelle holt und ihn dann abarbeitet. ich denke, das ist schon eher etwas für einen arm mit etwas mehr ram. by the way bis der interpreter fertig ist, dauert es noch lange (da ich beruflich total ausgelastet bin!). für die implementierung des interpreters arbeite ich mich momentan in lex und yacc ein, was aber wieder eine wissenschaft für sich ist.
Warum so viel Rechenleistung? An anderer Stelle hier im Forum gibt es doch auch den Basic-Atmel, der Programme aus einem EEPROM abarbeitet - prinzipiell sollte das doch dann auch mit AWL möglich sein? Ahoi, Martin
hmm... also wir (meine arbeitgeberfirma) schreibt programme von zig-tausenden opperationen und hat eine aykluszeit von <10ms ;-)
Hallo, Also bei meinem System das sicherlich langsamer war (8048) hatte ich eine Token-abarbeitung. Das Compilieren erledidte eine in Quickbasic(nicht lachen)geschriebene SOftware. Der Steuerrechner holte sich einen sps-opcode(1BYte fürs erste) aus dem eeprom(paralleles)und verzweigte indirekt adressiert, lud wenn nötig ein bis zei Byte nach und arbeitete dies ab. Ich kann mir vorstellen, daß soetwas auf nem 100MHz 1clock Rechner auch sehr schnell läuft. Man kann ja das programm in einem seriellen eepromm speichern, bei Programmstart ins externe Ram laden und von dort ausführen. Gruß Andreas
Hallo @K aus F wie man sowas macht...? in dem man 3000 Programmzeilen tippt. ;-) Ist noch verfügbar. Aber ich habe fast 10 Jahre nix mehr mit gemacht und muß erst gucken was für euch interessant ist. Einige wollen ja unbedingd C pompilieren. Wie das ein "einfacher" Elektriker dann ändern kann, ist die andere Frage. Ich hatte eine IDE programmiert. Quickbasic verfügt allerdings über Funktionen und Subroutines, so daß ich den reinen S5 Übersetzer rauslösen könnte.Diesen dann als exe abspeichern. Für die Übertragung ein eigenes exe Programm. Mit der MIDE könnte man dann auch S5 Programmieren. ;-) Gruß Andreas
Was für befehle müsste ein SPS-Arigers uC-Programm euere Meinung nach bereit stellen? Klar sind solche Sachen wie (an AWL orientiert): L,T,S,R,=,U,UN,O,ON,X,XN,ZV,ZR in meiner Idee drinne, aber der volle Umfang von AWL währe zu groß. Daher ist meine Frage an euch, was für Funktionen sehr oft von euch gebraucht werden. Braucht ihr z.B. unbedingt Rechenoperationen und Fließkommazahlen, oder reichen Ganzzahlen,... Für Ideen und Anregungen bin ich dankbar.
Aja, nur noch einmal zum verständnis. Ich will von dem C-Code-Compilieren weg! Ich will einen Interpreter und einen Compiler schreiben. Der Compiler soll das AWL-Artige Program in eine Zwischensprache übersetzten und der Interpreter (der auf dem uC sitzt) soll dann diese Zwischensprache abarbeiten, so das der uC nur einmal mit einer "VM" versehen werden muss und das Auszuführende Program (in der Zwischensprache) einfach dazugeladen wird (von z.B. externer Quelle)
Hallo nochmal. Also ich hätte da noch ein paar Ideen zur steigerung der Flexibilität. ABer mal ne andere Frage: hat überhaupt jemand Interresse an ein SPS-step5 interpreter/compiler? Gruß Andi
uuups @ KoF ich hatte dein letzten Beitrag übersehen. genau so etwas habe ich vor ungefähr 10 jahren gemacht. vielleicht sollten wir uns kurzschließen, damit das kompatibel wird! ich meine die OP Codes. mein system lief auf 8048. nun gut. mit der portierung nach 8051 hab ich begonnen. ist fast abgeschlossen. Also wäre es doch dchlau wenn du das für den avr machst. was den compiler angeht, der läuft unter dos (winfenster?) sollte ich mal hier die vorgaben posten? Ich will dir um Gotteswillen nix vorschreiben. kannst du C ? und das unter Linux? würde gerne zusammenarbeiten- Was hälst du davon?? gruß Andi das anhängsel ist trotz .doc keine winword datei.
hm. muß noch mal üben ..
die datei:
Dokumentation MP129
.OP
I. Programm-Codes:
P0 NOP 0 Keine Operationsausfürung
P1 U Operand...
P2 O Operand...
P3 U(
P4 O(
P5 )
P6 S Operand...
P7 R Operand...
P8 = Operand...
P9 UBD Unbedingd 0/1 auch VKE abhängigkeit der L/T
Bef.
P10 SE T...
P11 SA T...
P12 ZV Z...
P13 ZR Z...
P14 SZ...
P15 RZ...
P16 BE Baustein-Ende
P17 UN Operand...
P18 ON Operand...
P19 RES
P20 RES
P21 L KF 0-255 Konstande laden
P22 L KT 0-255.0-3 Timerwert laden
P23 L EB/AB/MB/Z/T/SYS Bereich laden
P24 LC EB/AB/MB/Z/T/SYS Bereich BCD codiert laden
P25 T EB/AB/MB/Z/T/SYS In Bereich transferieren
P26 =F Akku 1/Akku 2 Vergleich
P27 <F Akku 1/Akku 2 Vergleich
P28 >F Akku 1/Akku 2 Vergleich
P29 +F Akku 1/Akku 2 Addition
P30 -F Akku 1/Akku 2 Subtraktion
P31 SL MW Links-schieben eines
MW(*2)
II.Speicher-Bereiche:
0-7 Registerbänke
8-15 Stack bei 4 Call`s
16 U( / O( Flag`s
17-19 Zeit-Hilfsregister
20 Akku 1
21 Akku 2
22 Flankenspeicher-Zeiten 0-7
23-30 Zeitwerte 0-7
31 Flankenspeicher-Zähler 0-7
32-39 Z„hlerinhalt 0-7
40 High adress
41 low adress bei Sprung
42 high adress bei Sprung
43 Reserve System
44 Zeit-Ausgangs-Byte
45 Zähler-Ausgangs-Byte
46-53 PAE 8 Bytes
54-61 PAA 8 Bytes
62-93 Merker 32 Bytes nicht flchtig
94-125 Merker 32 Bytes flchtig
126 Res. für Bus-Sys
127 Res. für Bus-System
III.Register wärend des Zyklusablaufes
R0 Hilfsregister für indirekte Adressierung
R1 Zeiger auf low SPS-Adresse
R2,R3 Hifsregister für Logik und interne Schiebereien
R4 Akku 2
R5 Akku 1
R6 Zeitimpulse/System
R7 VKE Bit 0 = aktuelle Klammerebene
Also das von Josef ist grenzgenial. Es gibt natürlich sehr gute andere Vorschläge, aber das SPS-Betriebssystem ist vom Aufwand, Geschwindigkeit, Portierbarkeit, Erweiterbarkeit usw unschlagbar ! Ich habe es auf einem Tiny 13 eingesetzt und es läuft supi. Ein quasi Multitaskingsystem. Bravo Josef und natürlich auch an die anderen Autoren ! Schöne Grüße Susi
Kann man diesen Josef nicht ausfindig machen ? Er könnte sicher wertvolle Inputs geben. Also : Josef bitte melden ! SG Susi
KoF gerne können wir kommunizieren, aber ich kann deinen Namen nicht anklicken, vermutlich weil nur als Gast angemeldet bist oder so. du kannst mir deine geben dann schreib ich dir zurück. wenn das hier nicht möglich ist,ohne daß die addi von jedem eingesehen werden kann,dann müssen wir ne zeit ausmachen und in irgend einen chat gehen. Ich hab schon Tage jetzt gesessen und das auf 8051 umgestrickt. Wie du vielleicht siehst,ist der interne Speicher bis zum Rand voll. Ich wollte das nach wie vor mit internen Ram erledigen,weil man da dann ein Minisystem mit nem 2051 machen kann. Aktuell hat mein Kern ca 1400 Bytes. Allerdings ist die kommunikation noch die alte vom 8048. hier werden die Daten 4-Bit weise(alter Parallelport) übertragen. wegen timer init: kann man mit 9607 Baut leben,oder gibt es da Schwierigkeiten? öffne keine datei von mir,ich hab im moment trojanerprobleme. man kann ja hier posten und mit cut u. paste arbeiten. grüße freundlichst Andi
@ KoF Hallo nochmal, es gibt noch nicht viel neues. Bin noch am optimieren. hier habe ich ne mailaddy angelegt, daß du mir schreiben kannst. akrieger_de ät gmx.de wie du das ät ersetzt ist denke ich klar. Gruß Andi
Josef wrote: > Hi ! > > Habe wie versprochen ein SPS Betriebssystem für die AVRs programmiert. > Funktioniert super. Stromstoßschalter, Wischer ,Timer alles da. > > > Schöne Grüße Josef Hi Josef, ich habe Deinen Thread mitgelesen und habe gleich eine Frage zur SPS. Ich versuche eine Steuerung von 4 BL-Motoren in einem MicoKopter Projekt umzusetzen. Ich würde gerne Features wie Kompass und GPS mit einbauen. Wenn ich eine SPS (co) nehme was benötige ich noch? Ich hatte einmal etwas von EAGLE als Vollversion gehört. Worin besteht der Unterschied zur SPS (nc) Worin liegen die Einschränkungen? Über feedback würde ich mich freuen Beste Grüße Klaus
Hallo Klaus, Josef hat sich schon ~3,5 Jahre nicht mehr zu Wort gemeldet - aber ich habe das Projekt etwas (mit seiner Erlaubnis) erweitert. Deine Fragestellung ist mir nicht ganz klar, aber ich denke mit der Eagle-Geschichte meinst du http://www.mikrocontroller.com/de_sps/microsps.php Die habe ein "Produkt" entwickelt, bei dem du zwar mit Eagle das SPS-Programm in Form von Logikfunktionen ändern kannst, aber die eigentliche Firmware halten sie unter verschluss. Diese hier hingegen kannst du in Code erhalten und beliebig erweitern. Sie ist zwar (noch)nicht so schön zu bedienen, bietet aber mindestens genausoviele Einsatzmöglichkeiten. Aber bitte formuliere deine Frage nochmal neu und genauer ;-) mfg KoF
Hallo KoF, also ich arbeite zur Zeit an einem Projekt in dem ich eine SPS einsetzen muss. Nun habe ich in meinen Recherchen herausgefunden das es zwei SPS Systeme gibt. CO und NC. Da ich besondere Funktionalitäten in mein Projekt mit aufnehmen möchte (Kompaß und GPS) denke ich ich muß die CO - SPS Lizenz einsetzen. Dann habe ich aber erfahren das ich diese nur in Verbindung mit einer EAGLE Vollversion und Bootloader betreiben darf. Da ich als Entwickler aus einem ganz anderen Bereich komme sind mir diese Dinge erst einmal fremd und ich benötige Infos und Untestützung. Also Konkret geht es um ein Fluggerät (Quadkopter) der neben BL (brushless Motoersteuerung) auch noch einen Kompass und GPS bekommen soll. Ziel ist es eine Wegpunktspeicherung - die er dann abfliegen soll. Da sie SPS nc nur die BL-Steuerung und Gyroscope regelt brauche ich eine Erweiterung für Kompass und GPS Daten. Bei Fragen kannst Du mich auch mobil erreichen unter 0172 2317903 könnten wir uns austauschen. Genau, diese Steuerung von I.Busker meine ich. Kannst Du mich einmal dazu Informieren oder wäre es besser mit I.Busker in direktem Konatkt zu stehen Beste Grüße Klaus Löwenhagen
Ich glaube, das für solch eine Aufgabe eine SPS etwas unpassend ist. Eventuell sollte man hierfür eine eigene Software und ein eigenes Mikrocontrollersystem aufsetzten. Wenn ich dich richtig verstanden habe, hast du so(oooo) von der Materie keine große Ahnung, oder? - Weil etwas Wissen schon dafür von Nöten ist! Kannst dich ja mal bei mir melden ;-)
Josef wrote: > Wollte nur sagen: Ich lebe ! > > Schöne Grüße Josef Hey, schön zu hören :) aber das projekt ist scheinbar tot. Hab lange an einem Parser für Bitoperationen gebastelt (zielplatform u.a. ARM7), aber der ist nie fertig geworden... das ganze soll portabel sein und das Programm soll nun nicht mehr "mit-kompiliert" werden sondern aus einem Speicher ausgelesen werden. Ich denke, ich starte in der nächsten Zeit nochmal neu durch. Ideen und Anregungen sind willkommen ;) So und nun gute Nacht
Projekt lebt. Momentan sind die Anforderungen an die Software aber sehr hoch, so dass ich eine Mischung aus C und AWL machen muß. SG Josef
Wie hast du es gemacht ? Ich fahre jetzt in AWL und C gleichzeitig auf 48 Atmegas 128CAN (Hausleitsystem). Konventionelles SPSen scheiden aus weil zu teuer und zu umständlich. Dazu noch Profilab als Steuerzentrale und Visualisierung mit E-Mail-Benachrichtigungen, Schreiber, TCPIP usw. Auf den AVR-CAN-Knoten laufen die SPS Macros im Programmcode mit C gemischt. Läuft alles sehr gut und stabil. Schöne Grüße Josef
Wie habe ich es gemacht... Nun ja, ich habe mir einen recht primitiven Token Parser geschrieben (um ehrlich zu sein mehrere, da sie nie so ganz das machten, was ich wollte) aber das war nicht so erfolgreich, warum ich anfing (auch mehrere) Byte Interpreter zu schreiben. Aktuell läuft kein einziger, aber ich will wieder (einmal) neu auf Basis eines Byteinterpreters ansetzten. Diesesmal auch mit Funktionsblöcken, die mir bislang noch recht große Probleme bereiteten. Zusätzlich will ich die Hardware möglichst abstrackt halten, um mich nicht auf einen Mikrocontroller festzufahren. Aber was hast du weiterhin gemacht? Bist du bei blanker Bitoperation geblieben, oder hast du auch BYTE oder (D)WORD Operationen implementiert? Darf ich dich eventuell um einblick in den code bitten?
hi hoffe das liest noch irgentwer ich hab das hier gelesen und möchte einen vorschlag machen für einen Interpreter wie wäre es diesen ungefähr so zu realistieren 4 byteblöcke von irgentwo lesen z.B. Flash EEPROM oder ner SD Karte if abragen: ist das 2te zeichen M0 dann ist *ziel = M0 *ziel ist ein zeiger auf eine andere Variable wenn das zeichen A0 ist dann *ziel = A0 ..... 3tes und 4tes byte in 16 bit variable (wert) schreiben if abfragen: ist erstes byte U => aufruf unterprogamm U ( *zeit,wert) .... man müsst halt für jede variable und jede funktion eine if abfrage machen aber man könnte das vorhandene programm nutzen das ganze leuft dann in einer schleife die dann immer die nächsten 4 byte liest und verarbeitet was haltet ihr davon? mario
Hallo, Habe hier einen MC5 (Step5) Interpreter der bis auf Substitution (xyz=) fast komplett ist. Bei ernsthaftem Interesse an einer Mitarbeit (ist in C geschrieben braucht auf einem AVR derzeit ca. 14K Flash + 200 Byte Ram / pro MC5 Anweisung gehen bei 8MHz ca. 20uS drauf) dann meldet euch. Die Quellen hier zu veröffentlichen macht noch keinen Sinn, dazu ist das Teil noch nicht genug getestet. Aber wie gesagt bei Intresse an einer Mitarbeit meldet euch. MfG
Hi, ich hätte Interesse. Wie genau stellst Du Dir eine Mitarbeit vor ? Ich könnte einige Tests durchführen , da ich eine SPS Hardware schon aufgebaut habe. (AVR + MCP2515 CAN-BUS) Zur Zeit habe ich die Steuerung direkt in C programmiert, aber das soll in Zukunft auch mit Interpreter laufen. Würde mich über eine Rückmeldung freuen. Gruß Sven P.S.: mail sven.kasemann äat web DOTT de
Hallo,
> ich hätte Interesse. Wie genau stellst Du Dir eine Mitarbeit vor ?
daran rätsele ich auch noch rum.
Ein Interpreter alleine nützt nichts, er braucht ein Zuhause. Dieses
wäre eine virtuelle CPU (Verwaltung des SPS Programms, Bereitstellung
der Peripherie Abbilder usw.) Diese CPU wiederum wohnt in einem
virtuellen AG, das dann die Ansteuerung der Hardware übernimmt. All
diese Dinge sind in Software zu erledigen. Hier kann man Schnittstellen
definieren um die Aufgaben zu verteilen. Eine dicke Frage stellt sich
jedoch: wie koordiniert man das Ganze.
MfG
Nachtrag: kennt jemand einen Step5 Assembler oder irgendetwas mit dem man aus einer *.s5d Datei Bausteine extrahieren/generieren kann so das diese im Binärformat vorliegen? Das rumwühlen in den Operationslisten zur Erstellung von Testprogrammen ist doch sehr mühsam. MfG
http://www.ulrich.perwass.de/upsps4/upsps401.htm Ich kenne mich nur rudimentär mit der SPS aus. Allerdings gibt es meiner Erinnerung nach Simulationssoftware deren Daten auch exportierbar sind.
Angehängte Dateien:
-
SPS.JPG
53 KB
Hallo, ein Virtuelles AG könnte in etwa so (Anhang) in Module aufgeteilt werden.
Hallo zusammen Ich bin gerade dabei mir in C diverse Routinen zusammenzustricken um SPS-Basisfunktionen (Blinken, verzögertes Ein-/Ausschalten, RS-FF, usw.) auf einem µController nachzubilden Dazu würde ich mich gerne von bereits Vorhandenem inspirieren lassen - bin für jede Art von Info, Source usw. an wt@trotek.de dankbar Servus Walter
"Dazu würde ich mich gerne von bereits Vorhandenem inspirieren lassen - bin für jede Art von Info, Source usw. an wt@trotek.de dankbar" a) s. oben - Simulator b) Ich könnte mir vorstellen dass ein Atmega32 in seinem 1k EEROM locker genug Platz hat um SPS-Code für Interpreter zur Verfügung zu stellen. Und dazu 1 bis 1,5k RAM zum editieren. Ein Atmega32 mit Bootlader und SPS-Firmware, die einfache & veränderbare SPS bearbeitet wäre recht universell verwendbar. Vielleicht interessant auch eine Kopplung mit AVR NET-I/O damit jenes Board 'selbständig' kleine Aufgaben erledigen kann.
Also ich finde dieses Projekt sehr interessant. Angeblich kann man das Steuerprogramm als C-Quellcode ausgeben lassen um ihn dann in sein C-Programm einzufügen. http://www.cq.cx/ladder-de.html
also ich wollte mal nachfragen ob man das programm eigentlich nun irgendwo bekommen kann?
Ja! Ich weiß! Der thread ist schon über ein Jahr alt. Aber ich frage trozdem ;-) Gibt es eine Aktuelle weiterentwicklung davon? Ich beschäftige mich gerade Privat mit Automatisierungstechik und da ich keinen Geldschisser im Keller sitzen habe, suche ich eine günstige alternative. Und die hab ich ja wohl hier gefunden :D MfG RaZoR
Hallo, evlt. hilft dir auch der folgende Beitrag... Beitrag "MySPS: SPS mit ATmega8/16/32" Gruß Stefan
Als Anwender S 5, S 7 und aber open-source-Begeisterter habe ich folgendes hinzuzufügen: ich fände es sehr interessant, eine lizenzfreie SPS zu haben, aber das Projekt ist für einen einzelnen, vielleicht als Wochenend-Bastelei einfach zu groß. Um Industrie-fähig zu sein wird folgendes gebraucht: Software: 1. PC-Programmierung in KOP, FUP, AWL. Im Studium damals sagte mein Prof: Die Ingenieure programmieren in AWL, Facharbeiter in FUP, und wer in KOP programmiert kann ich gar nicht ausdrücken. Meine Praxis ist aber, daß ich das Programm auch nachts um 3 an der Maschine in 5 Meter Entfernung zum PC (online-Betrieb) noch lesen kann. Das ist bei langen Listen von o on o u un( undsoweiter nicht der Fall. Für mich (und international) ist KOP (ladder-logic) sehr wichtig, FUP kann auch wichtig sein und AWL nur für Wort-Verarbeitung. Eventuell könnte der PC das in C übersetzen, dann über avr-gcc. Sollte aber alles in einer IDE zusammengefaßt werden. 2. Unbedingt nötig ist, Merker online auslesen oder Programm online anschauen zu können. Das heißt, die Verbindungen in KOP,FUP markieren sich farblich, wenn dort eine "1" ist. Damit kann man die Initiatoren der Maschine beobachten, Zwischenergebnisse und die Schaltausgänge. 3. Unbedingt nötig ist, bei laufender Anlage das Programm ändern zu können. Da ist dann nix mehr mit ISP-Schnittstelle. Ich meine das echt so, daß die SPS die Maschine steuert und gleichzeitig eine neue Programm-Version runtergeladen wird, die dann übergangslos weiter verwendet wird. Das bedeutet: Der Programm-Speicher ist in Segmente aufgeteilt, die jeder ein Teil aufnehmen können (OB, PB, FB). Bei einer Änderung schreibt der bootloader das neue Programm in einen freies Segment, und ruft es im nächsten Zyklus anstatt des alten auf. Das heißt, daß die Programme so übersetzt sein müssen, daß sie in jedem Segment laufen können (nur relative Sprünge). Letztlich weiß der PC beim Übersetzen nicht mehr, in welchem Segment das Programm läuft, das entscheidet der bootloader selbständig. Genauso ist, daß die Daten-Adressen bei der Programmeingabe fest eingegeben werden müssen (Zuordnungsliste), der Compiler darf die Variablen nicht verschieben. Denn nach einer Programm-Änderung muß der Zustand der Zähler, Zeiten und Merker genauso weiter behalten werden. Stelle Dir vor, das Werkstück ist halb bearbeitet, Anpreß-Zeiten müssen trotz Programm-Download eingehalten werden. Manchmal ist es ein längerer Prozess mit viel Ausschuß, an einer Maschine einen Kaltstart zu machen. Und wenn Du einen Bottich voll Chemie-Suppe hast, kannst Du den auch nicht einfach mal so auskippen, weil der Herr Programmierer das so wünscht. "Echtzeit" braucht nicht schnell zu sein, muß aber immer die benötigte Reaktionszeit garantieren. 4. Es müssen vom Betriebssystem Zeit-Bits zur Verfügung gestellt werden. Ich setze ein Bit und mit einer Einschaltverzögerung von x (x= 20ms .. 600 s) wird das Ausgangs-Bit nachgeführt. In der Bit-Verarbeitung könnte es für den AVR gut sein, die Verknüpfungen byte-weise zu tun. also Eingang "1", das Betriebssystem macht daraus "char merker = 0xff", Eingang "0" wäre "char merker = 0x00". Ist eine Verschwendung von je 7 Bit, aber scheint mir dann ein besseres Assembler zu geben. SPS haben eigentlich einen Spezial-Prozessor als ASIC. Das kann man hier in GNU-Lizenz nicht haben. Auch ein FPGA würde das zu sehr verkomplizieren. 5. Bei Zykluszeit-Überschreitungen oder anderen Notfällen ist fail-safe Verhalten notwendig. Also alle Ausgänge aus. 6. Vorhandene PC-Umgebungen (codesys und andere) sind wahrscheinlich kostenpflichtig. Aber wenn sie nicht open source sind, ist hier keine Erweiterung oder Anpassung möglich. Da wird man dann unter GNU-Lizenz neu aufsetzen müssen. 7. PC-Software auch unter Linux, sonst mache ich nicht mit :-) Hardware: 1. Hardware skalierbar. Natürlich sind da jeweils verschiedene Betriebssystem-Varianten nötig. a.) ein ATm8, entsprechend vielleicht einer S7-Logo, b.) ein ATm644 entsprechend der S7-200 und c.) noch was größeres entspr. S7-300. Weiter mag ich nicht denken. 2. Ein-ausgabe-Erweiterungen bei a.) parallel, b.) und c.) ein serieller Rückwand-bus. Analog-E oder A, eventuell auch Module mit eigener CPU wie Schrittmotor-Treiber. Layouts natürlich auch auf GNU-Lizenz. Wenn Hersteller dann Leiterplatten, oder Bausätze oder Fertiggeräte verkaufen, solls recht so sein. 3. Digitale E/A mit Optokoppler, 24V plusschaltend, Ausgänge kurzschlußfest, jeweils mit LED. vielleicht auch eine Variante mit 230VAC und Relais. In USA hat man gern minusschaltend. 4. Programmierschnittstelle für den Anfang über USB-seriell Adapter, wahlweise auch FTD232, vllt auch soft-USB im Betriebssystem. 5. Visualisierung: Textdisplays wie 2x16 Zeichen mit Tasten müssen anschließbar sein. Die brauchen eigene CPU. Das display schaut in die SPS und holt sich die Parameter, oder setzt die Bits der SPS, die in seinem eigenen Projekt benannt sind. Natürlich muß es auch eine PC-Software geben, die die Gestaltung der Texte ermöglicht. Grafiken, Farbe, Touchscreen sind bei c.) üblich. 6. bei c.) ist auch an Erweiterungskarten für Bussysteme wie ASi, Profibus, Interbus zu denken. Da gibt es dann wahrscheinlich Lizenzgebühren, den Zeit-Aufwand mag ich nicht einschätzen. Projektmanagement: 1. das wird wohl nicht einfach als Thread hier ablaufen können. Vllt über yahoo-workgroups. 2. Doku wird auch gebraucht, für den Anwender, in verschiedenen Sprachen. 3. auf jeden Punkt wären mehrere Entwickler anzusetzen, damit es nicht einschläft. 4. ein Ober-Aufpasser ist nötig, der den Freiwilligen bei Bedarf die Seele streichelt. Schluss. In diesem Stil könnte ich mir vorstellen, daß eine GNU-SPS Entwicklung Erfolg hat. Man kann klein anfangen, sollte sich aber bewußt sein, daß im Lauf der Zeit alles beisammen sein muß. In DE wird der Erfolg wohl bei Bastelprojekten in der Berufsausbildung(Betrieb) beginnen, an kleineren Automations-Vorrichtungen dann in die Produktionssteuerung eingesetzt. Wie man den Aufwand leisten kann, weiß ich aber nicht. Und mit weniger Leistung wird wohl kein Erfolg da sein. Im Niedriglohn-Ausland denke ich, kommt eher der Einsatz. Andererseits gibt es auch ein Linux, das auf freiwilliger Basis entstand und dasselbe leistet, wie ein milliardenschweres Produkt eines anderen Herstellers. (mir fehlt nichts). also, klein anfangen ist gut. Ein interessanterer Einstiegspunkt ist aber, einen bootloader zu modifizieren daß auch Programm-Download in die laufende Maschine erfolgen kann. Die Sprache ergibt sich dann von selbst.
Hi, bin durch zufall hier drauf gestoßen. Also ich hab auf basis des STM32F407 eine industrielle Steuerung mit Ethernet, 24V galvanisch getrennte 8DE/16DA und 12bit 6AE, 2AA entwickelt. Ertweierungsmodule werden per CAN oder Modbus angeschlossen. Ja hab sogar ein Anybus Modul dran mit dem ich das Profinet und Profibus realisere. Programmieren tue ich es aber momentan in C/C++. Ich hab jetzt mal angefangen eine Abstraction Layer zu schreiben mit der man dann mittels C# Programm sein "logischen Ablaufplan" in FUP erstellen kann. der generierte Code kann dann aufs externe Flash geladen werden. Ich bin gerade dabei ein HMI dafür zu bauen und selbstverständlich muss am FUP Programm-Editor noch weiter gemacht werden und wird dann in einem Task abgearbeitet (RTOS). Wobei ich jetzt schon die Idee austeste die SPS via Webinterface (HTML5 & CGI) programmierbar zu machen, dann braucht man keine Software außer man "ver-flasht" sich. Falls da jemand lust drauf hat mir unter die Arme zu greifen, ich bin 27 Jahre alt und hab leider wie Ihr auch nich viel Zeit um das nebenher offen für alle zu machen. Das PCB ist übrigens in der neusten Revision letztens durch den "TÜV :-)" gekommen also EMV technische Zulassung. Die Selbsttestroutinen von ST sind auch integriert und der Prüfer war glücklich mit. BTW: Ich glaube kaum das jemand das einfach mal GNU open source macht, wenn da zuvor 500 Stunden arbeit investiert wurden. Irgendwie sollte man schon entlohnt werden. In den aktuellen Siemens Steuerungen sitzt ein TI drin, dort läuft die Step7 Runtime. Bei Beckhoff sitzt irgendwas drin, wo wiederum die CoDeSys Runtime instlalliert ist. Die runtime kostet Geld für den hersteller. Die Codesys Software nicht. Es gibt auch Speed7 Chips mit denem man dann via Step7 Programmieren kann.
Vielleicht wäre auch das eine Alternative zur SPS: http://www.elektronik-labor.de/Lernpakete/TPS/HandbuchTPS.htm Es gibt hier im MC-Netz auch einige AVR-Derivate.
Wir reden hier von Interpreter bzw. Parser. @Autor: chris (Gast) : Kennst du dich mit der Materie des TO aus?
@chris ... ich programmiere parallelisierte anwendungen auf nem arm cortex und will ein SPS Parser entwickeln ... wie kann mir jetzt dein Franzis Lernpaket dabei helfen? "Verwendung von Schraubklemmen Zur Verbindung mit externen Baugruppen wie Leistungstreibern, Relaistreibern oder Optokopplern können auch die Pfostenstecker verwendet werden, wobei wahlweise gerade oder gewinkelte Typen eingesetzt werden können." OHH ich sehe ;)
@Ersan G. : Kannst du mal einige Fotos deiner Platine mit/ohne Gehäuse posten? Währe sehr interresant.
Angehängte Dateien:
-
bild1.JPG
72 KB
Hi, ja hier haste eins, werde aber keine Detailbilder hochladen. Die Platine hat kein eigenes Gehäuse sondern sitzt in einem Spritzwassergeschützten Schränkle. Sorry wegen den Farben, hatte noch nen Filter an. Wie gesagt, man könnte auch gerne in Form einer Kooperation zusammen dran arbeiten, das Derivat mit aktuellen Prozesser (2MB Flash und 180mhz) ist noch bei der Bestückung. Ich hab jetzt noch Profinet, Profibus-DP und EtherCat via seperater Aufsteckplatine integriert. Leider ist das externe Flash zu klein mit 4Mbyte, muss in jedem Fall noch ein zusätzliches SPI Flash mit mind. 64MB dazulegen, die Daten des Webserver passen sonst nicht drauf. VG.
Währe doch schön, so ein Projekt OpenSource zu machen, oder? Dann kann jeder weiterentwickeln, und eine Sammelbestellung von Platinen,usw würde über dich laufen. Dann würde deine Arbeit auch entlohnt.
Hi, gerne kann das bestückte und getestete PCB über mich bezogen werden, samt einfachen Schaltplan und Projektdatei für Eclipse/Anleitung. EAGLE Layout und PCB Design würde ich nicht rausgeben weil es einfach nicht nachvollziehbar ist wer es dann einsetzt. Die open source License müsste so ausschauen das aber wirklich alles OpenSource bleibt falls es auf dieser Plattform läuft. Oder was meinst du?
@Ersan G. : Welcher Prozessor wird da verwendet? In welcher Sprache wird "das Teil" programmiert? Grafisch?
ek13 schrieb: > Vor ein paar Jahren hieß das bei PIC's >Parsic< und das war > ähnlich > super genial > Gruß Für alle die Parsic geliebt haben: etwas ähnliches mit fertiger Hardware incl Modbus TCP und einer Webfront ist Pokey57E. Das Potential ist nicht so ohne weiteres zu erkennen ;-) http://www.poscope.com/pokeys56e Man muß sich die PotBlock Software dazu in den µP und PC laden, simulieren geht zwar nur mit der Hardware, weil online, aber man kann die Leistungsfähigkeit schon erkennen. http://www.poscope.com/productattachments/index/download?id=81 Einiges an Infos steht hier: http://www.ip-symcon.de/wiki/Hardwarenews-Liste Bei Fragen dazu: mit 1Wire, PWM, analoge Sensoren, I2C, Modbus TCP und anders, auch im IPSymcon-Forum stehen Tipps. Gruß Helmut
Stm32F4 und in ner neuen Version ein Ti Am335x Zum programmieren gibts noch keine Software die wollte ich ja webbasiert machen oder mit QT.
Hab grad den Code von Josef auf einen STM32F103 portiert. Läuft wie'd Sau nach nicht mal 1 Stunde. Wau! Einfach und gut. Thanks!
Na, dann wäre es sehr nett, wenn du die STM32F103 Version hier hochladen könntest. Dann hätten evtl. andere auch was davon.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.