Hallo Leute Ich hoffe ich bin im richtigen Forum... Ich bin auf der Suche nach einem guten Kommunikations Protokoll für folgende Anwendung: Ich stell gerade ein neues Testsystem zusammen und nun stellt sich die Frage wie ich die Relais MUX Karten am besten anspreche. Der Aufbau ist ca. so: PC- > FTDI2232H -> RS485 -> ~Kabel~ -> RS485 -> AVR Der AVR schiebt dann über SPI die Daten auf einige 74HC595 raus wobei diese Anzahl immer unterschiedlich sein kann (also einmal nur 4x8bit oder auch 12x8bit). Weiters würde ich gerne die Möglichkeit für DA/AD Wandler nicht verbauen und natürlich auch digitale Eingänge (74HC165) sollten sich verbauen lassen. Am liebsten würde ich nur eine Software für den AVR schreiben und per Protokoll die HW abbilden lassen. Ich dachte schon an ModBus, aber der ist gerade bei den analogen Sachen (AD/DA Wandler) nicht gerade geeigent, oder? Was würden die alten Hasen in diesem Fall verwenden. Es gibt sicher genug bei euch die so etwas ähnliches auch schon mal aufbauen mussten... ich danke schonmal für die Infos! Günter
Wie zeitkritisch ist die Übertragung? Wie häufig müssen die Ausgänge geschaltet werden?
Ups, ganz vergessen, sorry Zeit ist unkritisch und so ein setztvorgang sollte in ca. 1ms gemacht sein. Wenns 5ms dauert ist es aber auch egal... So ein Setzvorgang wird ca. einmal pro Sekunde gemacht. Bei den DA Wandlern könnte es schneller werden aber nicht schnaller als 50-100ms.
Hmm.
Gibt es Einwände gegen
Ausgang setzen
**************
S<Nr>=<Wert>;
S ... Setze
<Nr> ... Nummer des Ausgangs. Ausgänge werden einfach durchnummeriert
Ein ev. DA WAndler hat genauso eine Nummer
<Wert> ... Wert der zu setzen ist.
Bei ordinären I/O ist das 0 oder 1
Bei analogen Ausgängen ist das der Wert für den DA Wandler
; ... Abschluss des Kommandos
?<Nr>;
******
Eingang abfragen
Der entsprechende Eingang schickt seinen Wert zurück. Wieder
digital: 0 / 1
analog: entsprechender Zahlenwert
Format könnte zb sein
V<Nr>=<Wert>;
V ... Value of
<Nr> ... Nummer des Eingangs
<Wert> ... Wert des Eingangs
Selbigen Datensatz könnte der Peripheriebaustein auch selbsttätig
generieren und zum Host schicken, wenn sich sein Eingang verändert hat.
Das könnte man vom Host aus zb auch einstellbar machen ob er das darf
oder nicht.
Ich hab vergessen zu sagen, dass ich mehrere Slaves auf der Schnittstelle habe. Master soll also immer der PC sein. Ich brauche also bei den Slaves eine Adresse. Bei deinem Vorschlag wäre noch ein Nachteil, dass ich für jedes Relais einen Befehl brauche. Ich dachte eher an sowas: <Start><Addr><DatenType><Anzahl Byte><n Daten><CRC><Ende> DatenTyp wäre hier also In, Out, DA oder AD. Die passenden Daten würde ich im PC verwalten. Der µC soll hier einfach nur "dumm" das passende dazu machen. Beispiel bei mir: <Start><Addr><DatenType><Anzahl Byte><n Daten><CRC><Ende> # 12 1 4 12 1 0 0 crc ; Ich muss auf jeden Fall verhindern, dass in den Daten ein <Start><Adresse> vor kommt. Ich hoffe du verstehst auf was ich raus will...
Günter R. schrieb: > Bei deinem Vorschlag wäre noch ein Nachteil, dass ich für jedes Relais > einen Befehl brauche. Genau deswegen hab ich nachgefragt, wie das Zeitverhalten aussieht :-) es hindert dich allerdings auch nichts Befehle zu postulieren, die dieses Manko beheben. Zb ein Broadcast, so dass alle Ausgänge darauf reagieren. Oder Broadcast für Ausgänge eines bestimmten Typs oder ... denk dir was aus :-) > <Start><Adresse> vor kommt. Ich hoffe du verstehst auf was ich raus > will... Ich weiß worauf du raus willst. Genau aus dem Grund hab ich nämlich ein Kommando einfach als Text aufgefasst. Dann ist diese Forderung nämlich leicht zu erfüllen, während sie bei rein binärer Übertragung eher schwer zu erfüllen ist (wenn auch nicht unmöglich). Und wenn du jetzt deine Bytes mal abzählst kommst du drauf, dass du auch nicht signifikant weniger Bytes brauchst :-) Wobei ich allerdings auch zugeben muss, dass ich eine gewisse Affinität zu textbasierten Protokollen habe. Warum? * weil sie bisher eigentlich immer schnell genug waren * die Frameintegrität ist leicht herzustellen * der Aufwand sie zu parsen hält sich in Grenzen * sie sind leicht zu testen solange das Frontend noch nicht fertig ist.
Ok, wenn ich ASCII übertrage, gehts natürlich. Heißt aber, dass ich im AVR ASCII -> Binär wandeln muss, find ich eher unschön. Natürlich ist es schöner wenn man mit horcht, aber wenn ich in der PC SW etwas mehr investiere, kann ich es auch lesbar nach außen tragen, was ich schicke. Naja, werd mir erst mal das Modbus RTU Protokoll anschauen. Evtl. lässt es sich ja "billig" erweitern. Danke trotzdem für die Hilfe!
>Heißt aber, dass ich im >AVR ASCII -> Binär wandeln muss, find ich eher unschön. Durch die Redundanz kannst Du aber besser auf Fehler prüfen. So dürfen in einem numerischen Feld nur Zeichen '0' - '9' vorkommen. Auch Zeichen wie '=' oder ';' synchronisieren die Daten. Eine andere Möglichkeit wären gepackte Hexwerte, wo dann nur '0' - '9' und 'A' - 'F' vorkommen dürfen. Ich nehme immer gerne Befehle, die wie Datenzeilen eines Intel-Hex-Formates aufgebaut sind. Die enthaltene Prüfsumme sichert nochmals ab. Dafür ist es schwieriger per Terminal zu simulieren und mitzulesen.
Es gibt beim blauen C eine Relaiskarte die ist kaskadierbar, da kannst Du mal nachschauen, wie die das gelöst haben: http://www.produktinfo.conrad.com/datenblaetter/175000-199999/197720-an-01-ml-8FACH_RELAISKARTE_24V_7A_de_en_fr_nl.pdf Ich tendiere auch eher zu Textbasierten Protokollen, zum Beispiel eine Untermenge von SCPI, gk
Ok der Ansatz mit hex find ich gut. Damit lässt es sich eigentlich lesbar und für den µC gut machen. Beispiel: <Start><Addr><DatenType><Anzahl Byte><n Daten><CRC><Ende> # 001 01 08 00100A00 crc ; Damit wäre der Byte "Verbrauch" relativ gering und der µC muss bei den Daten immer nur zweier Pakete wandeln. Adresse fix auf drei Byte damit hätte ich 4095 Adressen. 255 verschieden Datentypen reicht auch und 255 für numBytes reicht auch. Ich denke damit sollte es klapppen! Werds mal implementieren und schauen obs noch irgendwo klemmt... Danke nochmal
Hi Günter, nimm für sowas ModBus ist recht verbreitet und ist recht einfach zu programmieren. Wenn du dafür Hilfe brauchst, hier wird dir geholfen. www.modbus.org Stephan
@Stephan Ich hab mir das Modbus vorher schon angeschaut, aber AD/DA Sachen sidn in diesm Protokoll meines Erachtens nicht wirklich abgebildet. Da hätte ich bei meinem eigenen Protokoll viel mehr Möglichkeiten. Ok bei Modbus RTU bräuchte ich ein paar Bytes weniger, habe aber dadurch einige Nachteile (Lesbarkeit, max. 255 Adressen, usw.). Weiters muss ich beim RTU aufs Timing achten, was beim eigenen durch Start und Ende komplett fallen würde. Kurz gesagt, was bringt mir hier Modus? Es wird einen Grund geben, sonst würdest du Modbus ja nicht vorschlagen gg
Hi, also in Modbus ist auf 16Bit Werten, sogenannten Registern aufgebaut. Was sich in den Reg. befindet ist Definitionssache. AD / DA Werte werden in in ein Reg. abgelegt und gut. Lass das mit dem RTU weg, ist zu alt. Das andere, binäre, ist besser geeignet und lässt sich auch gut lesen. Die Beschränkung auf 255 Slaves stimmt aber. Stephan
Naja wenn ich RTU nicht nehmen soll, bleibt ja nur Modbus ASCII übrig. Da hab ich meiner Meinung nach mehr Daten als bei meinem eigenen. Ich brauche für 32 I/Os 19 bytes, Modbus im Ascii Mode braucht 27 bytes. OK Modbus wäre ein Standard Protokoll was natürlich wieder als pos. anzusehen wäre. Aber ich habe dann immer noch das Problem, dass ich meine Sonderfunktionen in die bestehende Modbus Funktionliste packen muss. Und dann bin ich meines Erachtens wieder weg von einem Standard. Dazu kommt, dass ich bei meinem Protokoll noch eine Sende Adresse hinzufügen könnte und somit auch Interrupts oder ähnliches realisieren könnte. Ich werd jetzt erst mal mein eigenes ausprobieren und wenn das nicht klappen sollte, kann ich immer noch mit Modbus herum probieren. Gruß Günter
Hi,
>Naja wenn ich RTU nicht nehmen soll, bleibt ja nur Modbus ASCII übrig.
sorry, meinte natürlich anders rum, RTU ist das richtige und das ASCII
das ältere.
Bin halt schon etwas raus, sorry.
Stephan
Und ich dachte schon ich spinne gg Eben aber die RTU Sache hat die Pflichtpausen und den min. Abstand zwischen Befehlen drin. Da kann ich mir vor stellen, dass der FTDI (hab schon genug mit dem Ding mit gemacht) nicht immer so brav mit macht. Wenn ich mir von dem Teil die Timings anschaue, stell ich immer wieder solche Lücken zwischen einzelnen Blöcken fest. Naja, werd mal basteln und dann wird es sich schon zeigen, was sich besser eignet. Gruß Günter
Schau dir doch mal das S.N.A.P. Protokoll an, ich finde es eigentlich ganz gut und vor allem sehr universell: http://www.kreatives-chaos.com/artikel/snap-protokoll http://www.hth.com/snap/ Christian
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.