[picbasic] Pulsin RPM

Op 17 januari 2010 16:18:39 schreef Kevinoud:
Toerental: 1500 6000 (pulsen die binnenkomen op de sensor) per minuut 50Hz
Pulsin waarde 15850 units (simulatie) 1 unit = 1,25 0,125 uS (32Mhz kristal)

Toerental is rpm >>> 1500/60 X 2 (2 nokken op de as) is 50Hz hoor dus heb je 50 pulsen per sec.
Tenminste ik denk dat Kevin dat bedoelt

Edit: 4 MHz >> 1 unit = 10uS
5x zo snel met een 20MHz geeft dan:
20MHz>> 1 unit = 2uS
En bij een 32MHz geeft 1 unit dan toch:
32MHz>> 1 unit = 1,25 uS ?? klopt toch??

EDIT2:

Bij 1500 RPM > 15850 units >>>> 19812,5 uS

VB Bij 3000RPM > 7925 units >>>>>> 9906,25 uS VB

Bij 6000 RPM > 3965 units >>>> 4956,24 uS

(VB= aangenomen dat bij 3000RPM je de helft van de 1500rpm units hebt)

Natuurlijk zit hier een afrondingsfout in, maar ik zie dat dit wel klopt..

Sja, duidelijkheid... in zijn zinscontructie slaat die "(pulsen die binnenkomen op de sensor)" op de 1500. Hij bedoelt het idd waarschijnlijk niet zo.

Euh, bij gebruik van een 32MHz kristal heb je 8MHz na interne deling bij de PIC zeker? 1/8000000 = 0,125 µs.

Nee, volgens de help van proton:

The units are dependant on the frequency of the crystal used. If a 4MHz crystal is used, then each unit is 10us, while a 20MHz crystal produces a unit length of 2us.

En zie mijn edit uit vorige post

Bah proton! Je bent meer bezig met de onlogische spinsels in die taal te leren dan dat je effectief de controller begrijpt. Goed om de wereld van µc's te leren kennen maar niet om in blijven verder te modderen.

Maar mijn probleem is dus dat de verhouding exact tegenovergesteld wordt

Bij 1500 RPM > 15850 units
Bij 6000 RPM > 3965 units

dus hoe kan ik die units omrekenen naar RPM
Anders moet ik een tabel oid gaan maken maar voor elke 25 rpm ofzo is dat nog een leuk lijstje en nogal wat geheugen

Ja, daar was ik mee bezig, om een formule voor je te maken, maar moet nu eten

Maar je moet denk ik iets van 1/ units gebruiken in je formule....
Dus ik ga nu eten,
Vanavond, als er niemand anders al langs geweest is ga ik wel verder....

T/2 = aantal_units x 1,25 x 10^-6
=> T = aantal_units x 2,5 x 10^-6
=> f = 1/T = 1/(aantal_units x 2,5 x 10^-6)
=> rpm = f x 60 = 1/(aantal_units x 2,5 x 10^-6) x 60
=> rpm = 60/2,5 x 10^6

=> rpm = 24000000/aantal_units

[Bericht gewijzigd door plantrekker op zondag 17 januari 2010 18:20:26 (87%)]

hmm bedankt maar dat haalt niets uit

als ik dat invoer bij 50Hz als input op mijn pic (1500Rpm 2 Nokken)
dan komt er op mijn display 0

MotorRPM:               ' Motor rounds per minute on the ax
RPMraw = PulsIn Input0, 1
    RPM = 24000000 / RPMraw
    Print At 6,0, Dec5 RPM
Return

[Bericht gewijzigd door Kevinoud op zondag 17 januari 2010 18:32:48 (24%)]

RPM zal een int zijn (16bit)

Probeer dit om te testen (de nauwkeurigheid is dan maar tot op 1000 rpm) en declareer nadien naar een type met grotere range.

MotorRPM:               ' Motor rounds per minute on the ax
RPMraw = PulsIn Input0, 1
    RPM = 24000 / RPMraw
    RPM = RPM * 1000
    Print At 6,0, Dec5 RPM
Return

heb RPM veranderd naar een float want kreeg bij 200Hz netjes 6000 maar bij 50Hz nog maar 1000

Bij 200 Hz (6000RPM) krijg ik nu 6051.437 op het scherm
Bij 50 Hz (1500RPM) krijg ik nu 1514.578 Rpm

Fredjuhhh en Plantrekker met zijn uiteindelijke oplossing
TNX het lijkt zo helemaal te werken

[Bericht gewijzigd door Kevinoud op zondag 17 januari 2010 18:42:34 (12%)]

Als je nu i.p.v. RPM = 24000 / RPMraw
Dit neerzet RPM = 24000000 / RPMraw
Dan kun je de andere regel gewoon weglaten:RPM = RPM * 1000
En maak van er een DWORD van, dat gebruikt niet zo veel geheugen
(Variable type that may hold a value of -2147483648 to +2147483647)

Even ter verduidelijking: wat plantrekker doet is goed: wat jij doet is ergens niet goed, maar dat kan komen door je nokken op de as.
Reken voor de grap eens uit:

RPM = X / units
Dan kom je voor 1500rpm bij jouw uit op 23775000 = X
en voor 6000rpm uit op 23790000 = X
En volgens de berekening moet je 24000000 hebben.
maar zie je dat je bij jou al een verschil hebt? Dat zou kunnen vanwege de zelf gemaakte nokken ...
Ook zal je kristal nooit op presies 32MHz werken, daar heb je ook een zeer kleine afwijking...
Persoonlijk zou ik de units van puls high en low bij elkaar optellen en het geheel nog eens narekenen....

EDIT

heb RPM veranderd naar een float want kreeg bij 200Hz netjes 6000 maar bij 50Hz nog maar 1000

Dat klopt dus :

RPM = 24000 / RPMraw
RPM = RPM * 1000

Hier komt die fout door: je krijgt dan voor RPM als uitkomst 1,5 maar dat wordt dus afgerond naar 1 en dan vermenigvuldigd met 1000, dan krijg je 1000.
Maar als je het doet zoals ik beschreef, dan heb je daar geen last van, en bespaar je nog geheugenruimte, en werk je nauwkeuriger.

et leukste is zoals ik net al zij dat ik dit simuleer in protheus

Op 17 januari 2010 19:01:16 schreef Fredjuhh:
Als je nu i.p.v. RPM = 24000 / RPMraw
Dit neerzet RPM = 24000000 / RPMraw

Dat was dan ook het eerste wat ik zei, die x1000 nadien was voor snel een test te doen en had toen al gezegd dat de nauwkeurigheid dan maar op 1000 rpm zou zijn.

Wat die afwijking betreft, gebruik 1 staafje ipv 2. Nu zullen de staafjes niet perfect 180° verschoven zijn ten opzichte van elkaar. Gebruik je er 1, dan heb je dat probleem niet. OK, je simuleert nu, maar dat zal wel het geval zijn als je het echt uitvoert.

dan maken we er 1 staafje van dat is op zich het probleem niet dit leek me nauwkeuriger maar dat is eigelijk niet echt et geval

MotorRPM:               ' Motor rounds per minute on the ax
RPMraw = PulsIn Input0, 1
    RPM = 48000000 / RPMraw
    Print At 6,0, Dec5 RPM
Return

[Bericht gewijzigd door Kevinoud op zondag 17 januari 2010 19:39:22 (40%)]

Okay, dat is dan duidelijk: Ik had even te snel, (zeg maar: bijna niet) gelezen, maar het gaat wel werken

Ik ben blij dat ik heb kunnen helpen, want de volgende keer mag je mij helpen
Want volgens mij weet jij al hoe je meerdere uitgangen en ingangen kan maken op een pic (shuifregisters?!?!) (Ik weet het niet zeker )

EDIT: je meet nu de tijd dat de nok hoog is, dus het maakt eigenlijk niet uit hoeveel nokken je er op zet, en het maakt ook niet eens uit waar ze staan
Maar belangrijk is wel dat de nokken allemaal presies even hoog staan (dus de leesstand van elke nok moet gelijk zijn ) en dat is dus wat lastig is denk ik...

EDIT2Ik weet niet waar het voor nodig is: alleen aflezen op display? Maar als ik het zou moeten doen zou ik er één nok op zetten, en dan pulsin high en pulsin low bij elkaar optellen, dan meet je de totaal tijd van één omwenteling, en dat lijkt mij hier nauwkeurig en snel genoeg..

[Bericht gewijzigd door Fredjuhh op zondag 17 januari 2010 19:52:55 (18%)]

Het is voor de vissersboot van de baas van een bedrijf hier in spanje hij zag foto's van ons vlot (in nederland) die wij met vrienden hebben gemaakt en deze start zelfs met een pic (de complete besturing is weg voor de ontsteking etc.

Toen zei hij mooi dan kunnen jullie als stage project wel wat leuks voor mijn boot maken.
Hij wou dus het oude analoge paneel in zijn boot vervangen door een display.
De kosten lopen nu al in de 500 euro en daar zit hij niet mee ik leer dr veel van en hij heeft een mooi vrijwel uniek product voor in zijn boot.
Er zitten ook 2 180Ah accu's in die ik onafhankelijk moet laden en ontladen dit gaat de pic ook doen (het schakelen van de relais).

Ik begin idd al pittig wat van pic basic te leren als ik je kan helpen uiteraard

Ik heb eens gekeken naar die PULSIN. Dit is egenlijk niet wat je nodig hebt en heb geen betere functie gevonden in picbasic. De functie is niet goed omdat die een timer start een stopt op verschillende flanken. Je hebt eigenlijk een functie nodig die een timer start bij bvb opgaande flank en de timer stopt bij weer een opgaande flank. Je kan dit zonder probleem zelf schrijven. Gebruik je toch PULSIN, dan zal je zoals Fredjuhh al zei, de hoge en lage puls moeten optellen en je zal een correctie moeten toevoegen want het aanroepen van de functie om de pulslengte van het andere niveau te meten, neemt ook tijd. Kortom, PULSIN is niet de rechte weg naar je doel.

klopt maar de afwijking is zo minimaal dat het niet echt intressant is om dit aan te passen.
Als bijvoorbeeld 1 % van de as voorbij de sensor gaat heb ik een afwijking van iets van 40 Rpm volgens de simulatie.
Dit is voor mij niet intressant aangezien de as tussen de 800 - 5000 toeren maakt en dan kan die 40 a 50 rpm mij niet zoveel intresseren

Nog even een fotootje voor de liefhebbers.

http://www.uploadarchief.net/files/download/simulatie%20toerenteller.j…