mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MINI-SPS mit AVR od. ARM


Autor: Peter Buchta (pebu66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Allerseits!

Wer von euch hätte Interesse, an einem Arbeitskreis MINI-SPS?

Diese sollte diverse Schnittstellen besitzt (Ethernet, RS485, USB, ...)
jedoch ohne direkten I/O's. Diese I/O's (PT1000, 0..10 IN/OUT,
Digital-Input -Output, ...). Diese werden über bereits vorhandene
Feldbusgeräte realisiert.

Die Programmierung der MINI-SPS müsste generell über einen FUPLA
erfolgen, denn wer einen Stromlaufplan lesen und zeichenen kann, kann
dann auch diese SPS programmieren - ist nun mal so *gg

Abschlißend möchte ich nur noch sagen, das wenn es möglich ist, ein
Betriebssystem wie Linux auf diese Art und Weise auf die Welt zu
bringen, dann muß es doch auch möglich sein, so eine kleine MINI-SPS
zusammenzubringen.

Würde mich freuen, wenn daran reges Interesse bestehen würde.

Besten Dank vorab Peter

Autor: Christoph Wagner (christoph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Idee. Ich bin zwar noch in der Ausbildung, hätte aber schon
Interesse.

Autor: Quark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

als Anregung, fals noch nicht bekannt:

http://www.mikrocontroller.net/forum/read-4-62596.html

Grüße

Quark

Autor: Der Elektrische Reiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein SPS/OS darauf warte ich auch schon lange. Ich schlage vor, das wir
zuerst hier im Thread die eine oder andere Idee sammeln sollten. Daraus
lässt sich dann die Hardware sowie die Software für die eigentliche SPS
als auch für das Programmiergerät definieren.

Da wir nicht an Hersetllervorgaben gebunden sind, können auch so
"Schmakerl" herauskommen wie "Programmieren mit dem PDA via
Blootooth" usw.

Wiw wär's?

cu

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fände das Projekt auch sehr interessant. Würde mich v.a. bereit
erklären, C-Code für den AVR sowie C++-Code für die PC-seitige
Programmiersoftware zu schreiben (hab mit PCB-Layout etc. weniger
Erfahrung).

Zu klären wäre erst einmal, was_ wir überhaupt _genau haben wollen.

Ich dachte dabei anders als beim oben verlinkten Projekt an einen
2-stufigen Interpreter: Der PC übersetzt den FUP bzw. den AWL-Code in
einen Bytecode und überspielt ihn ins EEPROM, von wo er vom AVR
interpretiert wird.

Begründung: So'n Bytecode-Interpreter kann ja mittels Sprungtabellen
etc. recht schnell werden, und bei typischen Steuerungsaufgaben kommts
auf die msec nicht an. Und nur so kann man (später) Schmankerln wie
Programmieren im laufenden Betrieb, Debuggen (Variablen beobachten oder
forcen) etc. einbauen und ist bei der Programmierung nicht auf die
üblichen Schnittstellen (ISP) angewiesen (s.o. "Programmieren über
Bluetooth").

Außerdem können wir so erst einmal eine Programmiersoftware zur
Verfügung stellen, die AWL in Bytecode übersetzt, und später (wenn
alles Wichtigere geht) auch FUP und/oder KOP unterstützen, was dann nur
noch eine Feature-Frage der Programmiersoftware ist, genauso wie eine
Portierung auf den PDA.

Natürlich können wir auch mit FUP anfangen, wenn anderen es wichtig
erscheint. Ich persönlich programmiere SPSen halt grundsätzlich in AWL,
weil bei mir im Betrieb eine interne Richtlinie dies vorschreibt, und
privat macht man nun einmal das, was man gewohnt ist. (Ich würde das
bei diesem Projekt herauskommende Gerät übrigens rein privat
verwenden.)

Ich will zwar (denke ich) wohl kein Konkurrenzprodukt zur S7
aufstellen, aber dies sind ja gerade die Features, die das
Automatisieren mit SPSen so angenehm machen, die sollten wir uns nicht
von vorneherein verbauen (das würde mich am von Quark verlinkten
Projekt stören).

Wichtig fände ich auch das freie "Mappen" z.B. von über CAN
angeschlossenen Geräten auf Eingangs-/Ausgangs-Adressbereiche sowie
die Organisation in Funktions- und Datenbausteinen (damit man modular
programmieren kann).

Die Idee mit Bluetooth fände ich super, v.a. für die
Heimautomatisierung. Zur genauen Schnittstellenausstattung kann ja
jeder mal seine Wünsche äußern.

Falls meine Vorstellungen mit euren einigermaßen übereinstimmen, wäre
ich dabei. abo

Autor: peter (pebu66) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo und danke vorerst einmal für euer interesse!

also meine frage in diesem forum kommt nich von ungefähr, denn ich habe
in letzter zeit einige anforderungen aus der industrie zu diesem thema
bekommen (oem-lösungen).

grundsätzlich hätte ich folgende vorschläge:

prozessor:      atmel AT91RM9200
flash:          min. 4mb erweiterbar bis 16mb
ram:            min. 1 mb erweiterbar bis 4mb
schnittstellen: 1x RJ45 für ethernet (tcp/ip, webserver, ...)
                1x USB 2.0 für prog.download
                2x rs854 bzw CAN-bus2.0 als modulbauform steckbar
                ...
gehäuse:        ts35-montage und 45mm-system (lichtverteilereinbau)

zur prorammierung der sps war meine grundüberlegung, auf eine
bestehende software wie z.b. codesys von 3s-software zurückzugreifen.
die können bis auf opcod ebene des microcontollers compilieren und
erfüllen die einschlägigem normen, was die programmieroberfläche
betrifft. vorallem ist jede software, die auf einem pc laufen soll sehr
aufwendig in betreuung - vorallem microsoft basierende pc's, und die
sind nach wie vor leider in der überzahl!
natürlich bin ich neuen lösungen immer aufgeschlossen, denn alles was
hier entsteht, auch wirklich praxisbezogen ist - meistends jedenfalls
;-)

lg
peter

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 1x USB 2.0 für prog.download

Klingt akzeptabel, Programmierung sollte aber auch über Ethernet (oder
wie vom Elektrischen Reiter angesprochen Bluetooth) erfolgen können,
damit man später im Betrieb nicht jedesmal mit dem Laptop zur SPS
rennen und ein USB-Kabel einstöpseln muß, wenn man was debuggen oder
eine Änderung einspielen will. USB oder so etwas ist dann natürlich
trotzdem nötig, um z.B. die IP-Einstellungen bzw.
Bluetooth-Einstellungen zu machen (wenn die SPS eben noch nicht am Netz
hängt) und z.B. ein vergessenes Programmier-PW zurücksetzen zu können.

> 2x rs854 bzw CAN-bus2.0 als modulbauform steckbar

Macht auch Sinn, aber apropos: Was nehmen wir als
Kommunikationsschnittstelle zwischen steckbaren Modulen?

> gehäuse:        ts35-montage und 45mm-system (lichtverteilereinbau)

An so etwas habe ich auch gedacht.

> vorallem ist jede software, die auf einem pc laufen soll sehr
> aufwendig in betreuung - vorallem microsoft basierende pc's

Das kommt ganz darauf an, wenn man das Windows-API "sauber" nutzt und
alle verwendeten Libraries statisch linkt, kann man durchaus EXE-Files
erhalten, die ohne Installation laufen und von NT4 bis XP durchgehend
verwendbar sind.

Ich kenne die von dir (peter) angesprochene PC-Software nicht, aber:

1. Was kostet die? (Da wohl einige, mich eingeschlossen, was für den
Privatgebrauch suchen, ist das nicht ganz unwichtig.)

2. Was kann die, bzw. wie erweiterbar ist sie? Sind damit die erwähnten
Schmankerln (Programmierung vom PDA, via BT, via Ethernet, Debugging)
realisierbar?

Woran ich mal kurz gedacht habe, ist, ob wir unsere Hardware nicht
kompatibel zum Step7-Paket machen können.

Vorteile:
1. Vorhandene PC-Software
2. Features ohne Ende: wenn wir im Laufe der Zeit Features wie
Programmierung per Ethernet, Programmierung im laufenden Betrieb,
Debuggen etc. im Gerät nachrüsten wollen, kann die Software das schon;
wir entwickeln also hier nicht so schnell in eine Sackgasse.

Nachteile:
1. Man müßte prüfen, ob "Features ohne Ende" nicht auch heißt, daß
wir alle diese Features auch gleich von Anfang an implementieren
müßten, bevor es überhaupt mit Step7 zusammen funktioniert.
2. Auch nicht ganz billig

Die Frage ist auch, ob wir entweder etwas haben wollen, was
(1) möglichst schnell fertig ist und
(2) "die einschlägigem normen, was die programmieroberfläche
betrifft" (wie du es schreibst) erfüllt,

oder es um
(1) etwas selbstgemachtes geht, was
(2) diverse Schmankerln bietet, die nicht unbedingt Industriestandard
sind, und an dem man, wenn es funktioniert,
(3) jederzeit weitermachen kann (auch im Hinblick auf (2)), wenn man
gerade Zeit und Lust hat, weil man ja alle Sourcecodes etc. besitzt.

Ich tendiere zur zweiten Möglichkeit, vor allem da es mir ja um den
Privatgebrauch geht.

Autor: Der Elektrische Reiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Diskussion nimmt ja richtig Schwing auf...


Also wenn ich das richtig sehe, dann haben wir drei Baustellen vor
uns:

1. Die Zentraleinheit, die die SPS-Programme abarbeitet. Dabei greift
sie über ein oder mehrere Bussysteme auf weitere Hardware wie z.B. Ein
und Ausgänge zu. Weder die Hardware noch Software sind bisher näher
spezifiziert. Jedoch ist klar, dass wir eher was mit Wumms brauchen.
Ein Tiny oder ein MARC4 wird's wohl nicht werden. Die Zentraleinheit
kommuniziert über eine Reiche von Schnittstellen mit Ihrer Umwelt.
Z.Zt.: Ethernet CAN und rs854. Zur Programmierung ist USB und BT
vorgesehen.

2. Die Einrichtung zur Entwicklung der SPS-Programme. Ich denke hier
sind wir uns einig, dass dies außerhalb der Zentraleinheit passieren
soll. Bei kleinen SPSen (LOGO & Co.) ist das ja anders. Die Einrichtung
zur Entwicklung der Programme übersetzt die Programme in ein Format, das
die Zentraleinheit entweder direkt, oder als Zwischencode (ähnlich UCSD,
JAVA usw.) abarbeitet. Die (Quell-)Programmiersprache ist noch unklar,
Sollte sich aber an was bestehenden anlehnen, oder ein 1:1 übernehmen.

3. Die Peripherie, die alle Aktionen der Zentraleinheit in die reale
Wert überträgt. Stand der Diskussion: Keine Definition, jedoch
bestehende Komponenten sollten angesprochen werden werden können.



Ich hab' da noch ein Paar fragen und Anmerkungen:

Was ist „codesys“? Ist das frei verfügbar? Gibt es weitere ähnliche
Produkte? Benötigen wir was unter GPL? Was eigenes wäre schon schön,
doch wenn's schon eine prima Software gibt, die wir einsetzenen könne
– why not!

Wie werden die Aktoren (Punkt 3) angesprochen. Gibt es da offenen
Protokolle, oder nur proprietäres Zeugs? Aus meiner Sicht macht es Sinn
auf bestehende Module zurückzugreifen. Dadurch ersparen wir uns eine
Menge VDE, CE und sonstiger Prüfungen und Zertifizierungen.

Da wir keine „lokalen“ Ein und Ausgaben haben werden, sollten wir auch
über die Lösung durch einen Industrie-PC nachdenken. Diese Dinger haben
ordentlich Schnittstellen, sind einigermaßen schnell und robust. Was
meint ihr dazu?

cu

Autor: Peter Mahler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich würde mich eurem Projekt gerne anschliessen.

"codesys" ist eine SPS-Programier- und Runtime-Umgebung und
unterstützt die IEC1131-Programmiersprachen

IL Instruction-List,enspricht AWL
ST Structured Text, Hochsprachen-ähnlich
FBD Function-Block,
LD Ladder-Diagram Kontaktplan
SFC Sequential Function Chart
CodeSys ist selbstverständlich nicht frei!

Offene Protokolle
CAN : CANopen, CAL
RS485 : Modbus
Ethernet : Ethernet-Powerlink (Hardware)
Siemens L1

PC halte ich nur für sehr bedingt als SPS-Hardware tauglich.
1. Boot-Zeiten sind nicht SPS-tauglich
2. Kontrollierbares Herunterfahren des PC's ist bei den SPS'en
unüblich.
3. Pufferbares SRAM für remanente Werte nur umständlich zu realisieren
4. Direkte I/O-Zugriffe sind auf dem PC realtiv langsam.
5. PCI-Bus-Arbitrierung ist nicht deterministisch.

Mein Vorschlag wäre hier ein Philips-ARM7 LPC2xxx mit 1 bis 4
CAN-Bussen sowie lokalen I/O. Der hat genügend Rechen-Power und ist
sehr preisgünstig. Durch die verbreitete ARM7-Architektur ist man auch
nicht auf den eine Halbleiter-Hersteller angewiesen.

Für die Software würde ich als Basis ein kleines RTOS (freeRTOS.org)
einsetzen und darauf entsprechende SPS-'Betriebsysteme' aufsetzen.

Ich habe mal vor Jahren angefangen einen Tabellen-Interpreter für
Siemens S5-Programme zu schreiben. Mein Ziel war damals dass ich für
die S5 geschreibene direkt eisetzen kann. Auf der Steuerung läuft dafür
ein sogenannter MC5-Interpreter. Ich schau mal ob ich die Diskette
(...man glaubt es kaum) noch wiederfinde.

Gruss,

Peter

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaut man sich die größeren Steuerungen an, stellt man fest das diese
auch mittlerweile in Hochsprachen programmiert werden können.
Was spricht also dagegen, für die CPU einen Linux Minirechner zu
nehmen?
Die Dinger haben Ethernet, RS232 und alles andere in einem 40poligen
Sockel integriert und kosten auch nicht mehr so viel.
SPS Interpreter gibts für Linux auch und als Anbindung z.B. I2C
(Treiber existiert).

Programme lassen sich auch sehr preiswert in SDRAM karten ablegen.
Anschlußbeispiele und Bascom Code gibts dafür auch.

Sollte die Linux Variante nicht bevorzugt werden, könnte man auch die
Bascom IDE als Hochsprachenplattform nehmen. Billig (wenn nicht
umsonst) und hinterlässt recht guten Maschinencode.

Sollte das ganze tatsächlich zum Rollen kommen bin ich dabei!
abo

Autor: Peter Mahler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke wir sollten bei der Hardware nicht von vorne weg von dem einem
Linux-System mit mehreren hundert Megahertz ausgehen sondern zuerst mal
kleinere Brötchen von backen. Eine Portierung des ganzen auf grössere
Maschinen sollte eigentlich machbar sein.

Ich bin mir jedoch nicht sicher ob ein 8-Bitter wie AVR oder PIC als
Untergrenze herangezogen werden sollte, oder ob man sich nicht gleich
auf mind. 16-Bit als Untergrenze einigt.

Eine Überlegung wäre auch ob man nicht sowas wie den R8C/13 der dem
nächsten Elektor-Heft beiliegt als gemeinsame
(Referenz-)Entwicklungs-Plattform verwendet und parallel dazu jeder auf
seiner eigenen Wunschplattform arbeitet.

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Linux Semmeln sind fertig zu beziehen und haben schon ein
lauffähiges Linux on Board. Ethernet und das ganze Zeug alles schon
"on Chip".

Eine Atmelvariante wäre auch nicht schlecht. Allerdings muss man dann
die vielen Dinge wie TCP/IP usw alles erst noch drum herum bauen und
das verschlingt auch nicht wenig Sourcecode und damit Prom Platz.
Daher war meine Idee eher, etwas schon tickendes zu nehmen. Dann bleibt
auch mehr Zeit und Spass in den ganzen Gadgets.

Ich hatte mal eine Stempeluhr mit Subminiatur PC+Linux und eine auf µC
Basis gebaut. Die Linux Kiste war dem µC um Welten überlegen, vor allem
weil mit einem bisschen Software sofort erweitert werden kann.

Uwe

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo freunde!
also so einen tollen start hätte ich mir eigentlich nicht gedacht -
gefällt mir, wie ihr euch gedanken darüber macht.
eines was nicht außer acht gelassen werden sollte, sind die kosten!
jetzt werdet ihr euch denken - mensch, nicht schon wieder so einer,
aber ich denke das wir hier in österreich  und deutschland sehr wohl
das potential haben, gegen den fernostmarkt entsprechend auftreten zu
können. nur müssen einfach andere strukturen gefunden werden, um den
großen konzernen entsprechend entgegenwirken zu können. immerhin hängen
viele arbeiteitsplätze in zukunft an solch einer stategie.

ok - jetzt reichts aber - wollte euch nur den grund meiner bestrebungen
noch bekanntgeben.

was eventuelle bestückung und materialbeschaffung betrifft, ist das
grundsätzlich kein problem. kann alles über meine firma laufen, da ich
auch die entsprechenden feritgungseinrichtungen besitze.

eventuell sollte auch überlegt werden, wenn es wirklich zu einer
realisierung kommen sollte, wer was macht, denn sonst laufen wir der
gefahr, das jeder irgend was macht und keiner damit fertig wird.

also dann - auf zu frischen untaten ;-)
peter

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir sollten auch darüber einig sein, wo die SPS verwendet werden soll,
was der Ziel-'Markt' ist und in wie weit die Sicherheits-Aspekte
berücksichtigt werden müssen. Gibt es einen 'Markt', soll eine
Kommerzialisierung möglich sein?

Gruss,

Peter

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo peter (mahlerp)!
also der markt ist da - zumindest in österreich hätten wir für nächstes
jahr einen mindestabsatz (1 kunde) von ca. 700 - 1000 geräten in der
haustechnik (hkl). zusätzlich kommen noch die anfragen für
oem-lösungen, die ich derzeit noch nicht bewerten möchte. grundsätzlich
sollte aber von den vorschriften der industrie genüge getan werden, denn
wer weiß - vielleicht finden sich dort auch entsprechende anwendungen.
gruß
peter

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Aber das gleiche zu bauen, was Siemens, Mitsubishi, Omron usw. alle
haben ist auch quatsch!
Entweder das Teilchen lässt sich für sehr komplizierte Dinge nutzen,
ich denke da an Hochsprachenprogrammiereung, oder aber für für kleine,
einfache Anwendungen, also preiswert aber nicht billig.
Das ganze sollte modular sein und per Bus erweiterbar.

Im übrigen steht ja beim richtigen Buslayout weder der einen noch der
anderen Lösung etwas im Wege. Die kleine CPU mit einem Atmel z.B. für
die "Billig"-lösung, die Linux-Variante für den "Power"-User.

Wer hat Erfahrung mit Bussystemen? Könnte der CAN für unserer
bestrebungen herhalten oder sind die Schnittstellen ICs zu teuer?

Vielleicht sollten wir hier mal sammeln, was für Erweiterungskarten wir
so bräuchten:
- Analogeingang (einfach oder isoliert)
- Analogausgang
- Binäreingang
- Binärausgang
- Temperaturerfassung
- Anschaltbaugruppe für Ethernet (oder integriert?)
- HMI Interface. (Für 128EUR gibts schon nette LCD mit Touchpad und
I2c)
- Leistungsbaugruppe (dicke Relais)
- Phasenanschnittbaugruppe für Wechselstrom /Drehstrom
- ...

Welche Gehäuseform wird gewählt?
- Norm C-Schiene ?
- Bopla
- OKW
- Phönix
- ...

Minimaler Befehlsvorrat
- UND ODER XOR NOT
- TIMER, COUNTER, RS-Glieder
- Vergleicher >,=,<, >=,<=
Mit Analogwertverarbeitung
- *, /, +, -

Eine vernünftige IDE muss her

Eine Möglichkeit wäre auch, für die Baugruppen Libs zu schreiben, die
man in Bascom integriert. Dann hätte man schon vieles zum Entwickeln
und sogar die µC Version wäre in einer "Hochsprache" programmierbar.

Gruß
Uwe

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo uwe!
also folgende feldbusgeräte mit rs485 schnittstelle sind bereits fertig
und laufen auch schon in größeren stückzahlen. busprotokoll derzeit
saia-sbus wird aber im moment um modbus rtu erweitert.

ts35-Montage
- 4x pt1000
- 4x pt1000 / 3x0..10V in / 3x 0..10V out
- 3x 0..10V out  mit/ohne notbedienebene
- 6x dig.in 24VDC / 3x dig.out pot-frei 6A/AC1 mit/ohne
     notbedienebene
- 8x dig.in 24VDC
- 4x dig.out 16A/AC1 mit/ohne notbedienebene
Diverse
- diverse auf-/unterputz raumfühler mit und ohne diplay

die gehäuse für die ts35 montage sind okw-railtec-c gehäuse. diese
linie möchte ich wenn geht beibehalten.

für die bedienebene setzte ich derzeit hakko-touchpanele ein, die über
eine rs232- bzw rs485-schnittstelle mit den sps'n kommunizieren. diese
sollten wenn geht auch in zukunft eingesetzt werden können - große
auswahl an größen, farben, speicher, ...

für die programmierung und aufbau finde ich den beitrag vom
mechatroniker recht gut, zudem er den s7 befehlssatz recht gut kennt.

in diesem sinne einen schönen abend
peter

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde den Bytecode der Siemens S5 als Basis für den SPS nehmen.

Vorteil :
+ Gut dokumentiert, findet man in jedem S5 Handbuch
+ relativ leicht zu implementieren auch auf sehr kleinen µC
+ Speicherbedarf ab ca. 4K RAM
+ Möglichkeit bestehende SPS-Programme (*s5d-Dateien) direkt zu
verwenden
+ grosse Akzeptanz, da im deutschsprachigen Raum wohl die meistgenutzte
SPS-Progr.-Sprache
+ preiswerte fertige Programmiertools z.B.
+ Dokumentierte Visu-Schnittstelle 3964R/RK512
http://www.mhj-software.com/de/WINSPS.HTM
Nachteile
- Online-Protokoll AS511 nicht offen
- veralteter Befehlssatz, kein IEC11631

Der Funktionsumfang einer kleinen S5 (90U) könnte u.U auch in einem
Atmel AVR untergebracht werden.

Der Byteinterpreter könnte auf kleinen µC Standalone, und auf den
Power-Maschinen als Thread neben Hochsprachen laufen. Einsprungpunkte
in selbstgeschriebe Assembler/Hochsprachen-Funktionen sollten auch auf
der µC Variante machbar sein.

Nicht vergessen dürfen wir, dass u.U. ein Update von Programmteilen im
laufenden Betrieb möglich sein sollte.

Als Bussystem würde ich auf jeden Fall CAN mit CANopen als
Transport-Schicht implementieren.

Bleibt noch die Frage nach einem internen Bus-System für direkte
I/O-Zugriffe. Dort würde ich SPI gegenüber Adress-/Datenbus vorziehen.

Autor: dose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Hat richtig Schwung bekommen.

Wichtig ist wie schon oben gesagt. Es sollte nicht an der
Rechenleistung gespart werden. Deshalb ist der ARM der Geeignetere.
Nächste Frage nimmt man ein fertiges Board und beschränkt sich auf eine
Softwärelösung oder entwickelt im dem Projekt noch Hardware.
Persönlich finde ich das digi ConnectCore 9C sehr interessant.
http://www.digi.de/products/embeddeddeviceservers/...
Und as noch für eine Sps sehr wichtig ist ein Real Time Betriebssystem.
Da gibt es für die freie Verwendung nur eine begrenzte sinnvolle
Auswahl. Am weitesten entwickelt ist das ECOS von Redhat.

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

was die Hardware-Plattform angeht, bin ich der Meinung, dass man nicht
von vorne weg auf die Dampfschiffe setzen sollte. Das kommt von ganz
alleine wen so ein Projekt einen gewissen Umfang erreicht.
Mein Ansatz wäre dass man sich ein paar Referenz-Plattformen aussucht
und auf diesen erste Versuche macht und den Code dabei portabel hält.

Beispiele :

Philips LPC2xxx ARM7
Atmel SAM ARM7
StrongARM/DILNET-PC
Motorola HCS12
Motorola 68K
Motorola Coldfire
Motorola MPC5x5
Atmel AVR z.B. Atmega128 (8K) AT90CAN, o.ä.
BECK-ipc@chip
X86-PC
....
....

Als Hardware-Plattform würde ich für den Anfang  möglichst weit
verbreitete EVAL-Boards als Entwicklungs-Plattform hernehmen, so z.B.
die Olimex-Boarsd LPC2106 für den LPC-ARM, oder das HCS12-T-Board von
Elektronikladen.

Die Anforderungen an ein Betriebsystem sollten so gering wie möglich
gehalten werden, um das ganze möglichst portabel zuhalten.
Um ein gewisses Set von OS-Funktionalität wird man jedoch herumkommen,
gerade wenn es in Richtung Busse oder TCP/IP geht
Hier wären zu nennen :
Threads (und/oder Prozesse)
Semaphore
Mutexe
Message-Queues

Beispiele für portable Implementierungen : uC/OS2, freeRtos

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo peter
meine erste überlegung bezüglich prozessor ist aus dem grund auf den
atmel arm7 at91rm9200 gefallen, da der alle notwenigen (und
mehr)schnittstellen bereits inkludiert hat. somit erübrigt sich der
ganze aufwand rundherum - ein keks für alles oder den großteil
zumindest.
zudem ist er ein 32bit prozessor mit einer recht guten rechenleistung,
für den fall, das es doch einmal ein etwas größeres programm werden
sollte.
lg
peter

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

der Prozessor ist ein ARM9 und spielt meiner Ansicht nach in einer ganz
anderen Liga. Ich sehe den im Vergleich zu einem Coldfire. Die 16K RAM
die der Prozessor On-Board hat werden dir nicht weit reichen, so dass
du recht schnell mehr externen Speicher benötigst. Gleichzeitig fehlt
sowas wie z.B. ein CAN-Bus.

Du wirst nicht umhin kommen recht viel Peripherie zu verbauen, bzw.
gleich ein vorgefertigtes Board verwenden. Ich vermute das sich es bei
dem Synertronixx-Board um diesen oder einen ähnlichen Prozessor
handelt.

Ich habe die Befüchtung dass du dann in einer Preisliga spielst, wo du
im Wettbewerb mit den sogenannten 'Profis' bist. Diese bieten zwar
meist wesentlich weniger Performance, haben jedoch ein abgerundetes
Produktportfolio, von dem wir noch weit entfernt sind. Ich würde dabei
auch nicht Siemens als Maßstab nehmen, sondern eher die kleineren
Hersteller wie z.B. B&R, (...aus deiner österreichischen Heimat) die
leistungsfähige Steuerungen ab einer Preisklasse von 200.-anbieten.


Gruss,

Peter

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@pebu66:
OKW Gehäuse ist eine gute Wahl weil sehr stabil und Super-Service.
Ich nehme an, das du deine Module nicht dieser Community zur Verfügung
stellen möchtest oder doch?

@mahlerp:
Beschränkt man sich bei der Diskussion mal auf das µC Board bzw.
einfachen IEC Code, dann braucht man auch nicht wirklich viel
Speicher.
Einen S5 Code kann man schon im Tiny laufen lassen, da man nur einen
1-bit Speicher für die Binären Opcodes und 2 Bytes bzw 4 Bytes für
arithmetische opcodes benötigt. Timer, Counter usw. brauchen dann
jeweils 2 Bytes. mit 128 Bytes RAM tuckert also ein SPS Programm schon
ordentlich.

Eine S5 oder S7 ist auch nicht "realtimefähig"!
Was sagt das eigentlich:realtimefähig? Es muss bestimmbar sein, wann
eine Logik wieder bearbeitet wird. Das kann 1ms, 100ms oder auf 10sek
sein. Letzteres würde z.B. aussagen, das in x-beliebiges netzwerk
Realtimefähig ist, wenn es diese Zeiten garantieren kann.
Also: Eine S95U mit 10 zeilen Code ist alle 20ms wieder an der gleichen
Stelle. Ist die S95U proppevoll, braucht die dann für einen Zyklus
80ms.
Nehmen wir wieder den ollen Tiny von oben, der mit 9,6MHz ohne Teiler
läuft. Der würde einen 1K Code (S95U hatte glaube ich damals so viel)
weit unter 20ms interpretieren.
Was ich damit sagen will ist, das die Dinger stupiden Code ausführen
und keine 3D Grafiken oder so. Der lahmste Atmel hängt schon alles ab,
was S5 genannt wird.

Im Übrigen lassen sich Programme hervorragend in SDRams ablegen. mit
den drei Strippen sind die ganz einfach zu adaptieren und vor allem am
PC kann man die Dinger wunderbar beschreiben. Geht eine CPU mal kaputt,
entnimmt man den SDRAM und steckt Ihn in die Neue CPU, fertig.

SPSen lesen am Anfang die gesamte IO in ein Speicherabbild ein, dann
wird der Code bearbeitet Ein U E1.0 liest nicht den Pin1.0 sondern die
Speicherstelle wo der Status hinkopiert wurde. Am Ende wird das
Speicherabbild der Ausgänge wieder an die Peripherie geschickt. Das ist
nicht nur einfach zu programmieren, sondern vor allem in der
Steuerungstechnik absolut notwendig, damit man während des Codes
überall die gleiche Situation vorfindet. Man braucht dafür halt etwas
mehr Speicher.

Würde man aus meiner Sicht einen Mega8 nehmen, hätte dieser schon alles
on Board, um eine richtig wummige CPU zu bauen. Nur das Bussystem fehlt
dann noch. Da der eine oder andere das Teilchen dann vielleicht doch in
HF-belasteten Räumen unterbringen will, muss der Bus schon recht stabil
sein. Ein SPI könnte dafür zu "schlapp" sein.
Aber die Entcheidung muss jemand treffen, der damit schon seine
Erfahrungen gemacht hat.

Alles in allem brauchen wir für das Vorhaben schon ein paar gute Analog
und Digital Entwickler. Der eine oder anderer Assembler Spezi muss auch
dabei sein. Und nicht zuletzt eine Truppe für die Windows IDE. Das wird
schon eine Herausforderung.

Vielleicht sollten wir vorab mal klären, wer alles Interesse und vor
allem Zeit hat, an diesem Projekt mitzuarbeiten? Ich denke under 6
Monaten kommt hier keiner raus, wenn er sich bereit erklärt, etwas zum
Projekt beizusteuern.

Wird die SPS "Public Domain"? Meines Erachtens ja.

Gruß
Uwe

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@uwe:
also die module könnte ich der community zur verfügung stellen. aber
wie gesagt - der zeit ist saia-sbus implementiert. voraussichtlich
gibts die ertsen felbusgeräte ab ende jänner mit modbus rtu. mal sehen,
wie ich die weihnachtsfeiertage verbingen werde *ggg

zu den i/o-pins - eigentlich brauchen wir die nicht, denn die
ursprünglich idee ist die, das eine zentrale cpu alle busschnittstellen
un kommunikationen macht, und über die feldbusgeräte die i/o's. dies
sind auch wesentlich eifacher bei speziellen oem-lösungen auf die welt
zu bringen, als eine komplett neue cpu. das ist mein eigentlicher
hintergedanke an der sache - ein richtig schönes modulares konzept, das
nicht nur an einem fleck erweiterbar ist, sonder wie z.B. über ein
ganzes haus verteilt werden kann.

was die aufteilung der arbeit betrifft, bin ich ganz bei dir. nur
sollten wir vielleicht noch etwas zeit in lande zeihen lassen, um
vielleicht auf mehr leute zurückgreifen zu können. da hab ich aber noch
keine erfahrung damit, wie sich hier sowas entwickeln kann. ist das 1.
mal, das ich in einem forum gepostet habe, nur so nebenbei erwähnt!

über das thema "public domain" sollten wir uns, wenn festeht, wer
letztendlich aller mitdabei ist getrennt unterhalten, aber ich denke
schon, das es in diese richtung gehen sollte.

lg
peter

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schlage als Prozessor den AT91SAM7X256 vor.
Der hat 256 Kbyte high-speed Flash und 64 Kbyte SRAM.
Dazu dann noch USB 2.0, 10/100 Ethernet MAC und einen CAN controller
(2.0A and 2.0B Full CAN).
Das sollte ausreichen.

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk:
Ich bin begeistert, was für nette Sachen es von Atmel gibt.
Wer soll denn sowas auflöten können? Oder hat jemand einen
Bestückungsautomaten? Gibts für den Kollegen auch eine IDE und
Hochsprachen? Ich glaube nicht, das wir dieses Projekt komplett in
Assembler schreiben wollen. Wenn das Teilchen tausend Schnittstellen
besitzt, müssen wir auch Code dafür schreiben. Wer hat schon mal einen
TCP/IP Stack geschrieben? Wer ist in der Lage sowohl den USB µC zu
programmieren als auch auf der Windows Seite den Treiber dazu zu
schreiben?
Der S5 Interpreter ist ja dagegen ein Kinderspiel...

Ansonsten schon eine echt schnuckelige CPU :-)
Was kostet die eigentlich?

Da fällt mir ein: Wenn wir Hardware bauen, wer hat Beziehungen um ans
Material zu kommen? Bei RS wird man arm, Reichelt hat nur Std.
sortiment und Platinen müssen auch gefertigt werden. Mit einer
einseitigen Platine mit 2,54mm Raster werden wir wohl nix gescheites
bauen können :-)

Welche Schnittstellen brauchen wir denn überhaupt? Wenn Ethernet, USB
und Seriell ein Muß ist, dann schlage ich wirklich ein embedded Linux
vor, damit aus dem projekt überhaupt was lauffähiges rauskommt. Alles
andere wird ein Mammutprojekt und sehr teuer.

Vielleicht könnten wir ja mal alle googlen gehen und hier im Forum die
embedded PC mit Linux samt Preis zusammentragen? Wenn ich ein fertigen
Kernel für 60 od.80EUR bekomme, dann bau ich mir doch nicht für
>>100EUR einen µC zusammen,oder?

Ich will das nicht plattreden, aber ich sehe die Schwierigkeiten,
bezahlbare Hardware zu bauen und die dann noch in diesem Jahrhundert
halbwegs fehlerfrei fertig programmieren zu können.

@Pebu66:
Saia-Sbus kenn ich gar nicht. Ist das sehr aufwendig die umzudupsen?
Ich nehme an die haben alle eine eigene Intelligenz?
Vielleicht kann man das ja auch mit mehreren in Angriff nehmen?
Die Idee, das die CPU nur Busse besitzt ist ja auch sehr gut. In dem
Fall kann ich aber lieber was fertiges nehmen und in einem Gehäuse
schön verpacken. Dann brauche ich ja "nur" noch die Software
schreiben.

Dann bleiben auch viel mehr Ressourcen übrig um die viel wichtigeren
Busanschaltbaugruppen zu bauen. Was nützt einem eine Super GHz Monster
CPU mit 512 Schnittstellen, wenn die Analogkarte mit +/- 10% die
Messwerte schätzt :-)) Na ja du weißt was ich meine...

Gruß
Uwe

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@uwe

->und keine 3D Grafiken oder so

du willst aber eine SPS basteln und keine Spielekonsole, oder ? :-0


Der Begriff 'Realtime' ist Definitions-Sache. Nach meiner Ansicht,
ebenso nach der Ansicht der vieler 'Realtime'-Entwickler ist
Echtzeit-Verhalten immer applikationsabhängig. Die Begriffe 'Soft'-
und 'Hard'-Realtime halte ich für Schwachsinn. Entweder dein System
erfüllt die Anforderungen der Applikation oder nicht, unerheblich davon
ob dieses System DOS, Linux, Windows, vxWorks heisst.

Die meisten verstehen 'Realtime'-Betriebsysteme, als Systeme die dem
Posix-Realtime-Standard entsprechen, bzw. daran angelehnt sind.
(Posix.4 Realtime, pthreads, ...). Dort werden ein Set von
Inter-Prozessmechanismen wie Semaphore, Mutexe, Message-Queues, usw.
definiert. Klassische Verteter davon sind vxWorks, QNX, pSOS, aber auch
eCos und WinCE (... zumindest zählen sie sich selbst dazu)

Ich mache den Job schon sehr lange, ich erinnere mich noch an die
Zeiten in denen die S5-Programmierer mit Taschenrechner und S5-Handbuch
gewappnet jede Zeile und jede Verzweigung Ihres S5-Codes durchgegangen
sind und Ausführungszeiten ihrer Befehle nachgerechnet haben um auf
ihre maximale und minimale Zykluszeit zu kommen.
Der Vorteil der S5 und vermutlich auch ihr Erfolg, lag darin, dass sie
genau das getan hat was dokumentiert war, nicht mehr und nicht weniger
und somit ist sie für mich das klassische Beispiel eines
'Realtime'-fähigen Systemes.

Bei den heutigen Anforderungen ist sowas natürlich nicht mehr
praktizierbar. Allein Bus-Systeme und -Protokolle machen eine exakte
Berechnung des Zeitverhaltens einschliesslich I/O nahezu unmöglich.

Modernere SPS-Systeme verwenden oft Zeitscheiben-Verfahren mit einem
lokalen I/O-Prozessabbild für jede Zeitscheibe. Die Einhaltung der
Zyklus-Zeit  wird nicht mehr durch Berechnung sichergestellt, sondern
das System durch Ausnahmebehandlung (z.B. Zykluszeit-Verletzung,
Watchdog) in einen sicheren Zustand gebracht.

Was ist bei dir  'Public-Domain'
Meinst du 'Open-Source', mit ohne GPL,LGPL,.. oder nur freie
Nutzbarkeit der Binaries ?

...lange Rede kurzer Sinn (ich will das Projekt ja nicht tot reden)

Ich halte die von Dirk vorgeschlagene Hardware für optimal.
Der Chip hat alles was das Herz begehrt auf dem Die. Die
Peripherie-Beschaltung beschränkt sich auf Versorgung, Pegelanpassung
und Signal-Konditionierung. Dies macht Baugrösse, EMV-Problematik,
Layout, .. wesentlich einfacher. Durch die ARM7-Architektur lässt sich
das ganze parallel auf einem LPC2xxx entwickeln und dazu portabel
halten.

zum Thema SPI :
Es ist richtig, dass SPI nicht gerade der Bus mit maximaler Performance
ist, ebenso leidet die EMV-Verträglichkeit eines etwas Boards darunter.
Die andere Seite hingegen ist, dass jeder noch so kleine PIC oder AVR
ein SPI-Slave darstellen kann. Ebenso musst du bei den EMV-Design nur 3
Leitungen mit üblen Flanken berücksichtigen.
In einer späteren Ausbaustufe könntest du die SPI-Funktionalität direkt
in einem FPGA abhandeln und dieses über parallele Ports an den Prozessor
anbinden.



kurz zu meinem Profil (.. etwas großspurig, nicht ganz ernst nehmen) :


Ich habe mehrere Jahre beim grössten östereichischen SPS-Hersteller
gearbeitet. Ebenso habe ich mehrere Jahre beim grössten deutschen
'Embedded'-Linux-Distributor gearbeitet. Derzeit arbeite ich bei
einem der weltgrössten Automobilkonzerne in der Entwicklung.

Meine Themen sind Mess-Steuer-und Regelungstechnik, sowie
Bus-Komunikation und -Protokolle, speziell bei CAN und Ethernet.
Betriebsysteme, Kernel-Treiber, Controller-Firmware ist kein Problem.
Ich spreche fliessend 'C' und nahezu fliessend 'C++' (mit leichtem
'C'-Aktzent). Ebenso sind  'C#' und 'Java' keine Fremdworte.

Ich habe so gut wie keine Ahnung von analoger Elektronik. Assembler
kann ich unter Zuhilfenahme eines Prozessor-Handbuches lesen, aber
nicht selbst programmieren.

Ich habe Zugriffe auf professionelle CAN-Analyse-Tools, als auch
MSR-Tools wie Labview, sowie mehrere Rechnerplatformen  PowerPC, VME,
CPCI,

Gruss

Peter

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Vielleicht lässt sich Olimex www.olimex/com/dev dazu breitschlagen ein
Headerboard auf dieser Basis zu basteln. Der Kontakt u.U. über Andreas
Schwarz hier vom Shop.

Ich habe vor kurzem den Adam Dunkels uIP-Stack (ARP, ICMP,UDP ) auf den
GCC und das Olimex LPC-E2294 portiert/angepasst. Sollte machbar sein

Als Entwicklungs-Umgebung sehe ich eigentlich nur den GCC (z.B.
WinARM).  Als Basis-OS würde ich freeRTOS (www.freeRTOS.org)
vorschlagen, zusätzlich sollte noch einer eCos und uCLinux betrachten.


Gleichzeitig sollten wir bei Sourceforge ein CVS-Repository anlegen.
Zuvor jedoch im Forum klären wer nimmt daran Teil, und wer hat welchen
Hut auf.


Gruss,

Peter

Autor: SPS-Newcomer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

sehr guter Thread. Hoffentlich wird aus dieser Sache was.
Da es sich um den Neubeginn einer hoffentlich "lanfristigen"
Entwicklung  handelt, sollte man sich auch mit einer "Profinet"
Schnittstelle beschäftigen. Dies soll ja in Zukunft eine (GROSSE(?)
Rolle in der verteilten Automatisierungstechnik spielen.
Von Siemens gibt es da ein EVA Board und auch einzelne Chip's (ERTEC
400). Sieht man mal vom Preis ab, wäre das für den Anfang sicherlich
eine gute Entwicklungsplattform. Was der einzelne Chip mal kosten wird
weis ich aber nicht, ist aber jedenfalss ne Wumme.

http://support.automation.siemens.com/WW/llisapi.d...
http://support.automation.siemens.com/WW/llisapi.d...

MfG
Achim

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erinnert mich stark an den Labor-Netzteil Thread.

Es werden immer mehr Features dazu geträumt, bis schließelich das ganze
Kartenhaus in sich zusammenfällt.

Eine eierlegende Wollmilchsau wird nie fertig !!!


Mag sein, die Materialkosten steigen noch fast linear zu den Features.
Aber die Entwicklungskosten (Hardware, Software) steigen exponentiell.

Schon allein "Diese werden über bereits vorhandene Feldbusgeräte
realisiert." läßt schlimmes ahnen.
Es gibt tausende von Feldbussen, entweder man legt sich auf ein paar
wenige fest oder man wird nie fertig.


Solche Projekte können nur dann Erfolg haben, wenn man von klein auf
anfängt, also sich überschaubare Ziele setzt.


Peter

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit den Peters wird langsam schwierig...

@Peter Dannegger

ich stimme dir voll zu, kleine Brötchen backen für den Anfang, dann
wird am ehesten  was draus.

Optimal arbeiten kann man wenn jeder ein Stück Hardware schon bei sich
im Bastelkeller hat. Daher würde ich vorerst davon absehen, voll in die
Hardware-Entwicklung einzusteigen.
Vielleicht kann da jeder mal kundtun was ( und mit was ) er sich das
ganze vorstellt .


Gruss,
Peter

Autor: SPS-Newcomer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

nur zur INFO

https://embeddedjava.dev.java.net/
https://jautomation.dev.java.net/


die steuern damit einen CNC Plasma cutter. Die haben das Ziel (?) eine
Standardhardware unter Linux mit einer JAVA VM für die Automatisierung
einzusetzen.
Ich möchte aber keinenfalls eine JAVA Diskussion in Gang setzen, aber
dieses Projekt läuft schon lange und man sollte die Erfahrung bezüglich
der Hardware nutzen.


MfG
Achim

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,


ich hab' mal ein Artikel hier im Forum angelegt:

http://www.mikrocontroller.net/articles/MiniSPS

Form und Inhalte kann sich jeder noch verbessern

Gruss,

Peter

Autor: T. Stütz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein paar Dinge/Ideen dazu:

- Interpretierter Code ist immer langsamer als ein compilierter
  Bsp: S5 CPU 102 hat 2 Betriebsmodi einen "Testmodus" bei dem die
  Befehle mit ca. 2us abgearbeitet werden und einen "Normalmodus" in
dem
  die Befehle mit 0.2s laufen.

- Die Programmiersoftware die verwendet werden soll, sollte frei
  verfügbar sein und folgende Grundfunktionen haben
  - SPS RUN/STOP/URLÖSCHEN
  - PROGRAM LADEN/SPEICHERN/Buchhalter
  - VARIABLEN BEOBACHTEN/ÄNDERN
  - PROGRAM BEOBACHTEN !

- Eine Anlehnung an S5 sehe ich für sinnvoll an (die S590U hatte nen
  8051 als Prozessor, wenn das ein ARM/ATMEL nicht kann)

- es sollte auch möglich sein über ein definiertes Protokoll Daten
  auszutauschen mit SPS/PC (Bsp: P3964R)

- das Profinet EVAL-Kit ist Blödsinn allein vom Preis her, außerdem
  spielt Profinet in einer anderen Liga

- Bitverarbeitung muß sehr schnell ausgeführt werden können (80% der
  Programme arbeiten mit Bits)

- Strukturierte Programmierung der SPS vorsehen (also aufteilen des
  Programms in Unterprogramme bei der S5 spricht Mann da von
  Bausteinen)

Gruss

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo uwe!

also deine frage, wer kann material besorgen, hat sich hiermit erledigt
- mach ich über meine firma, denn wir haben echt gute konditionen bei
allen großhändlern - kauf ja auch genug ein bei denen.

das bestücken von smd bauteilen ist auch kein thema, da ich in der
glücklichen lage bin, einen bestückautomaten zu besitzen. also steht
dem bau dieser baugruppen nichts mehr im weg.

die hardware für die i/o's, egal ob digital oder analog läuft bereits
seit über 2 jahren ohne einzigen ausfall, nur muß der
rs485-komm-treider auf modbus umgestellt werden (meine
weihnachtsbeschäftigung)

lg
peter (pebu66)

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt haben wir einen Supa Guru, der SPS gebaut hat, danach linux
vergewaltigt hat und nun Autos unsicher macht,
einen Materialbeschaffer der auch gleich das Hühnerfutter aufs board
klebt und viele Interessenten die auf sowas schon immer gewartet haben,
und das in nicht mal einer Woche! Nicht zu glauben!!

Also:

WER HAT ERNSTHAFT INTERESSE HIER EINE MINISPS BIS ZUR FERTIGSTELLUNG
MIT ZU ENTWICKELN? D.H. SPASS HABEN, VIEL LERNEN, ABER AUCH DIE PFLICHT
SEINEN PART ZU ENDE ZU BRINGEN!!

btw. Die Idee mit dem linux kam daher, das da schon fast alles
entwickelt ist. Nur der SPS teil müsste noch entwicklet werden. Damit
fällt das Risiko einer sterbenden Eierlegenden Wollmilchsau :-)
Aber da wir jemanden haben der wohl recht viel Ahnung von ARM
Entwicklung hat könnte es auch ohne Fertigprodukt was geben!

Ich für meinen Teil würde gern teilhaben an der Entwicklung einer
MiniSPS und meinen Beitrag dazu geben. Hilfe eurer seids
vorausgesetzt!!

PublicDomain meinte ich, das all die, die Ihre Freizeit in dieses
Projekt stecken, auch Nutznießer davon sein sollten. Wenn dann jemand
Profit aus dem Kind zieht solls mir recht sein, solange wir an seinem
Output(an dem Technischen, nicht am Profit) teilhaben. Dafür tun wir
uns ja hier zusammen!

Wir sollten mal einen Projektbrief formulieren, aus dem die
wesentlichen Bestandteile der Entwicklung ersichtlich werden:
1)Protokolldesign
2)Hardware
3)Entwicklungsumgebung
4)OS-System
5)Windows IDE
6)Zeitplan

Punkt 1 halte ich für am wichtigsten. Ein kleiner Fehler hier führt
später zu riesigen Problemen.

Für die Entwicklung der späteren Windows IDE wüsste ich schon
jemanden!
Ich selbst kann sowohl Teile der Hardware (Analogtechnik eher weniger
weil ich zu doof dazu bin) als auch am OS mit entwickeln.

Gruß
Uwe

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht könnte man Ulrich Radig noch zu dem Projekt dazugewinnen
:-))) ???

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
als test hartware könnte man z.b ein linksys rouer wrt54g benützt werde

*50€
* arm7
* 2 mal seriell
* ethernet
http://www.freifunk.net/wiki/LinksysWRT54G

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht macht mal jemand ein eigenes Forum auf in dem man sich
besprechen kann, wenn die Kommunikation schon so umständlich läuft dann
wird das ganze Projekt nix werden, da dann wieder jeder sein eigenes
Süppchen braut. Vielleicht könnte man mal so was wie eine Chatplattform
aufbauen über die man kommuniziern könnte.

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@123:

...du solltest an deiner Rechtschreibung etwas arbeiten,
aber prima Idee, eine gute Alternative dazu wäre auch der Linksys NSLU


Das ich da nicht schon selbst darauf gekommen bin, das Ding steht bei
mir im Keller !

133 (266) MHz ARM9
89.- Euro
2*USB
100 MBit Ethernet
vorgefertigte Linux-Distri

Infos unter www.nslu2-linux.org

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin,

wie wäre es mit S.N.A.P von www.hth.com als protokoll.
sieht eigentlich nicht schlecht aus und was ich da verstanden habe
kost es auch nix.

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Mahler
_____________________________
@123:

...du solltest an deiner Rechtschreibung etwas arbeiten,
aber prima Idee, eine gute Alternative dazu wäre auch der Linksys NSLU


Das(ß) ich da nicht schon selbst darauf gekommen bin, das Ding steht
bei
mir im Keller
______________________________
Du auch! -> in Österreich verwendet man das scharfe "s" = ß in
Deutschland das "sz" = ß ... .-)

Wenn ich schon nichts zum Thema beitrage, dann wenigstens eine kleine
Kritik an die "selbsternannten Rechtschreibexperten".
Ich sage immer: Wer einen Rechtschreibfehler findet, der darf ihn
behalten!

Ich bin auch sehr interessiert an der SPS.

Da noch keiner über das Profibus DP - Protokoll geschrieben hat, mache
ich es.

Über die Schnittstelle RS485 wurde ja gesprochen.
Für diese Physik (RS485) kann man als Feldbusprotokoll verschiedene
Protokolle wie z.B.

- Profibus (DP,FMS,PA)
- Modbus (++, RTU,..?)
oder auch der von Peter eingesetzte
- saia-sbus

verwenden.

Da ich aus der Automatisierungsbranche (Chemie, Pharma, Automobil aber
auch Haustechnik - DDC,GLT)komme ist mir das Spektrum der dort
eingesetzten Steuerungen und E/A-Komponenten bekannt.

Meiner Meinung nach sollte man die am häufigsten vorkommenden E/A -
Komponenten, aber auch z.B. Motorsteuerungen wie SimocodeDP oder
Frequenzumrichter nicht außer Acht lassen. Das sind sicherlich die
Profibus-Geräte.
Wenn man auf Profibus setzt, dann ist man auch auf viele Seiten hin
offen, da es sehr viele Umsetzer zwischen den einzelnen Busarten gibt.
Außerdem müßte man nicht noch Baugruppen für die E/A entwickeln, oder
könnte diese Thema hinten anstehen lassen.

Unabhängig von diesem Projekt frage ich, hat jemand Erfahrung mit der
Programmierung des Profibus-DP - Protokolls?
Ich denke über den Einsatz mit einem ATMega128 nach.
Habe aber keine Erfahrung mit Protokollen auf Entwicklungsebene.

Gruß Heinz

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Profibus DP ist im Kundeneinzugsbereich von Siemens weit verbreitet, in
Übersee kennts kaum jemand. Dann könnte man auch Interbus S von Phönix
nehmen, die beiden haben ja mal zusammen gekungelt, dann gestritten und
jetzt buss't jeder ein eigenes Süppchen.

Profibus Halbleiter sind nicht grade preiswert. und das ganze Protokoll
auch wieder in der CPU abbilden zu wollen wird wieder ein Riesen Berg an
Arbeit bescheren.

Ich glaube auch, das die Kommunikation zwischen unseren Busmodulen gar
nicht diesen ganzen Overhead von Profibus braucht!
Das SNAP Protokoll ist super very simpel und sehr sehr leicht zu
implementieren. Ich habe das mal für ein Projekt eingesetzt. Es könnte
als Basis dienen und wir erweitern es um die Belange für unsere SPS.
Ebensdo wäre CAN keine schlechte Wahl da es hierfür schon preiswerte,
fertige Bustreiber mit Logik gibt. Soweit ich weiß kann man aber bei
CAN keine Datenblöcke senden. Das macht den CAN bei großen Datenmengen
vielleicht wieder zu langsam.
Liesse sich das SPI nicht mit entsprechenden Bustreibern nutzen? da
haben wir alles schon in der CPU drin.

Parallel zu der Diskussion um das richtige Protokoll und die richtige
Wahl des Transportlayers sollten wir mal schauen, welche Busmodule am
wichtigsten wären und welche Art der Daten wir dafür brauchen.
Das ganze muss ja warscheinlich erst abstrahiert werden, damit man
später einmal einfach eine neue BG dranstecken kann, ansonsten müsste
man für jede BG wieder die CPU umstricken. (so ähnlich wie die GSD
Dateien bei Profibus)

Gruß
Uwe

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das wichtigste protokoll ist meiner meinung nach der modbus, da für
diesen im handel jede menge fertiger baugruppen verfügbar sind, und
auch bei diversen frequenzumformern (toshiba, schneider, danfoss, ...)
implementiert ist.
als zweites könnte can-bus mit canopen2.0 angedacht werden. dafür gilt
das gleiche wie bei modbus von den feldgeräten.
wir sollten halt nur darauf schauen, das wir nicht auf ein busprotokoll
setzten, das eine sehr geringe verbreitung hat. die 2 oben ganannten
sind zwar alt, aber haben sich in der vergangenheit bestends bewährt.
vorallem sind diese auch nicht so schnell wegzudenken.
wenn die busschnittstellen als steckbare module ausgeführt werden,
könnte die firmware der cpu aufgrund von kodierungen der jeweiligen
treiber selbständig aktivieren - nur mal so als mögliche zukünfige
alternative.
ein weiter möglichkeit kötte der lon darstellen, aber da hab ich bisher
nur negative erfahrungen gemacht und von vielen seiten auch bestätigt
bekommen - da mußt ein richtiger professor sein, um das zu behirnen -
also nicht wirklich mein ding.

lg
peter (pebu66)

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie muss ich mir eine hausautomation mit hilfe einer sps vorstellen?
Jeder taster sendet über den bus (welcher?) ein signal zur sps und
diese steuert ein relai?
Die ganze intelligenz ist also in der SpS?

zur NSLU:
hat auch eine serielle schnitstelle,da könnte man can oder rs-xxx
anschliesen. und das alles für 8o€

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@123

ja genau - ansonst wirst mit dem programmieren nicht fertig, bzw. wenn
änderungen anstehen, mußt immer von einem feldgerät zum nächsten
hirschen - mühsames unterfangen, vorallem dann, wenn die dinger irgend
wo versteckt angebracht sind (zwischendecke, up-dose, ...)
aber mit dieser sps soll nicht nur hausautomation möglich sein, sondern
- vielleicht etwas übertrieben - auch ein kleiner robotter steuerbar
sein - eigentlich alles was eine steuer- bzw. regelung braucht.
wenn ich das jetzt auch noch weiterspinne, dann könnte dieses ding
sogar, wenn es für linux auch ausgelegt wird, als mini-pc betrachtet
werden. aber wie gesagt - das ist in weiter ferne vorerst einmal.

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Mit CAN bzw. CANopen ist man recht schnell soweit, dass man einfache
I/O-Knoten ansprechen kann. Man kann dann recht schnell I/O-Module von
nahmhaften Herstellern nutzen. Innerhalb von CANopen gibt es
verschiedene Profile, mit das einfachste ist dabei das I/O-Profil. Es
gibt jedoch auch Profile für Antriebe und Programmierung.

Die Frage ist, wer Zugriff auf CAN-als auch Modbus-Hardware, gegen die
wir testen können.

@Uwe
Bei CAN werden in einem Frame bis zu 8 Datenbytes gleichzeitig als
Block übertragen. Grössere Blöcke werden sequentiell übertragen.


Was mich in der Anfangszeit mehr interssiert ist das Online-Protokoll,
mit dem man Statusbetrieb und SPS-Programmierung vornimmt. Die Physik
sollte dabei frei wählbar sein z.B. Ethernet,RS232,RS485,CAN.

Die Bus-spezififsche Hardware sollte zu Anfang nicht das Basisthema
sein. Ich denke für den ersten Schuss reicht es wenn wir uns das ganze
mal anschauen und die Prozessor die entsprechenden Interfaces bietet um
externe Profibus-Module o.ä, zukünftig anzuschliessen.

Vieleicht findet sich zum Thema Hausbus noch jemand der
Entwicklungserfahrung mit EIB und LON hat. Ich denke in diesem Markt
liegt künftig ein sehr grosses Potential.


Gruss,

Peter

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Mahler
...du solltest an deiner Rechtschreibung etwas arbeiten,
Hallo,
_____________________________________
Mit CAN bzw. CANopen ist man recht schnell soweit, dass man einfache
I/O-Knoten ansprechen kann. Man kann dann recht schnell I/O-Module von
nahmhaften (namhaften, kommt von Name) Herstellern nutzen. Innerhalb
von CANopen gibt es
verschiedene Profile, mit das einfachste (Einfachste) ist dabei das
I/O-Profil. Es
gibt jedoch auch Profile für Antriebe und Programmierung.

Die Frage ist, wer Zugriff auf CAN-als auch Modbus-Hardware, gegen die
wir testen können.

@Uwe
Bei CAN werden in einem Frame bis zu 8 Datenbytes gleichzeitig als
Block übertragen. Grössere Blöcke werden sequentiell übertragen.


Was mich in der Anfangszeit mehr interssiert ist das Online-Protokoll,
mit dem man Statusbetrieb und SPS-Programmierung vornimmt. Die Physik
sollte dabei frei wählbar sein z.B. Ethernet,RS232,RS485,CAN.

Die Bus-spezififsche (spezifische)Hardware sollte zu Anfang nicht das
Basisthema
sein. Ich denke für den ersten Schuss reicht es wenn wir uns das ganze
(Ganze)
mal anschauen und die Prozessor (Prozessoren) die entsprechenden
(entsprechende) Interfaces bietet (bieten) um
externe Profibus-Module o.ä, zukünftig anzuschliessen.

Vieleicht (Vielleicht)findet sich zum Thema Hausbus noch jemand der
Entwicklungserfahrung mit EIB und LON hat. Ich denke in diesem Markt
liegt künftig ein sehr grosses Potential. (Potenzial nach der neuen
Rechtschreibreform, ich schreibe auch nach der Alten, aber Du mischt
Alt und Neu..)
__________________________________________
warum habe ich Dich verbessert?
Ich finde, daß die Rechtschreibung nicht kritisiert werden soll (was
ich jetzt gerade mache), denn es schreibt keiner absichtlich falsch.
Ich hätte nach meiner ersten Antwort von Dir erwartet, daß Du Dich bei
@123 entschuldigst, in irgendeiner Form, aber nicht einfach durch
Ignoranz glänzt.
Bitte denke nicht, daß ich ein Erbsenzähler oder Rechtschreibfanatiker
bin, im Gegenteil. Aber ich kann es nicht ausstehen, wenn man Leute
öffentlich kritisiert, die wie in diesem Fall nichts dafür können.
Ich will Dir einfach nur zeigen, daß Du selbst viele Fehler machst.
Wenn man Fehler finden will, dann findet man diese überall.

Gruß Heinz

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Heinz

ich hatte das mit der Rechtschreibung nicht ganz so ernst gemeint,
habe aber das Smilie am ende vergessen.

Daher entschuldige ich mich nochmal bei 123, sowie allen die sich durch
mein Post auf den Schlips getreten fühlen in aller Form, war 'ne dumme
Idee, ich tu's nie wieder !!!

Gruss,

Peter

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zur rechtschreibung: Peter hat schon recht, ich hab mir mein posting
nochmal durchgelesen, war echt schrecklich. Ich habe schon schlimmere
und unproductivere postings gesehen. Die entschluldigung nehm ich an
und hoffentlich nicht ganz soviele fehler einzubauen. Ich denke damit
ist das thema auch abgeschlossen.

zum Hausbus: Es gibt ein neues forum dazu, leider ist es nicht
verlinkt.

http://www.mikrocontroller.net/forum/list-11-1.html

dort wird gerade über ein opensource Hausbus nachgedacht. Das projekt
benützt can als bus, vielleicht könnte man die sps ja als steuereinheit
benützen und sich zusammentun.

Autor: FJa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@mahlerp:
Haben sie eine Doku der S5 Bytecodes (wie am Di vorgeschlagen).
In der angegenenen Page steht zwar einiges kommerzielles und eine
Hilfedatei zum downloaden, aber die Codes finde ich dort nicht. Auch
googlen hilft nicht.

rgds

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@mahlerp:
Ich stelle fest:
entweder kommt Modbus oder CANopen2.0 als InterBus zum Einsatz, weil:
* weit verbreitet
* schon lange in Produktion und daher wohl als ausgereift zu
bezeichnen
* Viele Anschaltbaugruppen auf dem Markt
* Protokoll(Modbus) recht einfach
* Fertige Buskoppler (CAN) auf dem Markt existieren

Kann jemand ein Tabelle der Leistungsmerkmale beider Busse im Vergleich
mal posten? Interessant wäre:
* Geschwindigkeit
* Anzahl Bytes / sek.
* Größe des Overheads (bits/s, Bytes, ms oder sowas)
* Art der Sicherung des Datenpaketes (CRC32, Framecheck,...)
* klassifizierung der Daten
* etc...

Für die Übertragung von SPS zum PC (Programmierung, Onlineüberwachung)
halte ich die serielle Schnittstelle vom µC für die beste Wahl.
Denkbar wäre dann RS422, RS232 oder ein RS232 auf Ethernet wandler.
Dann gibts auch RS232 Funkübertragungen usw...
Als Protokoll könnte man auf SNAP zurückgreifen. Ist sehr gut
dokumentiert, Datenblöcke werden gesichert mit CRC32, und beliebig
erweiterbar.
Als Basisfunktionen wären da(Prio in der Reihenfolge von oben nach
unten):
* MMC löschen
* Übertragung des Programms in die MMC/SDCard
* Übertragung einzelner Codebausteine
* Abfrage des Hardwareaufbaus (Welche Module am Bus usw.)
* Zuweisung Adresse zu Hardwareadresse (E1.0 = Modul3,Pin3.0)
* Onlineabfrage des Ein- / und Ausgangabildes
* SPS Kommandos U, O, UN,ON, RS,XOR, = (Bitbefehle)
* Abfrage vom Merker, Merkerbytes und Merkerwörtern
* SPS Kommandos +,-,AND,OR,NOR,NAND,XOR (Byte/Wortbefehle)
* SPS Kommandos T,Z (Timer,Zähler)
* Abfrage von Timern, Zählern
* usw.

Die Reihenfolge halte ich für sinnvoll, weil wir jeden Schritt dann
alle testen können obs auch richtig funktioniert. Wenn Freigabe von
allen, dann wird nächster Punkt realisiert (baut aufeinander auf).

Parallel können die Hardwarespezis sich schon mal Gedanken über
Busmodule machen (IO=0,4-20mA, I=PT100/PT1000, Miniumrichter, Dimmer,
keine Ahnug was noch alles...), sofern wir uns über das Busprotokoll
einig geworden sind.

Gruß
 Uwe

PS: Bis auf drei Leute hat sich noch keiner aktiv bereit erklärt, daran
mit zu schrauben...

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S5 Bytecodetabelle habe ich hier. Muss ich abschreiben :-(
Wenn hier irgendwann mehr als reden rauskommt, werde ich auch aktiv
:-)

Uwe

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@FJa:

Den S5 Byte-Code findet man i.d.R. in jedem S5 Gerätehandbuch (der CPU
natürlich) im Anhang.

Ich habe noch zusätzlich ein S5 Programmierhandbuch der Siemens AG
wo ausführlichere Informationen zu Bausteinaufbau und Organisation des
Speichers vorhanden sind. (Das sogenannte Gardena-Handbuch)

Buchtitel "Automatisieren mit S5-115U"
Autor "Hans Berger"
ISBN 3-8009-1526-X

Da ich noch nicht weiss, inwieweit irgendwelche Urheberschutzrechte
verletzt werden, halte ich mich mit dem direkten Kopieren der
Buchseiten etwas zurück. Ich arbeite gerade an einem
(Vorab-)Design-Dokument über die MiniSPS, in dem ich das Buch mit
entsprechendem Quellenverzeichnis 'ausgiebig' zitiere.
Ich denke, dass ich das Dokument im Laufe der nächsten Woche soweit
habe, dass es per Email versendet werden kann.

Gruss,

Peter

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin schon dabei, nach geeigneten ARM7 Plattformen mit µCLinux
ausschau zu halten, auf denen man (wir) auch entwickeln können.

Ich halte ein Linux Kernel immer noch für die zukunftweisendere
Variante. Dafür findet man die meisten Sourcen und die meisten Leute
die was entwickeln könnten.

Bei welcher SPS kann man schon das OS erweitern? :-)

Gruß
 Uwe

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,


übrigens ist nächste Woche die SPS-IPC-Drives in Nürnberg. Ich werde
versuchen dort einen Tag hinzufahren. Eine gute Gelegenheit um sich
Anregungen zu holen.


Gruss,

Peter

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Mahler
hallo peter!
ich bin am montag in nürnberg bei der firma s+s regeltechnik.
vielleicht geht es sich aus, das wir uns kurz treffen, sofern du in der
näheren umgebung von nürnberg zu hause bist. mit uwe hab ich
mitlerweilen auch schon recht guten kontakt.

@ alle
vielleicht sollten wir versuchen, ulrich radig ins boot zu bekommen. er
dürfte schon eine fertige hardware haben, bzw müsste für unsere
anwendung nur um einige kleinigkeiten erweitert werden. wenn dem so
ist, könnt ich euch das layout machen und einige boards bestücken.
hätte auch den vorteil, das gleich von beginn an die richtige hardware
zur verfügung steht.

gruß peter (pebu66)

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@pebu

Die Messe beginnt am Dienstag, ich werde jedoch frühestens Mittwoch
oder Donnerstag nach Nürnberg kommen. Leider wohne ich auch nicht im
direkten Umfeld von Nürnberg. Eher die Ecke Stuttgart/Karlsruhe


Direkter Kontakt zu mir per Mail über
   peter(punkt)mahler(ät)web(punkt)de

Gruss

Peter

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab da mal ne Frage,wenn ihr das mit Linux machen wollt, wie lange
braucht eigentlich so ein µClinux beim booten? Wenn das nach einem
Absturz (egal wodurch) 5 Minuten braucht und evtl. sogar eine Person
die es bootet, dann denke ich wird es für die Automatisierung
unbrauchbar sein. Stellt euch mal vor ihr seid in Urlaub euer Haus wird
damit gesteuert und es kommt zu einem Stromausfall, dann müsst ihr den
Urlaub abbrechen...

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn z.B. Strom ausfällt, befindet sich eine Anlage eh in einem
nicht definierten zustand.
Dafür programmiert man spezielle Routinen.
Wenn die SPS bootet, geht das relativ fix (<1min). Ist ja kein Suse
oder so, wo die Hardware und bis zu 150 Tasks abgearbeitet werden.

Autor: franz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
für den amr7 gibt es auch schon eine opencanlib:
http://www.canexperts.de/engl/canprod/sw_lib_atmel.html

Autor: Der Elektrische Reiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Leider hatte ich in der vergangenen Woche keine Gelegenheit ins Formum
zu schauen. Ich bin überrascht, das sich so viel getan hat. Das Lesen
der aufgelaufenen Beiträge hat einige Minuten gedauert, aber auch Spass
gemacht. Great!

Zum Start bin ich auch der Meinung, das wie klein und definiert
beginnen sollten. Ich miene ein Design zu wählen, das schnell zum Ziel
führt, aber uns keine Möglichket zum wachsen nimmt. ARM CPUs sind
sicher auch eine gute Wahl: Kaum teuerer als 8-Bitter, aber mit
deutlich mehr Leistung. Die Philips ARMs sind schon einige Jahre am
Markt und Philips scheint hier auch eine offene Kommuinkation bezüglich
Fehler zu haben.

Wie ist das mit dem Linux? Ein ausgewachsenes Bereiebssystem stellt
Funktionen zum bequemen und standardisierten Zugriff auf die
Systemressourcen zur Verfügung. Dadurch können sich Anwendungsprogamme
die arbiebt sparen, direkt auf der Hardware usw. herumzurödeln. Dieser
Luxus wird jedoch mit einem gewissen maß an Overhead erkauft. Bei
unserem Projekt, läuft jedoch nur eine einzige Anwendung: Der
ByteCode-Interpreter. Es muss performant un sehr zuverlässig und
ungestört arbeiten. Die eigentliche Betriebssystem-Schnittstelle tritt
nicht nach aussen. Vielmehr ist nur der ByteCode-Interpreter sichtbar,

Ich meine der ByteCode-Interpreter (BCI) ist das Betriebssystem.

Wenn wir den BCI als Aufsatz eines bestehenden Betriesystems
realiseren, schleppen wir der Overhead der bequemen und
standardisierten Ressourcen-Zugriffe mit uns herum, ohne dass wir das
benötigen.

Was meit ihr?

cu

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meine, daß der Atmel-ARM ein wenig mehr bietet, was die Software
angeht, gebe ich Dir recht. Warum unter den Interpreter noch ein
Standardbetriebssystem legen?

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weil wir: Ethernet, CAN Bus, serielle Schnittstellen betreiben wollen
und irgendwie für alle einen treiber brauchen. Dann brauchen wir einen
layer, um alles auch noch "parallel" abfiedeln zu können.

Beispiel:
Die Prozessabbilder liegen im RAM, und du willst nun einen ganzen
Schwung Variablen beobachten oder sogar steuern. Dann muss der
"Bytecodeinterpreter auch die ganze Zeit die kommunikation zum PC
leisten.
Ich würde den Bereich der Prozessabbilder in eine Named Pipe packen.
ein zweiter Prozess (der auch noch parallel entwickelt werden kann)
greift sich Werte daraus wenn beobachtet werden soll. So kann der
Bytecode laufen, beobachtet werden und Can und RS485 werden vom OS
gemanaged.

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Design des Bytecode-Interpreters wird so gestaltet sein, dass
er sowohl auf einem Linux oder Windows-Rechner als Prozess/Thread
läuft, aber auch auf einem Atmel oder Philips ARM7. Als Standalone
-Prozess.
Der gesamte Addressraum einer S5 (...bis zur 115U) beträgt gerade mal
64Kbyte. Nach einer ersten Einschätzung  braucht der Interpreter jedoch
minimal 4KByte RAM für die internen Verwaltungs-Strukturen
Bausteinlisten,... so dass eine Verwendung z.B. auf einem 8-Bitter wie
AVR schwierig wird. Hinzu kommt , dass die Registerbreite mindestens 16
Bit betragen  sollte, um WORD-Konsistenz bei Zugriffen auf Addresslisten
zu gewährleisten.

@Uwe
Du solltest die mal die Boards von Olimex mit dem LPC2294 anschauen,
z.B. LCP-E2294 . Dort hast du n*CAN Ethernet, RS2323 1MB RAM 4 MB
Flash.

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon alles gesichtet:-)

So etwas schwebt mir ja auch vor, allerdings nicht für 149EUR.
Letzlich ist Ulrich Radigs Kiste ja auch nichts anderes.

Wenn wir sein Plan nehmen und jemand diesen auf eine kleine Platine
bekommt, sind wir doch schon sehr weit, weil ulrich schon µCLinux
daruaf laufen hat.

Der Bytecodeinterpreter kann ja auf einem Highlever (UML, oder
Struktogram z.B) formuliert werden und einer baut das ganze unter
Linux, der andere in GCC zusammen. Allerdings möchte ich nochmal
betonen, das unserer SPS "parallel" eine ganze Menge abfiedeln muss.
Das Multitasking und die ganzen Protokollstacks sind in Linux schon
vorhanden und getestet. Dort gibt es auch fertige Strukturen um von
getrennten Tasks auf einen Memory zugreifen zu können. Vor allem für
das steuern und beobachten sehr wichtig.

Gruß
Uwe

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es könnten mehrere Instanzen der SPS auf einem Rechner laufen, jede in
einer eigenen Zeitscheibe. Datenaustausch z.B. über Shared.Memory.

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yepp.
Auf diese weise wäre es z.B. möglich, ohne riesigen Aufwand z.B. das
normale OB1 Programm laufen zu lassen, aber auch einen OB21 usw, also
OB's die zeitlich getriggert werden. Das Tasking übernimmt das OS, da
haben wir dann rein gar nichts mehr mit zu tun!

btw: Anstatt für eine SPS lässt sich mit dem Teilchen dann auch die
Hardware für ganz spezielle Dinge verwenden. Also statt Bytecode
Interpreter ein spezielle C Programm mit ganz viel Mathematik on Board
usw.
Oder spezielle Programme, die Mails oder SMS verschicken können über
ein angeshlossenes Handy (Gibts alles schon für Linux)
Die SPS wäre per SNMP aus dem Netz überwachbar
Mehrere SPSen könnte man über ein zusätzliches Tool miteinander
koppeln. Das Progrämmchen spiegelt dann halt die Memorybereiche der
SPSen untereinander. Für den Bytecodeinterpreter siehts dann halt nur
so aus, als ob es sich um eine riesige SPS handelt. Bei richtigem
Aufsatz vom Bytecodeinterpreter braucht man für die Vernetzung
nichtmals ein Byte neu zu schreiben.

Ich könnte jetzt noch weiter aufzählen...

Ohne Linux wäre das alles nur Wunschdenken weil wir sonst sowas nie
zustande bringen würden.
Das einzige Handycap ist der Preis für die CPU Komponenten.

Gruß
Uwe

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irrtum (...der Klugscheisser bricht durch),

OB20/21 sind Kaltstart OB was du meinst sind OB 10 -13, die
zeitgetriggertern Bausteine

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Och Mensch, Klugscheisser :-))

Auf jeden Fall weiß jeder was gemeint war, und das zählt...

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer könnte uns mit einem Schaltnetzteil 24V ->5V beglücken?

Die SPS benötigt ja nun auch Energie. Das Netzteil sollte eine
Galvanische Trennung besitzen, damit man den PC oder andere
angeschlossene Gerätschaften nicht mit dem GND der Versorgungsspannung
koppelt.

Ich habe hier ein LM2575 Step Down Wandler in Betrieb. wenig Bauteile,
gute Qualität, aber nicht galv. getrennt! Kann man anstatt Spule nicht
einen Trafo nehmen mit zusätzlicher Wicklung für die Rückkopplung.
So ähnlich funktionieren doch die Fly-Back Netzteile, oder?

Gruß
Uwe

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wär's mit einem DC/DC-Wandler zur Printmontage (z.B. von Reichelt)?

Autor: Lumpi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde mal ein Trägerboard mit allen Relaisen, Optokopplern,Klemmen usw.
entwickeln. Dieses Trägerboard passt in ein Hutschienengehäuse.
Auf dieses Trägerboard kann man Processormodule aufstecken (zb
v.Phytec). Ebenso alle Schnittstellen-Boards (CAN,RS485,USB,Ethernet
usw. steckbar). Auch ein Netzteil wäre integrierbar (seitlich gesteckt,
je nach Gehäuse). Dazu noch eine Schnittstelle für LCD und Taster. So
ist das Gerät nach Kundenwunsch bestückbar.

SG Lumpi

Autor: Lumpi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PC104 ist auch eine sehr gute, erprobte Basis mit allen möglichen
Schnittstellen. Nicht sehr teuer.

SG Lumpi

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@lumpi im Hauabusforum:
http://www.mikrocontroller.net/forum/list-11-1.html

wird gerade auch über hutschinen E/A-module diskutiert. vieleicht kann
man sich ja zusammentun.

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:
DC/DC Wandler von Reichelt sind teuer und liefern u.u. nicht die
benötigte Leistung

@Lumpi:
ordentliche Gehäuse zum Anreihen gibts z.B. von OKW.
PC104 Boards sind zwar recht preiswert, aber auch groß. Außerdem ist
der PC104 Anschluß eher was zum Stapeln aber nicht für grobe
Elektrikerhände ;->

Gruß
 Uwe (selbst Grobmotoriker :-)

Autor: willi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Scheint so, dass das Projekt wohl gestorben ist... War ja vorhersagbar,
wenn man das Thema Tod diskutiert und sich nie einig wird...

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö,


ich arbeite daran, nur muss ich nebenbei meine Brötchen verdienen.

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe schon jemanden der das Windowsprogramm schreiben würde!

Ich versuche grade, eine preiwerte, linuxtaugliche ARM7 Variante zu
besorgen. Mich wundert, warum 4MB SRAM so teuer sein sollten...

Pebu will seine Module Modbustauglich schreiben, so das wir wohl einen
Modbus als ersten SPS bus nutzen werden. Die CAN Schnittstelle könnte
man als zweite Treiberschicht dann etwas später in Angriff nehmen.

zum Thema tot diskutieren:
Alle wollen das Teilchen haben, aber keiner meldet sich um mit daran zu
arbeiten. Es soll ja keine Patchwork-SPS werden, also muss da einiges
abgestimmt werden, oder?

mfg
Uwe

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

in der aktuellen CT ist ein recht interressantes Produkt :

http://www.taskit.de/en/products/microarm/

Gruss,
Peter

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu teuer.
Das FoxBoard kostet nur 139EUR, µClinux schon installiert, 2 USB,
100MBIT Ethernet, serielle IO und eine Hand voll parallele IO's on
Board.
Ausserdem gibts Support bis zum abwinken. Scheint mir die bessere
Alternative zu sein.

Gruß
 Uwe

Autor: Peter Mahler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mädels,

wird richtig still um das Projekt.
Nimmt denn keiner mehr daran Teil ?

Ich für meinen Teil wollte eigentlich eine grobe Spec. von dem SPS-Teil
abliefern, leider bin ich gerade beruflich unterwegs und komme gerade
mal spät abends oder früh morgens dazu, ein paar Minuten zu
programmieren oder zu schreiben.

Gruss,

Peter

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Mahler

mir gehts im moment auch nicht anders. bin aber mit uwe in kontakt
bezüglich dem "FoxBoard". das dürfte eine recht gute basis sein, auf
die wir aufsetzten können. außerdem bin ich jetzt soweit, das ich meine
feldbusgeräte auf modbus-rtu erweitern muß - ein schöner weihnachtsjob
so zu sagen.
würden uns sehr freuen, wenn du aktiv an diesem projekt mitarbeiten
würdest - ich denke, das wir dann eine recht gute truppe sind, die in
der lage ist etwas in diese richtung zu bewegen.

gruß
peter

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Colibrie-Board wäre auch etwas, vorallem da es relativ günstig ist,
für den Prozessor und die Ausstattung.
http://www.toradex.com/d/products.html
Siehe auch folgenden Thread
http://www.mikrocontroller.net/forum/read-1-265881.html#new

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
gestern kam das Fox-Board an!
5V drauf, Netzwerkkabel rein und ab die Post...

Läuft super! linux installiert, Webserver, ssh, telnet und ftp sind
betriebsbereit. I2C Treiber und USB sind auch aktiviert.
Für 139EUR echt ein Schmuckstück.
Die CPU wird etwas schwierig zum auflöten, das wird nur professionell
gehen, wenn man das aber lösen kann, kostet die Linux-Semmel nur noch
die Hälfte!

Das Board braucht zur Zeit 240mA bei 5V.
Die ersten einfachen Shellscripte laufen schon :-)
ACME bietet einen Compile-service für seine eigenen C-Sourcen an.
Mein Hello World läuft also auch schon. Allerdings habe ich mir
einen Debian Linux Rechner fertig gemacht, damit man selbst compilieren
kann. Das SPS Project wird ja warscheinlich größer als ein "Hello
World" :-)

Also dann, legt mal los!

Gruß
 uwe

Autor: A.lexander K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich würde mich für den Bytecode von Siemens ( S5 bzw S7 )
interessieren. Kann da jemand mal ein PDF machen? Über was zu reden was
man nicht kennt macht ja keinen Sinn.

Gruss Alex

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Netter Link zur Operationsliste
http://www.es.fh-mannheim.de/sp/simatic/s5.htm

Autor: SeppKnallhirsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier tut sich auch nichts mehr...

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe fast nichts anderes erwartet.

Ich habe mittlerweile das Fox-Board mit der gesamten Entwicklungs-
umgebung (Debian, SDK,usw) im Einsatz. LCD Anzeige funktioniert,
I2C funktioniert, RS232 funktioniert, USB Massenspeicher
funkioniert...

Plane Eval-Board, tue mich mit dem routen nur sehr schwer.

Wer richtig Ahnung vom routen hat (Eagle), der solle sich hier melden!

Gruß
 Uwe

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo uwe!
hab dir doch gesagt, dass wennst hilfe brauchst bezüglich routen, dann
kann ich das für dich übernehmen - brauch nur den neuen stromlaufplan!
lg
peter

Autor: Uwe Kullmann (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leutz

ich habe (hoffentlich fehlerfrei) ein Evalboard für das Foxboard
fertig.

Features:
+ I2C auf Pfostenleiste
+ 4/1 Analog IO über PCF8591 on Board, Adresse einstellbar ü. Jumper
+ 8 general IO über PCF 8574 on Board, Adresse einstellbar ü. Jumper
+ Port A vom Fox rausgeführt
+ 8 x Out vom Fox rausgeführt
+ 8 x In vom Fox rausgeführt, Spannung wählbar 3.3V / 5V
+ RS232 (/dev/TTYS2) mit Handshakeleitungen
+ RS485 (/dev/TTYS3) mit Abschlußwiderstand jumperbar
+ RS232 (Console) Um zu sehen, was das Board auf der Console ausgibt
+ LCD Anzeige (Displaytech 164A von Reichelt), jedes andere passt aber
auch
+ Step Down Wandler 8-15V --> 5V
+ 7 x Out über ULN2004, z.B. um Relais anzusteuern.

Damit kann man schon fast alles machen was man so macht. Die
Pfostenleisten sind so gewählt, das man das Board per Flachband
erweitern kann, d.h. Spannung + GND ist auf jedem Pfostenstecker
verfügbar.

Natürlich ist das Fox-Board so gesteckt, das man an die
Netzwerkdose und die USB Stecker hervorragend dran kommt.
Für die "Unter-Tage"-Bastler kann man das Board, das Evalboard und
die LCD-Anzeige mit Schraubbolzen auch noch verschrauben

Peter würde sich bereit erklären, da Board fertigen zu lassen.

Daher hier der Aufruf:
Wer hat Interesse an dem Eval Board und möchte sich an einer Sammel-
bestellung beteiligen? Je mehr Leute, desto billiger, kennt Ihr ja
schon.

Da ich sowohl das Linux mitsamt dem SDK schon am laufen habe und auch
die ersten Demoprogrämmchen compiliert habe, ist das für jeden
"Embedded-Linux"-Newbie ein gefundenes Fressen, da Hilfestellung
vorhanden.

Gruß
  Uwe

PS: Falls Ihrs vergessen hattet: Wir wollen immer noch eine SPS
bauen...

Autor: SPS-Lauscher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

guter Thread. Mal schauen was daraus wird. Ich habe nicht unmittelbares
SPS Interresse aber falls eine Sammelbestellung zusammen kommt würde ich
eventuell auch mitmischen.

Ist auch ne Sammelbestellung fürs FOXPRO geplant?

Viel Erfolg
Achim

Dieser Link könnte für Euch Interressant sein:
http://www.o-r-f.org/index.htm

Autor: Uwe Kullmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso nicht?

Da müsste man noch mal beim Elektronikladen nachfragen ob sich das denn
lohnt.

Autor: DirkP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein wirklich interessanter Thread. Ich war bis eben auch noch auf der
Suche nach soetwas wie einer einfachen Mini-SPS mit komfortabler
Bedienung und bin auf:
http://www.unitronics.com/
gestossen. Das ist eigentlich genau das, was ich für eine
Pumpstandsteuerung brauche. Was haltet Ihr von diesen Teilen?

Gruss
DirkP

Autor: Baldwin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fesch.

Autor: Baldwin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo soll denn die SPS eingesetzt werden (was soll sie können ) ?

SG Baldwin

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@dirk
wie und was soll die pumpensteuerung können? wenns nur darum geht, den
motorabgang anzusteuern und zu überwachen (schütz, motorschutz), dann
gibts eh schon fertige feldbusgeräte mit rs485 schnittstelle. die haben
auch eine notbedienebene am gerät drauf, sowie diverse signalisierungen
der betriebs- und störzustände.

@baldwin
im ersten step, sollte diese kleine sps im bereich hlk anwendung
finden. in weiterer folge ist aber auch der einsatz in der
automatiserung angedacht.

gruß
peter

Autor: DirkP (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Pumpensteuerung ist für einen Ultrahochvakuumpumpstand
(Pumpenkombination aus Turbomolekularpumpe und Vorpumpe
(Drehschieberpumpe o.ä.). Es werden ca. 4 Digitalsignale (Meldungen vom
Turbopumpensteuergerät und der Vorpumpe) sowie 2 Analogsignale
verarbeitet (Drehzahl der Turbopumpe, und Vakuumdruck der Messröhre
0-10 V)verarbeitet. Es gibt noch verschiedene Anforderungen bei
unterschiedlichen Betriebsmodi.

Schlussendlich wird damit ein Schieber angesteuert, der einerseits die
Turbopumpe vor einem plötzlichen Druckstoß, z.B. bei Lufteinbruch und
andererseits das zu bepumpende Volumen vor ungewollter Belüftung (z.B.
bei Pumpenausfall oder Stromausfall) schützen muss. Desweiteren soll
bei Problemen eine automatische und sichere Abschaltung erfolgen.
Die Steuerung soll vor allem kompakt und einfach zu bedienen sein. Es
soll für den normalen Einsatz nur eine Einknopf-Bedienung notwendig
sein. Gleichzeitig soll aber in einem Fehlerfall über das Display eine
klare Information des Problems gegeben werden.

Wir haben schon einiges an Siemens S7 für aufwendigere Sachen im Haus.
Für so eine Steuerung wäre das aber übertrieben. Auch die S7-200 müsste
zusätzlich noch mit einem HMI-Modul ausgerüstet werden und braucht eine
eigene Software zur Programmierung. Da sind wir auf die Unitronics
gekommen. Im Moment scheint mir die Visio 120-22-R2C als mein Favorit.
Das Ding wird wohl auch nicht die Welt kosten und die Software gibts
gleich dazu, was will der Mensch mehr?

Ich kann Euch gerne darüber berichten, wenn wir Erfahrungen mit dem
Gerät haben.

Gruss
DirkP

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@dirk
wenns immer die gleiche hw und sw ist, dann könntet ihr eventuell ein
oem-gerät andenken - kommt nartürlich auf die stückzahl drauf an. wobei
oem-gerät ein sehr dehnbarer begriff ist.
wenn du avr's mit c programmieren kannst, dann könntet ihr bereits
jetzt dafür geeignete geräte habe. falls irgend welche speziellen
kombinationen von ein und ausgängen notwendig sein sollte -> kein
problem.
das programm könntest du dir dann selbst in die geräte schreiben über
den üblichen isp-port. damit bei den ein und ausgängen nichts passiert,
könnte ich dir die c-umgebung so gestalten, das du nur mehr das
eigentliche steuerprogramm schreiben müsstest.
für die anzeige würde ich grundsätzlich nur mit touchpanels arbeiten.
die dinger gibts bereits ab 350 bis 400 eur und du kannst alles
vollgrafisch darstellen und bedienen (popup-fenster usw.).
das ist jetzt nur mal ein vorschlag, der eigentlich nicht wirklich hier
in diesen thread passt.
kannst mir auf pebu66@gmx.at genaueres schreiben falls daran interesse
bestehen sollte
gruß
peter

Autor: DirkP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@peter

auch darüber habe ich schon mal nachgedacht. Aber bei einer absehbaren
Stückzahl von 5 lohnt sich der Aufwand nicht. Prinzipiell würde ich mir
so eine Steuerung mit AVR auch zutrauen aber eine Industrielösung, die
auch bei wechselnder Hardware (austausch von Pumpen gegen andere
Modelle) modifiziert werden kann, ist sicherlich der bessere Weg.

So ein Touchpanel ist schon eine feine Sache. Aber an einem mobilen
Gerät, das auch mal mit einem 13er Schlüssel in der Hand bedient werden
soll, nicht das Optimum. Da finde ich ordinäre  und robuste Schalter und
Knöpfe für die wichtigen Funktionen besser.

Trotzdem Danke für die Vorschläge.

Gruss
Dirk

Autor: Stefan G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hier gibt eine microSPS-Umsetzung für einen AVR:
http://www.microsps.com

Als Editor wird EAGLE benutzt...

Gruss.

Autor: thomas stürmer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo dirk,
ich habe durch zufall dieses forum gefunden und bin sehr interessiert
an dem projekt. ich komme eher von der sps seite und bin nicht so der
microcontroller hacker. zum thema unitronics kann ich jedoch ein paar
infos geben da ich Mit den dingern schon einige jahre arbeite. die
neuen geräte der vision serie sind gut zu programmieren und bieten jede
menge features. die m90 und m91 sind nur für sehr kleine projekte. die
steuerungen basieren auf dem c164 (v120) und dem c167 von infineon
(v230,260,280).ethernet gibts leider nur auf den c167 versionen.
standhaft sind die spsen allemal, denn wir setzen sie auch im
alpinbereich für schneekanonen ein.jedoch haben die dinger auch
probleme. zum einen ist die can schnittstelle nur zur kommunikation
zwischen unitronics produkten gedacht und kann nicht als feldbus
verwendet werden und das andere problem ist, dass nur in
kontaktplanprogrammiert werden kann und so große projekte zur
"malarbeit" ausarten.übrigens die software und toolls wie opc,dde
server sind kostenlos(nicht wie bei so siemens)!.auch eine com libary
für c,vb,delphi steht zur kostenlos zur verfügung.sollte noch jemand
infos über die dinger benötigen so stehe ich gerne zur
verfügung.preislich startet die v120 bei ca.250eur kommt immer  auf die
stückzahl und ausführung an eine v280 mit i/o modul geht für ca. 700eur
über den ladentisch.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ein feriges Projekt gibt es schon ATMEL Chip und viel drumherum.
http://www.muff-electronic.ch/

Software ist umsonst, macht spass, habe eine Hausautomation mit Temp.
Steuerung, Rollo, Heizung gebaut.

Servus DIRK S.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin gerade auf dieses projekt gestoßen und finde es sehr
interessant. Ich arbeite beruflich mit der CoDeSys SPS auf einem XC167
Controller von Infineon. Ich könnte mit den folgenden Fähigkeiten
dienen um das Projekt voranzubringen:

- Hardwareentwicklung digital
- Hardwareentwicklung analog
- Layouterstellung
- Einsatz von PLD bzw. FPGA
- Programmierung von µC in C
- Erfahrung mit CAN
- Erfahrung mit CANOpen
- Erfahrung in der Programmierung von HMIs

Wenn das Projekt etwas werdemn soll, müsste man eine eigene Homepage
dafür einrichten um vernünftig kommunizieren zu können und Daten
auszutauschen. Des weiteren sollten zuersteinmal die Features festgelet
werden.

Gruß Mario

Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tönt wirklich sehr interessant das Projekt, aber ehlichgesagt hab ich
nach ner dreiviertelstunde lesen mühe mir ein genaues bild zu machen,
wie die Hardware-spezifikationen jetzt aussehen sollen, oder wie
leistungsstark der uP sein soll...

Wäre wohl mal an der Zeit ne endgültige definition, mit einer
auflistung der nötigen Arbeiten zu machen...

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, von dem ganzen Gerede sind nur zwei Leute übrig geblieben, die an
der Sache weiter arbeiten:
Peter und ich

Wir haben uns für das FOX Board entschieden, da dort µP seitig schon
alles in einem BGA vereint ist und Linux schon komplett drauf läuft.
Für 40EUR ein unschlagbarer Preis.

Zur Weiterentwicklung der Software haben wir schon ein Eval board
fertig. Zwei Stück sind in der Mache.

Das BGA wird dann später einmal das Herzstück der SPS-CPU. Drum herum
kommen dann ein LCD, ein paar Tasten, USB, RS232 und RS485 zum Anschluß
der weiteren IO.

Soweit der Plan...

Gruß
   Uwe

Autor: Mustafa Burc (burc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
Ich bin ziemlich neu.
Ich finde sehr gute Idee was Sie vorhaben,
ich habe folgende Idee, ich bin dabei ein Web basierende Weather 
Datenlogger auf Linux basis zu programmieren, ich habe für Weather 
logger die source schon fertig, auf Linux habe sehr wenige Erfahrung, 
wer möchte mitmachen.
Ich habe folgende hardware Xscale PXA 270

Autor: fluppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen. Gibt es aktuelle Infos zu diesem Thema? Gruß,fluppi

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.