Lüftersteuerung, Open Source Projekt

Hört sich Top am.
Wirst Du den ersten Post noch updaten mit Teileliste oder Paketpreis etc?
Wer bietet sich zum zusammenlöten an?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Den Warenkorb bei Reichelt werde ich die Tage neu Zusammenstellen. Hat sich Hardwareseitig ja doch ein bisschen was geändert.

Dann müssen wir mal schauen wie wir das mit den Platinen machen. Hat hier im Forum vllt. jemand Beziehungen zu soner Platinenbude?

Optionsmenü ist jetzt auch drin.


Mfg Bimbo385
 
Schmeiß doch die Daten des PCB mal in die Masken der Anbieter rein. Die errechnen dir dann den Preis automatisch. Bei Q-PCB kannst du sogar verschiedene Bestellmengen auf einmal anfragen.
Eurocircuits :: Kalkulieren / Bestellen
Q-PCB
Ich selbst hab letztens bei QPCB 2 Stück von einer 16x10 cm^2 Platte bestellt. Da kam die Maskenerstellung ca 50€ und die Platten zusammen nochmal soviel. Bei entsprechenden Mengen (ich schätz mal ab 30) wird der Stückpreis unter 10€ fallen.
 
Jop, kümmere ich mich bei Gelegenheit mal drum.

Aber die Steuerung besteht ja aus 3 Platinen. Mal schauen, wie die das so handhaben...

Habs hier nicht mal wen, der sich schwarze Platinen für seine LEDs und so hat machen lassen.

Der hat doch imho bei so einer Firma gearbeitet.

MfG Bimbo385
 
Schau doch mal bei PCBcart.com vorbei.
Dort hat auch Xien16 die (led-pcb's und etliche andere pcb's) anfertigen lassen.

edit:

Auch zu langsam aber dafür mit extra-info und passendem link :d
hatte ihn deswegen nämlich auch mal gefraqgt.
 
Ich schreib Xien16 gleich mal ne PN.

@ NTB und debauer,

DANKE für eure Angebote zur Mitarbeit!

@ debauer:

Der Chip ist ein ATXmega32A4. Der hat 8-Bit Architektur, kein 32 Bitter. 3,3V trifft aber zu. Der Quellcode ist sowieso öffentlich. Aktuelle Version auf meiner Homepage, bzw. Update kommt spätestens morgen. Wenn du da was auf einen anderen Chip portieren willst -> feel free!

Da die Firmware für den Xmega fast fertig ist, brauche ich da momentan weniger Hilfe. Mal ganz davon abgesehen, dass ihr ohne Hardware auch nicht ordentlich testen könnt (Der Bascom Simulator für die Xmegas taugt nichts) und Zusammenarbeit über die Ferne auch schwierig ist.


@ NTB:

klingt interessant, wie läuft so ein Softwaretest ab? Brauchst du da einmal Hardware? Bin schon interessiert, da ja auch eine gewisse Stabilität des Ganzen wichtig ist.



Mfg Bimbo385
 
Aber die Steuerung besteht ja aus 3 Platinen. Mal schauen, wie die das so handhaben...
Das sollte kein Problem sein. Am besten wär natürlich, wenn du gleich einen Nutzen fertig machst, also so viele wie möglich von den drei Platinen so anordnen, dass möglichst wenig verschnitt entsteht.

Übrigens, netter Server, den du da hast. Hab mir das 60MB-Zipfile grad in 0,5s gezogen :d
 
Also ich würde ein satz platinen mitbestellen. bzw von der Platine mit MCU 2 - dann mach ich mir daraus nen zombie mit nem Stellaris Launchpad.

Hab mir den Bascom Code mal angeschaut. Da gibts so einiges das ich anderst machen würde.
  • funktionen bauen
  • temp1, temp2, temp3 variablen sind schlecht. Mach das als Array und die zugehörigen einstellwerte als struct. also array von struct. Das fabriziert zwar nen assembler overhead, ist aber übersichtlicher und es wird sicher genug reserven haben.
  • mega loop -> würde ich in tasks aufsplitten und ne Zeitbasis realisieren. Wir nutzen 10ms. mit funktionen TimerSet(timerNummer,N) und TimerIsNull (timerNummer). Zeitbasis wird übern Hardware Timer gebildet. und decrementiert alle timerzellen - die theoretisch unendlich vorhanden sein können.

Das Protokoll für die kommunikation zur GUI finde ich ned optimal. Als identifier nimmste da ja ein byte. d.h. maximal 256 werte. Das hat 2 nachteile - du kannst keine zuweisungen ändern ohne imkompatibilität zu bekommen und recht schnell ist schluss mit weiteren werten.
Wir nutzen meist konstrukte wie: #1111#2...2#3...3#0
1111 = gruppe (temperatur, feuchte, speed)
2...2 = wert id
3...3 = wert
0 = terminierung
Entweder mit variabler länge oder mit fester länge. Feste länge hat den vorteil das du es direkt in nen Union schieben kannst. Damit direkter zugriff auf die Parameter.

Grade die fehlende flexibilität würde ich überdenken. Das projekt, mit einigen helfern, hätte potenzial ne ganze reihe von modulen, erweiterungen und features hervorzubringen.
 
Zuletzt bearbeitet:
Das Protokoll für die kommunikation zur GUI finde ich ned optimal. Als identifier nimmste da ja ein byte. d.h. maximal 256 werte. Das hat 2 nachteile - du kannst keine zuweisungen ändern ohne imkompatibilität zu bekommen und recht schnell ist schluss mit weiteren werten.
Wir nutzen meist konstrukte wie: #1111#2...2#3...3#0
1111 = gruppe (temperatur, feuchte, speed)
2...2 = wert id
3...3 = wert
0 = terminierung
Entweder mit variabler länge oder mit fester länge. Feste länge hat den vorteil das du es direkt in nen Union schieben kannst. Damit direkter zugriff auf die Parameter.

Kannst du das noch näher ausführen? Bin mit dem Protokoll auch nicht zu frieden. Ist unübersichtlich und unflexibel. Hatte nur keine bessere Idee.


Ein Struct hätte ich auch gerne. Dann könnte man alles was zusammen gehört auch zusammen fassen. Nur kennt Bascom imho kein struct...


mega loop -> würde ich in tasks aufsplitten und ne Zeitbasis realisieren. Wir nutzen 10ms. mit funktionen TimerSet(timerNummer,N) und TimerIsNull (timerNummer). Zeitbasis wird übern Hardware Timer gebildet. und decrementiert alle timerzellen - die theoretisch unendlich vorhanden sein können.

Mach ich doch quasi? Alles was Zeitmäßig ausgeführt werden soll hat einen Timertick Bit. Was gesetzt und wieder gelöscht wird. Das n einzelne Funktionen zu stecken macht ja wenig Sinn da ich nur unnötige Sprünge haben und alles ja eh nur einmal brauche.

Mfg Bimbo385
 
Kannst du das noch näher ausführen? Bin mit dem Protokoll auch nicht zu frieden. Ist unübersichtlich und unflexibel. Hatte nur keine bessere Idee.
z.b.
#temp#1#23.5#\0
#temp#2#21.5#\0
#temp#3#44.1#\0
#fan#1#2000#\0
#fan#2#1200#\0

Ob man das dann als ASCII oder als BCD sendet ist geschmacksache. Wobei ASCII das ganze einfach debugbar macht per Terminal Software.
Ob das dann feste paramter längen hat ist auch geschmacksache. Bei fester länge kann man trennzeichen ja auch weglassen.

Ein Struct hätte ich auch gerne. Dann könnte man alles was zusammen gehört auch zusammen fassen. Nur kennt Bascom imho kein struct...
puh, das ist bös :-D
Gibts denn wenigstens arrays? vllt sogar mehrdimensional?


Mach ich doch quasi? Alles was Zeitmäßig ausgeführt werden soll hat einen Timertick Bit. Was gesetzt und wieder gelöscht wird. Das n einzelne Funktionen zu stecken macht ja wenig Sinn da ich nur unnötige Sprünge haben und alles ja eh nur einmal brauche.

okey, hast gewonnen ^^
wobei... so ne art MVC ist schon sinnvoll. Mein mainloop bzw main state maschine spielt der controller der über die Modells (buffer, schnittstellen) werte an die View (CAN, 4 zeilen Display, Propritäre Protokolle, debug ausgaben) übergibt.
 
Zuletzt bearbeitet:
puh, das ist bös :-D
Gibts denn wenigstens arrays? vllt sogar mehrdimensional?

Habs gerade noch mal gegoogelt und es gibt tatsächlich nur 1-Dimensioanle Arrays. Die ich ja auch da wo es imho sinn hat benutzt habe.


okey, hast gewonnen ^^
Ich gewinne immer :fresse:

Mit nem 32 Bitter macht man das auch alles ein bisschen anders. Ich schau mal ob ich die Do-Loop noch etwas übersichtlicher hin bekomme. Vielleicht auch nur optisch.


Bezüglich Protokoll zerbreche ich mir heute Abend noch mal den Kopf. Die Idee mit den Trennzeichen ist nicht verkehrt.. Das Problem ist dabei halt nur, dass ich dann die gesamte Übertragung in ASCII machen muss, weil ja sonst ein Bytewert zufällig den ASCII Code für mein Trennzeichen annehmen kann. Auch eine Terminierung mit 0 hat genau das Problem.

Auf eine Übertragung komplett in ASCII habe ich verzichtet, da ich befürchte, dass das zu viel für den Xmega wird. Der muss ja dann mühselig die Strings wieder in Words und Bytes wandeln. Das kostet auch alles Rechenleistung.

Mal schauen. Vielleicht probiere ich es doch noch in ASCII.

Danke, Bimbo385
 
wenn kein asci dann eben eine fest länge, muss man halt im notfall mit nullen auffülen. bzw zb nen uInt_32 übertragen und passend casten. Denke ned das man fixpoint mit mehr als 32bit und oder double brauch. Damit kommt man mit 4byte hin. dazu dann ein byte für wertgruppe und 1-2byte für wertnummer. sind ma bei 6-7byte und ner recht großen flexibilität. Strings könnte man auch übertragen, aber halt 4 zeichen weise.

muss dann ma en bisle weiter schaffen :P
 
Ich hab mir mal Gedanken über das Protokoll gemacht. Prinzipiell so.

Die einzelnen Befehle erarbeite ich noch.


Befehlsliste für die ConFLiCT Steuerung

Die Schnittstelle ist Seriell (RS232) mit 57600 Baud, ein Start- und Stoppbit, keine Parity oder Flussteuerung. Diese wird, da die Serielle Schnittstelle kaum noch vorhanden ist, mit dem MCP2200 Baustein von Microchip realisiert. Dieser sitzt auf der Steuerung und ist mit dem Mikrokontroller per RS232 verbunden. Die Steuerung selber wird über den MCP2200 per USB mit dem PC verbunden. Auf diesem wird dann der Treiber von Microchip installiert der wiederum eine Virtuelle Serielle Schnittstelle erzeugt. Das GUI verwendet einfach eine Serielle Schnittstelle und braucht sich um den MCP2200 also nicht zu kümmern.


Da die bisherige Struktur unzureichend flexibel war, gibt es jetzt ein neues Konzept:

Beim Start (bzw. bei jedem Verbindungsaufbau) des GUI's meldet sich die Steuerung mit einem "Hallo". Darauf hin werden alle Einstellungen der Steuerung an das GUI übertragen (Initailisierung). Im weiteren Betrieb werden keine Konfigurationsadten mehr von der Steuerung zum GUI gesendet. Das hätte auch wenig Sinn, da ja die Konfiguratiion während der Laufzeit sowieso nur vom GUI aus geändert werden kann.

Nach der Initialisierung sendet die Steuerung automatisch in einem Abstand von 1s alle Sensordaten (Temperaturen, Umdrehungszahlen, Durchfluss) und den Alarmstatus an das GUI. Dafür ist kein Trigger vom GUI mehr nötig.

Das GUI sendet neue Konfigurationsdaten bei Betätigung des Übernehmen-Buttons. Sowie Daten von AIDA (falls aktiviert) in einem Abstand von 1s.

Die AIDA Daten dürfen nur gesendet werden, wenn diese aktuell sind! Dies muss das GUI unbedingt sicherstellen.

Die einzelnen Befehle sind ASCII Codiert und nach folgendem Schema aufgebaut:

Befehlsname#Befehlslänge#Datenwort#Datenwort#...#Datenwort#Datenwort<CR><LF>

# ist das Trennsymbol zwischen jedem Datenwort.
Das Ende jeder Übertragung wird mit <CR><LF> terminiert.
Jeder Stringteil (Datenwörter, Befehlsname, Befehlslänge) darf maximal 5 ASCII Zeichen lang sein.
Insgesamt darf ein Befehl maximal 40 Datenwörter + Befehlsname + Befehlslänge beinhalten.

Die Befehlslänge ist eine Zahl (ASCII-Codiert), die angibt wie viele Stringteile der Befehl insgesamt beinhaltet. Dies dient zur Verifizierung der Übertragung.

Die Länge jedes Befehls ist somit variabel. Es kann einfach für in einer neueren Version ein Befehl ergänzt werden.

Nach wie vor gilt:

Temperaturangaben sind immer mal 2. Das heißt z.B., dass 70 35°C bedeutet und 25,5°C ist 51. Somit lassen sich Temperaturen mit einer Auflösung von 0,5°C in einem Byte speichern.

Die Steuerung ist für Temperaturen von 0°C bis 99°C ausgelegt, wobei die analogen NTC Sensoren minimal 8,5°C zurückgeben. Das entspricht Werten von 0 bis 198. Ist an einem Anschluss der Steuerung kein Sensor angeschlossen wird als Wert 220 zurück gegeben. Um eine Temperatur für einen Kanal nicht zu verwenden wird der Minimalwert auf 250 und der Maximalwert auf 255 eingestellt.


Mfg Bimbo385
 
Zuletzt bearbeitet:
So hab das neue Protokoll implementiert, läuft auch bis auf ein paar kleinere Bugs.

Update auf meiner Website kommt gleich.

Xien16 hat sich leider nicht gemeldet.

Ein paar zusätzlich Temperatursensoren zum Testen sind auch unterwegs. Ich denke mal ich kann jetzt damit anfangen die letzten Bugs auszumerzen.


Mfg Bimbo385
 
supi... schaut ja schon super aus... dann kanns ja bld hoffentlich ans nachbauen gehen=?
 
Jop hab gerade mal wegen Platinen geschaut. Wird wohl PCBCART (China) werden. Die deutschen sind alle viel zu teuer. Bei 20 Stk. Sollten wir so unter 10€ pro Platine kommen.


Werde denke ich mal am WE noch ein paar Feinheiten machen und dann würde ich das Projekt auf euch loslassen. Mache dann aber ein extra Sammelbestellungs-thread auf.

Freu mich auch schon drauf!


Mfg Bimbo385
 
Das ist super =) freu mich schon =) ... am anfang wurd geschrieben das man spezielle Hardware braucht um die FW auf den Chip zu bekommen? zumidnest für die erste?! ist dem noch so? gibts dafür schon ne Lösung wie das gehandhabt wird?
 
Man braucht einen PDI kompatiblen Programmer für ATXmegas von Atmel um die erste Firmware und Bootloader drauf zu bekommen.

Ich werde auf jeden Fall kostenfrei die Firmware aufspielen, wenn jemand mir eine fertig bestückte Steuerung zuschickt. Nur das Rückporto wäre dann noch fällig...

Alternativ habe ich angedacht, dass ich auch Platinen mit SMD Bauteilen und Firmware bestücke. Quasi als Hilfestellung, wenn jemand bei meiner Sammelbestellung mitmacht. Dadurch würde 2 mal Versand entfallen.

Mfg Bimbo385
 
auch ne idee... und mindestens das was an Versand gespart wird, könnte man dir dann im Grunde als Dankeschön geben =)

Im Grunde wäre ich immer noch gerne (einer) der ersten Mitleser - Betatester^^ =)
 
Wäre echt genial, wenn du mal Startpost aktualisieren könntest! :-)
Also was jetzt der aktuelle Stand ist (vielleicht schon ein paar Fotos/Screens?) und wie lange man sich noch gedulden muss. ;-)
Gibt es eigentlich schon eine windows gui?^^

Dann kann man der Entwicklung leichter folgen.
 
Kurzes Mini Update,

War bis jetzt die ganze Woche im Dauerstress daher nur kurz:

Startpost sollte aktuell sein. Warenkorb und Preise hab ich aktualisiert!


Auch ist das Aquatuning Paket angekommen (diesmal mit 20% Sonderrabatt, dankeschön!). Darin waren noch 3 10K NTC Temperatursensoren mit denen ich heute noch einen Testlauf gemacht habe.

Temperaturbereich waren 20-60°C. Im unteren Bereich hab ich 0-0,5K zwischen meinen genauen Digitalsensoren und den NTC's. Bei gut 50°C sind es dann von 0K bis + 1K-1,5K gegenüber dem digitalen Sensor. Heißt auf gut deutsch dass die analogen Sensoren zwar etwas auseinander laufen, aber nicht so viel wie befürchtet.

Hab die Kennlinie jetzt im oberen Bereich um 0,5K nach unten korrigiert (in Excel, muss noch in die Firmware). Somit sollten die Analogen Sensoren im interessanten Bereich auf +/- 0,5K bis +/- 1K genau sein. Zumindest wenn die nicht mehr Streuen als meine insgesamt 4 Probeexemplare.

Mfg Bimbo385
 
Wann bestellst Platinen? Nehm 2 satz!
Reizt mich sehr die Firmware auf nen ARM, C51 oder ATmega zu portieren :) würde sie aber auch fürn aktuellen prozessor in C überführen.

Wie hast du eigentlich 1-wire realisiert? Selbst implementiert?
 
Für 1-Wire gibt es eine fertige Bib. von Bascom. Die hab ich verwendet, auch schon früher und die funktioniert echt gut. Für nen C-Port musst du da aber sicher selbst ran.

Platinen gibts, wenn AIDA läuft, steht auch so im Startpost.

MfG Bimbo385
 
Sooo Update,


hab mich heute an die AIDA Implementierung gemacht und läuft!

War nicht einfach und auch ziemlich umfangreich. Die Sensortypen kann man bequem per Dropdown auswählen und man muss nicht erst bei AIDA nachschauen wie der Sensor heißt. Ganz wichtig aber bei AIDA die Protokollierung der Uhrzeit und des Datums zu aktivieren, weil ich daraus berechne ob die von AIDA übermittelten Werte aktuell sind. Beim beenden braucht er GC noch ne weile, bis er den shared Memory Teil löscht und wenn AIDA mal abstürzen sollte...

Bin soweit echt ganz Happy mit der Steuerung und will euch schon mal den Mund etwas wässrig machen ;-)

Auf meiner To-Do Liste steht noch:

Taster Programmieren (Alarm aus und nächster Screen),
Runden der Prozentanzeigen im GUI,
ein paar Beschriftungen im GUI noch anpassen.

Also nichts Weltbewegendes mehr.

Wenn morgen immer noch alles funktioniert kommt noch ein Video denk ich mal!


Mfg Bimbo385
 
supi supi das sind tolle Nachrichten :) dann gehts ja bald ans selber basteln :) weiter so und schoenen Sonntag
 
Hab die Letzten Punkte noch beseitigt.

Videos sind am Uploaden. Links kommen morgen Vormittag, sobald die freigeschaltet sind.

Eine Sammelbestellung lass ich dann auch los, entsprechenden Thread gibt's im WaKü haupt Forum. Vllt. am Mittwoch, wenn ich bis dahin dazu komme.


Ich muss euch aber sagen, dass sowohl das GUI als auch die Firmware definitiv noch Beta sind. Auch wenn ich in den letzten Tagen keine groben Bugs mehr gefunden habe und abgesehen von einem Absturz (den ich aber auf das NT scheibe) auch alles sehr stabil läuft.

Wie gut und stabil die Steuerung in der Praxis wirklich läuft, kann letztendlich nur der längere Einsatz zeigen.

Die Bauteilliste hab ich noch etwas ergänzt (noch nicht online). Da steht jetzt eigentlich bis zur letzten Schraube alles drin.

@moritzl, bekommt man für den Avatar nicht ne Verwarnung XD

Mfg Bimbo385
 
Wow. Schön, daß es so gut voran geht.

Verlinkst Du den Thread dann auch hier?

Wird denn ein Firmwareupgrade später auch von uns machbar sein?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh