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

[chili023]

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.

[Werner Amort]

den spartan mit der i2c schnittstelle oder dem 0-5V Output?
 

[chili023]

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.

[Werner Amort]

den sparta2 habe ich auch auf der straße, der funktioniert tadellos soweit.
beim Prüfstand gehts halt um die schnittstelle

 

[Werner Amort]

ähm die Schaltung mit dem 4093N, läuft die so unverändert auch mit 5V?

oder müssen dafür Widerstände angepasst werdern?

wenn ja, dann könnte ich IC1A PIN3 einfach zusammen mit einem Pulldown an den Arduinoeingang hängen und gut?

brauchts für die Funktion auch den Widerstand an Pin IC1B Pin4?

[chili023]

die widerstände habe ich angepasst.

 

Kann die die Eagle Datei schicken wenn du willst.

[Werner Amort]

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(), wäre ein Reiter "Tacho"  evtl. interessant?
einfach alle Uhren groß aufm Bildschirm?
 

Bearbeitet 19. Januar 2018 von Werner Amort

[grua]

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 

 

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!

[Werner Amort]

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 22. Januar 2018 von Werner Amort

[grua]

@Werner Amort, bin gerade am Realisieren der beiden Live-Tachos. Dauert noch ein bisschen, aber kommt!

[Werner Amort]

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...

 

[grua]

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?

[grua]

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!

[Werner Amort]

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

 

 

 

[grua]

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.

[Werner Amort]

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...

[grua]

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 26. Januar 2018 von grua

[Werner Amort]

stimmt mein sketch hat nicht auf das m gewartet sondern sofort ab Reset Telegramme verschickt...
so kam es anfangs zum Stau...

 

Bearbeitet 28. Januar 2018 von Werner Amort

[Vespaland]

Der ist leider erst ende Februar lieferbar:

https://www.amazon.de/dp/B00IJ7876U/ref=cm_sw_r_em_api_c_nvMWzbKDM14R8

 

Kann mir jemand sagen ab der eine Alternative ist?

 

https://www.amazon.de/Wisamic-Inkrementaler-Drehgeber-Incremental-Eingangsspannungsbereich/dp/B015GYY7XU/ref=pd_lpo_sbs_60_t_0?_encoding=UTF8&psc=1&refRID=VZESN8MH7AHJ9GPE3BQH

 

Danke

 

 

[Werner Amort]

habe meinen selbigen auch irgendwo in china bestellen müssen

hoffe der kommt mitte Februar...

 

deine alternative macht 600 impulse pro umdrehung. ich fürchte damit schießt du dan über die 10kHz hinaus.. 

Bearbeitet 29. Januar 2018 von Werner Amort

[Werner Amort]

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 5. Februar 2018 von Werner Amort

[chili023]

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 5. Februar 2018 von chili023

[Werner Amort]

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
 

Bearbeitet 5. Februar 2018 von Werner Amort

[chili023]

Die Abtastung läuft mit 22.5 kHz

[Werner Amort]

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?

 

 

[GUE_]

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 5. Februar 2018 von GUE_

[grua]

 

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 6. Februar 2018 von grua

[grua]

In Tapatalk sieht mein obiges posting komplett zerstört aus. Sollte heißen:

Ich mach nur LabView, zum *.ino kann nur chili023 was sagen

[chili023]

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.

[chili023]

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.