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..
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.
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.
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)
@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?
@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 ;)
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.
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?
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.
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
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.
