Servus zusammen, hier ist eine weitere Reflow-Ofen-Steuerung (YAROS). Anträge, Meinungen, Maulereien oder auch nur konstruktive Kritik werden gerne entgegen genommen. Erste Leiterplatten werden in den nächsten Tagen eintreffen, mal sehen was daraus wird. Der Artikel dazu heißt: Reflow Ofen Steuerung
Hier jedenfalls der Link dazu. http://www.mikrocontroller.net/articles/Reflow_Ofen_Steuerung Würd mich an der Stelle mal interessieren, wie man das richtig macht....
Interessant ist so eine Schaltung doch nur wenn man stand alone aus einem Temperaturprofil ein verändertes neues machen kann mit anderen/mehr Zeit/Solltemperaturpunkten und dann zwischen den Profilen umschalten kann. So was geht mit benutzerfreundlicher Programmierung mit einem 2x16 alphanumerischen Display oder natürlich mit einem grossen graphischen Touchscreen. So kann man so ein Steuergerät auch für Töpferöfen und Härteöfen verwenden.
Hm, wäre auch eine Option. Wir hatten uns gedacht, als GUI einen PC zu nehmen. Auf jeden Fall haben wir folgendes vor: 1. Lötprofile, mit beliebig vielen Schritten. 2. Die Möglichkeit von "Repeat" um auch z.B. Dauertests mit Temperaturprofilen fahren zu können. Wie in einer Klimakammer. Deshalb auch die zwei getrennten "Heizkreise". Oder halt für Ober- und Unterhitze. 3. Die Möglichkeit, eine Temperatur zu halten. Ich dachte da an einen vernünftigen "Fondue-Controller"... :-) Wir haben aber noch den Service-UART frei. Ein Display mit Touch habe ich fertig entwickelt. Das kann man da direkt anschließen...
Ach ja, falls jemand Interesse hat, mitzumachen.... Heute sind die ersten Leiterplatten (Prototypen) eingetroffen. Ich könnte noch die eine oder andere abgeben....
da habt Ihr Euch schon viel Arbeit gemacht. Respekt ! Steht denn die Software schon ? Wird die auch veröffentlicht ? Die Gui könntest Du auch auf einem günstigen Tablet machen. Ich wäre eventuell an einer Platine interessiert, kommt halt auf den Preis drauf an. Sieht auf den ersten Blick echt gut aus.! cheers oscar
Hallo, also GUI ist schon ziemlich weit und muss noch von paar Leuten auf Bugs getestet werden.PIC Sofware ist gerade in Arbeit und dauert noch ein wenig. Sofware wird dann auf der Projektseite veröffentlicht. Also der Preis für die ersten Prototypenplatten ist so um die 18,-€. Bei größeren Stückzahlen würde sie dann halt billiger. Viele Grüße
Karl--> Weisst Du noch, wie das Gehäuse heisst?
Frank --> Hammond RM2055M http://www.hammondmfg.com/RM.htm Ich hatte die 'M' Version wegen der Kühlkörper- & Steckdosenhöhe genommen. Die STP-Datei heißt exakt wie das Gehäuse. Platinengröße müsste ja auch 3,14 * Daumen passen. Here you go for SOS Electronic http://www.soselectronic.com/?str=371&artnum=73595&name=hammond-ritec-rm2055m
weiter im Text ... Man könnte noch überlegen, ob man nicht bei Schaeffer sich Frontplatten für das Gehäuse machen lässt. Da gibts z.B. Alu schwarz eloxiert mit allen Bohrungen, Beschriftungen, und und und. Für den der Wert auf Design legt. Kostenpunkt ~20€ @ 1St. bei der angesagten Größe incl. Werkzeugkkosten, etc. Andere Farben und Materialien gibt es auch. MaWin schrieb: > Interessant ist so eine Schaltung doch nur wenn man stand alone aus > einem Temperaturprofil ein verändertes neues machen kann mit > anderen/mehr Zeit/Solltemperaturpunkten und dann zwischen den Profilen > umschalten kann. Ich sag mal was ich mir dabei gedacht hatte. Meiner Meinung nach wird der gemeine Hobbyist seinen Ofen einmal hintrimmen und dann immer wieder das gleiche Standard Profil fahren. Ein etwas 'sensibleres' Profil hat er vielleicht bei SMD-LEDs und er könnte in einem Anfall von Dilettantismus versuchen >200 pinnige BGAs zu löten. Das ist es dann aber auch schon. Wir haben 4 Profile vorgesehen (zumindest mal 4 LEDs + 2 Taster für Auswahl und Steuerung). Die Software lässt prinzipiell beliebig viele Programme mit beliebig vielen Punkte zu, nur die Gesamtzahl der Punkte ist auf den Speicherplatz des EEPROM beschränkt. Ich glaube das waren insgesamt 180 Punkte. Geregelt werden sollen lineare Profile. Alles andere wäre Illusion bei einem Pizzaofen. MaWin schrieb: > So was geht mit benutzerfreundlicher Programmierung mit > einem 2x16 alphanumerischen Display oder natürlich mit einem grossen > graphischen Touchscreen. Das könnte man immer noch anbauen über UART, SPI, I2C, ... Ich / Wir hielten das für unnötig und eher benutzerunfreundlich. Einen Laptop hat imho. so gut wie jeder herumstehen beim Basteln. Und man muss ja streng genommen nur einmal sein Profil für die Standartbaugruppen finden und einprogrammieren. Das läuft dann auf Tastendruck los. Wir hatten bereit über einen PIC18LF4550 + LCD nachgedacht aber die Idee dann wieder verworfen. Evtl bei einem Redesign. oscar schrieb: > Steht denn die > Software schon ? Wird die auch veröffentlicht ? Ja es wird alles "open source" sein. GUI im Moment auf VB.net. Schnittstelle wird HID oder optional Virtual COM Port. Wird natürlich auch öffentlich. oscar schrieb: > Die Gui könntest Du auch auf einem günstigen Tablet machen. Tablet = WLAN Könnte man optional z.B. mit so einem Lantronix Modul machen. Die quasseln mit UART und haben einen Webserver drauf. Da könnte man auch ein GUI basteln. Zukunftsmusik aber möglich. Weiß aber nicht ob Tablet sinnvoll ist in der Werkstatt. Wer mitmachen will ist jeder Zeit herzlich eingeladen. Platinen gibt es bei https://www.mikrocontroller.net/user/show/frankman per PN denke ich.
29-05-2013 major update, GUI Screenshots, ... http://www.mikrocontroller.net/articles/Reflow_Ofen_Steuerung
--> Stephan: Die Bestückvarianten könntest Du doch machen? Oder?
Karl schrieb: > Tablet = WLAN > Könnte man optional z.B. mit so einem Lantronix Modul machen. Die > quasseln mit UART und haben einen Webserver drauf. Da könnte man auch > ein GUI basteln. Zukunftsmusik aber möglich. Weiß aber nicht ob Tablet > sinnvoll ist in der Werkstatt. Das wäre sicherlich, allein wegen der Kosten nicht unbedingt sinnvoll, vom Softwareaufwand mal abgesehen. Die meisten Tablets sind jedoch mit einer USB Host Schnittstelle ausgestattet und sollen sogar mit den prolific Bausteinen umgehen können. Somit hast Du eine serielle Schnittstelle. Ich werde dies in den nächsten Tagen, sobald ich mein OTG USB Kabel erhalten habe, ausgiebig testen. Tablet hätte halt den Vorteil, das man nicht immer die große Kisten laufen lassen muß. Nochmals : tolles Projekt Karl ! cheers oscar
Ein schönes Projekt. Allerdings sollte man bevor hier über Gehäuse diskutiert wird den Schaltplan noch genauer anschauen. Nachdem was ich im Plan bislang gesehen habe sind an einigen Stellen im 230V Teil (Nulldurchgangsdetektor und Triac Ansteuerung) ungeeignete Cs vorgesehen. X7R, 600V, 1206 sind Werte die meiner Meinung nach nicht zusammen passen. An dieser Stelle gehören ordentliche Netzspannungs Kondensatoren der Klasse X1..3 und Y1..3 rein (Details muß man noch nachprüfen, schätze mal X2 und Y2 reichen) . Die sind als SMD recht selten und teuer. Die 220K in der Nullspannungsschaltung würde ich persönlich jeweils durch 2 in Reihe geschaltetet Rs ersetzten. Grund: Spannungsfestigkeit der SMD Rs, und Mindestabstände der Pads bei höherer Spannung. Kurz gesagt Obacht im 230V Teil ! Gruß Udo
Die Kritik werden wir selbstverständlich in die nächste Version - soweit nötig - einfließen lassen. Ich möchte aber dennoch betonen, dass alle Komponenten ausreichend dimensioniert sind. Gerade bei den Cs ist das zwar straff gehalten aber nicht verfehlt. Widerstände 1206 haben normalerweise 200V Spannungsfestigkeit, wo 230V anliegen fällt die Spannung immer über 2 Widerständen ab. Macht dann 75V Spielraum nach oben. Straff aber im Rahmen. rmf schrieb: > Nachdem was ich im Plan bislang gesehen habe sind an einigen Stellen im > 230V Teil (Nulldurchgangsdetektor und Triac Ansteuerung) ungeeignete Cs > vorgesehen. X7R, 600V, 1206 sind Werte die meiner Meinung nach nicht > zusammen passen. An dieser Stelle gehören ordentliche Netzspannungs > Kondensatoren der Klasse X1..3 und Y1..3 rein (Details muß man noch > nachprüfen, schätze mal X2 und Y2 reichen) . Die sind als SMD recht > selten und teuer. Wegen Farnell 2x 30 Cent bei einem Hobbyprojekt würde ich kein so großes Fass aufmachen. Ohne Frage - es würde nichts kosten da einfach jeweils einen zweiten Footprint hinzuzufügen. Werden wir im nächsten Layout berücksichtigen. Aber auch hier haben wir kein Problem - wir sind absolut in den Ratings.
oscar schrieb: > Die meisten Tablets sind jedoch mit einer USB Host Schnittstelle > ausgestattet und sollen sogar mit den prolific Bausteinen umgehen > können. > Somit hast Du eine serielle Schnittstelle. Ich werde schauen recherchieren ob USB OTG auch mit PIC18 funktioniert. Bei den Microchip 16bitern bin ich mir da absolut sicher aber wie es bei den 8bitern aussieht muss ich nachschauen. Alternativ könnte man - wie du angedeutet hast - die herausgeführt UART Schnittstelle nutzen um dort ein FTDI/Prolific Kabel anzuschließen dessen Funktionalität mit dem Host des Tablets geklärt ist. > Ich werde dies in den nächsten Tagen, sobald ich mein OTG USB Kabel > erhalten habe, ausgiebig testen. Wäre sehr nett wenn du uns/mir diesbezüglich Rückmeldung geben könntest. > Tablet hätte halt den Vorteil, das man nicht immer die große Kisten > laufen lassen muß. Ich denke das ist Geschmackssache. Die Möglichkeit besteht und das ist wichtig. Über eine App muss man dann nochmal nachdenken. Da bin ich (noch) nicht so fit ... evtl. findet sich ja hier jemand der sich mit sowas auskennt und ein wenig Lust und Elan mitbringt. Wäre schon cool.
Frankman schrieb: > --> Stephan: Die Bestückvarianten könntest Du doch machen? Oder? Klar kann ich machen. Wenn ich die Altium Dateien bekomme, kann ich es am Freitag gleich machen.
Karl schrieb: > Die meisten Tablets sind jedoch mit einer USB Host Schnittstelle > ausgestattet und sollen sogar mit den prolific Bausteinen umgehen > können. > Somit hast Du eine serielle Schnittstelle. Ziemlich einfach ist es auch, Tablets oder Smartphones über Bluetooth-To-Serial-Adapter anzubinden. Die entsprechenden Module (JY-MCU) gibt es bei Ebay für < 10 €. Hat den zusätzlichen Vorteil, dass man sich das Kabel sparen kann.
Hubert schrieb: > Ziemlich einfach ist es auch, Tablets oder Smartphones über > Bluetooth-To-Serial-Adapter anzubinden. Versucht das mal mit den vedongelten Apple Zeugs.
Versucht mal die Schaltplanseiten mit einem Titelblock zu versehen, damit man die einzelnen Schaltplanseiten/Subsheets außeinanderhalten kann. Altium liefert da schon brauchbare Templates mit. mfg technikadonis
rmf schrieb: > Nachdem was ich im Plan bislang gesehen habe sind an einigen Stellen im > 230V Teil (Nulldurchgangsdetektor und Triac Ansteuerung) ungeeignete Cs > vorgesehen. X7R, 600V, 1206 sind Werte die meiner Meinung nach nicht > zusammen passen. An dieser Stelle gehören ordentliche Netzspannungs > Kondensatoren der Klasse X1..3 und Y1..3 rein (Details muß man noch > nachprüfen, schätze mal X2 und Y2 reichen) . Die sind als SMD recht > selten und teuer. --> Ist nicht böse gemeint, aber ich muß Dir hier wiedersprechen. Ich habe in einem Design von mir (welches in größeren Stückzahlen läuft) einen Snubber mit genau solchen Kondensatoren gebaut: 630V Bauform 1206. Die Keramiksorte schau ich noch mal nach, die Bestellnummer sag ich Dir gerne noch. Die sind speziell für 230V gedacht und sehr preiswert. > Die 220K in der Nullspannungsschaltung würde ich persönlich jeweils > durch 2 in Reihe geschaltetet Rs ersetzten. Grund: Spannungsfestigkeit > der SMD Rs, und Mindestabstände der Pads bei höherer Spannung. > Kurz gesagt Obacht im 230V Teil ! --> Auch hier gibt die guten Widerstände mit 400V Spannungsfestigkeit mit 1206er Bauform. Aber: es sind doch zwei mal 220k in Reihe geschaltet, auch wenn noch ein Gleichrichter und ein 22k-Widerstand dazwischen ist....Macht also in Summe 110V pro 220k-Widerstand. Wenn man jetzt noch eine FMEA macht, würde man feststellen, dass Widerstände wesentlich zuverlässiger und langlebiger sind, als z.B. der Gleichrichter oder der Optokoppler. Selbst wenn ein Widerstand plötzlich 0 Ohm hätte ( und wie soll das bitte passieren???) wäre der Strom durch den restlichen Widerstand rund und roh nur 1mA und somit immer noch im zulässigen Bereich von 240mW für den anderen 220k-Widerstand. Den guten alten Dextrel hab ich auch schon in eben dieser Bauart "recycelt", mit sehr guten Erfolg.
Hier isser nochmal, der gute 630V-Kondensator (DOCH X7R) MCCA000633 10n MULTICOMP CHIP-CAP. 630V X7R 1206 FARNELL 1759518
technikadonis schrieb: > Versucht mal die Schaltplanseiten mit einem Titelblock zu versehen, > damit man die einzelnen Schaltplanseiten/Subsheets außeinanderhalten > kann. > Altium liefert da schon brauchbare Templates mit. > > mfg technikadonis Da muss ich Dir wirklich recht geben. Aber wir haben die Templates erst mal "bewusst" entfernt. Zwecks Firmenlogo ect. welches man sonst erst hätte entfernen müssen. Wird nachgereicht...Vielleicht
> Ziemlich einfach ist es auch, Tablets oder Smartphones über > Bluetooth-To-Serial-Adapter anzubinden. Die entsprechenden Module > (JY-MCU) gibt es bei Ebay für < 10 €. Hat den zusätzlichen Vorteil, dass > man sich das Kabel sparen kann. Man kann ja ein Bluetooth-Modul an die TTL-Service-Schnittstelle anschließen. Die ist ja auf eine Stiftleiste gelegt....
Stefan mit "f" ;-) schrieb: > Frankman schrieb: >> --> Stephan: Die Bestückvarianten könntest Du doch machen? Oder? > > Klar kann ich machen. Wenn ich die Altium Dateien bekomme, kann ich es > am Freitag gleich machen. Stefan--> Das Altium-Projekt ist schon beim Artikel hochgeladen, oder?
Frank B. schrieb: > Selbst wenn ein Widerstand plötzlich > 0 Ohm hätte ( und wie soll das bitte passieren???) wäre der Strom durch > den restlichen Widerstand rund und roh nur 1mA und somit immer noch im > zulässigen Bereich von 240mW für den anderen 220k-Widerstand. Das gilt bei der Nullstellenerkennung. Aber nicht beim Snubber, da sind nur 2x47 Ohm vorgesehen wenn ich das richtig sehe. Gab hier neulich erst einen Thread wo es um einen Kerko ging der brach, niederohmig wurde und dann zu brennen anfing. Die machen dann wohl meist keinen kompletten Kurzschluss das gleich die Sicherung kommt, sondern lassen halt nur etwas durch bis sie überhitzen. Und gerade die größeren Kerko-Bauformen sind empfindlicher für mechanischen Stress und daraus resultierende Ausfälle. In der Automobilbranche wird daher wohl an kritischen Stellen gefordert daß 2 Kerkos in Reihe geschaltet werden. Dann müssen schon 2 Bauteile kaputt gehen bevor es raucht. Das könntest Du hier auch machen.
Frank B. schrieb: > Stefan mit "f" ;-) schrieb: >> Frankman schrieb: >>> --> Stephan: Die Bestückvarianten könntest Du doch machen? Oder? >> >> Klar kann ich machen. Wenn ich die Altium Dateien bekomme, kann ich es >> am Freitag gleich machen. > > Stefan--> Das Altium-Projekt ist schon beim Artikel hochgeladen, oder? Aha stimmt hab das Zip-File übersehen. Sorry.
Ich nehme da nichts böse, lerne gerne dazu. Bei einer FMEA würde ich hier aber lange und ausdauernd den Finger heben. Auf die Sache mit den Keramikkondensatoren in der 230V Abteilung muß ich nochmal zurückkommen. Ich habe mir mal das Datenblatt der Farnell Kondensatoren angeschaut und selbst im Datenblatt des unbekannten Herstellers steht das die Anwendung in Netzfiltern nicht vorgesehen sei(ganz am Anfang des Datenblatts). Gut das hier ist kein Netzfilter aber ich persönlich traue Vielschicht Cs alles erdenkliche zu. Zumeist wie von Gerd E. beschrieben ein Kurzschluß. Die Dinger sind meist einfach nicht robust genug für 230V. Das gilt für mechanische Belastungen wie auch für elektrische Impulse wie sie im 230V Netz oft auftreten. Wir haben doch hier nicht den extremen Kostendruck beim Design wie er in der Industrie herrscht. Und auf geplanten Ausfall hin muß hier auch nicht entwickelt werden. Daher bin ich der Meinung das das Leben und die Gesundheit der Anwender an erster Stelle stehen sollte. Für mich bedeutet das nichtentflammbare (Sicherungs) Widerstände im 230V Bereich, Korrekte Luft und Kriechstrecken, für Netzbetrieb zugelassene Cs. Zu den Cs gibt es übrigens hier im Forum auch einen Artikel über Dimensionierung von Snubber Schaltungen. Als Ergänzung zu dem Tip von Gerd mit den 2 Cs in Reihe noch die Info die beiden Cs 90Grad zueinander versetzt anzuordnen. Dadurch sinkt die Warscheinlichkeit das mechanischer Stress beide Cs gleich trifft. (Auch Automobilindustrie..) Und Sorry aber die Zitatfunktion hier hab ich noch nicht daruf...
Hallo Gerd, kein Problem, ich hab das mit den C´s schon in unsere ToDo-Liste übernommen.
Frankman schrieb: > kein Problem, ich hab das mit den C´s schon in unsere ToDo-Liste > übernommen. Danke. Der Vorschlag von rmf die Cs 90° zu winkeln ist auch gut. Spätestens dann sollte das Thema sauber erledigt sein. Das Projekt an sich und die Vorstellung auf der Projektseite gefallen mir sehr gut. Falls ich mich wirklich irgendwann mal mit Lötpaste und Stencils anstatt Handlöten anfreunde, dann könnte ich mir gut vorstellen das Teil zur Steuerung zu verwenden.
Karl: müssen wir noch die Thermoelemente bestellen? Wo? Ebay?
--> Frank: ThermoelementICs hab ich immer die aus China. Schätzungsweise Fakes aber mal probieren ... kosten halt nix http://www.ebay.de/itm/1X-MAX6675-Cold-Junction-Compensated-Converter-SO-8-/360450720046?pt=LH_DefaultDomain_0&hash=item53ec89812e oder Maxim sampeln? Gehäuse Kühlkörper + Wärmeleitpads Sicherungshalter + Kappen THT Kondensatoren im Triac-Teil Optotriacs Quarze PIC18*LF*2550 Wagos (???) Befestigungsschrauben / Plastikscheiben Ich hab jetzt mal nen 24MHz THT Quarz bestückt zum Testen. Bild lad ich heute Abend hoch. Dann werd ich das Ding mal anwerfen, hab gestern noch den MAX6675 bestückt und den PIC entlötlitzt ...
--> Karl: Ich habe Gehäuse bestellt, Kühlkörper, Sicherungshalter. Steckdosen hab ich auch schon bestellt. Die sind schon da. Bring ich am Mo mit. Also brauch ma noch: Quarze, Maxim ICs, passende PICs. Wie viele Thermoelemente hast Du noch? Ich würd sagen, jetzt schaun ma mal, obs rennt, dann kaufen wir die Thermoelemente....
Thermoelemte Hab insgesamt 3 Stück - eines nehm ich jetzt mal für die Erstinbetriebnahme her. Da ich den max6675 drauf habe kann ich das Ding auch mit 5V rennen lassen. Sonst der Spannungsregler wäre noch wichtig. -> Spannungsregler bestellen?! Frank B. schrieb: > > Ich würd sagen, jetzt schaun ma mal, obs rennt, dann kaufen wir die > Thermoelemente.... Guter Plan, bin aber erst Mittwoch wieder da oder ich Schau morgen mal kurz rein ...
--> Karl: Die Steckdosen sind auch schon da.
Karl: Ich hab das Zeugs mit der Phasenabschnitt rausgeschmissen, das ist nicht möglich...
--> Frank: OK. Hab gerade ein anderes Problem - die Triacs zünden immer egal ob mit oder ohne Optotriac bestückt sind oder (logischer Weise) egal ob die Steuerspannung der Optotriacs on oder off ist. Irgendwelche Ideen ? Nulldurchgangserkennung funktioniert wie alles andere übrigens wunderbar.
Hm, jetzt, wo ich mir die Triac Gaudi noch mal anschaue, frage ich mich, was R5 soll? Lass den mal weg. Schau auch noch mal, der Triac braucht bis zu 35mA zum Zünden, ggv. muss man noch R2 anpassen. Gruß Frank
Also ich hab gestern mal R5 rausgenommen jetzt zündet er mal garnicht mehr. Ich hab noch keine Zeit gehabt R2 anzupassen...
So nun geht alles. Platine hat noch ein paar Kinderkrankheiten in v1.0 aber es ist alles voll funktionsfähig ...
Also ich bastel jetzt den HAL für die Leds das Service Interface den PID die Kalibrierroutine die Justierroutine
-> Parser (UART+USB) - Bernhard -> USB - ich (Karl) -> MAX6675/MAX31855 Temperatur via SPI HW Modul timerbasiert -> Karl -> Nulldurchgangserkennung - Wellenpaketsteuerung - Phasenanschnitt - Zeitbasis (INT2 Flanken Interrupt) -> ??? (Stefan???) Themen: - Zeitbasis aus Nulldurchgangserkennung abgeleitet. Counter vom Typ INT32 (siehe Microchip GenericTypeDefs.h) der mit Beginn der Stromversorgung bei 0 los zählt. Erhöhung jeden 100. Nulldruchgang. -> jede Sekunde. 2^32 Sekunden = 4294967296 Sekunden -> 136.19252 Jahre = völlig überzogen Erhöhung jeden 10. Nulldruchgang. -> jede 100mS. 13.619252 Jahre = immer noch völlig überzogen Erhöhung in jedem Nulldruchgang. -> jede 10mS (= genau Halbwellendauer). 1.3619252 Jahre = immer noch genügend - Timerbelegung : TMR0 - 8/16bit - interruptfähig overflow (Prescale 1:1 ... 1:256) TMR1 - 8/16bit - interruptfähig overflow (Prescale 1:1 ... 1:8) TMR2 - 8bit - interruptfähig compare match - (Prescale 1:1 ... 1:16) TMR3 - 2x8/16bit - interruptfähig overflow - (Prescale 1:1 ... 1:8), zusätzlich aber CCP (PWM) source -> für MOSFET Hardware PWM, je nach gewünschter PWM-Frequenz ist also der Prescaler vorgegeben. Im Angang mal der Taktpfad und die Timerdiagramme. Die meisten Timer sind mit Fosc/4 gespeist. Rot unterstrichen immer der relevante Takteingang. _Belegung:_ TMR3 für PWM Modul freilassen TMR2 für Phasenanschnitt (Nulldurchgangserkennung, die 3 Comparewerte (3 Kanäle) sortieren -> TMR2 go, setze ersten compare-Wert -> Compare erreicht -> TMR2 Interrupt -> ersten Triac zünden -> Comparewert für zweiten Triac setzen -> TMR2 Interrupt -> zweiten Triac zünden -> ... sonstige Funktionen mit Timerinterrupt: + Debouncing von hier http://www.mikrocontroller.net/articles/Entprellung#Komfortroutine_.28C_f.C3.BCr_AVR.29 mit Erkennung von lange gedrückten oder wiederholt gedrückten Tastern (-> Bedienfreundlichkeit, für später) + LED Blinken möglichst interruptbasiert - wer es übertreiben will (sieht aber geil aus) ne kleine SoftPWM und dann die LEDs nicht hart an- und ausschalten sondern faden. (Zukunftsmusik) nicht Timerinterrupt: Zeitbasis (Nulldurchgangserkennung, Flankeninterrupt), Wellenpaketsteuerung da ebenfalls Flankeninterrupt-gesteuert (Entscheidung nehmen wir diese Halbwelle mit Ja/Nein?)
Den Nulldurchgang mach ich auch noch ... Hab ich schon ...
OK Korrektur: Timer2 (TMR2) und nicht Timer3 ist Quelle für das PWM-Modul also musste ich leider auf den schönen Compare-match verzichten und das alles von Hand machen und alles mit if abrattern. Ich verwende nun Timer0 für den Phasenanschnitt, die Wellenpaketsteuerung läuft völlig ohne Timer. Die angehängte Datei ist keine für Sourceforge da das alles in die main.c rein muss / sollte. (-> globale Variablen für die Statemachine). Sind größtenteils ISR-Teile und minimale Konfiguration der Interrupts. - Für das HAL habe ich ein paar Annahmen getroffen die muss man dann halt rauslassen (Triac Ansteuerung) - Für die Konfiguration (Kanal Off, Phasenanschnitt oder Wellenpaketsteuerung) habe ich auch einige Annahmen getroffen. Diese sind als TESTBENCH markiert. Die müssen/sollten dann später von der Statemachine oder Parser gesetzt werden. Armes Schwein wer auch immer das mergen muss ... ich sehe mich in der Pflicht. Eine Anmerkung : Die Wellepakte- Phasenanschnittssteuerung greifen auf globale Variablen zu (insbesondere die Einstellung der Leistung erfolgt über solche globale Variablen). Wenn diese verändert werden so muss das unbedingt atomisch geschehen (!). Es wäre fatal, wenn der PID gerade diese Leistungs-Variablen updatet und dabei unterbrochen wird (vom Phasenanschnitt/Nulldurchgang). Da diese Updaten sicherlich mehrere Takte in Anspruch nimmt muss man während des Updatens dringendst die Interrupts aussperren. Sonst ist die Variable unter Umständen erst halb upgedatet (-> Mist steht da). Die Interrupts laufen dann auf (Interruptflag wird ja nicht gesetzt) und werden dann abgearbeitet sobald die Interrupts wieder frei sind. See you
Carlos D. schrieb: > . Die Interrupts laufen dann auf > (Interruptflag wird ja nicht gesetzt) und werden dann abgearbeitet > sobald die Interrupts wieder frei sind. Ich war wohl bisschen müde. Natürlich werden die Interruptflags gesetzt nur die ISR nicht angesprungen. Sobald die Interrups wieder freigegeben sind beginnt die ISR mit der Abarbeitung aller gesetzten Flags. (In der Reihenfolge wie sie in der ISR abgefragt werden (IFs))
Einige Unzulänglichkeiten in den Kommentaren ausgemerzt.
Ham wir einen Global Header??? Da sollte alles rein, was USB und GUI GEMEINSAM betrifft. --> LEDS bin ich grad dran, ich hab aber keine Blinkerei vorgesehen. --> PID bin ich auch grad dran, ist so gut wie fertig. --> Service Interface zum Hardware-Testen ist auch so gut wie fertig. --> Justieren, Kalibrieren mach ich, dauert aber noch.
Hi erst mal ein cooles Projekt hast du da auf die beine gestellt. Wollte nun auch das mal nachbauen habe aber noch die eine oder andere Frage. Könntest du mal die aktuelle PIC HEX als Anhang oder Direktlink posten habe bei sourceforge nichts gefunden. Ist der Hardware Schaltplan pre-final. Ist die Software GUI Pablic oder im Alpha Stadium gibt es einen Link habe bei sourceforge nichts gefunden mfg
Hi wird das Projekt noch weiter entwickelt von euch. Finde es sehr interessant
Ja, das Projekt wird noch weiterentwickelt. Der Stand ist zur Zeit folgender: Wir ( Karl, Berhard, Stefan und Ich) sind jetzt alle erst mal wieder aus dem Urlaub da und haben uns die Leiterplatten bestückt. Die Hardware ist prinzipiell in Ordnung - bis auf einen kleinen Fehler: Die Pins der Triacs müssen beim Einlöten gedreht werden. Nun stecken wir gerade mitten in der Programmierung. Wobei wir da noch um jede Hilfe dankbar wären. Die Sourcen sind offen und werden bei Sourceforge gehosted. Das Hexfile später auch. Aber wir stehen da noch relativ am Anfang. Die PC-Software ist natürlich auch offen. Leiterplatten haben wir 10 Stück bestellt, da sind auch noch 6 Stück da - bei Interesse...
Hallo Frank, zunächst einmal werde ich, wie auch viele andere vor mir, euch zu dem Projekt gratulieren. Was ich bisher gelesen habe, klingt sehr interessant. Daher möchte ich die Gelegenheit nutzten und nach dem aktuellen Stand der Dinge fragen. Interesse an einer Platine wäre vorhanden. Aber zur Zeit wäre ein solches Projekt für mich sekundär, was aber nicht bedeutet, das in naher Zukunft sich die Prioritäten nicht ändern können. Bis dahin wünsche ich euch allen, die an dem Projekt arbeiten "immer ein Hand breit Wasser unter dem Kiel - ähhhmmmm..... nein, wir sind ja nicht bei der Marine"... Alles liebe, Sarah
Hallo Sarah, also der Stand ist zur Zeit folgender: Virtueller COM-Port mit USB funktioniert. Temperaturmessen über SPI auch. Die Pulspaketsteuerung funktioniert. "Normaler" UART geht auch schon. Jetzt basteln wir gerade alles zusammen. Also der Parser und die MAIN() Unsere Platinen sind aufgebaut. Meine Reflow-Steuerung ist fertig und der Ofen ist beschafft. Viele Grüße Frank
Hallo Frank, hatte selber schon eine ähnliche Steuerung begonnen zu entwickeln (vor 2,5 Jahren). Nur das Layout war noch nicht fertig. Statt USB Schnittstele wäre bei mir eine LAN-Schnittstelle drauf gekommen. Und ich hatte mehr Messeingänge vorgesehen (mit Thermoelement und zusätzlich auch mit dem Dallas 18S20). 1.) Nun bräuchte ich auf die Schnelle eine Regelung zum experimentieren, habe aber rel. wenig Zeit. Wäre es möglich von euch eine bestückte Leiterplatte zu erwerben? Wenn ja, was würde die kosten? 2.) Ich könnte eine quelloffene PC-Software für die Steuerung schreiben. Man müsste halt eine Schnittstelle definieren. Hattet Ihr da schon was geplant? Ich würde das mit FreePascal/Lazarus machen, da habe ich eine GUI recht schnell fertig. Mit UART Schnittstelle habe ich auch Erfahrung. Und Der Vorteil wäre, dass die Programm Plattformübergreifend geschrieben werden könnten. Ich würde da in den MC erst mal nur sehr wenig Funktionalität bauen und alles über den PC machen. Eine einfache Schnittstelle, zum Schalten der Heizleistung. Und zur Abfrage der Tempsensoren. Dann noch eine Watchdog Steuerung, so dass bei Verbindungsabbruch zum PC die Heizung ausgeschaltet wird. Das dürste fürs erste schon genügen. später könnte mehr Standalone Features in die MC Steuerung gebaut werden. Gruß Wolfram
Sorry, aber durch Nutzung von Altium habt ihr 99% der User hier ausgesperrt. Nochmals sorry: aber welcher Idi führt 230V-Leiterbahnen auf dem gleichen Layer wie die Kühlkörper? Auch die Befestigungsbohrungen für die Kühlkörper unterschreiten den Mindestabstand zu den 230V-Leiterbahnen. Der Ratschlag Isolierband unter die Kühlkörper zu kleben war wohl ein Witz, oder?
Wolfram S. schrieb: >Und ich > hatte mehr Messeingänge vorgesehen (mit Thermoelement und zusätzlich > auch mit dem Dallas 18S20). Hm, das könnte mit dem Dallas knapp werden, der kann nur 150 Grad. Wir haben aber freie Portpins auf Stiftleisten gelegt. So kannst Du das sicher noch erweitern. > 1.) Nun bräuchte ich auf die Schnelle eine Regelung zum experimentieren, > habe aber rel. wenig Zeit. Wäre es möglich von euch eine bestückte > Leiterplatte zu erwerben? Wenn ja, was würde die kosten? Die Leiterplatte kostet so um die 20 Euro. Für die Bestückung melde ich mich noch bei Dir. > 2.) Ich könnte eine quelloffene PC-Software für die Steuerung schreiben. > Man müsste halt eine Schnittstelle definieren. Hattet Ihr da schon was > geplant? Ich würde das mit FreePascal/Lazarus machen, da habe ich eine > GUI recht schnell fertig. Mit UART Schnittstelle habe ich auch > Erfahrung. Und Der Vorteil wäre, dass die Programm Plattformübergreifend > geschrieben werden könnten. Schau doch bitte mal bei Sourceforge nach. Da gibt es auch ein kleines Demo, wie der Prozessor über einen virtuellen Com-ort läuft. > Ich würde da in den MC erst mal nur sehr wenig Funktionalität bauen und > alles über den PC machen. Eine einfache Schnittstelle, zum Schalten der > Heizleistung. Und zur Abfrage der Tempsensoren. Dann noch eine Watchdog > Steuerung, so dass bei Verbindungsabbruch zum PC die Heizung > ausgeschaltet wird. Das dürste fürs erste schon genügen. später könnte > mehr Standalone Features in die MC Steuerung gebaut werden. > > Gruß > Wolfram
... schrieb: > Sorry, aber durch Nutzung von Altium habt ihr 99% der User hier > ausgesperrt. Ja, das war uns bewußt... Aber es gabt mehrere Gründe, es mit Altium zu machen: 1: Es war für uns kostenlos Verfügbar. 2: Es kann halt mehr als Eagle. 3: u.v.m Im übrigen ist es mit Altium eher so wie mit Open Office und mit Word: komischerweise kann ich mit Altium auch Eagle-Dateien öffen. Aber leider keine Altium-Dateien mit Eagle.....Aber ich werde jetzt mal bei AD14 nachsehen, ob man die Leiterplatte irgendwie zu Eagle konvertieren kann. > Nochmals sorry: aber welcher Idi führt 230V-Leiterbahnen auf dem > gleichen Layer wie die Kühlkörper? Auch die Befestigungsbohrungen für > die Kühlkörper unterschreiten den Mindestabstand zu den > 230V-Leiterbahnen. Der Mindestabstand ist hier zweitrangig, da die Kühlkörper in einem isolierten Gehäuse untergebracht sind. Wenn weiterhin der Triac isoliert angeschraubt wird, besteht hier kein Problem. Die Leiterbahnen sind auf dem TOP UND BOT-Layer verlegt. Immerhin sollen hier 10A fließen können. Deshalb mußten die auf dem gleichen Layer wie der Kühlkörper verlegt werden. > Der Ratschlag Isolierband unter die Kühlkörper zu kleben war wohl ein > Witz, oder? Nein, das war ernst gemeint. Wie oben gesagt, die Leiterbahnen sind auf dem oberen und unteren Layer verlegt, um somit eine doppelte Kupferstärke zu erreichen. Es gibt aber mehrere Alternativen: 1. Top-Layer ohne Kupfer--> Ist blöd, weil dann keine 10A mehr geschaltet werden können. 2. Multilayer machen:--> Ist blöd, weil viel teurer. 3. Eine kleines Stückchen FR4 ohne Kupfer zwischen den Kühlkörper und die Leiterplatte legen. --> Ist halt mehr Aufwand, aber dann geht es auch ohne Isolierband. Und - Asche über unser Haupt - die Leiterplatte ist V1.0, also Prototyp. Wir werden die bestimmt nochmal anfassen und diesen Punkt - neben einigen anderen Kleinigkeiten - verbessern, wenn möglich.
:
Bearbeitet durch User
> Hm, das könnte mit dem Dallas knapp werden, der kann nur 150 Grad. > Wir haben aber freie Portpins auf Stiftleisten gelegt. So kannst Du das > sicher noch erweitern. Der Dallas 18S20 wäre natürlich nur für den Fall, dass man die Regelung für andere Aufgaben verwenden will in niedrigeren Temperaturbereichen.
--> Wolfram: Da hast Du recht! Wie gesagt, wir haben ja noch Portpins auf Stiftleisten gelegt. Da ist der Dallas recht schnell drangeknippert. Da spricht nichts dageben. Auf den Stiftleisten ligt auch RS232-TTL SPI und I2C. Da kann man alle möglichen Temperaturfühler dranmachen. Programmieren muss man es halt. Ich wollte z.B. einen Temperaturfühler an den I2C-Bus anschließen, um damit die Thermoelemente zu kalibrieren. Das könnte man so machen, dass man alle drei Fühler in einen Wasserkocher steckt. Die Steuerung mach dann die Leiterplatte. So habe ich in Nullkommanix eine Mehrpunkt-Kalibrierung für beide Thermoelemente.
Noch was an alle Eagle Benutzer: Mit der neuen Eagle Version kann man auch Altium Files einlesen. Die dazu notwendigen ASCII-Files werden wir in den kommenden Tagen zur Verfügung stellen. (Wer sich das unbedingt antun möchte.) Allerdings wird die Platine eh nochmal überarbeitet.
Für alle, die es interessiert, die Firmware hat jetzt einen Stand erreicht, in dem man ein Reflow-Profil mit der Steuerung durchfahren kann. PID-Regler, Outputs, Temperaturmessung und Pulspaketsteuerung könenn verwendet werden. Die Leiterplatte mit der Version 1.1 ist vom Layout her (fast) fertig. Es fehlt noch ein Review und die finalen Gerberdateien. Beides, also Firmeware und Leiterplatte sind auf Sourceforge gehostet. Wenn ein Eagle-Nutzer Interesse an der Leiterplatte hat, bitte kurz Info an mich, dannn kann ich auch noch die entsprechenden ASCII-Files für den Eagle-Import generieren. Zur Zeit ist es auch möglich, die Daten des Reglers mit der Software " Logview" darzustellen. Dafür ist eine *.INI-Datei vorhanden, um die Reflow-Steuerung als "Gerät" in die Logview-Software zu integrieren. Das ist hilfreich, um den PID-Regler an seinen Ofen anpassen zu können. Es kann der Sollwert, Istwert und die Stellgrösse betrachtet werden.
Hallo Frank, ich habe da mal eine Frage zu deiner PID Regelung. Ich möchte damit einen Brutschrank regeln und erste Versuche sehen ganz gut aus. (DS18B20 und 60 Watt Birne in einem Schuhkarton) Die Werte habe ich bis jetzt so in etwas heraus gefummelt: #define P_ANTEIL_DEFAULT 150 #define I_ANTEIL_DEFAULT 150 #define D_ANTEIL_DEFAULT 150 #define ISTWERTLIMIT 50 In Anbetracht der der Relativ großen Sprünge vom DS18B20 bin ich mit der Regelung zufrieden. Mir gefällt nur nicht, dass bei Überschreiten der Soll Temperatur das PWM Signal kurzfristig auf 0 gesenkt wird. Ist das normales Verhalten deines PID ? Wenn ja wie kann ich das ändern? Grüße Jörg
Hallo Jörg, das liegt am D-Anteil. Der macht ja nichts anderes, als bei einer (kurzfristigen) starken Änderung stark in die Stellgrösse einzugreifen. Wenn Du den auf 0 setzt, sollte das Verhalten weg sein. Für eine Temperaturregelung sollte ein PI-Regler eigendlich völlig reichen. Den D-Anteil nimmt ja z.B. mehr für Motoren, wo man rasch gegensteuern muss. Da aber Dein Brutschrank und auch mein Reflow-Ofen eher träge sind, ist der D-Anteil hier eher überflüssig. Ich hatte das hier zum Thema gefunden, diese App-Note fand ich echt sehr gut. http://www.honeywell.de/fp/regler/Reglerparametrierung.pdf Viele Grüße Frank P.S. Jörg, kannst Du mir vielleicht Deinen DS 18B20 Code überlassen?
Ich benutze zum testen diesen DS18B20 http://mikrocontroller.bplaced.net/wordpress/?page_id=2518 Code. In meiner richtigen Anwendung macht das aber ein Atmega 328 der nur dafür da ist. Die 1 Wire Geschichte ist leider extrem Zeitkritisch. Das mit dem D Anteil werde ich gleich mal testen.
Ich habe das getestet, aber das macht das ganze unbrauchbar. Nach einmal erreichen der Temperatur fällt diese extrem wieder ab. Ich habe jetzt den D Anteil auf 250 erhöht. Da sieht die Kurve gut aus aber das ganze wird zu träge... Gar nicht so einfach so ein Regler
:
Bearbeitet durch User
Wieso, schaut doch schon gut aus. Bei einem Brutschrank hast Du ja nicht das Problem, dass Du ständig die Türe auf und zu machst, oder? Die Zeit, bis die 37 Grad erreicht sind, wirst Du warscheinlich nicht ändern können, die wird ja auch hauptsächlich von deinem Brutschrank bestimmt. ( Heizleistung, Isolation, Verluste durch Aufheizen der Materialien etc.)
Nicht ständig, aber wenn ist es schon sehr wichtig, dass die Temperatur schnell wieder auf dem alten Level ist. Ich bin jetzt wieder auf 50 runter. Jetzt kommt er nicht auf die Temperatur die er soll. Irgendwie ist da der Wurm drin. Bei 30 fängt es wieder an, dass die Reglung bei Überschreiten ganz auf Null geht.
:
Bearbeitet durch User
ich habe D jetzt auf 0, gefällt mir gut vom Ansprechverhalten, aber nach wie vor geht PWM 0 wenn die Temperatur Überschritten wird.
Ich verstehe jetzt ehrlich gesagt, nicht Dein Problem. Natürlich geht die Stellgrösse auf 0 wenn die Temperatur überschritten ist. Ist ja auch logisch, oder? Also: Wenn zu Heiss, dann mit Heizen aufhören..... Oder?
Nein, am besten rechtzeitig herunter regeln. Durch das Ausschalten und darauf warten, dass die Temperatur wieder unter dem Sollwert ist fällt die "Heizkörper" Temperatur so tief, dass es zu einen starken Ausschlag nach unten kommt. Dein Regler verhält sich oberhalb der Solltemperatur wie ein 2 Punkt Regler. Gerade bei trägen Systemen ist das ungünstig.
Frankman schrieb: > Natürlich geht die Stellgrösse auf 0 wenn die Temperatur überschritten > ist. > Ist ja auch logisch, oder? Also: Wenn zu Heiss, dann mit Heizen > aufhören..... > Oder? Idealerweise würde man doch erwarten, dass die Stellgrösse sich so einstellt, dass nach Erreichen der Solltemperatur genau die Wärmeleistung nachgeliefert wird, die der Ofen an die Umgebung verliert - und das ist bestimmt nicht 0.
Habe mir mal die mal die Specs angeschaut: http://www.mikrocontroller.net/articles/Datei:Spec_Reflow.pdf Der Nobelpreis ist euch sicher (Seite 6) !!! ;-)
Alfred Nobel schrieb: > Habe mir mal die mal die Specs angeschaut: > http://www.mikrocontroller.net/articles/Datei:Spec_Reflow.pdf > > Der Nobelpreis ist euch sicher (Seite 6) !!! Da siehst du mal wozu eine einfache Reflow-Ofen-Steuerung in der Lage ist. Und die Physiker machen da so einen Terz drum ...
Ja, jetzt seh ichs auch..... Das ist doch mal echt ne Innovation von uns! (Ist aber leider schon zum Patent angemeldet...) :-)
Wer zuerst über Auflösung oder Genauigkeit stolpert, dem ging es wie mir. ;-) Erst auf den 2. Blick habe ich gesehen, daß -512 Grad Celsius doch ganz schön "frisch" wären, wenn man sie erreichen könnte. MfG Paul
Hab mir mal eure Software geladen. Wie steht es um das Projekt? Wird noch entwickelt? Ich kann das Projekt nicht compilieren ohne Fehler! [code] MPLINK 4.48, Linker Device Database Version 1.13 Copyright (c) 1998-2011 Microchip Technology Inc. make[2]: *** [dist/default/production/REFLOW_OFEN_CDC.X.production.hex] Error 1 make[1]: *** [.build-conf] Error 2 Error - could not find definition of symbol 'test_PrintForLogView' in file './build/default/production/_ext/1797155568/system.o'. Errors : 1 make[2]: Leaving directory `C:/Users/Herri/temp/trunk/ratcos_firmware/REFLOW_OFEN_CDC.X' make[1]: Leaving directory `C:/Users/Herri/temp/trunk/ratcos_firmware/REFLOW_OFEN_CDC.X' make: *** [.build-impl] Error 2 BUILD FAILED (exit value 2, total time: 15s) [code]
Leider habe ich die selben Probleme. Die Version 79 ließ sich wenigstens noch compilieren und hat teilweise schon irgend was gemacht. Ich will auch eindlich male eine erste lauffähige Version haben, um darauf aufzubauen. Bisher hat noch nichts wirklich funktioniert. Vielleicht kann mal jemand helfen wie die Software in Betrieb genommen werden soll und schreiben, was schon gehen sollte und was nicht. Insbesondere wäre es wichtig mal zu wissen, wie eine USB Verbindung zum PC zum Funktionierne gebracht werden soll. Damit hatte ich bisher kein Glück. Ich denke, wenn die Firmware mal reproduzierbar für jeden in Betrieb genommen werden kann, dann geht es mit der Entwicklung der SW erst richtig voran.
Für alle die noch Probleme haben beim compilieren / linken: Man braucht den aktuellsten alten Compiler C18 (nicht den neuen XC8) von Microchip. Die momentane Version ist 3.47. Damit kann ich mit MPLAB X 2.10 builden - ganz im Gegensatz zu Compiler v 3.46 mit MPLAB X 1.90 Aktuellste RATCOS-Revision ist 88.
Carlos schrieb: > Für alle die noch Probleme haben beim compilieren / linken: Man braucht > den aktuellsten alten Compiler C18 (nicht den neuen XC8) von Microchip. > Die momentane Version ist 3.47. Damit kann ich mit MPLAB X 2.10 builden > - ganz im Gegensatz zu Compiler v 3.46 mit MPLAB X 1.90 > Aktuellste RATCOS-Revision ist 88. Läßt sich auch klären, was der Grund dafür ist? So ist das doch ganz großer Käse.
--> ELN: Ja, es läßt sich erklären, warum: Die Periferal Lib von Microchip läßt sich mit dem neuen XC8 Compiler nicht verwenden. Man müßte also den gesamten USB-Stack neu schreiben...
Hier ist eine kleine Aufstellung, welche Tools notwendig sind. https://sourceforge.net/p/ratcos/wiki/Toolchain/ -->Wolfram: Bei mir, Bernhard und Karl kann das Projekt einwandfrei kompiliert werden. Ich selbst habe mit meiner sehr rudimentären Firmware in der Zwischenzeit 14 Leiterplatten gemacht. Sorry, wenn es bei Dir nicht funktioniert. Aber wolltet Du nicht eine Software für den PC schreiben? Wie ich Dir schon schrieb, bekommst Du nur eine Verbindung zum PC, wenn der Zerocrosser läuft. Also schau doch nochmal nach, ob die Hardware richtig funktioniert.
Bei der 79er Version hat der Zerocrosser funktioniert und der Triac wurde jede Sekunde kurz angesteuert. Auch die LEDs haben geleuchtet. Und bei der START-Taste hat sich auch was verändert. Seit der 88er Version geht das compilieren nun wieder. Soweit OK. Allerderdings macht die Software nichts mehr und auch keine LED wird angesteuert. Trotz anliegendem Zerocross Signal. Warum ist die PC Verbindung vom Zerocross Signal abhängig? Mir fehlt eine kleine Beschreibung, was die Firmware derzeit kann und wie sie in Betrieb genommen wird (besonders im Hinblick auf die serielle Schnittstelle) bzw. wie die Firmware grob aufgebaut ist und was wo zu finden ist, so dass man das wichtigste versteht, ohne den ganzen Sourcecode durchsuchen und verstehen zu müssen. Ja, wenn ich die HW/Firmware lauffähig habe, kümmere ich mich um die PC Software. Viele Grüße Wolfram
Hellas zusammen, ich schnacke mal ein wenig mit. Der Zerocross [ZC] ist für die USB Schnittstelle nicht notwendig. Allerdings benötigt man den ZC um in den Servicemode zu gelangen. Die Systemzeit ist an den ZC gekoppelt. Ich werde nächste Woche versuchen ein paar größere Schritte in Sachen Funktionalität zu gehen. Im Moment bin ich mehr am Strukturieren und Aufräumen. Heute habe ich noch meine Hardware funktional fertiggestellt. Das heißt ich kann die SW auch mal am "lebenden" Objekt ausprobieren. ;-) Je nachdem, wie mich meine Mädels am WE einspannen, werde ich mal eine kleine Doku zur Software schreiben. Viele Grüße Berni
Deine Mädels müssen dich ja ziemlich heftig einspannen, wenn deine kleine Doku zur Software noch immer nicht fertig geworden ist :-) Besteht noch Hoffnung auf die Doku? Viele Grüße Wolfram
Ich habe mal einen Reflow Controller 1.2 gemacht. Die Platine ist jetzt nur noch 50 x 50mm gross, so kann man die sehr billig bei ITEAD oder DirtyPCBs kaufen. Einziger Wehrmutstropfen: Nun braucht man 1 oder 2 Solidstate Relais extra. Die Taster und Leds können über einen Wannenstecker (mit Flachbandkabel, RM2,54mm ) angeschlossen werden.
Betreff: Ratcos PC-Software ------- Kann mir mal bitte jemand bechreiben, was alles installiert werden muss und was konfiguriert werden muss um die PC-Software zu compilieren? Oder gibt es fertige Binärdateien? Ich habe QT noch nicht verwendet! Unter Win-XP habe ich mal den QT Creator isntalliert (mit MinGW). Der findet dann aber Dateien aus der QWT-Software nicht! Daraufhin habe ich noch QWT installiert. Allerdings habe ich keine Ahnung, wie ich das jetzt in QT einbinden muss. Eine Kurzanleitung mit allen Tools und Systemvoraussetzungen und was sonst noch so zu konfigurieren ist, wäre sehr willkommen. Betreff: Reflow Controller 1.2 ------- Gibt es dazu auch Schaltplan und die Layoutdateien?
Hier ist das Altium Projekt für die V1.2 Die Eagle-ASCII-Daten kann ich auf Anfrage noch machen. Gerbers reiche ich noch nach. Achtung: Bei der V1.2 ist der ZeroCrosser nicht mehr auf der Leiterplatte. Also entweder dazubasteln oder die Software entsprechend anpassen. Da jetzt ja nur noch mit Pulspaketsteuerung gearbeitet wird, sollte das aber kein Problem sein. Wenn man Solid-State-Relais mit Nulldurchgangsschalter nimmt, ist es egal, ob man syncron zur Netzfrequenz ist.
Danke. Für mich am besten auch noch die Eagle Dateien. Und bitte doch auch noch die Infos zur ratcos PC-Software... Viele Grüße Wolfram
Bis ratcos Releas r138 konnte ich noch alles fehlerfrei compilieren. Seit r143 kommen jetzt jede Menge Fehlermeldungen. Hat das schon mal jemand compiliert? Was muss ich ggf ändern?
Wolfram S. schrieb: > Bis ratcos Releas r138 konnte ich noch alles fehlerfrei compilieren. > Seit r143 kommen jetzt jede Menge Fehlermeldungen. > Hat das schon mal jemand compiliert? > Was muss ich ggf ändern? Hallo Wolfram, zwischen r138 und r143 gibt es kaum Unterschiede. Es handelt sich dabei eher um kosmetische Eingriffe und Repository Bereinigung. Ich selbst habe r143 trunk noch nicht compiliert. Ich werde das am Wochenende mal probieren. Wenn du es nicht schaffst r143 zu kompilieren, dann nimm r138 den Branch FBprogControl. Mit r143 wurde r138 FBprogControl in den r142 Trunk gemerged. Vielleicht ging da was schief. Wenn du den r138 FBprogControl kompilierst, dann hast du die selbe wie den aktuellsten Trunk. Funktionalität ist bis dato: Funktionierender parametrisierter PID läuft autark nach drücken der Start-Taste ab. Die Daten kommen permanent (auch ohne laufendes Programm) über die serielle Schnittstelle (virtual COM Port via USB) mit 9600 baud an. Das Lötprofil ist in einer eigenen Datei realisiert. Da kann man nach belieben verändern. Wolfram S. schrieb: > Mir fehlt eine kleine Beschreibung, was die Firmware derzeit kann und > wie sie in Betrieb genommen wird (besonders im Hinblick auf die serielle > Schnittstelle) bzw. wie die Firmware grob aufgebaut ist und was wo zu > finden ist, so dass man das wichtigste versteht, ohne den ganzen > Sourcecode durchsuchen und verstehen zu müssen. Die Firmware ist ziemlich perfekt geschrieben. Du musst dich nicht durch den ganzen Code durchwühlen. Schau dir den app-Ordner an. Alle Module sind gekapselt (PID, Power Control, Program Control, HAL, ...). > Ja, wenn ich die HW/Firmware lauffähig habe, kümmere ich mich um die PC > Software. Das wäre ein feiner Zug.
Guten Morgen Wolfram, ich habe gerade nochmal den Trunk bei Revision 143 separat ausgecheckt und compiliert. Bis auf eine Warning spuckt er mir keine Fehler aus. Vielleicht kannst du kurz mal deine Fehlermeldungen posten, dann kann ich dir ja vielleicht weiterhelfen. Viele Grüße Bernhard
Hab das Mopped gerade nochmal auf ner blanken Win7 Gurke compiliert, da sieht's auch nicht anders aus, als bei meinem Linuxfön. Checks dir am besten mal in einen neuen Ordner aus und versuche es dann noch einmal zu bauen. ;-)
Hier mal genau was ich mache (irgfendwo muss ja der Fehler sein): 1. MPLABX 2.20 installiert 2. C18 v3.47 installiert 3. Microchip Librarys for Applications installiert (nur USB Teile) 4. svn checkout RATCOS (auf Serverlaufwerk im LAN) 5. MPLABX - Datei - OpenProject - "n:\dev\PIC\reflow_mcnet\ratcos-code\firmware\branches\FB_progControl\ra tcos.X" Nun kommt folgende Meldung:
1 | warning: Configuration "default" builds with "XC8", but indicates no toolchain directory. |
2 | _error:_ Configuration "default" builds with "XC8", but no toolchains of that type are installed. |
3 | Errors have occurred while loading one or more configurations. |
4 | If a specific error is not shown above, this may happen when you import a project from another computer. |
5 | + You can add language tools in Tools->Options embedded tab. |
6 | + You can change which language tool to use in the project properties dialog. |
6. Nun MPLABX - Run - SetProjectConfiguration - Customize... - "auf PICkit3 umstellen" 7. Nun MPLABX - Run - SetProjectConfiguration - Customize... - "auf C18 umstellen" 8. Nun MPLABX - Run - "CleanAndBuildProject" Folgende Meldungen kommen:
1 | CLEAN SUCCESSFUL (total time: 62ms) |
2 | make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf |
3 | make[1]: Entering directory 'N:/dev/_PIC/reflow_mcnet/ratcos-code/firmware/trunk/ratcos.X' |
4 | make -f nbproject/Makefile-default.mk dist/default/production/ratcos.X.production.hex |
5 | make[2]: Entering directory 'N:/dev/_PIC/reflow_mcnet/ratcos-code/firmware/trunk/ratcos.X' |
6 | "C:\Programme\Microchip\mplabc18\v3.47\bin\mcc18.exe" -p18F2550 -ms -oa- -I "C:\Programme\Microchip\mplabc18\v3.47\bin"\\..\\h -fo build/default/production/app/ratcos.o app/ratcos.c |
7 | N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\app\ratcos.c:14:*Error* [1027] unable to locate 'stdbool.h' |
8 | "C:\Programme\Microchip\mplabc18\v3.47\bin\mcc18.exe" -p18F2550 -ms -oa- -I "C:\Programme\Microchip\mplabc18\v3.47\bin"\\..\\h -fo build/default/production/hardware/usb/src/usb_winusb.o hardware/usb/src/usb_winusb.c |
9 | N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\mcu.h:22:*Error:* [1027] unable to locate 'stdbool.h' |
10 | N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\mcu.h:23:*Error* [1027] unable to locate 'stdint.h' |
11 | N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\modules\powerController.h:11:*Error* [1027] unable to locate 'stdint.h'N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\usb\src\usb_winusb.c:27:*Error* [1027] |
12 | unable to locate 'stdint.h'N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\modules\pid.h:11:*Error* [1027] |
13 | unable to locate 'stdint.h' |
14 | N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\usb\src\usb_winusb.c:28:*Error* [1027] N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\app\ratcos.c:21:*Error* [1027] unable to locate 'usb_config.h' |
15 | unable to locate 'ratcos.X/modules/programController.h'N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\usb\src\usb_winusb.c:29:*Error* [1027] |
16 | unable to locate 'usb_microsoft.h' |
17 | make[2]: *** [build/default/production/app/ratcos.o] *Error_* |
18 | make[2]: *** Waiting for unfinished jobs.... |
19 | N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\usb\src\usb_winusb.h:30:*Error* [1027] MPLAB C18 3.47 (feature limited) |
20 | Copyright 2000-2011 Microchip Technology Inc. |
21 | This version of MPLAB C18 does not support the extended mode |
22 | and will not perform all optimizations. To purchase a full |
23 | copy of MPLAB C18, please contact your local distributor or |
24 | visit buy.microchip.com. |
25 | |
26 | WARNING: This version of MPLAB C18 does not support procedural abstraction. Procedural abstraction will not be run. |
27 | |
28 | unable to locate 'stdint.h'nbproject/Makefile-default.mk:206: recipe for target 'build/default/production/app/ratcos.o' failed |
29 | |
30 | MPLAB C18 3.47 (feature limited) |
31 | Copyright 2000-2011 Microchip Technology Inc. |
32 | This version of MPLAB C18 does not support the extended mode |
33 | and will not perform all optimizations. To purchase a full |
34 | copy of MPLAB C18, please contact your local distributor or |
35 | visit buy.microchip.com. |
36 | |
37 | WARNING: This version of MPLAB C18 does not support procedural abstraction. Procedural abstraction will not be run. |
38 | |
39 | "C:\Programme\Microchip\mplabc18\v3.47\bin\mcc18.exe" -p18F2550 -ms -oa- -I "C:\Programme\Microchip\mplabc18\v3.47\bin"\\..\\h -fo build/default/production/hardware/usb/src/usb_cdc.o hardware/usb/src/usb_cdc.c |
40 | make[2]: *** [build/default/production/hardware/usb/src/usb_winusb.o] *Error 3* |
41 | nbproject/Makefile-default.mk:214: recipe for target 'build/default/production/hardware/usb/src/usb_winusb.o' failed |
42 | "C:\Programme\Microchip\mplabc18\v3.47\bin\mcc18.exe" -p18F2550 -ms -oa- -I "C:\Programme\Microchip\mplabc18\v3.47\bin"\\..\\h -fo build/default/production/hardware/usb/src/usb.o hardware/usb/src/usb.c |
43 | N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\usb\src\usb_cdc.c:27:*Error* [1027] N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\usb\src\usb.c:41:*Error* [1099] unable to locate 'usb_config.h'"Compiler not supported" |
44 | |
45 | N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\usb\src\usb_cdc.c:28:*Error* [1027] MPLAB C18 3.47 (feature limited) |
46 | Copyright 2000-2011 Microchip Technology Inc. |
47 | This version of MPLAB C18 does not support the extended mode |
48 | and will not perform all optimizations. To purchase a full |
49 | copy of MPLAB C18, please contact your local distributor or |
50 | visit buy.microchip.com. |
51 | |
52 | WARNING: This version of MPLAB C18 does not support procedural abstraction. Procedural abstraction will not be run. |
53 | |
54 | make[2]: *** [build/default/production/hardware/usb/src/usb.o] *Error* |
55 | unable to locate 'usb_ch9.h'nbproject/Makefile-default.mk:222: recipe for target 'build/default/production/hardware/usb/src/usb.o' failed |
56 | |
57 | N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\usb\src\usb_cdc.c:29:*Error* [1027] unable to locate 'usb.h' |
58 | N:\dev\_PIC\reflow_mcnet\ratcos-code\firmware\trunk\ratcos.X\hardware\usb\src\usb_cdc.c:30:*Error* [1027] unable to locate 'usb_cdc.h' |
59 | MPLAB C18 3.47 (feature limited) |
60 | Copyright 2000-2011 Microchip Technology Inc. |
61 | This version of MPLAB C18 does not support the extended mode |
62 | and will not perform all optimizations. To purchase a full |
63 | copy of MPLAB C18, please contact your local distributor or |
64 | visit buy.microchip.com. |
65 | |
66 | WARNING: This version of MPLAB C18 does not support procedural abstraction. Procedural abstraction will not be run. |
67 | |
68 | nbproject/Makefile-default.mk:230: recipe for target 'build/default/production/hardware/usb/src/usb_cdc.o' failed |
69 | make[2]: Leaving directory 'N:/dev/_PIC/reflow_mcnet/ratcos-code/firmware/trunk/ratcos.X' |
70 | nbproject/Makefile-default.mk:78: recipe for target '.build-conf' failed |
71 | make[1]: Leaving directory 'N:/dev/_PIC/reflow_mcnet/ratcos-code/firmware/trunk/ratcos.X' |
72 | nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed |
73 | make[2]: *** [build/default/production/hardware/usb/src/usb_cdc.o] *Error 3* |
74 | make[1]: *** [.build-conf] *Error 2* |
75 | make: *** [.build-impl] *Error 2* |
76 | |
77 | BUILD FAILED (exit value 2, total time: 1s) |
Für mich schaut das so aus, als ob Du die Firmware mit dem alten C18 Compiler kompiliert hast. Bernhard hat zwischenzeitlich alles umgeschrieben, so das es jetzt auf dem neuen XC8 Compiler läuft. Lade Dir doch mal den XC8 Compiler von Microchip runter, dann sollte es funktionieren.
Für mich schaut das so aus, als ob Du die Firmware mit dem alten C18 Compiler kompiliert hast. Bernhard hat zwischenzeitlich alles umgeschrieben, so das es jetzt auf dem neuen XC8 Compiler läuft. Lade Dir doch mal den XC8 Compiler von Microchip runter, dann sollte es funktionieren. DA--> http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/
Frankman schrieb: > Für mich schaut das so aus, als ob Du die Firmware mit dem alten C18 > Compiler kompiliert hast. > > Bernhard hat zwischenzeitlich alles umgeschrieben, so das es jetzt auf > dem neuen XC8 Compiler läuft. Lade Dir doch mal den XC8 Compiler von > Microchip runter, dann sollte es funktionieren. > > DA--> http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/ So so. Dann sollte man Wiki bei Sourceforge aktualisieren, da steht nämlich genau das Gegenteil. Am besten schreien, ab welcher Version mit dem CX8 Compiler zu arbeitet ist.
Ah ok, dann ist das ja schonmal geklärt. ;-) Danke für den Hinweis, ich habs im SF-Wiki mal geändert. Wie schon beschrieben, ist im Moment ein "Stand Allone"-Betrieb implementiert, welcher beim Druck auf den Start-Button (ist im Bild der rechte...) ein festes Programm (module/ReflowProgramm.h) abfährt. Auf der CDC-Verbindung wird zyklisch ein Debugstatus im CSV Format rausgehauen. "Timestamp, Solltemperatur,Steuergröße des PID, Temperatur1, Temperatur2\r\n" Funktion der LEDs LED1 - Blinkt, wenn Z-Cross erkannt wird. LED2/3 - Leuchten, wenn Temperatursensoren erkannt werden. LED4 - Zeigt an, ob Power Ausgang 1 aktiv ist. Zur Zeit arbeite ich am Empfang von Daten vom PC. Das Feature ist umgesetzt, aber nicht getestet (Habe meinen Kram gerade nicht zur Hand und Job, Frau, Kind, Firmen-IT meiner Eltern, Wasserwacht, Ikea, etc. am Hals). Aber hoffentlich wirds bald was... ;-) Die PC-Software im Repository ist mehr oder weniger ein "Projektansatz". Das Programm zeigt ein Fenster mit einem Graph-Widget aus der QWT Lib an und füllt diesen mit Zufallszahlen. Viele Grüße Bernhard
> So so. Dann sollte man Wiki bei Sourceforge aktualisieren, da steht > nämlich genau das Gegenteil. Am besten schreien, ab welcher Version mit > dem CX8 Compiler zu arbeitet ist. Sag mal, Wolfram, wie bist Du denn drauf? Glaubst Du echt, wir alle hier haben nichts besseres zu tun, als DIR alles hinterher zu tragen??? Wenn Du die Revision-Messages im SVN gelesen hättest. Oder zumindest die Complier-Warnung, dann hättest Du das selber gemerkt! Wenn Du merkst, dass die Doku falsch ist, dann BITTE ändere doch DU zu Abwechslung mal die Doku im Wiki. Also echt, auf die Gefahr hin, dass ich mich hier jetzt unbeliebt mache: Selber nix auf die Kette kriegen, und immer nur haben, haben, haben, wollen, wollen, wollen... Kein Bitte, kein Danke... und selbst außer labern NULL KOMMA NICHTS zum Projekt beitragen.... So nicht!!!
Aber Hallo, nicht gleich aufregen. 1. Vielleicht ist es falsch rüber gekommen. Wollte hier nicht meckern. 2. Heißt es hier aber nicht "Zum Stöbern, Meckern, Bauen"...? 3. Habe mehrfach versucht nach allem was ich gefunden habe vor zu gehen und die Firmware in Betrieb zu nehemen. Und wenn da extra steht ich soll den C18 und nicht den XC8 Comiler nehemen, dann habe ich das halt so gemacht. Sorry. 4. Ich ändere hier gern eine Doku oder sonst was ab, wenn ich Fehler finde. Aber muss ich da nicht von euch freigeschaltet werden um im Sourceforge Projekt mit zu wirken? 5. Wenn keinerlei verbale Beschreibung da ist, was in der Software aktuell funktioniert (oder noch nicht funktioniert), dann ist es für einen außenstehenden halt schwer, das in Betrieb zu nehmen. 6. Habe auch nur begrenzt Zeit. 7. MPLABX und Microchip C18 sind für mich neu. 8. Sobald ich das Teil hier endlich am laufen habe, werde ich mal eine PC-Software schreiben. Momentan ist mein Stand jetzt so: - Nach Compiler Umstellung kann ich jetzt compilieren. - Entgegen vorher mit dem C18 Compiler, ist die Firmware nun auch lauffähig. Hurra! Endlich :-) Was fehlt mir: - Im Wiki fehlt noch eine Beschreibung wie der seriell Treiber in Betrieb genommen wird. Da stand vorher was von "Microchip Libraries for Applications" drin. Das ist jetzt aber wieder weg. - Von Windows XP wird jetzt ein Treiber für "USB CDC Test" verlagt. Ich habe zwar "Microchip Libraries for Applications" installiert. Windows findet hier aber nicht den benötigten Treiber. Mit der alten 138er Version hat XP schon erfolgreich den Microchip COM-Treiber installiert. Warum wird jetzt ein ganz anderer Treiber verlangt? Für einen Hinweis wäre ich sehr dankbar. Also: Vielen Dank für euer Projekt hier. Das einzige, was ich zu bemängeln habe, ist, dass ein etwas ausführliches Readme.txt feht, in dem beschrieben wird, wie alles Schritt für Schritt in Betrieb zu nehem ist, ohne dass sich ein außenstehender gleich in alle Details einarbeiten muss.
Guten Abend allerseits, beim eigebundenen USB-Stack, handelt es sich um den Open Source M-Stack von dieser Seite: http://www.signal11.us/oss/m-stack/ Dieser wird bei Github entwickelt: https://github.com/signal11/m-stack Dort finden sich auch Treiber für Windows. Karl hat das ganze unter Windows 8.1 aber auch zum Knattern gebracht, indem er die VID und PID im USB-Stack geändert und das ganze nochmal compiled hat. Er hat dazu auch ein Issue auf SourceForge verfasst: http://sourceforge.net/p/ratcos/tickets/3/ Viele Grüße Berni PS: Mit dem freischalten auf sf.net muss ich mich mal genauer befassen... ;-)
Danke für die schnelle Antwort. Ist ja interessant mit dem m-stack. Aber welcher Treiber wird denn jetzt unter Windows verwendet? Wird letztlich über einen Windows COM-Port kommuniziert, oder muss ich den Windows-Treiber selber ansprechen, was dann wieder aufwändiger wäre?
Das USB-Gerät wird unter Windows als "virtual COM" Device (beim Github-Stack ist eine .inf dabei) erkannt. Den CSV-Print kannst du dir auch mit HTERM & Co ansehen. Baudrate ist übrigens wumpe, das interessiert den CDC nicht...
:
Bearbeitet durch User
Danke für die Infos. Jetzt funktioniert alles. Bin gerade an einen kleinen ersten PC Programm zur Visualisierung. Viele Grüße Wolfram
Hier mal eine Anleitung, wie der Windows Treiber (z. B. unter Win7) - für den in der Firmware verwendeten M-Stack - installiert wird. 1. Unter www.github.com/signal11/m-stack/blob/master/apps/cdc_acm/inf/ die Dateie cdc-acm.inf runter laden. 2. USB der Controller-Hardware am PC anstecken. Im Gerätemanager muss jetzt unter "Andere Geräte" der Eintrag "USB CDC Test" angezeigt werden. 3. Auf diesem Eintrag "USB CDC Test" im Gerätemanager mit der rechten Maustaste klicken und "Treibersoftware aktualisieren" auswählen. 4. Dann den zweiten Punkt ("Auf dem Computer nach Treibersoftware suchen") auswählen. 5. "Durchsuchen" wählen und das Verzeichnis auswählen, in dem sich die heruntergeladene Datei cdc-acm.inf befindet. 6. Der Treiber wird nun installiert und danach sollte eine Erfolgsmeldung kommen. 7. Im Erfolgsfall wir im Gerätemanager unter "Anschlüsse (COM,...)..." z. B."M-Stack CDS Demo (COM5)" angezeigt.
Hallo, Ist es muglich Eagle-ASCII-Daten machen oder sch for Eagle ? Danke Mike
Gibt es derzeit in der Firmware schon eine Möglichkeit die Steuerung vom PC aus zu übernehmen? Es würde mir fürs erste schon mal genügen, wenn man nur Sollwerte schicken kann. Gut wäre auch, wenn man die Firmware in einen PC-Mode schalten könnte, in dem dann die Tastenbedienung gesperrt wird bzw. der Stop-Taster den Sollwert wieder auf 0 setzt und den PC-Mode beendet.
Ist eigentlich in der Firmware auch vorgesehen Temperatur-Rampen zu fahren oder kann man nur Stufen fahren? Mein Ofen hat so viel Power, dass die Temperatur-Anstiegsgeschwindigkeit um Welten zu hoch ist.
@Wolfram: Die Temperatur-Rampen implementiert Bernhard gerade. --> ggv. schon fertig? Schau mal bei Sourceforge... @Mike.M: Ich schau, das ich die ASCII-Daten für Eagle irgendwann die Woche mache. Ich bin gerade recht dick drin... Wäre dann also ein kleines Nicolaus-Geschenk für Dich.... :-) Kannst Du bitte so nett sein, und kurz bescheid geben, falls es mit dem Export nicht hinhaut?
Hier mal vorab ein Bild von der Software. frankman schrieb: > Die Temperatur-Rampen implementiert Bernhard gerade. --> ggv. schon > fertig? Schau mal bei Sourceforge... Das hört sich ja gut an. Habe die neue Version gerade ausprobiert. Von einer Rampe habe ich aber noch nichts gemerkt. Für weitere Infos wäre ich sehr dankbar. Bin gerade an der PC Software und würde dann auch gerne für den Fall der Rampe den Sollwert entsprechend anzeigen. Und da frage ich mich gerade wie das der PC Software mitgeteilt wird? Anregungen und Wünsche zur PC-Software können gerne geäußert werden. Ich stelle mir als nächstes folgendes vor: 1. Gespeicherte Kennlinien sollten aus dem Controller ausgelesen werden können. So kann ich die Sollwerte schon vorab im Graph anzeigen. 2. Kennlinien sollten an den Controller gesendet werden können. Wenigstens eine einzige, die dann im RAM gehalten wird und die vom PC gestartet werden kann.
:
Bearbeitet durch User
Hallo Wolfram, ich war jetzt mal so frei und hab Deine Beschreibung für die Treiberinstallation in den Artikel und ins Sourceforge-Wiki übernommen, noch mal danke an der Stelle.
Wolfram, die Regelung bei Dir schau ja echt sauber aus, ist das "Deine" oder der PID-Controller von der RATCOS-Software?
Frankman schrieb: > Wolfram, die Regelung bei Dir schau ja echt sauber aus, ist das "Deine" > oder der PID-Controller von der RATCOS-Software? Das ist der PID-Controller von der RATCOS-Software. Meines Erachtens ist aber bei 200° noch ewas zu viel Überschwingen! Ist jetzt eigentlich schon was für die Temperatur-Rampen drin? Gerne würde ich auch das Temperaturprofil vom PC aus schicken können - und den Lötvorgang vom PC aus starten können. Wenn man die Regeler-Parameter auch noch vom PC schreiben könnte wäre es ganz perfekt. Und alles möglichst für jeden Kanal getrennt. Vielleicht sollte man aber auch einfach nur Sollwerte vom PC aus schicken können, die dann ohne Regelung oder mit Regelung (und mit oder ohne Rampe) angefahren werden. In welchem Zeitraster wird eigentlich die Temperatur gemessen? Zum PC wird ja nur im jede Sekunde übertragen.
Frankman schrieb: > Wolfram, die Regelung bei Dir schau ja echt sauber aus, ist das "Deine" > oder der PID-Controller von der RATCOS-Software? Was wird eigentlich auf dem 2ten Kanal (blau) für ein Sollwert geschickt? Sind das irgendwelche Zufallswerte?
Nö, keine Zufallswerte. Da kann man doch einen zweiten MAX6635 bestücken und auch eine 2. Temperatur messen.
Frankman schrieb: > Nö, keine Zufallswerte. > Da kann man doch einen zweiten MAX6635 bestücken und auch eine 2. > Temperatur messen. Der ist bei mir bestückt und zeigt auch das richtige an. Siehe violette Kurve. Das ist bei mir die "Unterhitze" im Backofen. Der Triac wird aber nicht angesteuert. Ist ja auch ok, da kein Profil da. Nur warum da auf dem USB so komische Sollwerte kommen (blaue Kurve), ist merkwürdig. BTW: Ich hatte noch einen Beitrag davor geschrieben. Vielleicht hast Du den ja übersehen. Viele Grüße Wolfram
Die blaue Kurve duerfte die Power Kurve sein, also die Kurve in Prozent 0-100 fuer die Power on Leistung.
chris schrieb: > Die blaue Kurve duerfte die Power Kurve sein, also die > Kurve in Prozent 0-100 fuer die Power on Leistung. Ach ja, das stimmt. Das ist mir noch garnicht aufgefallen. Ich dachte die Werte sind Time, Sol1, Soll2, Ist1, Ist2 Wenn dem aber jetzt nicht so ist, wo sind dann Soll2 und Power2% ? Die sollten dann doch auch übertragen werden, wenn schon Ist2 ebenfalls im Datensatz übertragen wird. Oder man übertraägt besser für jeden Kanal einen separaten Datensatz, was ich nur konequent finden würde. In ratcos.c fehlt übrigens in "printf("INFO: Program finished!");" noch das "\r\n" am Ende, sonst wird die "Info:" mit dem nächsten Datensatz in einen Zeile vermischt, was die Auswertung im PC-Programm unnötig erschwert.
Moin zusammen, das mit der Power stimmt. Das war bisher auch mehr eine CSV Debug-Info welche ich schnell aus dem Terminal kopieren und mir Calc als Diagramm anzeigen lassen konnte. Im Moment schaut es wie folgt aus: Time,Soll1,Power,T1,T2 Bevor damit noch fleißig gebastelt wird, würde ich sagen, machen wir das erst mal schick. Ich versuche mal mir bis zu WE was auszudenken. ;-) Für die Rampe habe ich einen Featurebranch in der Firmware offen. Den kann man gerne mal ziehen und testen. Liegt auf SF unter /firmware/branches/FB_rampControl und läuft recht passabel. Ich habe ihn noch nicht vollständig mit dem Öfchen getestet. Bei ~1300W muss man die Rampen fast horizontal machen. Er startet die Rampe im Moment auch bei Null, was auch noch nicht ganz stimmt... @Wolfram Hast du Bilder von deinem Toaster? Würde mich mal interessieren welches Gerät so schöne Rampen fährt... :-) So long, Gruß Bernhard
Bernhard R. schrieb: > Moin zusammen, > das mit der Power stimmt. Das war bisher auch mehr eine CSV Debug-Info > welche ich schnell aus dem Terminal kopieren und mir Calc als Diagramm > anzeigen lassen konnte. Im Moment schaut es wie folgt aus: > Time,Soll1,Power,T1,T2 > Bevor damit noch fleißig gebastelt wird, würde ich sagen, machen wir das > erst mal schick. Ich versuche mal mir bis zu WE was auszudenken. ;-) Das mit der Power sollte ruhig drin bleiben. Ich mache es in der PC-Software im Diagramm einfach abschaltbar. Aber es sollte halt für alle Kanäle übertragen werden. Auch würde ich die Daten für jeden Kanal separat übertagen. Die Firmware soll ja universell sein und für 1, 2 oder künftig vielleicht sogar mehr Kanälen funktionieren. Außerdem ist dann die Außwertung in der PC-Software übersichtlicher. Desweiteren würde ich mir überlegen die Daten (ev. optional) häufiger zu übertragen. Wäre das möglich? > Für die Rampe habe ich einen Featurebranch in der Firmware offen. Den > kann man gerne mal ziehen und testen. Liegt auf SF unter > /firmware/branches/FB_rampControl und läuft recht passabel. Ich habe ihn > noch nicht vollständig mit dem Öfchen getestet. Bei ~1300W muss man die > Rampen fast horizontal machen. Er startet die Rampe im Moment auch bei > Null, was auch noch nicht ganz stimmt... Ich werde es mal testen.
Hallo Bernhard, ich werde die Tage auch mal wieder mitmachen... Ich hab meinem Ofen etwas aufgemotzt. Mit 900W extra Power :-) Also drei mal Halogen-Brennstab dazu. Bin gespannt, werde mir dann bei der Gelegenheit auch mal die neuste Version ziehen... Viele Grüße Frank
Bernhard R. schrieb: > @Wolfram Hast du Bilder von deinem Toaster? Würde mich mal interessieren > welches Gerät so schöne Rampen fährt... :-) Ich verwende einen Billigstbackofen (eBay, Suchtext: "9 L Minibackofen 800 Watt") für 21,90 EUR. Der Trick ist aber, dass ich oben und unten jeweils 2 zusätzliche Halogen-Heizstrahler a 400W (nicht Quarzstraher sondern Halogen!) eingebaut habe. Somit hat der Ofen 2 x 1200W also 2400W. Die Halogenstrahler habe ich samt Fassungen aus zwei gebrauchten/defekten Heizstrahlern (ebay, Suchtext: "Halogen Heizstrahler VT 1200") ausgeschlachtet. Der Minibackofen ist allerdings zu billig und zu primitiv aufgebaut, was beim Umbau sehr genervt hat! Außerdem sind die zwei originalen Heizstäbe nicht Halogen- sondern Quarz-Strahler. Da würde ich das nächste mal etwas besseres verwenden. Am besten einen Heißluft Ofen, so dass durch die Luftumwälzung der Nachteil der reinen Infrarotstrahlung gemildert wird. Schön am Halogen finde ich aber auch, dass es sehr hell im Ofen wird. Die dargestellte Kurve ist aber nur unter alleiniger Verwendung der 3 oberen Heizstrahler (1200W) zustande gekommen (siehe violette Kurve, die immer unterhalb der roten verläuft). Messen tue ich mit einer Restleiterplatte mit einem Thermoelement oben und einem unten befestigt. Ciao, Wolfram
:
Bearbeitet durch User
Ich hab bei mir jetzt die Halogenstäbe dazugebaut und auch endlich mal die Thermoelemente gescheit montiert. Das mit dem Kabel durch die Ofenklappe war auf Dauer echt nix.
Hallo Ich würde sehr gerne diese Steuerung nachbauen. Hat jemand schon Gerber-Files für die kleinere Platinenversion V1.2, mit externen SSRs und kann sie geben ? Noch zur Info die Gerber-Files in der Projekt-ZIP sind noch von Version 1.0 (2.4.2013).
Hallo allerseits Das Projekt klingt sehr interessant. Ich hätte aber noch die eine oder andere Frage an euch. Betreff: Ratcos PC-Software Kann mir mal bitte jemand beschreiben, was alles installiert werden muss und was konfiguriert werden muss um die PC-Software zu compilieren? MinGW ist nicht meine Baustelle Eine Kurzanleitung wäre sehr willkommen. Oder gibt es fertige Binärdateien? Zum Testen @ Frankman Betreff: Reflow Controller 1.2 Eagle-ASCII-Daten oder ein Schaltplan wäre mir sehr willkommen da ich ein Eagle User bin Danke im voraus
Hi insertYourName(), die PC Software existiert in dieser Form leider (noch) nicht. Was auf Sourceforge im Repo so rumdümpelt ist mehr oder weniger eine Boilerplate und wurde nie weiter bearbeitet. Da brauchst du dir keine mühe machen. Ich werde das bei Zeiten mal rausschmeißen. Aktuell fahre ich den Ofen per Terminal oder den Tastern. Die grafische Oberfläche wäre schön, allerdings bin ich der letzte, der hier noch an der Software werkelt und meine Zeit ist bei Job, 10 Kindern, und Admin spielen im Betrieb meiner Eltern leider etwas knapp. Falls jemand also Lust verspürt eine Software für RATCOS zu schreiben, ist er herzlich eingeladen, das zu tun. Mitstreiter sind immer herzlich willkommen! ;-) Bei Interesse einfach schreien. Liebe Grüße, Bernhard PS: Mein Ofen steht nun seit zweieinhalb Monaten auf Arbeit und wird vom Kollegen als kompakte Klimakammer zum Backen von Prototypen verwendet. Wenn ich den wieder daheim habe, geht's auch wieder etwas schneller vorwärts.
Achja was ich noch vergessen hatte: Schaltplan gibts als PDF im Artikel https://www.mikrocontroller.net/articles/Reflow_Ofen_Steuerung
Bernhard R. schrieb: > die PC Software existiert in dieser Form leider (noch) nicht. > Was auf Sourceforge im Repo so rumdümpelt ist mehr oder weniger eine > Boilerplate und wurde nie weiter bearbeitet. Da brauchst du dir keine > mühe machen. Ich werde das bei Zeiten mal rausschmeißen. > > Aktuell fahre ich den Ofen per Terminal oder den Tastern. Die grafische > Oberfläche wäre schön, allerdings bin ich der letzte, der hier noch an > der Software werkelt und meine Zeit ist bei Job, 10 Kindern, und Admin > spielen im Betrieb meiner Eltern leider etwas knapp. > > Falls jemand also Lust verspürt eine Software für RATCOS zu schreiben, > ist er herzlich eingeladen, das zu tun. > > Mitstreiter sind immer herzlich willkommen! ;-) > Bei Interesse einfach schreien. Eine GUI PC-Software habe ich mit FreePascal/Lazarus geschrieben (Siehe Beitrag vom 03.12.2014. Allerdings hatten damals in der Firmware noch so diverse Möglichkeiten gefehlt, weswegen ich das noch nicht veröffentlicht habe. Außerdem habe ich derzeit leider auch sehr wenig Zeit. Aber wenn Interesse besteht, kann ich mir das demnächst nochmal ansehen. Viele Grüße, Wolfram
Ein richtig Tolles Project, sehr gut gemacht.Was für einen Ofen benutzt du dafür? Wäre vielleicht nicht schlecht wenn du das Ganze Project als ZIP Datei mit einer Guten Beschreibung als Download zu verfügung stellen würdest.
Hallo Ein Hinweis: Die Pdf Schaltplan Links sind defekt. Kannst du das nochmal richtig verknuepfen? Lg
Stefan schrieb: > Hallo Ein Hinweis: Die Pdf Schaltplan Links sind defekt. Kannst du das > nochmal richtig verknuepfen? Also bei mir gehen die Links alle (https://www.mikrocontroller.net/articles/Reflow_Ofen_Steuerung#Zum_Nachbauen)
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.