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?
@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 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!
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
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
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.
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
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
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.
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
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
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.
@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 ;)
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?
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
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang