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
Gute Idee. Ich bin zwar noch in der Ausbildung, hätte aber schon Interesse.
Hallo, als Anregung, fals noch nicht bekannt: http://www.mikrocontroller.net/forum/read-4-62596.html Grüße Quark
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
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
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
> 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.
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
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
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
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.
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
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
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
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
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
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
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.
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/connectcore9c.jsp 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.
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
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
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
@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
@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
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.
@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
@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
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
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.dll/csfetch/21631481/ERTEC400_Handbuch_V100.pdf?func=cslib.csFetch&nodeid=21634799&forcedownload=true http://support.automation.siemens.com/WW/llisapi.dll/csfetch/21631586/EB400_Handbuch_V100.pdf?func=cslib.csFetch&nodeid=21633770&forcedownload=true MfG Achim
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
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
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
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
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
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)
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
Vielleicht könnte man Ulrich Radig noch zu dem Projekt dazugewinnen :-))) ???
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
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.
@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
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.
@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
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
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)
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
@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.
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
@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
@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
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.
@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
@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...
S5 Bytecodetabelle habe ich hier. Muss ich abschreiben :-( Wenn hier irgendwann mehr als reden rauskommt, werde ich auch aktiv :-) Uwe
@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
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
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
@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)
@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
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...
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.
für den amr7 gibt es auch schon eine opencanlib: http://www.canexperts.de/engl/canprod/sw_lib_atmel.html
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
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?
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.
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.
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
Es könnten mehrere Instanzen der SPS auf einem Rechner laufen, jede in einer eigenen Zeitscheibe. Datenaustausch z.B. über Shared.Memory.
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
Irrtum (...der Klugscheisser bricht durch), OB20/21 sind Kaltstart OB was du meinst sind OB 10 -13, die zeitgetriggertern Bausteine
Och Mensch, Klugscheisser :-)) Auf jeden Fall weiß jeder was gemeint war, und das zählt...
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
Wie wär's mit einem DC/DC-Wandler zur Printmontage (z.B. von Reichelt)?
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
PC104 ist auch eine sehr gute, erprobte Basis mit allen möglichen Schnittstellen. Nicht sehr teuer. SG Lumpi
@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.
@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 :-)
Scheint so, dass das Projekt wohl gestorben ist... War ja vorhersagbar, wenn man das Thema Tod diskutiert und sich nie einig wird...
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
Hallo, in der aktuellen CT ist ein recht interressantes Produkt : http://www.taskit.de/en/products/microarm/ Gruss, Peter
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
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
@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
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
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
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
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
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
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...
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
Wieso nicht? Da müsste man noch mal beim Elektronikladen nachfragen ob sich das denn lohnt.
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
Wo soll denn die SPS eingesetzt werden (was soll sie können ) ? SG Baldwin
@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
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
@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
@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
Hallo, hier gibt eine microSPS-Umsetzung für einen AVR: http://www.microsps.com Als Editor wird EAGLE benutzt... Gruss.
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.
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.
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
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...
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.