Hallo, sitze gerade an einem "SPS"-Projekt. Möchte mir eine kleine Steuerung bauen. Habe erste Versuche mit dem IO-Warrior (USB-Device, 32IO's) erfolgreicht hinter mir. Möchte nun auf Linux mit RTAI umsteigen. Hab ein kleines VIA Epia irgendwasboard.. lüfterlos mit C3 Prozessor. Hab da keine besonderen Schnittstellen, nur Standart LPT und einmal COM. Wie bekomme ich da nun am besten Eingäng/AUsgänge angeschlossen? Läuft die Kommunikation per Com/LPT ebenfalls im mikrosekundenbereich ab, oder brauch ich da spezielle pci-io karten? als ein/ausgabe baugruppen möchte ich gerne jeweils 16Kanäle haben. Die Bausteine sollen alle über einen Bus angesteuert werden. Insgesamt ca. 15 solcher Baugruppen. Ist die serielle Standartschnittstelle überhaupt schnell genug? Was würdet ihr mir raten? Alternative wäre ein ARM7 und dann per SPI CAN oder eigenem Bus über die IO's auf Schieberegister/Latches usw.da fehlt mir dann nur leider die Grafikarte für die Visualisierung..
> Ist die serielle Standartschnittstelle überhaupt schnell genug?
Welche Datenmengen sollen übertragen werden?
Hallo, keine Ahnung wieviel genau, es sollen wie gesagt maximal 15 Module angeschlossen werden, die jeweils als 16IO arbeiten, also 2 Byte.. ein paar Steuerdaten drumrum und das wars.
Ich vermute, das eine RS232 diesen "geringen" Datenstrom nebenbei erledigen könnte ;)
Naja... kommt darauf an, oben stand ja was von mikrosekunden... pro µs 2*15 Bytes sind 30 Megabytes pro Sekunde. Das wird nix über RS232, auch PCI wird da schon an seine Grenzen stossen.
Also ich werde meine Software so aufbauen dass sie deterministisch im 1ms Takt arbeitet. Spricht jede ms alles einmal einlesen und wieder ausgeben. Die Mikrosekundenangabe bezog sich nur auf die Interruptfähigkeit und das Timing des Schedulers, hatte mich wohl etwas falsch ausgedrückt. Wollte damit wissen, ob es da gewisse Latenzzeiten bei der Ausgabs per RS232 gibt, oder ob da nur die Datenübertrarungsrate den Engpass darstellt und ob eine Echtzeiterweiterung wie RTAI aus dem Kernel direkten Zugriff auf die Schnittstelle hat und somit die Echtzeit erfüllt. Müsste aber eigentlich der fall sein. Also wenn man mit 1ms Zykluszeit rechnet: 2Byte Daten 1Byte Adressierung der Module und eventuell nochmal 1Byte Steuerdaten? Kenn mich da nicht aus. Wären jedenfalls 4Byte daten pro Modul. Bei 15 Module wären es schon 60Byte/ms sprich 60kB/s, ist das soweit korrekt? Bis zu welcher Geschwindigkeit arbeitet RS232? Frage zur externen Hardware: wie sieht denn das passende Gegenstück für so eine Schnittstelle aus? Brauche da einen Controller, richtig? Wollte die einzelnen Module eh mit einem kleinen Controller ausstatten zwecks Identifizierung, Zwischenpufferung. Oder haltet ihr die Lösung für zu kompliziert?
> Bis zu welcher Geschwindigkeit arbeitet RS232?
Die Onboard-Schnittstelle Deines Motherboards kann wie jede andere
Standard-Schnittstelle eines PCs maximal 11520 Bytes pro Sekunde
übertragen.
Desweiteren arbeitet eine serielle Schnittstelle selbstverständlich mit
einer gewissen Latenzzeit - es dauert halt eine definierte Zeit, ein
einzelnes Byte zu versenden und zu empfangen. Je nach verwendeter
Hardware und Programmierung selbiger kommen noch diverse Hard- und
Softwarepuffer dazwischen, die das ganze noch deutlich verzögern.
Also ist das eine für Deine Anforderungen denkbar ungeeignete
Schnittstelle.
Du wirst um eine PCI-Karte nicht umhinkommen, oder aber sehr viel der
"Intelligenz" in externe per USB/Ethernet angebundene Hardware auslagern
müssen, da KEINE der üblichen PC-Schnittstellen für die von Dir
genannten kurzen Reaktionszeiten geeignet ist.
Was würde die eine Interrupt-Reaktionszeit im µs-Bereich bringen wenn Du nur jede ms die Daten abrufst/sendest. Soll noch irgendwas Lokal auf den I/O Bausteinen passieren (Datenaufbereitung, Reaktion auf Events) oder sind das nur dumme Bausteine die ausschließlich Daten zum/vom PC bekommen? Wie sollen die max. 15 Baugruppen kommunizieren und wie weit liegen die auseinander? Was willst Du überhaupt messen/steuern? Vielleicht reicht ja auch weniger Speed. Möglicherweise reicht ein "Kommunikations-Master" und mehrer I/O-Slaves (evtl. reine I2C-Bausteine) die per SPI oder I2C am Master dranhängen.
Echtzeit mit dem PC ? Das wird muehsam und teuer. Besser in einen Controller auslagern.
Der Parallelport kann max. 2.4MByte/s im (mist, hab den modinamen vergessen) jedenfalls mit DMA.
Hi Also über den COM Anschluss gehen bis zu 115200 Byte pro sekunde(115Byte / 1ms) die Hardwarepuffer schaltet man im PC einfach ab, die braucht man in der regel nicht. Der Dateneingang ist ja problemlos mit interrupts zu handeln. Wenn du einen ATMEGA128 benutzt kannst du pro uC schon 49 IO's abdecken und hast dann trotztem noch die 2 UARTS zur kommunikation frei. Also für "SPS-Zwecke" durchaus ausreichend. Fertige IO-Karten sind meist sehr teuer. Also lieber selber bauen :) MfG Michael alias Lanhazza
Lanhazza wrote: > Hi > > Also über den COM Anschluss gehen bis zu 115200 Byte pro sekunde(115Byte > / 1ms) Ne. 115200 Bit/s. Macht 11520 Byte/s bei 8Bit 1 Start, 1 Stop. (Siehe Rufus oben)
hallo wie weit sind die einzelnen Baugruppen entfernd? mfg Florian
@nullpainter: mühsam? teuer? open source? das ganze kostet keinen pfenning und ist vom aufwand ziemlich überschaubar. @Jörg B.: die IO Bausteine sind dumm, sind sogesehen nur Porterweiterungen. Zu einem späteren Zeitpunkt will ich auch Positioniermodule, sowie AD DA Wandler ansteuern. Da komm ich natürlich um einen Controller nicht drumrum. An die Bausteine kommt ein bisschen Eleltronik für 24V Relais, Eingangsseitig Optokoppler, alles auf 24V Basis. Das ganze lieget nah beieinander, im 19" Rack. Maximal 6HE auseinander. Untereinander sollen die Baugruppen gar nicht kommunizieren können. Nur zur HauptCPU, wo ich am liebsten einen "StandartPC" nehmen möchte. Da habe ich aber halt keine SPI oder I2C Schnittstelle, sondern nur LPT oder RS232. Wichtig ist halt, dass das Lesen nicht länger als 1ms dauert. Zur schnellen Reaktionszeit im Mikrosekundenbereich: Natürlich ist das wichtig, ich brauch schließlich ein deterministisches Zeitverhalten mit kleinem Jitter. Dass ich im Endeffekt nur mit einer Auflösung von 1ms als Zykluszeit arbeite hat damit ja nicht viel zu tun. Könnte ja auch 500mikrosekunden oder sonst was nehmen, natürlich wird dadurch der Datenverkehr zu den IO's größer. Und einen 1ms Takt kann ich halt nur mit einem EchtzeitOS realisieren.. @ Rufus t. Firefly Hard und Softwarepuffer: über welche Größenordnung sprechen wir denn da? Wenn in einem RTOS im Kernel auf die Schnittstelle zugegriffen wird ist doch gar kein Softwarepuffer mehr dazwischen, oder sehe ich da was falsch? Ich hab doch dann direkten Zugriff auf die Schnittstelle. Ethernet und USB hat doch viel zu viel Overhead und benötigt erst recht spezielle Echtzeiterweiterungen für die Protokolle, das kann ich vergessen. Bei Pcikarten weiß ich leider auch nicht, wie ich die direkt aus dem Kernel ansprechen kann. Kenn sowas nur über die Treiber die dabei sind. Scheint mir also, dass ein eigenener Microcontroller doch einfacher ist. Was ist von einem Arm7 zu halten, auf dem ein RTOS Linux läuft, der auch Grafikchip hat, also nix anderes als ein kleiner PC, nur dass der ARM noch freie IOpins hat, aus denen ich ja dann einen schnellen Bus bauen kann!? Oder halt die LPT Lösung, 2,4MB/s klingt doch gut. Wieviel Datenleitungen hab ich denn da zur Verfügung?
@Lanhazza: 115200Byte? eben schrieb einer was von 11520, was ist denn nun richtig? 115kByte würden mir ja wirklich ausreichen. Und wenn ich damit nicht auskomme kann ich mir doch eine zusätzliche RS232 Pcikarte einbauen und kann darauf unabhängig zugreifen, richtig?
ah okay, hab die bits und byte verwechselung gerade erst gelesen..
@Florian Die Baugruppen sitzen alle nebeneinander in einem 19" Rack. Also nur ein paar CM. 3HE hoch. eventuell das ganze 2mal übereinander, also wird der Bus 2mal 19" lang, plus Verbindungsstrecke Zwischen den beiden Racks. Frage: RS232 ist doch ne Punkt zu Punkt Verbindung, oder? Hätte ja dann verschiedene IO Module, Brauch ich also auch mehrere RS232 Schnittstellen im Rechner, oder wie?
Ein PC ist nicht automatisch echtzeittauglich nur weil er GHz schnell ist. Es gibt Echtzeiterweiterungen, die schieben dem Windows einen anderen Scheduler unter, die sind aber satt teuer. Ein Soft-realtime-kernel ist um die 7kEuro, ein Hard-Realtimekernel ist 20kEuro. Soft-realtime heisst, die Zeitlimiten werden in den meisten Faellen eingehalten. Hard-realtime heisst, die Zeiten werden immer eingehalten. Windows selbst ist nicht mal soft. Da fehlt noch einiges. Daher hat man die kritsche Intelligenz falls moeglich in einem Controller und aendert dort nur ein paar parameter. Unter kritschen Intelligenz verstehe ich das sichere Funktionieren einer Maschine, eines Prozesses.
Nun, um die Interruptlast nicht ausufern zu lassen, wurde in der Standard-UART des PCs (16550) ein Sende- und Empfangsfifo mit jeweils 16 Bytes Größe eingerichtet. Dadurch lässt sich die Interruptlast auf ein erträgliches Maß reduzieren (Lesen/Senden mehrerer Bytes pro Interrupt). Der lässt sich zwar abschalten, aber das erzeugt eine signifikant höhere Interruptlast (bei den genannten 115200 Baud also etwa 11 kHz Interruptrate). Bedenkt man, daß die I/O-Architektur des PCs gerade bei der Anbindung der Standard-ISA-Hardware wahrlich steinzeitlich ist (gerade mal 8 MHz effektiver Bustakt), dann bremsen I/O-Zugriffe auf die serielle Schnittstelle das System nicht unerheblich aus. Ein einzelner I/O-Zugriff dauert unter optimalen Bedingungen vier Taktzyklen, dauert also 500 nsec. Damit sind bei 11520 Bytes pro Sekunde bei nur einem Lesezugriff je Byte 5760 µSec einer Sekunde "verballert" (immerhin knapp 6 Promille). Und es werden für jedes einzelne Byte deutlich mehr Zugriffe erforderlich sein, denn es wird im Interrupthandler des OS erst mal geprüft, warum die Schnittstelle ihren Interrupt ausgelöst hat (könnte ja auch Hardwarehandshake oder dergl. sein), dann wird bei Fifo-Nutzung dessen Füllstand geprüft ... Das ist also auf normaler PC-Hardware pröttenlangsam. Selbst wenn die mit einem 2 GHz-Doppelkernprozessor arbeitet. Daher meine Empfehlung: Lagere den gesamten zeitkritischen Krempel auf eigene Hardware aus, die kann wesentlich schneller auf externe Ereignisse reagieren als es ein PC könnte. Und verwende für die Schnittstelle zwischen PC und der externen Hardware ein timingunkritisches Protokoll oder lass den PC gleich ganz weg.
>Frage: RS232 ist doch ne Punkt zu Punkt Verbindung, oder? Hätte ja dann >verschiedene IO Module, Brauch ich also auch mehrere RS232 >Schnittstellen im Rechner, oder wie? prinzipiel ist es nicht als bus gedach, also punkt zu punkt. Ich wüde auf einen Leistungsfähigen Kontroller gehen und von dort über I2C alle Komponenten Ansprechen. Im normalfall geht sich das im uC "echtzeit" aus. Am PC schauts mit echtzeit nicht so toll aus, vielleicht mit Linux aber mit Windows, glaub ich nicht. Also einfach: uC denken lassen und PC Zeichnen lassen g mfg Florian
entweder: du möchtest eine hohe datenrate gebrauchen, musst aber auf USB oder Ethernet oder Firewire oder sowas ähnliches setzen - und hast somit eine gewisse (für dich: inakzeptable) zeitverzögerung. oder: du hast eine kleine datenrate, und schnellen zugriff - da aber kleine datenrate kannst du die nicht mehr per OS bearbeiten (weil du nicht meh alle daten hast) oder: du lösst das problem ausserhalb deines OS, sprich in einem externen uC, der sich widerum von deinem OS steuern lässt (mit geringer datenrate) und ggf. nur die wichtigsten daten zum OS übermittelt, sprich nur statusänderungen o.ä. (die hoffentlich nicht bei allen modulen immer im 1ms takt ändern - aber ändern können). ich würde die "echzeit-behandlung" extern machen und den PC nur als "monitoring" verwenden. ...ich weiss halt nicht, was du alles echzeit behandelt haben willst ^^
Als Portbus bietet sich SPI, und RS422, und RS485 an. I2C ist schrott, da muss man immer die Richtung umschalten. Desgleichen mag ich RS485 nicht. Das SPI sollte mit richtigen Treibern gemacht werden, nicht mit dem Prozessorpins. Auch SPI ueber LVDS waere eine Moeglichkeit.
> I2C ist schrott, da muss man immer die Richtung umschalten. > Desgleichen mag ich RS485 nicht. Heißt "Desgleichen" hier, daß das wg. Richtungsumschaltung auch Schrott ist? Prinzipiell können modernere PC-UARTs das in Hardware (so beispielsweise die USB-RS232-Bridges von FTDI oder aber die PCI-UARTs von Oxford Semiconductor oder auch Exar).
@Nullpainter I2C ist schrott, ich bin dahingehend anderer Meinung, was stört dich an I2C? Würd mich interessieren, vielleicht ändere ich meine Meinung Grundsätzlich ist er echtzeifähig und auch Stand der Technik mfg Florian
@Nullpainter wieso sollte man spi nicht über die prozessorpins machen? hab gelesen dass die schneller sind als eine eigene version über die normalen ios.
zorstn wrote: > bauen. Habe erste Versuche mit dem IO-Warrior (USB-Device, 32IO's) > erfolgreicht hinter mir. USB Hat doch wenn ic hrecht erinnere 10ms Latenz... also ich würd sagen: Probiers aus! Kosten sind überschaubar... Und besser als wenn du 100te Euro ausgibst wenns auch so "einfach" auch geht...
@Nullpainter zum thema rtos. erstmal vorweg: der thread hier bezieht sich auf io bausteine, nicht auf os, trotzdem danke für die tipps, auch wenn ich damit nix anfangen kann. wie gesagt, es gibt diverse opensource echtzeiterweiterungen für linuxsystem, als auch opensource rtossystem für armprozessoren oder andere mikrocontroller. frage mich also, wieso du immer mit deinem teuer um die ecke kommst :)
zorstn wrote: > Frage: RS232 ist doch ne Punkt zu Punkt Verbindung, oder? Hätte ja dann > verschiedene IO Module, Brauch ich also auch mehrere RS232 > Schnittstellen im Rechner, oder wie? Das war das was ich mit dem "Kommunikations-Master" ausdrücken wollte. Es gibt einen µC der mit dem PC über RS232 in Verbindung steht und von dem aus dann die I/O-Module entweder gesteuert werden oder ihre Steuerkommandos über I2C oder SPI bekommen.
Aufgrund von welchen Kriterien wird denn die Richtung umgeschaltet ? Wenn nichts mehr kommt ? Man kann sich dem entziehen indem man 2 Faeden mehr hat, dann nennt sich das RS422. Problem geloest. I2C und RS485 ist nicht direkt vergleichbar. I2C ist eher fuer kurze Verbindungen, mit kurzen Packeten, waehrend RS485 zumindest hunderte von Metern bis Kilometer bringt. Ne, I2C mag noch lustig sein wenn man einen softI2C master schreibt, aber einen Soft I2C Slave ? Der macht nicht mehr viel anderes. Da ist SPI schon praktischer. Einen Interrupt dran und dann soll der mal uebertragen. Ja, einen Soft SPI slave zu schreiben ist auch unguenstig, da geschieht nicht mehr sehr viel.
Autor: Läubi Mail@laeubi.de (laeubi) Datum: 26.07.2007 14:17 zorstn wrote: > bauen. Habe erste Versuche mit dem IO-Warrior (USB-Device, 32IO's) > erfolgreicht hinter mir. USB Hat doch wenn ic hrecht erinnere 10ms Latenz... also ich würd sagen: Probiers aus! Kosten sind überschaubar... Und besser als wenn du 100te Euro ausgibst wenns auch so "einfach" auch geht... genau, viel zu langsam, wie ich schon sagte.. und ausprobiert hab ich es doch, wie ich schon sagte ;)
Mit ausprobieren mein ich die RS232 Sache!
Zum Thema SPI zwischen Boards. Mit TTL signalen zwischen den Modulen kommt die ganze EMV Problematik rein, du hast einen schnellen bus, den kannst du dort nicht filtern wo er arbeitet. Zusammen mit den SPI pins verbindest die GND der boards, dh da ist dann nichts mehr mit 16bit ADC und so. Ein differentieller Bus hingegen laesst sich, falls die GND Unterschiede der einzelnen Module hinreichend klein sind, ohne GND verbinden. Zudem koppelt ein differentieller Bus viel weniger und er strahlt auch weniger.
Man könnte SPI auch über Optokoppler anbinden da hier eine eindeutige Richtung pro Leitung vorliegt.
Sorry da hab ich mich vertüdelt 115200 Bit pro sekunde müssen es natürlich sein wären also ca 14 kByte pro sekunde also 14 Byte pro ms Aber darin lassen sich aber immernoch gut 80 io's drin verpacken(10*8bit)
und die vernetzung der ATMega128 geht bis zu 1Mbit sogar durch die interne hardware, was den uC weniger belastet. Ich hab bei einem ähnlichen System die uC's mit 500kBit/s vernetzt läuft einwandfrei. Aber da ich nicht weis wie zeitkritisch deine Signale sein müssen kann ich hier nichts weiter dazu beitragen. MfG Lanhazza
von emv und so hab ich nun mal gar keine ahnung. was ist denn nun von folgendem szenario zu halten: pc zur visualisierung und parametrierung <-rs232-> spscpu (arm7) übertragen werden die zustände der ein und ausgänge. da reicht mir eine auflösung von etwa 4Hz, also recht geringe datenmenge. spscpu: 16 ausgänge für 2 byte daten 5 ausgänge für demultiplexer zum adressieren von 16 modulen 1 ausgang clocksignal zum übernehmen der daten in den einzelnen modulen reicht da an den modulen ein einfaches schieberegister mit latch? oder gibts timingprobleme? ist ein microcontroller doch sinnvoller? Für die Inputs das gleiche, nur genau andersrum. macht zusammen 44 IO-Pins. Habe den SPI und I2C dann auf dem Steuerprozessor immernoch frei, falls ich ihn noch für andere Dinge brauche.
@ Lanhazza also über den internen spi bus der controller? das klingt gut soweit. nun stand da was von emv usw.. gibts da was besonderes zu beachten? geschirmte verbindungskabel oder sowas? wie siehts auf der leiterplatte aus. probleme? also zeitkritisch: wie gesagt, alle module solten innerhalb einer millisekunde ausgelesen sein. das würde reichen.
Lanhazza wrote: > Sorry da hab ich mich vertüdelt > > 115200 Bit pro sekunde müssen es natürlich sein > > wären also ca 14 kByte pro sekunde > also 14 Byte pro ms > Nein, das ist immernoch falsch. 115200 Bit/s werden gesendet. Davon gehen 10 Bits drauf, um 8 Bit Daten zu senden. Das macht 11520 Byte/s. Und dies wiederum sind 11520 Byte/s / 1024 = 11,25kiB/s. Bzw. 11520 Byte/s / 1000 = 11,52 Byte pro Millisekunde.
mal ne frage.. hab nun eine 32kanal ttl pci karte im auge. die wahnsinnigschnell ist. hab mir überlegt darüber nen bus zu bauen 8bit für input 5bit adressierung input 3bit handshake und das gleiche auch nochmal für output bus. oder das ganze kombinieren, mal sehen. das ganze wird maximal 1m lang sein. und direkt auf dem bus hängen kleien microcontroller. ist das so möglich? oder hab ich da spannungsverluste und das letzte modul bekommt von der adressierung überhaupt nix mehr mit?
Wenn Du sowas machen möchtest, könntest Du auch den guten alten GPIB/ieee488 wieder auferstehen lassen. Dafür gibt es fertige Interfacekarten, und die Übertragungsrate ist bei modernen Implementierungen auch nicht von schlechten Eltern. Vortei: Standardisierter Bus, standardisiertes Protokoll, standardisierte Steckverbinder - und auch das Problem von längeren Kabeln (ein paar Meter) ist geklärt.
davon hab ich gestern auch gelesen, preislich ähnlich die karte! und ziemlich schnell. eigentlich genau das richtige. allerdings 15 teilnehmer maximal, aber ads sollte reichen. frage nur: ist das protokoll schwer zu programmieren, bzw bekommz man da fertige c dateien fürn mikrocontroller?
Das ist anzunehmen, da es diese Schnittstelle schon seit einigen Jahrzehnten gibt.
hm ja, okay ;) dachte es hätte vielleicht jemand direkt nen link parat.. nochmal zu meiner lösung. kenn mich da elektrotechnisch nicht so aus, hatte mir das ja folgendermaßen vorgestellt: 5 ttl leitungen, daran hängen ca 10 emfänger, also alle in reihe sozusagen, als bus, und überprüfen gleichzeitig den pegel zur adressierung. geht das berhaupt? oder kann immer nur ein modul die 5 leitungen lesen?
nein, wie gesagt, die leitungen sind maximal 1m lang.. soll halt alles in ein 19" gehäuse.. und in der rückwand halt der bus wo einzelne module aufgesteckt werden können. das ganze 2mal, also ca. 1m
@zorstn: was für eine IO Karte ist das denn? Ich habe da auch mal nachgesehen: da die meist für den industriellen Bereich angeboten werden (NI, Meilhaus, DataTranslation usw) sind die für Hobbyzwecke rel. teuer. Low-Cost Netzwerkkarten oder Druckerinterfaces werden für unter 10€ verkauft, aber Multi IOs fangen eher bei 200€ an. Auch leere PCI Boards kosten schon 25€ (Reichelt) und da ist nicht mal ein PCI Interface drauf. Andere Frage: 1ms I/O ist für 'normale' SPS Aufgaben etwas schnell, einfache Taster oder Schalter prellen, die braucht man nicht so schnell. Antriebssteuerungen zur Positions oder Drehzahlregelung sind meist eigene intelligente Steuerungen die dann von der SPS nur Fahrbefehle bekommen. Bei 'gemütlichen' 5ms z.B. müsste man einen einfachen Ring mit serieller Technik hinbekommen.
es ist auch für den indutriellen anwendung, daher auch eine io karte. von quancom. pcittl32 oder so ähnlich heisst die. alternativ gpio karte. hab gelesen, dass kleine standartsps systeme auch mit 1-2ms latenz auf ihren eingängen arbeiten. sind auch alles industreielle näherungsschalter etc. also kein problem mit dem prellen. bis 5ms maximal 10ms wäre aber für die angeschlossenen geräte auch okay (hauptsächlich pneumatische antriebe). zum positionieren kommt natürlich nen eigenen microcontroller dran, die müssen natürlich schneller arbeiten, klar.
Industrielle Anwendung und dann soviel Selbstbauen? Das ist aber mutig... Wg. Gewährleistung, Wartung auch nach mehreren Jahren usw. Wir setzen auch eine Soft SPS unter Windows CE mit Zyklen bis runter zu 1ms für Messtechnik und Steuerung ein. Das System arbeitet mit Interbus Modulen von Phoenix, da hat man eine breite Palette an IOs (digital und analog, Opto-In, Encoder, Frequenzumrichter, Potenzialfrei usw.). Und vor allem gleich ordentliche Klemmen ohne viel Verdrahtungsaufwand. TTL Signale sind im industriellen Umfeld nicht das Wahre. Alternativ gibts da natürlich noch den Profibus, Modbus (Wago hat da ein universelles System) und Beckhoff hat Ethernet basierendes. Beim Interbus hängt die max. IO Frequenz an der Anzahl der Module, je mehr Module desto wird die IO Message die da immer 'im Kreis läuft'.
es ist nur für den eigenen betrieb. system wird nicht verkauft, von daher ist da alles im grünen bereich. nötige sicherheitstechnik drumrum ist natürlich vorhanden. von phoenix hab ich gestern eine preisliste bekommen. werde ich mir mal näher anschauen. prinzipiell spricht auch nichts gegen fertige sps systeme. aber durchs studium und interesse am fach würde ich gerne etwas eigenes machen. das ist der hintergrund. die ttl signale werden ja nicht wirklich im schaltschrank spazieren geführt. was benutzt denn zB. siemens bei ihren sps auf ihren backplanes? da gibst doch massig pins. könnte mir gut vorstellen, dass das auch nur ttl pegel ist um die einzelnen module anzusteuern. fürn seriellen bus wärs jedenfalls ein bisschen zu viel.. mehr, von der größendimensionierung, hab ich ja auch nicht vor, also hoffe ich dass ttl passt. die beckhoff komponenten finde ich auch sehr ansprechend. aus kostengründe und wie gesagt aus intersse daran, würde ich nur gerne etwas eigenes entwickeln. die hersteller solcher systeme lassen sich das ja immer ganz schön bezahlen. schaut man mal in ein modul rein entdeckt man nicht mehr als nen kleinen microcontroller, ein paar bauteile für die stromversorgung und das wars.. nach möglichkeit wird das auch das thema meiner bachelorarbeit. leider bin ich kein elektrotechniker, daher such ich hier meinen rat :)
Hallo, das einfachste ist es die Ausgänge RTS und DTR zu benützen. Man kann die Signale setzen (+12V -12V und mit 2 Z-Dioden und 2 Widerständen) auf TTL bringen. Ein Schieberegister z.B. 74HC164 genügt für 8 Ausgänge. + Einfach zu verdrahten (nur Masse und 2 Leitungen von RS232 zu verkegen. + Kosten ca 1-2 Euro + Leicht Kaskadierbar - Nicht sehr schnell, aber für Relais oder Lampen geeignet - Beim hinausschreiben ändert sich für kurze Zeit die Signale Gruß Fritz
Hallo, vielleicht noch eine Ergänzung, aus der man erkennt, wie einfach man mit LabVIEW (in Windows oder Linux oder PDA) diese Bits setzen kann. siehe Bild im Anhang Gruß Fritz
Du hast aber schon mitbekommen, um welche Anforderungen es hier eigentlich geht? "Bit-Banging" an der seriellen Schnittstelle ist noch ungeeigneter als die serielle Schnittstelle an sich, und das hatten wir etwas weiter oben im Thread bereits herausgefunden.
ehm ja.. bitte vielleicht mal alle einträge lesen.. und nur 8ports helfen mir nicht sonderlich weiter :D trotzdem danke für den beitrag.
zorstn wrote: > ehm ja.. bitte vielleicht mal alle einträge lesen.. und nur 8ports > helfen mir nicht sonderlich weiter :D trotzdem danke für den beitrag. Vielleicht solltest du mal die Beiträge lesen? Mit mehreren Schieberegistern lassen sich auch mehr als 8 "Ports" (Pins?) ansteuern. PS: Fritz: Es gibt auch Schieberegister mit Latch - Da hätte man das Problem des kurzen "Bitwacklers" auf den Pinnen nicht mehr. Müsste man gucken, wo man noch Pinne an der RS232 herkriegt ;)
@Simon: da der thread von mir ist, kannst du davon ausgehen, dass ich alles lese. und das thema schieberegister hintereinander schalten hatten wir ja schonmal, siehe geschwindigkeitsproblem der seriellen schnittstelle (maximal ca. 80 io pins).
Hallo, also unmöglich ist die Lösung mit RTS CTS und Schieberegistern nicht. 1) RTS mit Z-Diode auf 5 Volt bringen und an Clock des Schieberegisters. 2) DTR mit Z-Diode auf 5 Volt bringen und an Daten des Schieberegisters 3) TXD mit Z-Diode auf 5 Volt bringen und an "Latch-Ausgangs-Clock" des Schieberegisters Es ist dabei die Bautrate nicht Geschwindigkeitsbestimmend! Aufwand für Schaltung Spikes: 3 Widerstände 3 Z Dioden Pro 8 Datenleitungen 1 Stück 74HC595 (ist kaskadierbar). Gruß Fritz
Die Baudrate ist dabei nicht geschwindigkeitsbestimmend, sicher. Sondern die erzielbare Geschwindigkeit ist NOCH LANGSAMER. Bit-Banging ist auf einem PC die denkbar ungeeignetste Möglichkeit der Kommunikation mit irgendwelcher Peripherie. Bedingt durch des PCs I/O-Architektur kann per Bit-Banging an egal welcher Peripherie kein Takt mit mehr als 1 bis 2 MHz erzeugt werden - und dann ist das beteiligte OS, egal welches es ist, annähernd vollständig ausgebremst. Was also soll der Unfug?
Hallo, die geforderten 1 ms kann man mit einem Reat-Time Modul (Software) machen. z.B. bei LabVIEW siehe: http://sine.ni.com/nips/cds/view/p/lang/de/nid/13751 Enstprechende Lizenz hat in der Regel jede Hochschule oder ist auch in der Studentenversion enthalten. Auch Freunde von Matlab finden bei mathworks entsprechende Softwaretools. In dem Zeitraster vom 1 ms kann man in einer Schleife das Schieberegister laden. Eine Ausgabe eines Zeichens auf TXD benötigt nur ca 0,1 ms (115Bd) und das müßte im Zeitraster auch noch unterzubringen sein. Gruß Fritz
hey fritz, danke.. aber ein zeichen 0.1ms.. also 10 zeichen je ms.. ich brauch aber ca. 150 (io's)..
Hallo, Das Laden des Schieberegisters geht über die RTS und DTR Leitungen und ist relativ rasch. Das geht ohne Begrenzung dirch die Baud-Rate. Nur die Übernahme ins Ausgangregister erfolgt mit einem Zeichen auf dem normalen Signalausgang der RS232. Ob es sich wirklich in 1 ms ausgeht, kann ich zwar nicht garantieren, aber ein begründetes Argument, dass es unmöglich ist, kenne ich nicht. 1ms ist aber wirklich schon sehr schwierig. 10 ms würden alles erleichtern. (Das oben von mit als Bild angegebene Programm ist nicht für LabVIEW-Real-Time. Man muss dafür eine zeitgesteuerte Schleife verwenden!) Gruß Fritz
> Das Laden des Schieberegisters geht über die RTS und DTR Leitungen und > ist relativ rasch. Ich muss dem hartnäckig und wiederholt widersprechen. Du kannst auf einer PC-Hardware maximal mit 1 bis 2 MHz Takt an irgendwelchen Portpins wackeln, dann aber macht Dein PC, mit egal wieviel GHz er läuft, nichts anderes mehr. Das ist Murks.
Also meine Lösung sieht nun folgendermaßen aus. Via C3 600Mhz Mini ITX Quancom PCI TTL 32IO (bis zu 32MB/s!) Latenzzeit 200ns embedded Linux RTAI als Echtzeiterweiterung. um die 32 Ports zu erweitern, stelle ich mir folgendes vor. - zu Beginn setze ich 5 Ausgänge zur Adressierung eines Inputmoduls. - das Modul sendet ein "bereit zum Senden" Signal - die PCI Karte ein "bereit zum empfangen" Signal - das Modul berträgt 16 bit parallel auf die Eingänge der TTL-Karte - danach ein CLK Signal zum übernehmen der Daten - falls es sich um ein 32Input Modul handelt wird das ganze spiel noch einmal wiederholt (bereit zum senden, bereit zum empfangen...) falls nicht, wird direkt ein StopBit gesetzt. - die PCI-Karte adressiert nun das nächste IO-Modul usw. Dann Verarbeitung der Daten im PC. Dann Ausgabe: - Zuerst wieder die 5 Adressbits setzen um Ausgangsmodul bekanntzugeben - Das Entsprechende Modul schickt auf einer Leitung ein Signal zurück, dass es bereit ist. - die PCI Karte sendet über 8 Pins Daten - die PCI Karte sendet ein Clk Signal zum übernehmen im Modul - das Modul sendet ein Signal zur Bestätigung - die PCI Karte sendet entweder ein weiteres Byte, oder aber ein Signal um das übertragen der Daten zu beenden. - Nun wäre das nächste Modul an der Reihe. Für Input nehme ich 16 pins, weil ich auch ungefähr doppelt so viele Eingänge wie Ausgänge anschließe. 8 Bit Output Daten 16 Bit Input Daten 5 Bit Output Adressierung 2 Bit Output Bereit zum senden, Clk, 1 Bit Input Modul bereit zum senden/empfangen da wären meine 32 auch schon voll. Was haltet ihr davon? Spricht irgendetwas dagegen? Könnte man was verbessern!? Und jetzt bitte nicht wieder Vorschläge für RSR 232.. das ganz soll halt ziemlich Modular und erweiterungsfähig sein. Stelle mir die TTL Signal auf ner Backplane für ein 19" gehäuse vor. Leiterlänge jeweils max. 1m. Funktioniert das so, oder hat das letzte Modul gar kein Pegel mehr?
warum dann nicht gleich einen Industrie PC mit passiver Backplane (für mehr PCI Steckplätze) ? Dann nicht eine 32Bit IO Karte sondern mehrere von den 64Bit Karten oder bei Bedarf passende AD, DA oder sonstige IF Karten. Das 19" Gehäuse, die Backplane und der Selbstbau der IO Module ist da auch nicht billiger, vor allem wenn man die eigene Arbeitszeit mal mitrechnet. Schon die Steuerung von deinen >100 IOs wird einiges an Arbeitszeit verschlingen wenn du das auch selber machen willst. Ich steuere mit einem µC auch eine Reihe Schieberegister für ein Display an, die Datenleitungen sind ca. 80cm lang und das klappt auch. Aber wenn da ein Bit verloren geht zuckt das Display höchstens mal für einige µs, es passiert also nix schlimmes. Bei deinem Parallelbus mit vielen Signalen wäre wohl eine aktive Terminierung sinnvoll.
also selbstbau ist günstiger. fertige iotokoppler/relais pcikarten kosten schon ein stolzes sümmchen, wäre natürlich am einfachsten, ja, dass ein wenig eigene arbeit reingesteckt werden muss, klar. aber ist halt ein projekt, daher selbst bauen. die kosten für ein modul mit 32 eingänge dürften bei unter 50€ bleiben. und eine vervielfältigung geht ja recht schnell, wenns erst einmal fertig ist. werden dann schon geätze platinen für die ein/ausgabemodule. da ich zB bei den eingangsmodule mit 16bit parallel arbeite und maximal 2auslesevorgänge benötige (für 32inputs) und nach jedem senden/empfangen quittiere, müsste es doch eigentlich ohne fehler laufen, oder? dachte einfach an eine kleine timeoutroutine. wenn das lesen/senden in der zeit nicht vollzogen ist, dann wird erneut zugestellt. bei mehrmaligem scheitern wird ein fehler gemeldet.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.