Interesse poll: PWM regeling voor FANs

[Verwijderd]

Op vrijdag 22 februari 2002 23:49 schreef Maxim het volgende:

[..]

Wees gerust. Aangezien je zelf de fan schakelt weet je ook dat je die overgang niet als een rpm puls moet behandelen.

Maar ik ben wel benieuwd hoe je de rpm-meting gaat implementeren in de software. Pollen of met de timers (T0,T1) werken?
[..]

Beide toeren-inputs zitten op T0 en T1. Dus ik kan pulsen meten via de "nette" timer oplossing. De 3e timer heb ik dan over om PWM te genereren. Een seriele poort op een AVR "verbruikt" immers geen timer. Ik hoop dat ik het op deze manier rond krijg. Polling daar ben ik geen fan van

Ik niet, ben zelf ook bezig met PWM/RPM en het gaat helemaal goedkomen!
Dit weekend hoop ik alles werkend te krijgen.

Aha, en hoe ga jij de pulsen meten? ook via de "nette" oplossing? Ik denk dat het herkennen wanneer je zelf een puls stuurt en wanneer er een RPM puls voorbij komt niet heeel eenvoudig is om het betrouwbaar te maken in software. Maar ook niet echt onoplosbaar

edit:

IDEE. Als je via T0 en T1 niet pulsen "timed" maar pulsen TELT (het aantal flanken dus), dit over b.v. een seconde, dan is het toerental altijd het gemeten aantal pulsen min het aantal Hz van je PWM! Kan er hoogstens een paar ticks naast zitten als beide toevallig tegelijk vallen... Maar zo heb je wel een simpele filtering van je PWM signaal. Een tweede alternatief kan liggen in hardware: Via een laagdoorlaat filter kun je denk ik het PWM signaal wel eruit filteren. Omdat de hogere harmonischen van het RPM signaal er dan ook uitgaan, moet je het signaal daarna schmitt-triggeren

[moefit]

Op vrijdag 22 februari 2002 20:04 schreef Maxim het volgende:

[..]

Als je RPM frequentie onder de PWM frequentie duikt krijg je dit iig. Op je RPM uitgang heb je op zijn minst de schakelfrequentie staan da's logisch.

Maar,aarmee heb jij de duty cycle eigelijk gemeten ? Oscilloscoop of anders ?

Bij mijn bedrijf werken we nogal veel met proportionele (PWM) aansturingen van hydrauliek. Daarvoor hebben we dus ook een speciale controller, volledig programmeerbaar via een laptop (PC). In de testmode kan ik dus eenvoudig de duty cycle instellen (0-100%) en de frequentie (10-500Hz). Het resultaat heb ik gemeten met een scope.

Op zaterdag 23 februari 2002 09:10 schreef --EasY-- het volgende:

[..]

Aha, en hoe ga jij de pulsen meten? ook via de "nette" oplossing? Ik denk dat het herkennen wanneer je zelf een puls stuurt en wanneer er een RPM puls voorbij komt niet heeel eenvoudig is om het betrouwbaar te maken in software. Maar ook niet echt onoplosbaar

edit:

IDEE. Als je via T0 en T1 niet pulsen "timed" maar pulsen TELT (het aantal flanken dus), dit over b.v. een seconde, dan is het toerental altijd het gemeten aantal pulsen min het aantal Hz van je PWM! Kan er hoogstens een paar ticks naast zitten als beide toevallig tegelijk vallen... Maar zo heb je wel een simpele filtering van je PWM signaal. Een tweede alternatief kan liggen in hardware: Via een laagdoorlaat filter kun je denk ik het PWM signaal wel eruit filteren. Omdat de hogere harmonischen van het RPM signaal er dan ook uitgaan, moet je het signaal daarna schmitt-triggeren

Het vreemde aan mijn meting is dat boven een bepaalde duty cycle het volledige toerensignaal wel beschikbaar is. Het lijkt wel of dat meer met de gemiddelde voedingsspanning te maken heeft dan met het PWM signaal. Zoals ik een van de vorige posts al zei: het resultaat is onafhankelijk van de gebruikte PWM frequentie. In alle gevallen, bij lage duty cycle, kwam de PWM frequentie tevoorschijn.

Het signaal op de scope zag er wel een beetje vreemd uit: Het signaal van de toerenmeting is bijna een 50% duty cycle signaal. Bij lage PWM zag ik echter elke keer bij uitschakelen van de PNP tor het RPM signaal even schakelen (=0V), vlak daarna (voordat de PNP tor weer insgeschakeld is) was het signaal weer hoog. Bij wat hogere duty cycle was dit effect er niet meer.

Een oplossing hiervoor is denk ik wel mogelijk! Je zou bijvoorbeel een neergaande flank tegelijk met het PWM hoog->laag overgang kunnen negeren. Of enkel de tijd meten dat het signaal laag is (geschakeld dus), dit b.v. drie keer achter elkaar en dan de véél kortere negeren.

[Verwijderd]

Op vrijdag 22 februari 2002 23:28 schreef --EasY-- het volgende:
Ditmaal de PNP powertorren (hopelijk ) goed aangesloten, De AVR micro is nu een DIL-40 variant. Verder het schema iets ruimer opgezet, dat is wat beter leesbaar...

Kun je niet een PLCC44 gebruiken? Die neem ik meestal: relatief klein, en toch eenvoudig hanteerbaar doordat je ze in een voetje monteert met pinnetjes aan de onderkant. Volgens mij is de PLCC44 ook beter verkrijgbaar en goedkoper

Over de haalbaarheid van toerenmeting met een PWM sturing daar twijfel ik nu erg aan; het ziet ernaar uit dat ik dat toch moet gaan testen alvorens ik een PCB kan gaan bakken

Ik weet niet zoveel van die toeren, maar is het niet zo dat je in principe een AND krijgt van je PWM signaal en je toerensignaal? Zoeist dus:

code:

(LF RPM meetsignaal AND PWM signaal)

     +--+  +--+  +--+            +--+  +-- .......
-------+  +--+  +--+  +-----------------+  +--+

In dat geval kun je meten hoeveel PWM pulsen je krijgt, en dat uitmiddelen over een stel metingen.

[Verwijderd]

Op zaterdag 23 februari 2002 09:10 schreef --EasY-- het volgende:

Beide toeren-inputs zitten op T0 en T1. Dus ik kan pulsen meten via de "nette" timer oplossing. De 3e timer heb ik dan over om PWM te genereren. Een seriele poort op een AVR "verbruikt" immers geen timer. Ik hoop dat ik het op deze manier rond krijg. Polling daar ben ik geen fan van

Ik ook niet, domme vraag eigenlijk. Maar ik ging uit van een 8515 ipv 4434. En die heeft maar 2 timers.
Er staat trouwens ook nog 8515 in je schema.

Aha, en hoe ga jij de pulsen meten? ook via de "nette" oplossing? Ik denk dat het herkennen wanneer je zelf een puls stuurt en wanneer er een RPM puls voorbij komt niet heeel eenvoudig is om het betrouwbaar te maken in software. Maar ook niet echt onoplosbaar

Ik gebruik ook een 'nette' oplossing. T1 als extern geclockte counter gebruiken(falling edge).
TO als timer voor tijdbasis. Fan aan timer0 enabled. Fan uit timer0 disabled. Bij overflow T0 T1 uitlezen. Globaal uitgelegt. Maar deze opzet is hier niet echt zinvol geloof ik. Omdat je geen timer voor de RPM generatie meer over hebt. Is in mijn applicatie ook niet relevant. Maar hier wel.

edit:

IDEE. Als je via T0 en T1 niet pulsen "timed" maar pulsen TELT (het aantal flanken dus), dit over b.v. een seconde, dan is het toerental altijd het gemeten aantal pulsen min het aantal Hz van je PWM! Kan er hoogstens een paar ticks naast zitten als beide toevallig tegelijk vallen... Maar zo heb je wel een simpele filtering van je PWM signaal. Een tweede alternatief kan liggen in hardware: Via een laagdoorlaat filter kun je denk ik het PWM signaal wel eruit filteren. Omdat de hogere harmonischen van het RPM signaal er dan ook uitgaan, moet je het signaal daarna schmitt-triggeren

Ja, maar dan moet je nog wel compenseren voor de duty-cyle. Omdat het aantal gemeten pulsen in een seconde ook nog van de duty-cycle afhangt.

Wat betreft het hardwarematig filteren zou ik zeggen: 'Be My Guest'.


Voordeeltje: De RPM-uitgang van een fan geeft 2 pulsen per omwenteling af ipv 1. Dus 3000 toeren = 100hz.

[Verwijderd]

ff uitgezocht hoe het RPM signaal van de fan opgewekt wordt :



Dit schema verklaart misschien gelijk waarom de PWM uitgang na het uitschakelen nog even naar massa schakelt. Inductieve uitschakelperikelen ????

Maargoed volgens mij is dit wel makkelijk op te lossen. Softwarematig of met een AND-poortje dat de RPM uitgang loskoppelt van de uC als het PWM-signaal laag is.

[Verwijderd]

Op zaterdag 23 februari 2002 13:01 schreef DaBit het volgende:

[..]

Kun je niet een PLCC44 gebruiken? Die neem ik meestal: relatief klein, en toch eenvoudig hanteerbaar doordat je ze in een voetje monteert met pinnetjes aan de onderkant. Volgens mij is de PLCC44 ook beter verkrijgbaar en goedkoper

Beter verkrijgbaar en goedkoper niet, wel kleiner. Ik had deze eerst ingedesigned, maar heb hem later vervangen voor de DIL40 omdat deze beter debugbaar zijn... Maar zeg het maar, ik heb beide shapes nu in CAD zitten

Ik weet niet zoveel van die toeren, maar is het niet zo dat je in principe een AND krijgt van je PWM signaal en je toerensignaal? Zoeist dus:

code:

(LF RPM meetsignaal AND PWM signaal)

     +--+  +--+  +--+            +--+  +-- .......
-------+  +--+  +--+  +-----------------+  +--+

In dat geval kun je meten hoeveel PWM pulsen je krijgt, en dat uitmiddelen over een stel metingen.

Ja zie hieronder. Ik zag al een post met de achterliggende RPM logica in de fan...

[Verwijderd]

Op zaterdag 23 februari 2002 15:35 schreef Maxim het volgende:

[..]

Ik ook niet, domme vraag eigenlijk. Maar ik ging uit van een 8515 ipv 4434. En die heeft maar 2 timers.
Er staat trouwens ook nog 8515 in je schema.

Hummm ja inderdaad... De nummering is wel van een 8535, maar het naampje is idd nog 8515 (de shape had ik "geleend"). Ik pas het gelijk ff aan tanx!

edit:

Ff aangepast op http://www.xs4all.nl/~kruimpie

Ik gebruik ook een 'nette' oplossing. T1 als extern geclockte counter gebruiken(falling edge).
TO als timer voor tijdbasis. Fan aan timer0 enabled. Fan uit timer0 disabled. Bij overflow T0 T1 uitlezen. Globaal uitgelegt. Maar deze opzet is hier niet echt zinvol geloof ik. Omdat je geen timer voor de RPM generatie meer over hebt. Is in mijn applicatie ook niet relevant. Maar hier wel.

Mja het kan zo hoor, ik ga ofwel T0 en T1 gebruiken om pulsbreedte te meten (is immers een maat voor de freq.) of ik ga ze gebruiken als tellers en gebruik ik de PWM tijdbasis (meervoud) om de tellers uit te lezen.

Ja, maar dan moet je nog wel compenseren voor de duty-cyle. Omdat het aantal gemeten pulsen in een seconde ook nog van de duty-cycle afhangt.

uhm? Volgens mij niet, de dutycyle zal niet relevant zijn. Ik tel immers alleen de opgaande flanken.

[Verwijderd]

Op zaterdag 23 februari 2002 19:08 schreef Maxim het volgende:
ff uitgezocht hoe het RPM signaal van de fan opgewekt wordt :

[afbeelding]

Dit schema verklaart misschien gelijk waarom de PWM uitgang na het uitschakelen nog even naar massa schakelt. Inductieve uitschakelperikelen ????

Maargoed volgens mij is dit wel makkelijk op te lossen. Softwarematig of met een AND-poortje dat de RPM uitgang loskoppelt van de uC als het PWM-signaal laag is.

Hmmm bedankt voor het opzoeken van het spul in de FAN t.b.v. RPM meting! Helaas, hier was ik al bang voor: De RPM logica is wel degelijk actief en vind het dus niet fijn om gePWMmed te worden

dat AND poortje werkt niet zo heel fijn denk ik: Als de fan laag toeren draait ga je erg veel pulsen missen

Hier moeten we nog maar eens goed over breenstormen

[Verwijderd]

Op zaterdag 23 februari 2002 23:57 schreef --EasY-- het volgende:

uhm? Volgens mij niet, de dutycyle zal niet relevant zijn. Ik tel immers alleen de opgaande flanken.

Ik bedoel de dutycycle van het PWM-signaal niet het RPM-signaal. Je kan niet zomaar een seconde lang pulsen tellen, omdat je fan geen seconde lang achter elkaar aan staat. Op deze manier bedoelde ik het.

dat AND poortje werkt niet zo heel fijn denk ik: Als de fan laag toeren draait ga je erg veel pulsen missen

Het AND poortje dient alleen om de puls na het uitschakelen van de fan zoals door Moefit beschreven er uit te 'filteren'.

[Verwijderd]

Op zondag 24 februari 2002 00:24 schreef Maxim het volgende:

[..]

Ik bedoel de dutycycle van het PWM-signaal niet het RPM-signaal. Je kan niet zomaar een seconde lang pulsen tellen, omdat je fan geen seconde lang achter elkaar aan staat. Op deze manier bedoelde ik het.

Aha op die manier. Ik denk dat de beste kans nog is om te kijken hoe lang de fan aan geweest is, het aantal RPM pulsen te tellen tijdens het aan zijn, en dat aantal te vergroten naar een fan-tijd van 100%

Dus met 50% PWM het aantal RPM pulsen die in de "PWM-aan" tijd vielen met 2 te vermenigvuldigen oef....

Het AND poortje dient alleen om de puls na het uitschakelen van de fan zoals door Moefit beschreven er uit te 'filteren'.

Juistum, dit kost helaas wel weer extra logica op de PCB, misschien is er wel een net zo goed software oplossing. B.v. de teller stopzetten als het PWM signaal nul is, en alleen het tellen te enablen tijdens PWM=1....

[moefit]

Op zondag 24 februari 2002 12:45 schreef --EasY-- het volgende:

[..]

Juistum, dit kost helaas wel weer extra logica op de PCB, misschien is er wel een net zo goed software oplossing. B.v. de teller stopzetten als het PWM signaal nul is, en alleen het tellen te enablen tijdens PWM=1....

Het probleem is dat op een gegeven moment het rpm signaal van de fan dus lager wordt dan de frequentie van het PWM signaal, dan heb je <<1 puls per PWM hoog tijd. Stel FAN:3600 RPM => 60 omwentelingen/seconde = 120Hz RPM signaal. Als je deze fan gaat vertragen dan krijg je al heel snel: PWM frequentie >(>) RPM frequentie.

Het lijkt mij beter om eens te gaan kijken naar het effect dat ik laatst heb beschreven, dat het RPM signaal enkel kortstondig geschakeld wordt bij het uitschakelen van het PWM signaal. Heel kort daarna is het signaal weer terug, voordat het PWM signaal weer geschakeld is! Vraag met niet waarom dat zo is, maar dit moet makkelijk te filteren zijn in de software. Er vallen geen pulsen weg, alleen soms een extra heel korte puls meteen na het uitschakelen van het PWM signaal.

edit:
Ik wist niet hoeveel pulsen je per omwenteling krijgt. 2 dus volgens Maxim

[moefit]

Ik heb een poging gedaan even te tekenen wat ik op de scope zag. Het is wel een digitale geheugen scope maar helaas geen PC-interface...

[Verwijderd]

Hoe kan dat RPM signaal nou laag zijn als het PWM signaal ook laag is

[moefit]

Graag vorige posts even lezen.

Op zaterdag 23 februari 2002 12:04 schreef moefit het volgende:

[..]

Het vreemde aan mijn meting is dat boven een bepaalde duty cycle het volledige toerensignaal wel beschikbaar is. Het lijkt wel of dat meer met de gemiddelde voedingsspanning te maken heeft dan met het PWM signaal. Zoals ik een van de vorige posts al zei: het resultaat is onafhankelijk van de gebruikte PWM frequentie. In alle gevallen, bij lage duty cycle, kwam de PWM frequentie tevoorschijn.

Het signaal op de scope zag er wel een beetje vreemd uit: Het signaal van de toerenmeting is bijna een 50% duty cycle signaal. Bij lage PWM zag ik echter elke keer bij uitschakelen van de PNP tor het RPM signaal even schakelen (=0V), vlak daarna (voordat de PNP tor weer insgeschakeld is) was het signaal weer hoog. Bij wat hogere duty cycle was dit effect er niet meer.

[..]

Op zaterdag 23 februari 2002 19:08 schreef Maxim het volgende:
ff uitgezocht hoe het RPM signaal van de fan opgewekt wordt :

[afbeelding]

Dit schema verklaart misschien gelijk waarom de PWM uitgang na het uitschakelen nog even naar massa schakelt. Inductieve uitschakelperikelen ????

[..]

Op zondag 24 februari 2002 16:24 schreef moefit het volgende:

[..]

Het lijkt mij beter om eens te gaan kijken naar het effect dat ik laatst heb beschreven, dat het RPM signaal enkel kortstondig geschakeld wordt bij het uitschakelen van het PWM signaal. Heel kort daarna is het signaal weer terug, voordat het PWM signaal weer geschakeld is! Vraag met niet waarom dat zo is, maar dit moet makkelijk te filteren zijn in de software. Er vallen geen pulsen weg, alleen soms een extra heel korte puls meteen na het uitschakelen van het PWM signaal.

edit:
Ik wist niet hoeveel pulsen je per omwenteling krijgt. 2 dus volgens Maxim

Let op: hier is het PWM signaal + geschakeld, het RPM signaal is laag als het geschakeld is.

[Verwijderd]

Op maandag 25 februari 2002 10:06 schreef moefit het volgende:
Ik heb een poging gedaan even te tekenen wat ik op de scope zag. Het is wel een digitale geheugen scope maar helaas geen PC-interface...

[afbeelding]

Dit is een interessant plaatje; ik snap het echter ook niet 100%. Het RPM signaal wordt laag als de tor in de fan (zie schema verder terug) dicht gaat. Dit kan echter alleen als de fan op dat moment spanning krijgt. Hoe kan ik nu PWM=0 en ook RPM=0 zien? Volgens mij moet RPM altijd "hoog" zijn (inactief) tijdens PWM=0

Anyway, ik laat me niet verder vertragen en ben vandaag begonnen met de PCB layout. Ik had erg veel problemen met de Atmel controller in PLCC44 behuizing (ook al nam ik een through-hole voetje) dat ik nu van de DIL40 ben uitgegegaan. Deze route nu op 100% enkelzijdig, iets wat de gemiddelde hobbyist wel prettig zal vinden

Ik heb de RPM-meting alleen voorzien van een serieweerstand (in het schema 1k) om eventuele (te) hoge voltages wat te stroombegrenzen. Daarna zie ik wel in hoeverre ik dit in software kan gebruiken voor een degelijke meting. Elke RPM input hangt aan T0 resp. T1, zodat ik maximale flexibiliteit heb t.a.v. hardware-timing.

[moefit]

Het getekende PWM signaal is de spanning aan de + kant van de FAN, dus inderdaad wordt het RPM signaal aktief als het moment dat de voeding wegvalt.

Vergeet bij de RPM input in ieder geval de pull-up niet! In mijn testopstelling heb ik 10K gebruikt hiervoor.

[Verwijderd]

Op maandag 25 februari 2002 13:20 schreef moefit het volgende:
Het getekende PWM signaal is de spanning aan de + kant van de FAN, dus inderdaad wordt het RPM signaal aktief als het moment dat de voeding wegvalt.

Vergeet bij de RPM input in ieder geval de pull-up niet! In mijn testopstelling heb ik 10K gebruikt hiervoor.

Ja, de AVR heeft interne pullups die je "per pin" kunt in en uitschakelen

Dus daar is aan gedacht... De serieweerstand heb ik puur ingebakken ter beveiliging mocht er ooit door een defecte fan oid veel stroom gaan lopen. Eventueel vervangbaar door een draadje natuurlijk

Bijkomend voordeel was trouwens dat het errug lekker route met zo hier en daar een "via" naar de bovenkant

Ik heb nu een heeeel aardige layout liggen!

edit:

Voor de gein ff een snelle prtscrn van de PCB gemaakt. Te bezichtigen op http://www.xs4all.nl/~kruimpie

[Verwijderd]

Het schema zit nu degelijk in layout. Tis een nette enkelzijdige PCB geworden. Ik had nog een polariteitsfout gemaakt op de FAN headers voor de fans met de kleinere 3 pins connectoren

Ook heb ik voor FAN3 en 4 een 2 pins header toegevoegd, zodat je op die FAN outputs eventueel heel kleine fans kunt plaatsen (mobo en video fan b.v.*moet wel 12V zijn*). FAN1 is primair bedoeld voor de CPU FAN, FAN2 als casefan of aantal casefans (parallel).

Het enige waar ik nog mee zit, zijn de druktoetsen. Er zijn zoveel verschillende met zoveel maten en steken, het is heel moeilijk om een goede keuze te maken. Ik wou de PCB gelijk in het front fixeren via deze (3) drukknoppen, maar dat gaat dus (veelal) niet lukken denk ik. Dus moet de PCB gemonteerd worden via metalen hoekjes o.i.d., en moeten de schakelaars ofwel op cd PCB zitten en door het front heensteken ofwel in het front gemonteerd worden en via een stukje 2 aderig kabel naar de pcb gevoerd worden. Alleen hoe ik dat op de pcb netjes kan maken? Ik zit erover te denken om daar een header te plaatsen met daanaast een groot kopervlak, zodat voor elke schakelaar "op maat" kan worden geboord waar hij gefixeerd moet worden.

Als het meezit kan ik komend weekend misschien al het eerste test PCBtje gaan etsen.

Over de kosten qua onderdelen post ik binnenkort meer.

En dan richting de software speczzz!

[Verwijderd]

Op dinsdag 26 februari 2002 13:43 schreef --EasY-- het volgende:
Het schema zit nu degelijk in layout. Tis een nette enkelzijdige PCB geworden. Ik had nog een polariteitsfout gemaakt op de FAN headers voor de fans met de kleinere 3 pins connectoren

Ook heb ik voor FAN3 en 4 een 2 pins header toegevoegd, zodat je op die FAN outputs eventueel heel kleine fans kunt plaatsen (mobo en video fan b.v.*moet wel 12V zijn*). FAN1 is primair bedoeld voor de CPU FAN, FAN2 als casefan of aantal casefans (parallel).

Misschien over alle fan molex headers (meerdere) 3 pins headers parrallel schakelen of iemand ze daadwerkelijk toevoegt kan hij dan zelf bepalen. Je hebt er n.l. ruimte zat voor.

Het enige waar ik nog mee zit, zijn de druktoetsen. Er zijn zoveel verschillende met zoveel maten en steken, het is heel moeilijk om een goede keuze te maken. Ik wou de PCB gelijk in het front fixeren via deze (3) drukknoppen, maar dat gaat dus (veelal) niet lukken denk ik. Dus moet de PCB gemonteerd worden via metalen hoekjes o.i.d., en moeten de schakelaars ofwel op cd PCB zitten en door het front heensteken ofwel in het front gemonteerd worden en via een stukje 2 aderig kabel naar de pcb gevoerd worden. Alleen hoe ik dat op de pcb netjes kan maken? Ik zit erover te denken om daar een header te plaatsen met daanaast een groot kopervlak, zodat voor elke schakelaar "op maat" kan worden geboord waar hij gefixeerd moet worden.

Zelfde verhaal met de LED's dus. Je hebt trouwens van die mooie haakse (dubbel male) headers. Is ook vrij stevig. Een optie?

Als het meezit kan ik komend weekend misschien al het eerste test PCBtje gaan etsen.

Is het mischien handig om een nieuw topic te openen waarin je de tussen resultaten 'showt'. Mijn ervaring is dat veel niet meer in 't topic terugkomen als het te technisch wordt. Dan ga je veel feedback missen. Denk ik.

Over de kosten qua onderdelen post ik binnenkort meer.

Ben benieuwd.

En dan richting de software speczzz!

Het echte werk

[Verwijderd]

Op dinsdag 26 februari 2002 20:40 schreef Maxim het volgende:

[..]

Misschien over alle fan molex headers (meerdere) 3 pins headers parrallel schakelen of iemand ze daadwerkelijk toevoegt kan hij dan zelf bepalen. Je hebt er n.l. ruimte zat voor.

Hmm... Zoals het nu zit, heb ik 4 molex connectoren voor de fans, plus 2 aparte 3 pinners voor fan1 en 2. Deze zitten apart omdat fans met RPM input vaak een Molex en een 3pinner hebben.

Fan 3 en 4 hebben een extra 2 pin header. Ik zou eventueel "in" de molex connectoren van fan 3 en 4 een 3-pinner kunnen plaatsen, zodat je voor fan 3 en 4 de keuze hebt tussen molex of 3 pinner. Probleem is dan wel dat in CAD mijn shapes op elkaar liggen

Zelfde verhaal met de LED's dus. Je hebt trouwens van die mooie haakse (dubbel male) headers. Is ook vrij stevig. Een optie?

Ik heb er nu een leuke shape in weten te proppen. Het wordt sowieso te slap om via de switches het hele ding vast te maken aan het front. Je kunt er eventueel een 3-header (met missende middenpin) in plaatsen. Of een haakse PCB drukknop (als je ze vinden kan )

Is het mischien handig om een nieuw topic te openen waarin je de tussen resultaten 'showt'. Mijn ervaring is dat veel niet meer in 't topic terugkomen als het te technisch wordt. Dan ga je veel feedback missen. Denk ik.

DAT ga ik maar eens doen... Nu heb ik sowieso de hardware definitief... Misschien een optie om een "software spec" draad te openen! Eerst ga ik daar een opzet voor maken, zodra ik wat resultaten heb open ik een nieuwe draad.

[C@SP]

Ben je ook van plan om die prints te etsen en te gaan verkopen? Dit lijkt mij wel interessant

[Verwijderd]

Volgens mij heb je het hele topic dan niet gelezen, had ik ook al gevraagd, en hij wilde het wel doen, als er genoeg animo was en het uiteraard perfect deed

[Verwijderd]

Aangezien de hardware nu min of meer fixed is, gaan we verder met de software!!! Dit in het draadje [topic=424325/1/50]