Zum Inhalt springen

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


chili023

Empfohlene Beiträge

Ich war gerade in den USA und habe mir den Spartan controller gekauft. Den werde ich nun gegen den Knödler vergleichen.

Es fehlen jetzt eigentlich nur noch die Umsetzung in Labview.

 

Denkbar wären auch zwei unterschiedliche Boards eins nur für PST und Messung eins für Thermoelement und Lambda. Aber das wird sich zeigen sobald ich die ersten Labview Messungen gemacht habe.

  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Diesen für den PST

https://www.14point7.com/products/slc-free

 

Hier kann man einfach das Display anzapfen bei jedem neuen Frame (Displayupdate)

 

diesen für die Straße

https://www.14point7.com/products/spartan-lambda-controller-2

 

Der den du ( @Werner Amort) gepostet hast kannte ich gar nicht. Werde ich mir bestellen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

habe mal einen kleinen Arduino Sketch geschrieben,
der sendet laut Protokoll die Freqenzen laut Vorgabe von 2 Potis an die serielle Schnittstelle...

somit kann ich schonmal Läufe simulieren.

klappt soweit...
die Zeiger haben teilweise Verzögerung...

vor allem beim Übersetzung ausmessen?
Für die Berechnung hoffe ich aber irrelevant, oder?

ähm wenn ich beim Warmfahren gerne einen Tacho und Drehzahlmesser hätte, stell ich einfach n vomGas auf 50000, starte einen Lauf, den ich dann abbreche?
vor allem wenn irgendwann mal eine AFR Uhr dazu käme(:inlove:), wäre ein Reiter "Tacho"  evtl. interessant?
einfach alle Uhren groß aufm Bildschirm?
 

Bearbeitet von Werner Amort
  • Like 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

Einen Debug-Sketch zur Laufsimulation hat chili023 auch schon mal geschrieben, ist sehr praktisch zum Testen der Software, aber du hast jetzt eh schon deinen eigenen :thumbsup:

 

Die Verzögerung ist tats. egal, da geht nichts verloren.

 

Richtig, wenn du nvomGas hoch genug setzt, dann müsste der Lauf bis zum Abbruch laufen. Die Messdatenspeicher (Arrays) werden halt immer größer, keine Ahnung, wo dann mal leistungsmäßig oder speichermäßig Schluss ist, hab das nie versucht. Aber das kannst du ja gerne testen!

 

Das mit dem Reiter Tacho ist eine gute Idee, sollte eigentlich kurzfristig realisierbar sein. Einfach die beiden Uhren 1/min und km/h nebeneinander groß am Bildschirm ohne die laufenden Messdaten abzuspeichern, so dass man im Gegensatz zum "nvomGas hochsetzen" keinen Speicher anfüllt. Mal sehen, entweder @Bughardcore oder ich kommen da sicher mal dazu!

  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich wollte gleich mit Lambdasonde starten.

 

ähm, Protokoll?

 

wie gehabt 

Zyklus;Übertragungsfrequenz;Frequenz1;Frequenz2;EGT;AFR

 

afr dann gleich als 2stelliger float?

 

Zur Umsetzung in Labview

das mitloggen auf dem Diagramm wäre natürlich nett fürs erste wären aber auch 2 LiveTachos wohl ausreichend...

 

 

Bearbeitet von Werner Amort
Link zu diesem Kommentar
Auf anderen Seiten teilen

Sehr geil...

 

ähm wie gesagt möchte am liebsten gleich mit dem Lambdacontroller auf dem Board starten...

 

wie integrier ich den AFR wert am besten im Arduino Ausgabeprotokoll?

 

 

Zyklus;Übertragungsfrequenz;Frequenz1;Frequenz2;EGT;AFR?

Heizstatus der Sonde wäre noch.

aber das kann auch ein Led aufm Board übernehmen...

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich mach mal im ersten Schritt nur die Tachos (ohne afr usw) und stelle die exe dann hier mal als Testversion rein. Sollte im Laufe der Woche kommen mit der Bitte um Test und Rückmeldung, ob das so aussieht und funktioniert wie es soll.

Weitere Werte (afr, ...) dann im Anschluss. Dazu bitte aber vorher um Abstimmung mit@chili023 Evtl hat er dbgl. schon was gemacht?

Link zu diesem Kommentar
Auf anderen Seiten teilen

So, hier mal ein Versuch mit Tacho-Betrieb:

  • Reiter "Recalc" umbenannt auf "Betriebsmodus & Recalc". In diesem findet man nun einen Kippschalter , mit welchem man zw. den Betriebsmodi "Leistungsmessung" und "Tacho" umschalten kann.
  • Bei "Tacho" werden nach "Start" die Klimadaten nicht eingelesen, aber die Übersetzung wird wie gehabt ermittelt.
  • Anschließend werden die vom Arduino kommenden Frequenzen nicht mehr in Arrays gespeichert, sondern nur noch auf zwei großen Drehzahlanzeigen visualiert.

Ihr könnt entweder das gesamte Projekt downloaden: 

https://github.com/gruaGit/WildBugChilGru/archive/2.0.1.zip

 

oder auch nur die EXE, und die bisherige durch diese ersetzen (die bisherige aber vorher sichern ;-)):

https://github.com/gruaGit/WildBugChilGru/raw/2.0.1/LabVIEW/01_EXE/WildBugChilGru.exe

 

Kam leider noch nicht dazu,das ordentlich testen, bitte daher um Tests!

  • Like 1
  • Thanks 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

schaut sehr geil aus:-)

 

funktioniert mit meinem Fakedynoscript prächtig....

ähm kann es sein dass mein Lenovo T410 mit I5 2,40GHz schon eher langsam für die Labview umgebung ist?

 

Es dauert nach 'start' dann doch immer eine weile bis die Messzyklen abgearbeitet sind und die Zeiger in Echtzeit reagieren...

 

Windows 10 relativ unzerdaddelt weil ich sonst fast ausschließlich ins Linux boote...

 

oder gibts irdenwelche Windows hacks welche evtl helfen könnten Ressourcen zu sparen?

 

hatte die Labview geschichte auch unter wine im linux laufen,

lief auch aber viel zu langsam alles

 

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wie genau äußert sich dein LabView-Performanceproblem?

Sind immer mehrere Arduino-Telegramme im Lesepuffer enthalten (= Anzahl Zeilen im Lesepuffer links unten)? Im Idealfall sind da immer nur ein bis zwei Telegramme (Zeilen) enthalten, im Optimalfall immer nur eine. Wenn mehrere Zeilen enthalten sind, dann gehen diese Telegramme zwar nicht verloren, werden aber der Reihe nach abgearbeitet. Und dadurch verzögert sich natürlich das dargestellte Drehzahlsignal.

Oder ist zwar immer nur eine Zeile enthalten, die Zeiger arbeiten aber trotzdem zeitverzögert? Ich glaube, dass an die Drehzahlanzeigen immer die per gleitendem Mittelwert gefilterten Drehzahlen dargestellt werden. Durch die Filterung entsteht natürlich ein gewisser Zeitverzug. Ob das wirklich so ist, dazu müsste ich mal einen Blick ins LabView-Programm werfen, dazu komme ich aber frühestens heute Abend.

Falls letzteres der Fall ist (also Zeitverzug durch die Filterung, obwohl immer nur 1 Telegramm im Lesepuffer enthalten ist), dann könnte man das evtl. so lösen, dass man zumindest im Tachobetrieb auf die Filterung verzichtet. Oder ein Optionsfeld setzt, mit welchem man auswählen kann, ob in den Drehzahlanzeigen die gefilterte oder die ungefilterte Drehzahl angezeigt werden soll.

Aber erst wäre mal wichtig zu wissen, wie genau sich dein Laufzeitproblem äußert bzw. wodurch es verursacht wird.

Link zu diesem Kommentar
Auf anderen Seiten teilen

es dauert nach start immer ca. 20-30 Sekunden

bis alle Telegramme abgearbeitet sind.

bei 50Hz

Sobald alle abgearbeitet sind läufts dann sauber und ohne Verzögerung.

 

Ich muss jetzt aber erstmal einen Mega hohlen und dadrauf dann den originalen Sketch testen.

nicht dass das Problem bei meinem fakedynosketch liegt...

Link zu diesem Kommentar
Auf anderen Seiten teilen

OK, dann vergess ich das mit den Filtern wieder.

D.h. also, dass sich nach Start der Lesepuffer füllt, dieser dann aber nach und nach abgearbeitet wird, bis dann letztendlich immer nur 1 Telegramm enthalten ist und ab dann alles in Echtzeit läuft, wenn ich dich richtig verstehe?

Ich hatte anfangs, als ich noch ein älteres, langsames Notebook mit Win10 nutzte, ähnliche Symptome. Da musste ich nach dem Booten oft mehrere Minuten lang warten, bis obiger Effekt nicht mehr auftrat. Ursache war, dass nach dem Booten die Datenträgerauslastung längere Zeit auf >90% lief (kontrolliert mit Windows Taskmanager). Ursache dafür waren vmtl. Updates (Virenscanner usw.), welche nach Windows-Start ziemlich lange andauerten. Wenn ich gewartet hatte, bis die Datenträgerauslastung auf Normalmaß runter gefallen war und dort auch blieb, lief dann alles astrein.

Seitdem ich das Notebook vom WLAN getrennt habe, also nicht mehr im Netzwerk hänge, tritt obiger Effekt nicht mehr auf. Natürlich gibt’s dann auch keine Windows- und Virusupdates mehr…

Evtl. ist dein Problem ja ähnlich gelagert.

 

 

Edit: Thema geklärt, Problem lag an Werners Arduino-Sketch, mit dem korrekten Sketch läufts auch bei Werner problemlos!

Bearbeitet von grua
  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wir zeichnen hier gerade das Layout für unsere Plattine
BME280 und Max31855 Chip kommt direkt auf die Plattine,
für 12V Drehgeber sehen wir eine 12V Versorgung und einen Optokoppler vor.
bei 5V Sensor ohne Lambdasonde erfolgt die Spannungsversorgung komplett über USB, ohne Koppler

soweit alles klar...

aber Lambda!

 

wenn wir den Spartan OEM I2C Controller verwenden wollen hängt der ja direkt am I2C Port...
das heiß ich kann den wohl nicht einfach ausschalten, damit die Sonde nicht beheitzt wird solange der Motor aus ist...

die Frage ist nun wie wir das Handhaben...
der Controller hätte einen separaten Heater GND Pin
den könnte man von Masse trennen solang nicht beheizt werden soll...

susätz noch ein Controlled wenn Sondentemperatur im soll, angesteueret vom arduino und gut?

dann hätte man einen Kippschalter zum an und ausmachen der Heizung

und ein Kontrolled für die Sondentemperatur...

und das Telegramm welches zu Labview gesendet wird bliebe schön schlank...

sendCycle;Messfrequenz;Frequenz Kanal1(Pin49);Frequenz Kanal2(Pin48);Max31855 Thermocouple read;AFR-Wert

 

 

Bearbeitet von Werner Amort
Link zu diesem Kommentar
Auf anderen Seiten teilen

Also ich würde den Spartan BME und Thermocoupleauswerter auf ein seperates UNO Board machen.

Da kann man dann auch noch diverse 0-5 Analogeingänge mit aufzeichnen.

 

Somit geben wir noch resourcen frei auf dem MEGA um eine höhere Frequenz bei der Rollenmessung zu erreichen.

Bearbeitet von chili023
Link zu diesem Kommentar
Auf anderen Seiten teilen

läuft das jetzt mit den 50 Hz schon eher an der Grenze?
Resourcenmäßig?

als dass wenn der Mega die Daten des I2C Lambda controllers auch noch auswerten müsste wir die 50Hz, nichtmehr halten könnten?

ich kann das absolut nicht beurteilen mein Verständniss für MIcrocontroller ist viel zu rudimentär:rotwerd:
 

Bearbeitet von Werner Amort
Link zu diesem Kommentar
Auf anderen Seiten teilen

die Abtastung von Drehgeber und Drehzahlsignal?

 

mein 100p/r Drehgeber macht 4kHz bei 180km/h

von dem her dürfte das passen...

der BME wird eh nur vor dem Lauf ausgelesen,

 

Blöde frage warum wird zum Übertragen der Wetterdaten die Baudrate geändert?

 

den Max wollte ich nichtmal Sicher bestücken, hab kein Moped mit EGT.

 

sehe ich das richtig, mit jeder Zeile Code die im Loop abgearbeitet wird verringert sich ein wenig die Abtastfrequenz?

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Echt ein cooles Projekt! Gerade erst entdeckt.

 

Ich rate da mal rein: Die baudrate der RS232 müsste man für den BME280 gar nicht ändern. Der BME280 hängt ja am I2C bus und nicht an der RS232.

 

@grua: ich glaube Zeilen 131 bis 134 in https://github.com/gruaGit/WildBugChilGru/blob/master/Arduino/MEGA_PSTfreq_BME280_v1/MEGA_PSTfreq_BME280_v1.ino

kannst du auch löschen - da werden Register des BME280 gelesen, die return Werte der Funktion aber nicht verwendet. Da das lesen dieser Register auch keine sonstigen Nebeneffekte hat ist das IMHO unnötig.

Bearbeitet von GUE_
Link zu diesem Kommentar
Auf anderen Seiten teilen


 

vor 7 Stunden schrieb GUE_:

grua: ich glaube Zeilen 131 bis 134 in https://github.com/gruaGit/WildBugChilGru/blob/master/Arduino/MEGA_PSTfreq_BME280_v1/MEGA_PSTfreq_BME280_v1.ino
kannst du auch löschen - da werden Register des BME280 gelesen, die return Werte der Funktion aber nicht verwendet. Da das lesen dieser Register auch keine sonstigen Nebeneffekte hat ist das IMHO unnötig.

 


Ich mach nur LabView, zum *.ino kann nur @chili023 was sagen :-)

 

 

Bearbeitet von grua
  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 17 Stunden schrieb Werner Amort:

Blöde frage warum wird zum Übertragen der Wetterdaten die Baudrate geändert?

Der BME benötigt diese Baudrate um zu kommunizieren.

 

vor 17 Stunden schrieb Werner Amort:

sehe ich das richtig, mit jeder Zeile Code die im Loop abgearbeitet wird verringert sich ein wenig die Abtastfrequenz?

Die Frequenzermittlung wird mit ISRs (Interrupt Service Routine) abgearbeitet. Das sind Routinen die eine höhere Priorität als das Hauptprogramm haben. Hier werden bei jeder neuen Flanke der Drehzahl oder der Rolle der Aktuelle Zeitwert ermittelt. Diese sollten möglichst kurz gehalten werden, da sie den Controller blockieren. Wenn z.b. einen neue Flanke am PIN anliegt die alte ISR noch nicht fertig ist kann die Zeit zwischen den beiden Events nicht richtig ermittelt werden. Dadurch kommt es zu Fehlmessungen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 10 Stunden schrieb GUE_:

ich glaube Zeilen 131 bis 134 in https://github.com/gruaGit/WildBugChilGru/blob/master/Arduino/MEGA_PSTfreq_BME280_v1/MEGA_PSTfreq_BME280_v1.ino

kannst du auch löschen - da werden Register des BME280 gelesen, die return Werte der Funktion aber nicht verwendet. Da das lesen dieser Register auch keine sonstigen Nebeneffekte hat ist das IMHO unnötig.

Schau mal bitte in dieLibary vom BME da steht drin wieso wir die brauchen. Trotz read wird hier eigentlich der BME konfiguriert. Ist etwas ungewöhnlich aber die haben das so gemacht.

  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

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.



×
×
  • Neu erstellen...

Wichtige Information