Hallo Forumsmitglieder, ich hoffe Ihr könnt mir weiterhelfen. und Zwar geht es darum diesen Drucksensor http://www.reichelt.de/MPX-53DP/3/index.html?&ACTION=3&LA=446&ARTICLE=82335&artnr=MPX+53DP&SEARCH=freescale+drucksensor+mpx an einem Atmega zu Betreiben das Projekt dient dazu eine Vakuum sauganlage an Mehreren Stellen im System zu Überwachen und bei Vakuum-Problemen Alarm zu Schlagen. Die Sauganlage baut max -0,5 bar auf. mein Problem der Drucksensor liefert mir ein signal von 1,2mV / kPa köönt ihr mir helfen wie Ich das Signal richtig auswerten kann ? weil über google finde ich leider nichts passendes.
klar kann man dir helfen. wo liegt denn jetzt sein Problem? beim Umrechnen der Einheiten? beim Verstärken vom Signal? beim Einlesen mit dem ADC? bei Übertragen der Daten?
>Hauptsächlich beim Verstärken vom Signal Bitte schön: http://de.wikipedia.org/wiki/Instrumentenverst%C3%A4rker
Warum nimmst du nicht einen Drucksensor mit integrierter Kompensation und Verstärker?
- Weil er (vielleicht) jetzt schon diesen Sensor gekauft hat - Weil ihm dieser Sensor (vielleicht) vorgegeben wurde - Weil er ja (vielleicht) auch was lernen will/soll Es ist wohl generell besser, etwas mit Standardkomponenten selber aufzubauen. Zumal das hier ja wirklich keine Raketentechnik ist.
Lutz schrieb: > Es ist wohl generell besser, etwas mit Standardkomponenten selber > aufzubauen. Dein Handy ist aus Transistoren und Widerständen selbst gelötet? Oder hast du das etwa fertig gekauft? Bei mir ist es, ehrlich gesagt, schon lange her, dass ich einen OP aus Einzeltransistoren aufgebaut habe und statt eines µC eine Logikverknüpfung in handverlöteter DT-Logik verwendet habe. http://de.wikipedia.org/wiki/Diode-Transistor-Logik
Hi Frescale hat eine große Anzahl Appnotes zu Drucksensoren z.B. http://cache.freescale.com/files/sensors/doc/app_note/AN1100.pdf Hier zu finden http://www.freescale.com/search?client=search_documents&site=fsl_en&lang_cd=en&ulang=de&output=xml_no_dtd&proxystylesheet=search_style_fe&filter=0&getfields=*&rc=1&ie=UTF-8&access=p&sort=date:D:L:d1&entqr=3&entqrm=0&oe=UTF-8&ud=1&ip=89.14.45.86&wc=200&wc_mc=1&q=+inmeta:Asset_Type%3DDocuments+inmeta:type%3DApplication%2520Notes+inmeta:prodTypeCategory%3DSensors_Pressure%2520Sensors&dnavs=inmeta:Asset_Type%3DDocuments+inmeta:type%3DApplication%2520Notes+inmeta:prodTypeCategory%3DSensors_Pressure%2520Sensors MfG Spess
Lutz schrieb: > - Weil er ja (vielleicht) auch was lernen will/soll Lutz schrieb: > Zumal das hier ja wirklich keine Raketentechnik ist. @Mike: Das mußt du schon im Zusammenhang sehen. Mike schrieb: > Bei mir ist es, ehrlich gesagt, schon lange her, dass ich einen OP aus > Einzeltransistoren aufgebaut habe und statt eines µC eine > Logikverknüpfung in handverlöteter DT-Logik verwendet habe. Also gab es damals® noch keine IC's? ;-)
Lutz schrieb: > Also gab es damals® noch keine IC's? ;-) Zumindest waren viele, gemessen am Taschengeld, schweineteuer. Da standen Drucksensoren, wie BMP085, BMP180 oder MS5611, die einem die Druckdaten für wenige Euro fertig für die digitale Weiterverarbeitung auf dem Silbertablett präsentieren, gar nicht zur Debatte. ;-)
Lutz schrieb: > - Weil er (vielleicht) jetzt schon diesen Sensor gekauft hat > - Weil ihm dieser Sensor (vielleicht) vorgegeben wurde > - Weil er ja (vielleicht) auch was lernen will/soll > ... Tja, Lutz, vielleicht sollte Andreas selber antworten? Er wird die Antworten nämlich kennen.
spess53 schrieb: > Frescale hat eine große Anzahl Appnotes zu Drucksensoren > > z.B. > > http://cache.freescale.com/files/sensors/doc/app_note/AN1100.pdf Danke Erstmal für die vielen Antworten. @ spess53 - ist dies ein Vorschlag wie Ich meinen Sensor anschließen soll/muss ? oder nur ein Beispiel ? @ Lutz - Ja ich habe den Sensor bereits gekauft und Ja ich möchte natürlich lernen. @ alle - mein Problem ist das Budget wo Ich für dieses Projekt habe ist sehr gering und da Ich ja Alleine schon 5-6 Drucksensoren brauche schlägt dies schon gewaltig zu. Außerdem sollte es mit möglichst vielen fertig Komponenten ( bezogen auf Signal Verstärken ) geschehen. Außerdem wird Das Signal über eine Leitungslänge von ca 35 m Transportiert ( könnte dies eine Rolle Spielen bzgl. Leitungswiederstand ??? ) mir wäre natürlich ein "einfacher" Signalverstärker lieber vorallem müsste es was sein wo Ich wüsste wie Ich dies Anschließen muss. Vielen Dank Schonmal für Hilfe
Andreas Hermann schrieb: > @ alle - mein Problem ist das Budget wo Ich für dieses Projekt habe > ist sehr gering und da Ich ja Alleine schon 5-6 Drucksensoren brauche > schlägt dies schon gewaltig zu. Von dem BMP180 kosten 5 Stück, fertig auf einem Board zum direkten Anschluss an den Arduino, zusammen weniger als einer deiner MPX-53, beispielsweise ebay 400567862490
Hallo Wolfgang, danke für deinen Tipp. Problem nur der Drucksensor muss einen Schlauchanschluss haben. leider hatte Ich vergessen dies zu erwähnen =(
Also ich würde das Signal direkt am sensor messen und digital wandeln. Bei 35m sollte das schon lieber digital übertragen werden. Evtl auch wegen umgebungstörungen?
Jörg Esser schrieb: > Also ich würde das Signal direkt am sensor messen und digital wandeln. > Bei 35m sollte das schon > lieber digital übertragen werden. Evtl auch wegen umgebungstörungen? könntest du mir Erklären wie Ich das am Einfachsten machen würde ?
Andreas Hermann schrieb: > Jörg Esser schrieb: >> Also ich würde das Signal direkt am sensor messen und digital wandeln. >> Bei 35m sollte das schon >> lieber digital übertragen werden. Evtl auch wegen umgebungstörungen? > > könntest du mir Erklären wie Ich das am Einfachsten machen würde ? Du könntest einen ATTiny25/45/85 mit eingebautem Differenzverstärker nehmen, der Verstärkung und Digitalisierung übernimmt - wenn dir die 10 Bit des internen A/D Wandlers genügen. Da der ATTiny auch einen eingebauten Temperatursensor hat, könnte er auch gleich den Temperaturgang des Sensors kompensieren. Jeder Sensor bekommt so einen MC 'Kopf'. Ein geschickt gemachtes 1-Wire oder 2-Wire Protokoll (z.B. langsames SPI oder I²C) könnte dann alle Sensoren auf einen gemeinsamen Bus bringen.
Brauchst Du den tatsächlichen Sensorwert? Oder soll er einfach nur bei Unterschreiten eines bestimmten Wertes ein Alarmsignal geben? Für letzteres brauchst du nur einen (einstellaren) Vergleichswert, da könnte schon ein Poti reichen, und ein Komparator pro Sensor. Fertig ist das binäre Ausgangssignal. Eine weitere analog zu digital Wandlung wäre nicht nötig. Das sind keine teuren Teile. Da wäre kein Mikrocontroller und keine Software nötig. Eventuell benötigst du noch eine Schaltung mit Operationsverstärkern, wenn Du das Signal vergrößern willst um den Schwellwert und die Hysterese etwas genauer eintstellen zu können. Auch das ist kein Hexenwerk. Um das zu vertiefen müßten die Anforderungen aber genauer beschrieben werden.
:
Bearbeitet durch User
Also ich benötige die Tatsächlichen Sensorwerte da eben 3 Sensoren in einer Vakuumleitung sitzen und eben ich den genauen Druck brauche. Wenn es möglich ist alle Sensoren auf eine Leitung zu bringen wäre natürlich nicht schlecht. Also nochmal zu Veranschaulichung der Tatsachen: Ich habe eine Vakuumsystem bei der -0,5 bar aufgebaut werden. Es Sitzen je 3 Sensoren in einer Leitung ( Abstand dazwischen ca 40 m ) und je nachdem bei welchen Sensor der Druck zuerst wegfällt sollte dieser Alarm schlagen und der Atmega soll ein Relais Schalten und dies Optisch an einer Schalttafel ( dort ist die Halle mit den Vakuumleitungen und den Bereichen der Sensoren abgebildet) anzeigen. Eingesetzter Sensor ist der MPX-53 der ein Signal von 1,2mV / kPa ausgibt somit habe ich bei vollem Vakkum 0,6 V. Der Alarmwert sollte ca -0,3 bar sein . Ich hoffe ich habe jetzt nichts vergessen. vll könnte mir ja jemand eine skizze machen wie Ich das System mit den Sensoren zusammenbasteln muss.
Darf man fragen wofür du die Messwerte sonst noch benötigst? Das könnte helfen das auf eine Leitung zu bekommen. Für den Alarm benötigst du die ja nicht. Da reicht ja die Schwellwertüberschreitung bzw. -unterschreitung. Was ist der maximale Messbereich? Was ist der maximale Unterdruck. Was ist der maximale Überdruck, sofern das auftreten kann. Alternativ: Was ist der minimale Unterdruck. Und welcher Bereich davon soll auch korrekt angezeigt werden? Auf welchen Wertebereich soll das abgebildet werden um es dann zu digitalisieren? 0-5 Volt, 0-10 Volt 020 mA bzw 4-20 mA? So kann an nur sagen: Schalte eine Standard OPV schaltungvor den ADC. Mach dir mal einen Kopf um die Anforderungen genau zu spezifizieren. http://www.elektronik-kompendium.de/sites/slt/0210151.htm Da brauchst du dann nur noch die Zahlen in die Formel einsetzen.
:
Bearbeitet durch User
@ Carsten - Danke für die vielen Fragen / Infos also der Maximale Messbereich ist 0 bis -0,5 bar die Messwerte werden benötigt um diese auf einem Display wiederzugeben. Ausgegeben soll der Wert des Sensors auf einen wertebereich von 0-5 Volt. Überdruck kann keiner Enstehen. Bei Unterschreiten des Unterdrucks von -0,3 bar sollte Alarm geschlagen werden. Also ich werde jetzt einfach mal einen OPV bestellen und diesen dann an meinen Drucksensor anschließen. z.B. diesen Hier http://www.conrad.de/ce/de/product/157032/Operationsverstaerker-Typ-K-KEC-Korea-Electronics-KIA358P-Gehaeuseart-DIP-8-Ausfuehrung-Dual-OP-Amp?ref=searchDetail verstehe ich das richtig ich muss einfach das SignalOut+ von meinem Sensor an den +inA des OPV anschließen und den OutA des OPV an den Atmega und an VCC ganz normal die 5V des Atmega und an VEE die Spannung die der Verstärkung enspricht ??
Andreas Hermann schrieb: > VEE die Spannung > die der Verstärkung enspricht ?? Ich bin mir nicht sicher was Du da vor hast. Ich nehme an du meinst mit "die der Verstärkung entspricht" die Rückkopplung über den Spannungsteiler. Dann heißt das nein. Das kommt an negativen EINGANG. Der Rest ist richtig. Vee ist die "negative" VERSORGUNG. Da kommt also die negative Versorgungsspannung dran. Die muß nicht unbedingt negativ sein. Wenn Du den Pin auf Masse legst, nennt sich das single Supply. Das geht mit dem 358. Um dann aber auch auf die vollen 0-5 Volt abzubilden benötigst du eigentlich einen Rail to Rail Typen, weil normale OPVs verzerren, wenn die Ausgangsspannung nahe an Vcc bzw Vee herankommt. Zum Beispeil ginge der TS912. Ich vermute allerdings, daß du dich ohnehin mehr für den Bereich um die 0,3 Bar interessierst und mit Ungenauigkeiten bei den Maximalwerten leben kannst. Dann reicht das von Dir gewählte Modell. Ich würde Trotzdem den Meßbereich nicht auf 0,5 Bar begrenzen und etwas Platz lassen, damit du sehen kannst wenn man den Rahmen doch mal verläßt, vielleicht 0,6 bar... Das alles auf einen Draht zu Multiplexen, da fällt mir jetzt keine einfache Lösung ein. Da würde ich entweder ein mehradriges Kabel nehmen oder mich der schon gegebenen Empfehlung anschließen und vor Ort digitalisieren und das dann digital auf einen gemeinsamemn Bus weiterleiten. Das erhöht die Kosten pro Sensor aber spart vermutlich Kabel und veringert somit dort Kosten und möglche Störeinflüsse. Das wäre deine Entscheidung.
:
Bearbeitet durch User
Andreas Hermann schrieb: > Eingesetzter Sensor ist der MPX-53 der ein Signal von 1,2mV / kPa > ausgibt somit habe ich bei vollem Vakkum 0,6 V. Der Alarmwert sollte ca > -0,3 bar sein . Da ist die Kommastelle verrutscht. Das Ding hat einen FS von 60mV und ist nicht temperaturkompensiert. Selbst wenn du einen geeigneten Verstärker (Instrumentation, Differential) mit einstellbarem Gain und Offset nimmst, bleibt das Problem mit der Temperatur. Auch wenn du schon einen Sensor gekauft hast - tu dir den Gefallen und nimm einen der MP3V5050xx. Gibt es bei Mouser für €8,5 + Steuer, entspricht also dem Reichelt-Preis. Der hat aber einen 2,8V FS Ausgang (Vcc=3V). Zusammen mit einem XTR111 (4-20mA 1,72) ergibt das ein einfach auszuwertendes und auch über 35m stabiles Signal. Das einzige Problem dabei ist die Stromaufnahme des Drucksensors von max. 10mA. Dadurch ist eine echte Zweidrahtlösung nicht möglich. Auch an REGF muß noch ein zusätzlicher Transistor. Als Alternative: AD7740 (V/f-Konverter 2,-) und Übertragung mit Leitungstreiber FIN1019 1,40 über normale UTP-Kabel. Clk entweder lokal mit Oszillator oder zentral über den zweiten Kanal des FIN1019. p.s. Mit für Brückenschaltungen vollig ungeeigneten einzelnen Opamps wie dem verlinkten bei Conrad wird das nix.
Hi Loren, der Sensor gefällt mir auch. :) Könntest du bitte kurz mit ein zwei Sätzen vertiefen was beim LM358 völlig ungeeignet ist?
:
Bearbeitet durch User
Carsten R. schrieb: > Könntest du bitte kurz mit ein zwei Sätzen vertiefen was beim LM358 > völlig ungeeignet ist? Die Offsetspannung ist mit etlichen Millivolt angegeben. Bei anderen OPs steht da "Mikrovolt".
Carsten R. schrieb: > Könntest du bitte kurz mit ein zwei Sätzen vertiefen was beim LM358 > völlig ungeeignet ist? Gegenfrage: Kriegst du damit z.B. eine Schaltung nach https://de.wikipedia.org/wiki/Instrumentenverst%C3%A4rker#Zwei_OPVs mit einem Gain von ca. 50 gebacken? Allein die Offsetspannung bzw. deren Drift sprechen zusammen mit den Widerstandstoleranzen meiner Meinung nach dagegen.
würde dieser Sensor vom Reichelt auch gehen ? der hat ja 0,2V bis 4,7 V http://www.reichelt.de/MPX-5050DP/3/index.html?&ACTION=3&LA=446&ARTICLE=82339&artnr=MPX+5050DP&SEARCH=freescale+drucksensor und sollte somit auch ohne Verstärker auskommen oder ?
Der entspricht dem vorgeschlagenen MP3V5050xx. Ist aber die 5V-Version, etwas größer und teurer.
Da hast Du genau die richtige Schaltung ausgesucht. Eine die erhöhte Anforderungen an die Offsetgenauigkeit stellt. ;-) Was spricht denn gegen die einfachere Version vom Kompendium? Natürlich gibt es schönere OPVs. Ist halt eine lowcost Lösung. Einen Offsetabgleich muß man ohnehin durchführen. Wenn euch die paar Millivolt des LM358 stören, setzt das mal in Relation zum Offset des ursprünglichen Sensors. Ein Hardwareabgleich wäre zwar zusätzlicher Aufwand, aber hier folgt ja direkt danach keine weitere Analogschaltung sondern ein ADC. :) Einfach und billig, wenn auch nicht maximal genau, wäre ein Null-Abgleich per Software. Auch dafür ist es praktisch etwas mehr Luft in der Skalierung zu haben. Angesichts des Datenblattes des Ursprünglichen Sensors halte ich ebenfalls eine Verstärkung von maximal ca. Faktor 50 für angemessen (ergibt bis zu 4,5 Volt am Ausgang). Da es kein Rail-to-Rail ist macht es kaum Sinn ganz nahe an die 5 Volt gehen zu vollen. Zur geforderten Auflösung, Genauigkeit und Umgebungstemperatur und dessen Schwankungsbreite fehlen noch die Angaben. Muß es absolut genau sein oder nur Relativ genau? Im ersten Fall müßten man ohnehin irgendwie eichen.
loren schrieb: > Der entspricht dem vorgeschlagenen MP3V5050xx. Ist aber die 5V-Version, > etwas größer und teurer. Ok Vielen Dank. das mit Größer und bisschen Teurer ist ned ganz so tragisch da ich's über meine Firma in der Ich Arbeite kaufe und dann kommt es fast auf den Preis von dir. Wäre es evtl klug nach dem Sensor einen AD Wandler dran zu hängen und das Signal dann gleich per I2C zu senden ?? Welcher AD-Wandler wäre denn dann perfekt ? gruß und schönen Abend Andy
Andreas Hermann schrieb: > Welcher AD-Wandler wäre denn > dann perfekt ? Welche Auflösung wird denn gefordert?
Carsten R. schrieb: > Welche Auflösung wird denn gefordert? Andreas Hermann schrieb: > Der Alarmwert sollte ca -0,3 bar sein . Dafür sollte 1 Bit reichen
Puhh gute Frage. Wie darf ich des verstehen mit der Auflösung ? Also wenn bar gemeint sind dann 0,05 bar
Also würde der hier gehen http://www.reichelt.de/ADS-7816-P/3/index.html?&ACTION=3&LA=446&ARTICLE=147247&artnr=ADS+7816+P&SEARCH=AD+wandler ??
Das wären 11 Schritte. Da käme man mit 4 Bit hin. Bei so geringen Anforderungen sollte das mit der Temperatur auch zu lösen sein, je nachdem wie extrem die Temperaturschwankungen sind, könnte man das eventuell auch vernachlässigen. Schlaf nochmal eine Nacht drüber wie genau das alles werden soll bevor wir hier mit Kanonen auf Spatzen schießen und uns mit Details unterhalb der geforderten Meßgenauigkeit beschäftigen. Unterscheide Auflösung und Genauigkeit. Will man nur x Stufen unterscheiden können (Auflösung)oder soll Stufe x auch einem bestimmten Wert entsprechen. Sollst Du das bauen oder ist das eine Hobbyschaltung für Dich selbst? Wenn Du es bauen sollst, würde ich die Fragen mal weiterreichen damit man eine Anforderungsspezifikation bekommt. Sonst wird das ein Lamborghini Diablo wobei ein VW Polo bestellt wurde. Wolfgang schrieb: > Dafür sollte 1 Bit reichen Den Gedanken hatten wir schon. Der Unterdruck soll aber auch angezeigt werden.
Carsten R. schrieb: > Unterscheide Auflösung und Genauigkeit. Will man nur x Stufen > unterscheiden können (Auflösung)oder soll Stufe x auch einem bestimmten > Wert entsprechen. > > Sollst Du das bauen oder ist das eine Hobbyschaltung für Dich selbst? > Wenn Du es bauen sollst, würde ich die Fragen mal weiterreichen damit > man eine Anforderungsspezifikation bekommt. Sonst wird das ein > Lamborghini Diablo wobei ein VW Polo bestellt wurde. Also Stufe x sollte auch einen Wert entsechen und das ganz sollte eine genauigkeit von 0,05 bar haben. Das Projekt hat sich mein Arbeitskollege und Ich ausgedacht da wir immer wieder Probleme mit dem Vakkum haben und dann eben mal 30 min suchen bis wir das Problem gefunden haben. Also Ich habe mich dazu entschlossen den Sensor von Reichelt den MPX-5050 zu nehmen. Nun noch eine Frage wäre es dann Möglich diesen an einen Attiny anzuschließen ( über ADC-Wandler ) und diese 6 Attinys über I2C an den Atmega anzuschließen und dort die Werte zu erhalten und dann die AAuswertung zu übernehmen ?
Andreas Hermann schrieb: > Also Stufe x sollte auch einen Wert entsechen und das ganz sollte eine > genauigkeit von 0,05 bar haben. Ich fasse das so auf. Wenn Du 4 Bit Auflösung hättest, entspricht 16 Stufen, und Du hast einen Wert der umgerechnet 0,27 entspräche und die Realität weicht um weniger als 0,05 Bar ab, dann wäre das ok? Ich unterstelle mal. Es reicht dir wenn dir dein maximales Vakuum als 0,5 Bar "angezeigt". Es müssen keine geeichten echten 0,5 Bar sein. Werte sollen nur untereinander zwecks Fehlersuche vergleichbar und einigermaßen genau sein. Kommt das hin? Ansonsten müßtest du in der Billigvariante irgenwann einmal ein bekanntes Vergleichsvakuum einmessen oder mit einen geeichten Gerät eine Vergleichsmessung machen. Sind die Sensoren denn nun schon gekauft oder nicht. Ich komme da nicht mit, weil du nun doch die anderen nehmen willst. Wenn Du sie doch noch nicht bestellt hast und noch umsatteln kannst würde ich dir auch empfehlen dich nach Lorens Vorschlag zu richten. Der Aufpreis der höhrwertigen Komponenten ist gering. Wenn die Sensoren schon da sind geht das bei deinen Anforderungen auch mit denen. Du mußt nur den Offset Abgleichen. Im Leerlauf messen und das ist dann deine Null. Zu deiner letzten Frage. Vergiß I²C. Der ist dafür nicht gedacht. Das ist eher ein Chip-to-Chip-Bus geräteintern. Der ist nicht dafür gedacht zig Meter zu überbrücken. Dafür gibt es andere Systeme. Da Du vermutlich nicht mehrfach pro Sekunde messen mußt ist die Datenrate gering. Damit wäre das Beispielsweise mit der seriellen Schnittstelle zu lösen. Ich meine damit eine bestimmte serielle Schnittstelle, RS232 genannt. Bei mäßiger Datenrate schafft die das. http://www.mikrocontroller.net/articles/RS-232 Auch wenn der Tiny etwas günstiger ist würde ich an deiner Stelle einen kleinen Atmega nehmen. Suche Dir ein Modell daß schon den Verstärker drinnen hat. Der Faktor wird zwar nicht optimal sein, aber ausreichend. Warum ich den Atmega empfehle? Die Mehrkosten sind in diesem Falle überschaubar. Dafür haben die den vollständigen USART für RS232 drin. Es fehlt nur der Leitungstreiber (z.B. MAX232A). Der USART unterstützt es auch in Hardware die Leitung wie einen Bus mit mehreren Teilnehmern zu nutzen. Das geht zwar auch mit einer Softwareversion oder mit einer Mischung aus Software, unterstützt von der Sparversion der seriellen Schnittstelle im Tiny, aber dann muß man etwas mehr programmieren. Das ist natürlich machbar, aber ich vermute, daß du da keine umfassende Routine hast. Als ich damit anfing war ich froh, daß ich im Atmega die volle Hardware hatte. Zeitersparnis versus höherer Preis bei einem halben Dutzend Mikrocontrollern.
:
Bearbeitet durch User
Carsten R. schrieb: > Sind die Sensoren denn nun schon gekauft oder nicht. Ich komme da nicht > mit, weil du nun doch die anderen nehmen willst. Wenn Du sie doch noch > nicht bestellt hast und noch umsatteln kannst würde ich dir auch > empfehlen dich nach Lorens Vorschlag zu richten Ja es ist der MPX-53 da und eben der MPX-5050 da wir eben erst einmal Testen wollten welcher dieser Sensoren besser geeignet ist. Unsere Entscheidung liegt auf grund der Hier gewonnenen Erkentnisse nun bei dem MPX-5050. Ok Das mit I²C hatte ich nicht gewusst dass dieser nicht für Große wege Geeignet ist. Nun zu RS232 --> 1. kann ich dann einfach sag Ich mal 6 Sensoren auf eine Leitung hängen und dann Meinetwegen dazwischen noch Relaiskarten ? 2. brauche ich dann nur 1 Atmega8 als Master und dann lauter kleinere Atmega's als Slave zum Auswerten der Sensoren und Schalten der Relais ? 3. Muss Ich dazu einfach nur die RxD und TxD leitung sowie Masse und VCC durschleifen ? Dieser MAX232A dient ja dazu den Pegel zu wandeln zur Kommunikation mit dem PC versteh Ich das nun richtig ? Ich Werde mal schauen ob ich auf die Schnelle einen Schaltplan hinbekomm um zu Veranschaulichen wie Ich es nun machen würde.
Carsten R. schrieb: > Vergiß I²C. Der ist dafür nicht gedacht. Das ist eher ein > Chip-to-Chip-Bus geräteintern. Der ist nicht dafür gedacht > zig Meter zu überbrücken. Der "Erfinder" des I²C ist da inzwischen weiter und spricht von 100 Metern, wenn man sich ein bisschen Mühe gibt. Dazu gibt es die APP-Note AN10658. http://www.nxp.com/documents/application_note/AN10658.pdf RS232 bekommt bei der Länge genauso Probleme. Für lange Strecken wäre wohl sonst entweder eine klassische Stromschleife oder etwas moderneres, wie z.B. CAN, angesagt.
Andreas Hermann schrieb: > 1. kann ich dann einfach sag Ich mal 6 Sensoren auf > eine Leitung hängen und dann Meinetwegen dazwischen noch Relaiskarten ? Zur ersen Hälfte: Ja Zur zweiten Hälfte ist unklar was die Relaiskarte da soll und wie sie "dazwischen" soll. Was ich mir vorstellen kann: Sie kann mit an der Versorgung hängen und wird vom Sensorcontroller gesteuert bzw hat ihren eigenen Controller und hängt damit wie die Sensoren mit auf dem Bus. Andreas Hermann schrieb: > brauche ich dann nur 1 Atmega8 als Master und dann > lauter kleinere Atmega's als Slave zum Auswerten der Sensoren und > Schalten der Relais ? Kannst Du so machen. Wer wann Master ist, ist Sache der Software. Die Rollenverteilung ist nicht in Hardware gegossen. Von der Programmlogik wäre dies aber vermutlich eine übersichtliche Rollenverteilung. Es hängt auch ein wenig von der Aufgabenverteilung bezüglich der Relaiskarten ab. Andreas Hermann schrieb: > 3. Muss Ich dazu einfach nur die RxD und TxD leitung > sowie Masse und VCC durschleifen ? Dieser MAX232A dient ja dazu den > Pegel zu wandeln zur Kommunikation mit dem PC versteh Ich das nun > richtig ? Ja, das kann man so machen. Ich würde es aber eher bezeichnen als: Jeweils eine Hauptleitung legen un diese dann von den Teilnehmern per "Stichleitung" anzapfen. Das entspricht eher der Natur des Busses von der Logik. Es gäbe auch noch Alternativen. Und ja, das kann er auch, wenn Du so eine Schnittstelle noch hast. Ich finde sie auch heute noch immer praktisch. Es gibt auch Atmels mit zwei USART. So einen kannst du auch als Master nehmen. Dann muß der PC nicht mit auf den Bus. Allerdings habe ich noch nie 10 Teilnehmer auf 35 Metern gehabt. In der Größenordnung fehlen mir die Erfahrungswerte. Zur Not muß irgendwann ein Controller als Repeater zwei getrennte Bussegmente verbinden, sollte die hohe Teilnehmerzahl bei der Länge und der dann gewählten Datenrate elektrisch an die Grenzen kommen. Aber auch das wäre keine Raketentechnik, sondern das gleiche Prinzip wie beim Master der einerseits den Bus hat und andererseits den PC. Ich würde, wenn die ersten Module ferig sind, das Netz nach und nach aufbauen und testen. Zuerst testen ob das geGerät prinzipiel funktioniert. Danach die Teilnehmeranzahl rhöhen. Ansonsten hat an im Fehlerfall zu viele Eventualitäten zugleich.
Angehängte Dateien:
-
Image_1.png
36 KB -
Image_1.gif
17 KB
So nun habe Ich mal alles getestet und Die Drucksensoren erfüllen genau meine wünsche. Nur stehe Ich nun von einem Neuen Problem und zwar mit der Kommunikation zwischen den Atmega's. Zwischen atmega und PC funktioniert alles super und genauso wie es soll. Im Bild sieht man wie die Atmega's versucht habe zu verbinden aber leider ohne Erfolg. Woran könnte es denn liegen ?
Ich kann das nicht entziffern zu klein. Ich unterstelle mal daß Du die richtigen PINs genommen hast. -Dann kann es am (unbekannten) Code liegen. -Oder wenn Du schon mit lagen Leitungen testest: Jeder µC braucht seinen eigenen Max232 als Leitungstreiber. Nachtrag: Ach ja, es könne helfen wenn Du bschreibst was nicht funktioniert. Du schreibst von einem Problem zwischen den ATMegas. Aber anstatt dieses zu beschreiben schrebst Du dann, daß etwas anderes funktioniert.
:
Bearbeitet durch User
Hey also ich Teste es aktuell mit kurzen Leitungen. Es funktioniert die Kommunikation zwischen den Atmegas nicht. Wenn ich aber jeden Atmega einzeln Teste mit Terminal Programm dann funktioniert es genauso wie es soll. Also brauch ich vor jedem Controller nen MAX232 ? Ich habe nur einen vor dem ersten und dann bin Ich vom Master RxD an Slave TxD und umgekehrt. Leider haut des dann nicht mehr hin.
Hi >Also brauch ich vor jedem Controller nen MAX232 ? Ich habe nur einen vor >dem ersten und dann bin Ich vom Master RxD an Slave TxD und umgekehrt. >Leider haut des dann nicht mehr hin. Dir ist bewusst, das die TX-Pins der ATMega8(?), alles Ausgänge sind, die du einfach parallel geschaltet hast. Mit einem Max232 ist es auch nicht besser. MfG Spess
Also hier hab ich mal den Programmcode vom Master und vom Slave ( dieser funktioniert auch in verbindung mit dem Terminalprogramm] jedoch funktionieren Sie nicht untereinander also Sprich nicht von Mega zu Mega. könnte es am Programm liegen oder am Anschluss?
Andreas Hermann schrieb: > könnte es am Programm liegen oder am Anschluss? Ja. Zeig mal einen kompletten, lesbaren Schaltplan.
Da gibt es nun mehrere Möglicheiten. Tx und Rx sind ja Sende- und Empfangsleitung. Je nachdem wie du das fest verdrahtest wird also festgelegt wer mit wem reden kann. Für die Chips, die miteinander "reden" sollen, gilt jeweils: Tx des Senders muß mit Rx des Empfängrs verbunden werden und umgekehrt. Die Kommunikation benötigt immer ein solches Crossover/Kreuz. Ohne eine Art Hub, welcher die "Kreuze" nach Bedarf passend setzt, ist also keine beliebige Punkt zu Punkt Kommunikation möglich. Wie gesagt, die Schrift im Bild ist kaum zu entziffern. Ich rate da mal halb nach der Leitungsführung. Andreas Hermann schrieb: > Es funktioniert die > Kommunikation zwischen den Atmegas nicht. Wenn ich aber jeden Atmega > einzeln Teste mit Terminal Programm dann funktioniert es genauso wie es > soll. Das paßt zu Schaltungsaufbau 1. Das Kreuz sitzt im der Verbindug zwischen PC und MAX232. Sendepin des PC ist mit allen Empfangspins der ATMegas verbunden und alle Sendepins gehen auf den Empfangspin des PC. Sie "hören" deinen PC und können ihm Antworten. Das ist allerdings das einzige "Kreuz" Die gesammte Kommunikation muß da durch. Die Controller könnten also nur über den Umweg über den PC miteinander sprechen, wenn dieser den Hub spielt, Daten empfängt und weiterleitet. Diese Aufgabe wäre eigentlich dem Master-Controller zugedacht. In Schaltung 2 sitzt ein zweites Kreuz zwischen Master und den Slaves. Er kann mit den Slaves sprechen, diese aber nicht untereinander, es sei denn der Master spielt wieder Hub und vermittelt. Diese Komunikation untereinander ist aber durch die Aufgabe kaum erforderlich. Da dieses zweite Kreuz auf dem Weg von PC zu Slave zum ersten Kreuz zwischen PC und MAX232 hinzukommt, heben sich hier die Kreuze wieder auf. Sender sind mit Sender und Empfänger sind mit Empfänger parallel verbunden. Man kann die Slaves nicht vom PC direkt erreichen, aber der Master kann es. Darum wiederhole ich meine Empfehlung für die Wahl des Mastercontrollers: Carsten R. schrieb: > Es gibt auch Atmels mit zwei > USART. So einen kannst du auch als Master nehmen. Dann muß der PC nicht > mit auf den Bus. Dazu nimmtman noch beschaltungsvariante 2. Dann läuft da nicht so leicht was durcheinander wenn die Sensoren und der PC gleichzeitig mit dem Master sprechen wollen. Und der PC muß auch nicht alles was auf dem Bus geschieht erfahren. Er bekommt die Daten gesammelt und vorverdaut in einem Päckchen vom Master. Man kann das auch mit einem Master mit nur einem USART frickeln wenn man will. Aber hier bleibt es bei dem selben Argument wie beim vollwertigen USART vs abgespecktes serielles Interface bzw Softwareemulation. Für das im Vergleich zum passenden Chip gesparte Geld bekommt man nur ein sehr billiges Bier um den Frust herunterzuspülen weil es unnötig lang gedauert hat. ;-)
:
Bearbeitet durch User
Wie gesagt, mit einem einfachen 4-20mA-Ausgang gäbe es diese Probleme nicht, du hättest eine universelle Schnittstelle (z.B. für SPS) und es wäre vermutlich billiger. Wozu sollen die einzelnen Controller gut sein sollen. Kupfer sparen? Wegen der Relais - wo sollen die überhaupt sitzen - einen eigenen Bus erfinden? Aus eigener Erfahrung (z.B. Verbindung industrielle Schaltwarte<->Analysengeräte über ca. 25m, max. 9600 Bd erreichbar, Probeme mit Potentialausgleich) halte ich RS232 für ungeeignet. Wenn du schon eine solche Topologie haben willst, solltest du zumindest RS422/RS485 als Hardware einsetzen (ST485, MAX485...). Für deine Zwecke (Geschwindigkeit) sollte ein Half-Duplex-Betrieb ausreichen. Für die Implementierung des dafür unbedingt notwendigen Protokolls kannst du dann bei den diversen Hausbussen oder eben Profibus, CAN etc. abkupfern. PC <-RS232-> Master <-RS422-> + <-RS422-> + <-RS422-> Sensor1 Sensor2 Selbst zum Testen der Kommmunikation ist deine Konfiguration, bei der die Pins direkt zusammengeschaltet werden, denkbar ungeeignet, da der wesentliche Pin (Enable Sender) nicht abgebildet wird. Kann man natürlich diskret oder mit einzelnen Gattern/Transceivern nachbauen, ist aber nicht sehr sinnvoll. Auch ein MAX232 kann das nicht - es gibt keine Möglichkeit die TX-Ausgänge abzuschalten und damit direkt zusammenzuschalten. Man kann maximal die beiden Ports kombinieren, so dass eine (transparente) Brücke entsteht - mit allen Nachteilen (z.B. Ausfall einer Komponente legt den gesamten Bus lahm).
1 | Rx1 -- R1in(13) - R1out(12) - Brücke - T2in(11) - T2out(7) -- Tx2 |
2 | Tx1 -- T1out(14) - T1in(11) - µC/Gatter - R2out(9) - R2in(8) -- Rx2 |
3 | |
4 | Tx(PC) - Rx1(C1) Tx2(C1) - Rx1(C2) Tx2(C2) - Rx1(Cn) Tx2(Cn) |
5 | Rx(PC) - Tx1(C1) Rx2(C1) - Tx1(C2) Rx2(C2) - Tx1(Cn) Rx2(Cn) |
Der jeweilige Client entscheidet dann, ob die Daten weitergeleitet
werden, oder ob er selber antwortet (und alle Dahinterliegenden
ablemmt).
Mit RS422/85 läuft das im Prinzip immer nach dem selben Schema des
Schnittstellenstatus:
Master Client
Command Send Receive
Data R S
Wobei innerhalb der Command-Sequenz eine Adresse zum eindeutigen
Ansprechen des Clients übertragen wird. Nur der Angesprochene darf
antworten, alle anderen halten die Klappe.
Dazu kommen noch Routinen zu Überwachung (z.B. Timeout wenn niemand
antwortet, Handshakeprotokoll,...) und Datenintegrität (z.B. CRC für
Command und Data). Das kann dann beliebig komplex werden.
Irgendwie habe ich den Eindruck, dass den Aufwand für eine solche
Schnittstelle unterschätzt.
ps. Bei dieser Gelegenheit würde ich mir auch Gedanken zu Stomversorgung
(zentral mit 5V ist keine gute Idee) und EMV machen.
loren schrieb: > da der > wesentliche Pin (Enable Sender) nicht abgebildet wird. Stimmt, mein Fehler, das hatte ich übersehen. Ich benutze den USART wie ein Bus entweder direkt im Nahbreich, da kann man den TX-Pin am Controller auf High-Z (high impedance) passiv schalten, oder den 232 für weitere Strecken für eine Punkt zu Punkt Verbindung. Hier wäre in der Tat RS485 sinnvoller. Zum Rest: Es ist ja nicht neu erfunden. BAUD-Rate und Reichweite passen auch, so schnell muß es ja nicht sein. Das TX-Problem ist aber ein echtes Dilemma und Ausschlußkriterium. loren schrieb: > Wobei innerhalb der Command-Sequenz eine Adresse zum eindeutigen > Ansprechen des Clients übertragen wird. Nur der Angesprochene darf > antworten, alle anderen halten die Klappe. Das erweckt ein bisschen den Eindruck, das dies RS485 spezifisch wäre. Diese Verwaltung kann der USART von Haus aus und kommt dann hier zum Zug. Es kann aber mit jeder anderen Technik kombiniert werden. Bei der Stromschnittstelle sehe ich allerdings auch ein Problem. Wie bekommt man das auf eine Leitung (Mutiplex) bzw. wie vergrößert man so ein System ohne Multiplexing mit wenig Aufwand ohne jedes mal von ganz hinten eine neue Leitung zu holen. Was auch immer das Motiv war welches ursprünglich zu der Anforderung führte, daß alles auf eine Leitung sollte...
Carsten R. schrieb: > loren schrieb: >> Wobei innerhalb der Command-Sequenz eine Adresse zum eindeutigen >> Ansprechen des Clients übertragen wird. Nur der Angesprochene darf >> antworten, alle anderen halten die Klappe. > > Das erweckt ein bisschen den Eindruck, das dies RS485 spezifisch wäre. > Diese Verwaltung kann der USART von Haus aus und kommt dann hier zum > Zug. Es kann aber mit jeder anderen Technik kombiniert werden. Sobald mehrere Teilnehmer an einer Leitung hängen muß eine Logik vorhanden sein, welche festlegt wer nun gerade Senden darf. Das gilt unabhängig von der Hard-/Software-spezifischen Implementierung des gemeinen UART - auf welche Version beziehst du dich denn? Und, nach welchem Kriterium erfolgt dabei dein "schalte TX-Pin am Controller auf High-Z"?
Ich beziehe mich auf den USART den man in ATMegas findet. Die kennen ein Adressframe. Das nennt sich dort Multi-processor Communication mode (MPCM). Paßt die Adresse im Header so kann man in der Interruproutine eine Antwort auslösen. Dabei schaltet der Slave sein TX online und danach wieder aus. Die Anderen "halten die Klappe" und ihren Tx-Pin auf High-Z. Das setzt allerdings einen Master voraus, den wir hier aber auch haben. Leider hilft uns das hier ja nicht weiter, weil der Sender zu schwach für einen so "weiten Bus" ist. Daher wird ein Leitungstreiber benötigt den man idealerweise auch auf high-z schalten kann wenn er nicht senden muß. Mehr muß der nicht können. Dank Dir sind wir mit einem Max485 versorgt. Nun ist nur noch die Frage wie die "Tickets" zu verteilen sind. Werden nur Daten (zyklisch und planbar) abgerufen wie hier, so ist das eigentlich egal wie der Master das macht. Interessant wird es wenn die Clients nicht nur als passive Slaves laufen, sondern sich auch mal ungeplant zu Wort melden müssen/sollen. Das wäre aber ein eigenes Thema was hier nicht benötigt wird. Die einfachen Methoden sind nicht universell. Sie haben ihre Vor- und Nachteile. Sie aufzulisten würde den Rahmen sprengen. Ein weiteres Anwendungsbespiel wäre von Nöten um eine passende Vorauswahl zu treffen. Exemplarisch seien hier aber genannt: -Eine Selectleitung pro Client, woraufhin der Arbiter wie auch immer die Erlaubnis erteilt. Hier nicht anwendbar, da wir nicht zig Leitungen zusätzlich legen wollen. -Zeitmultiplexverfahren, verschiedenste Auführungen, z.B. jedem Client wird ein Zeitschlitz zutegteilt in dem er eine Transmission beginnen darf.
Carsten R. schrieb: > Ich beziehe mich auf den USART den man in ATMegas findet. Die kennen ein > Adressframe. Das nennt sich dort Multi-processor Communication mode > (MPCM). Also doch mit Adressierung ;). Das die Adresse, wie in diesem Fall, als eigenes Byte übertragen und automagisch ausgewertet wird, ist da eher sekundär. > Dank Dir sind wir mit einem Max485 versorgt. Fehlt also nur noch die entsprechende Initialisierung und eine passende Interupt-Routine - in Bascom, wenn ich den Quelltext richtig interpretiere. Auch wenn ich mit diversen Basic-Derivaten aufgewachsen bin, dazu kann ich beim besten Willen nix beitragen.
loren schrieb: > Also doch mit Adressierung ;) Ja klar, was denn sonst. Ohne Adresse kann man niemanden anschreiben. ;-) Ich meinte bei dem ursprünglichen Zitat auch nur, daß das nichts 485-spezifisches ist und das schon über den USART ud seine Software geregelt wird. Der MAX485 macht ja nur die elektrische Umsetzung des Signals auf die Leitung, so wie es auch der MAX232 tut, nur kann letzterer sich dummerweise nicht passiv verhalten beim Däumchen drehen.
Thread beobachten
Seitenaufteilung abschalten
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.