Jump to content
chili023

Open Source Prüfstandssoftware auf Basis von Arduino Mega und LabVIEW

Recommended Posts

hat das Wattenrottbreakout einen originalen Bosch BME280 drauf?

 

ich hab z.B ein anderes BME Breakout, das funkt auch mit dem offiziellem Sketch, naja I2C-Adresse muss angepasst werden, aber ob da wirklich ein originaler Bosch sensor drauf ist würde ich nicht unterschreiben....

 

Diesen Beitrag teilen


Link zum Beitrag

Das weiß ich nicht ob der original ist.

Schreib mir mal bitte welchen Breakout du hast, dann schreib ich das mal in die Doku.

 

Grüße

A.

 

Diesen Beitrag teilen


Link zum Beitrag
Des Weiteren ist mir die Frage aufgekommen, wie es mit einer Ausgabe der Daten außer Drucken oder als Pdf speichern bzw. drucken aussieht? Gibt es da schon etwas wie zum Beispiel Ausgabe der Datenpaare als txt- oder csv-Datei um die Daten weiterverarbeiten zu können?
Nö, gibts derzeit noch nichts. Ich glaube aber, dass LabView da schon VI für csv oder xls Ausgabe anbietet. Muss ich oder@BugHardcore bei Gelegenheit mal gucken

Diesen Beitrag teilen


Link zum Beitrag
vor 6 Minuten schrieb grua:

Nö, gibts derzeit noch nichts. Ich glaube aber, dass LabView da schon VI für csv oder xls Ausgabe anbietet. Muss ich oder@BugHardcore bei Gelegenheit mal gucken

Das wäre schon nice, wenn man die Kurven über die Prüfstandssoftware exportieren und direkt in Excel oder Uniplot importieren könnte.

Bearbeitet von Herr Ingenieur

Diesen Beitrag teilen


Link zum Beitrag

Ich habe den da
https://www.ebay.de/itm/3-in-1-BME280-sensore-di-umidità-temperatura-pressione-barometrica-GY-BME280-5v/263451263373?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649

 

 

den gibts mit dem Suchbegriff GYBMEP auch bei ebay.de evtl. als Alternative wenn mal bei Wattenrott nicht lieferbar.

 

Funktioniert mit dem offiziellem Sketch, es muss aber die Adresse auf 0x76 geändert werden und die Pinouts sind anders als beim Wattenrott teil.


Leider habe ich aber keine Referenz, was die Genauigkeit angeht.

Ich habe die Ausgabe von Labview jetzt aber öfters Gegengerechnet mit diesem OnlineRechner, https://rechneronline.de/barometer/

 

Einfach eingeben
Barometeranzeige
Meereshöhe und
Außentemperatur.

der berechnete relative Luftdruckt, hat immer bis auf ein hPa oder so mit den Werten der Wetterdienste gepasst.
Offseteinstellung im Sketch habe ich aber auch auf -200 glaube ich...

ich muss das am abend aber noch verifizieren
Habs kontrolliert
adresse:

  mySensor.settings.I2CAddress = 0x76; 

 

 

 

Bearbeitet von Werner Amort

Diesen Beitrag teilen


Link zum Beitrag

@grua

Das Exportieren in Exel funktioniert soweit super - Rechtsklick - Exportieren - Datei in Excel exportieren. Leider sind die Zahlenwerte von Leistung und Drehmoment noch zu ungenau. Mindestens die erste Nachkommastelle sollte mit exportiert, da es für kleinere Motoren sonst zu ungenau wird. Kann man da noch was machen?

Diesen Beitrag teilen


Link zum Beitrag
[mention=40090]grua[/mention]
Das Exportieren in Exel funktioniert soweit super - Rechtsklick - Exportieren - Datei in Excel exportieren. Leider sind die Zahlenwerte von Leistung und Drehmoment noch zu ungenau. Mindestens die erste Nachkommastelle sollte mit exportiert, da es für kleinere Motoren sonst zu ungenau wird. Kann man da noch was machen?
Ok, das muss ich dann mal abends prüfen!

Diesen Beitrag teilen


Link zum Beitrag

Hi,

 

hatte grade kurz Zeit, mir den Sketch reinzuziehen.

 

Anmerkungen:

Viele Konstante sind als Variablen definiert, das verbraucht unnötig RAM - defines funktionieren da besser. Auch wenn hier ein MEGA zum Einsatz kommt, der Speicher und Schnittstellen zuhauf hat, sollte man sich das nicht angewöhnen :) Wenn man mal mit einem etwas limitierteren Mikrocontroller arbeitet, lernt man das schnell zu schätzen.

 

Ebenso ist die Abarbeitung von Interrupts so nicht ganz ideal; wenn bei Timer4 oder Timer5 der ICP feuert, dann laufen trotzdem alle anderen Interrupts weiter, da sie nicht mit cli() oder ähnlichem deaktiviert wurden. Es kann vorkommen, dass man mitten in einer ISR dann von einer anderen ISR unterbrochen wird - wahrscheinlich nicht sinnvoll. Wie viel Zeit da zwischen solchen ICP events verstreicht oder ob die wirklich gleichzeitig passieren - noch nicht getestet, dafür fehlt mir noch Hardware.

 

Der Ringpuffer ist als int mit 50 Elementen angegeben, alle Puffer-Vars haben aber 50 hardcoded drin stehen (15-20x bei den Var-Definitionen). Sowas verringert die Wartbarkeit drastisch ;)

 

Ebenso wird nur Serial.begin() verwendet - der Mega hat aber 4 Serials! Analog dazu gibt es hier auch Serial1.begin(), Serial2.begin, Serial3.begin() - wird wirklich nur eine (die erste, die auch USB debug macht) verwendet? Fände ich verbesserbar, eben weil ja 4 COMs vorhanden sind und der BME eine ganz eigene bekommen könnte, was auch die Latenz verringern könnte (die UARTs werden parallel ausgewertet).

 

Ich hab' da mal ein bißchen rumeditiert am Code - da ich nicht im Repo bin kann ich auch nichts committen, also hab' ich den Sketch hier als Attachment angehängt. Die einzigen Änderungen sind der Übersichtlichkeit und Speichernutzung geschuldet - defines statt Variablen, Ringpuffer-Variablen statt hardcoded 50 RINGBUFFER_SIZE usw. Was die Detektion von Doppelimpulsen usw. angeht, muß ich erst die ISRs bzw. den Programmlauf genauer analysieren, noch keine Zeit gehabt :) Basiert auf 2.0.1.

MEGA_PSTfreq_BME280_v1.zip

Bearbeitet von Nexus665
Zip Datei vergessen
  • Thanks 2

Diesen Beitrag teilen


Link zum Beitrag
vor 3 Stunden schrieb grua:

Nö, gibts derzeit noch nichts. Ich glaube aber, dass LabView da schon VI für csv oder xls Ausgabe anbietet. Muss ich oder@BugHardcore bei Gelegenheit mal gucken

Grundsätzlich habt ihr das j schon gefunden. Das kann man aber auch über nen Button machen.

Da gibt's einige Varianten.

 

Man könnte beim Drücken auf den Speichern Button auch abfragen, ob Excel oder komplett gespeichert werden soll, oder sowas.

Diesen Beitrag teilen


Link zum Beitrag
vor 57 Minuten schrieb BugHardcore:

Grundsätzlich habt ihr das j schon gefunden. Das kann man aber auch über nen Button machen.

Da gibt's einige Varianten.

 

Man könnte beim Drücken auf den Speichern Button auch abfragen, ob Excel oder komplett gespeichert werden soll, oder sowas.

Ich glaub die beste Lösung wäre, die verschiedenen Dateitypen (xml , csv, txt, xlsx) als Auswahl beim Speichern anzubieten.

Bearbeitet von Herr Ingenieur

Diesen Beitrag teilen


Link zum Beitrag

MEGA_PSTfreq_BME280_v1_5_ringsize_gesplittet-gsf.ino.zip

 

 

bei mir funktiniert der BME übrigens ohne dass ich dafür die Baudrate ändere...


zur Ringspeichergröße,
hier habe ich sie auch per define definiert, und zwar für beide Signal unterschiedlich groß.
So kann man die Ringspeichergröße für das Zündsignal schön klein wählen. und für das viel hochfrequentere Rollensignal größer...




 

Diesen Beitrag teilen


Link zum Beitrag

Hi,

 

sagt mal - die Berechnungen im Loop mit ATOMIC_BLOCK, das ist ja eigentlich nicht die feine englische Art...gibt's einen relevanten Grund dafür, warum alle Interrupt Flags währenddessen aus sein sollen? Das kann zu einigen Problemen führen. Da hier ja im Wesentlichen nur einzelne Timer (Timer4/Timer5) bearbeitet werden, könnte man doch die jeweils separat anhalten/starten stattdessen? Es kann ja eigentlich nur darum gehen, dass sich die Daten nicht während der Auswertung ändern, oder?

 

lG,

Simon

MEGA_PSTfreq_BME280_v1_nexus665.zip

Bearbeitet von Nexus665
Zip mit gesplitteten Ringspeichern
  • Thanks 1

Diesen Beitrag teilen


Link zum Beitrag
vor einer Stunde schrieb Nexus665:

Hi,

 

sagt mal - die Berechnungen im Loop mit ATOMIC_BLOCK, das ist ja eigentlich nicht die feine englische Art...gibt's einen relevanten Grund dafür, warum alle Interrupt Flags währenddessen aus sein sollen? Das kann zu einigen Problemen führen. Da hier ja im Wesentlichen nur einzelne Timer (Timer4/Timer5) bearbeitet werden, könnte man doch die jeweils separat anhalten/starten stattdessen? Es kann ja eigentlich nur darum gehen, dass sich die Daten nicht während der Auswertung ändern, oder?

 

lG,

Simon

MEGA_PSTfreq_BME280_v1_nexus665.zip

scheinbar ist noch ein Bug drin...

habs mal geflasht.
per  Ringsize Zündung auf 10

Ringsize Rolle belassen...
Auszug einer Messung ohne anliegende Signale, 48 und 49 per 10K auf GND

419;58.96;2;4294967295;0.00
420;58.96;0;4294967295;0.00
421;58.96;1431655764;4294967295;0.00
422;58.96;477218587;4294967295;0.00
423;58.96;159072861;4294967295;0.00
424;58.96;53024286;4294967295;0.00
425;58.96;17674761;4294967295;0.00
426;58.96;5891586;4294967295;0.00
427;58.96;1963861;4294967295;0.00
428;58.96;654619;4294967295;0.00
429;58.96;218205;4294967295;0.00
430;58.96;72734;4294967295;0.00
431;58.96;24244;4294967295;0.00
432;58.96;8080;4294967295;0.00
433;58.96;2692;4294967295;0.00
434;58.96;896;4294967295;0.00
435;58.96;298;4294967295;0.00
436;58.96;98;4294967295;0.00
437;58.96;32;4294967295;0.00
438;58.96;10;4294967295;0.00
439;58.96;2;4294967295;0.00
440;58.96;0;4294967295;0.00
441;58.96;1431655764;4294967295;0.00
442;58.96;477218587;4294967295;0.00
443;58.96;159072861;4294967295;0.00
444;58.96;53024286;4294967295;0.00

Diesen Beitrag teilen


Link zum Beitrag

Hm, 

ohne HW ist das noch ein bißchen blöd mit Code ^^

 

Leider sagen mir die Daten aus dem Log genau gar nix - bzw. weiß ich nicht, was da plausibel ist an Daten - springende Frequenzen aber wohl nicht. Im File oben ist das noch nicht geändert von ATOMIC_BLOCK, aber ein paar Konstanten sind drin statt Variablen. Kann sein, daß da noch ein paar Typecasts fehlen und deswegen die Berechnungen inkorrekte Ergebnisse liefern. Denke, wenn ich die HW habe ist das schnell debuggt.

 

Habe einen Flüchtigkeitsfehler gefunden - RINGSIZE4/5 waren in der Berechnungsschleife vertauscht, mea culpa. In der attachten Version sind auch die Timer nun einzeln deaktiviert statt alles in einer ATOMIC_BLOCK Anweisung.

MEGA_PSTfreq_BME280_v1_nexus665.zip

Bearbeitet von Nexus665
  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
vor 15 Stunden schrieb Nexus665:

Hm, 

ohne HW ist das noch ein bißchen blöd mit Code ^^

 

Leider sagen mir die Daten aus dem Log genau gar nix - bzw. weiß ich nicht, was da plausibel ist an Daten - springende Frequenzen aber wohl nicht. Im File oben ist das noch nicht geändert von ATOMIC_BLOCK, aber ein paar Konstanten sind drin statt Variablen. Kann sein, daß da noch ein paar Typecasts fehlen und deswegen die Berechnungen inkorrekte Ergebnisse liefern. Denke, wenn ich die HW habe ist das schnell debuggt.

 

Habe einen Flüchtigkeitsfehler gefunden - RINGSIZE4/5 waren in der Berechnungsschleife vertauscht, mea culpa. In der attachten Version sind auch die Timer nun einzeln deaktiviert statt alles in einer ATOMIC_BLOCK Anweisung.

MEGA_PSTfreq_BME280_v1_nexus665.zip

 

 

Ringsize Ignition auf 5 liefert, mit dem Sketch, an der Kettensäge schonmal plausible Ergebnisse,
mein Drehgeber kommt -hoffentlich-  heute, von dem her kann ich dazu noch nix sagen...

ähm wäre eine Plausibilisierung der Drehzahlfrequenz möglich, um Doppelfunken von Kontaktzündungen zu ignorieren?

also dass wir z.B. sagen nach einen Interrupt werden für x Millis keine Interrupts mehr gezählt oder so...

evtl könnte man damit die bei Kontaktzündungen teilweise auftretenden Doppelfunken wegfiltern.

Wobei mit dem verkleinertem Ringsize, ist die Drehzahlmessung jetzt ja auch bei Problemzündungen recht brauchbar, zumindest zum Kontrollieren der eingestellten Übersetzung


5a9fa3750d766_Bildschirmfotovom2018-03-0709-31-29.thumb.png.f8dae07c28bfc8ba538cf83478f73bc6.png
 

Edit meint:
Wenn ich mir den Plot aus der Doku ansehe ist eine Plausibilisierung über eine feste Zeiteinstellung eh nicht möglich...

wenn dann wohl eher über eine Begrenzung der maximal plausiblen Änderungsrate oder so...

Bearbeitet von Werner Amort

Diesen Beitrag teilen


Link zum Beitrag

Ich habe jetzt mal die Frequenzmessung, so gut es mir halt möglich war kontrolliert,

originalsketch und @Nexus665 sketch
Ringsize jeweils 50
das TTL Signal kam von einem Voltcraft ScopeDMM750

 

 

5a9ffa2fd8c95_Bildschirmfotovom2018-03-0715-41-25.thumb.png.7400bf806697a53b896c6b7aee90eb97.png

 

Grundsätzlich hat der Serielle Output immer eine leicht höhere Frequenz angezeigt als am Signalgenerator eingestellt. Keine Ahnung ab das direkt am Signalgenerator lag oder am Quarz vom Arduino...

der originale Sketch funktioniert bis ca 16kHz bei höheren Frequenten schwankt die Ausgabe dann immer mehr...
der NexusSketch funktioniert bis 78kHz (mehr konnte mein Singalgenerator nicht erzeugen) liefert aber schwankende Werte von 100 bis gut 2000Hz

 


 

Bearbeitet von Werner Amort

Diesen Beitrag teilen


Link zum Beitrag

halte ich für unsere Motoren, wo die Kupplungen meist eh nicht gscheid trennen für nicht aussagekräftig und uninteressant....

 

Zum optimieren liefert sowieso nur die Hinterradleistung reproduzierbare Ergebnisse.

 

Und der Tüv wird ein Diagramm von einer offenen Software eh nicht akzeptieren...

Diesen Beitrag teilen


Link zum Beitrag

Ja, das kann gut sein mit dem Tüv, aber für zum Beispiel Simson Motoren ist die Verlustleistung sehr aussagekräftig für den Zustand der Kupplung und des Getriebes bzw. die Verluste im Motor selbst. Um zu wissen ob man da erstmal noch optimieren sollte, bevor man dann ans eigentliche Messen und Einstellen des Motors geht.

Diesen Beitrag teilen


Link zum Beitrag
Am 7.3.2018 um 09:11 schrieb Werner Amort:

 

 

ähm wäre eine Plausibilisierung der Drehzahlfrequenz möglich, um Doppelfunken von Kontaktzündungen zu ignorieren?

also dass wir z.B. sagen nach einen Interrupt werden für x Millis keine Interrupts mehr gezählt oder so...

evtl könnte man damit die bei Kontaktzündungen teilweise auftretenden Doppelfunken wegfiltern.
[...]

Edit meint:
Wenn ich mir den Plot aus der Doku ansehe ist eine Plausibilisierung über eine feste Zeiteinstellung eh nicht möglich...

wenn dann wohl eher über eine Begrenzung der maximal plausiblen Änderungsrate oder so...

Hi Werner,

 

genau diesen Gedanken hatte ich auch gleich, als ihr Doppelzündung erwähnt habt. Wenn das nächste detektierte Intervall so stark kürzer ist als das vorige, dann kann man das filtern bzw. den Wert einfach einfrieren anstatt ihn springen zu lassen.

 

Am WE habe ich evtl. mal Zeit mir ein bißchen HW aufzubauen und selber das Oszi und den Signalgenerator anzuwerfen.

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
vor 8 Minuten schrieb Nexus665:

Hi Werner,

....Wenn das nächste detektierte Intervall so stark kürzer ist als das vorige, dann kann man das filtern bzw. den Wert einfach einfrieren anstatt ihn springen zu lassen....


klingt vernünftig...:thumbsup:

ähm bin gespannt ob bei dir auch die ausgegebene Frequenz auch zwischen 200 und 2kHz schwankt.

wenn die ausgegebe Frequenz wirklich, wenn auch zugegeben nur leicht, von der Vorgegebenen Frequenz abweicht ist die Frage ob die Abweichung konsistent immer gleich bleibt.
Dann könnte man ja noch einen Korrekturfaktor einbauen, um die Ausgabe zu trimmen?

Diesen Beitrag teilen


Link zum Beitrag
Am 14.2.2018 um 19:50 schrieb Malzi1977:

Habe diesen bei Amazon bestellt.    Vielleicht haut das bei dir besser hin.   Bin gespannt auf dein Ergebnis!!!

AC7CCFE3-70F2-45A7-876F-7D6DE767A8FC.png

Meiner kam heute aus Chinesien

 

ist genau so einer wie auf dem Bild,
Beschriftung HS38S100B

hab ihn grad eben ans Breadboard gesteckt...

ACHTUNG DIE FARBBELEGUNG DER ADERN IST EHER UNÜBLICH

GND ist Schwarz
VCC ist Weiß (!)
Grün und Rot jeweils eine Phase

bei meinem mess ich 5kOhm von Grün oder Rot zu VCC.
es ist also bereits intern ein  Pullup Eingelötet.

Das heißt die Phase kann wohl direkt am Arduino angeschlossen werden, sofern VCC 5V beträgt...

Bearbeitet von Werner Amort
  • Like 1

Diesen Beitrag teilen


Link zum Beitrag

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden

  • Wer ist Online   0 Benutzer

    Keine registrierten Benutzer online.



×

Wichtiger Hinweis

Wir haben einen Cookie auf deinem Endgerät abgespeichert, um dein Benutzererlebnis zu optimieren. Du kannst deine Cookie Einstellungen ändern, falls du dies nicht wünscht. Ansonsten gehen wir davon aus, dass es OK für dich ist.
Weiterhin ist auf dieser Webseite Google Analytics aktiviert. Hier kannst du für alle Webseiten verhindern, dass du durch Google Analytics erfasst wirst: http://tools.google.com/dlpage/gaoptout.
Mit der Nutzung des GSF erklärst du dich mit unseren Datenschutzerklärung und unseren Nutzungsbedingungen einverstanden.