permanente magneet dc motor als servo motor?


Het gaat er om dat de ene driver de ene kant van de motor naar de 12v stuurt. Zijn "boost" moet dan 24V zijn. De andere kant van de motor wordt naar 0V gestuurd. De source van de high-side-fet is dan 0V. Normaliter is de "boost" waarde aan die kant dan 11.4V, maar nu haal je die naar 24V.

200mW in de gate stoppen (24V * 24V/1k) als ie doorslaat kan ook wel fataal zijn. Kortom, die 1k is prutswerk dat ook niet gaat helpen om de boel heel te houden. Gewoon de boel goed aansturen binnen de beperkingen die er zijn. Gewoon de highside PWMen met max 95%. Daarna kijken of het bij 99 en 99.6% nog werkt. volgens mijn tests bij mij wel (99.6% = 255/256).

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Beste Lambiek
ik had geen 4011 liggen waardoor ik het schema een klein beetje heb aangepast. Ondertussen heb ik r eentje gevonden , vanavond probeer ik het opnieuw, deze keer 100 % zoals het schema.

mvg

Eddy

ps waarom gebruik je het invers sd poort ( pen 2) op de ir2184 niet? Zou dit er niet voor kunnen zorgen dat de 4011 overbodig wordt?

Lambiek

Special Member

Pin_2 is SD, logic input for shutdown. Dat is volgens mij heel iets anders. :)

http://www.irf.com/product-info/datasheets/data/ir2184.pdf

[Bericht gewijzigd door Lambiek op 3 juli 2013 10:40:06 (28%)]

Als je haar maar goed zit, GROETEN LAMBIEK.

@lambiek
ik heb uw raad opgevolgd en alles werkt nu perfect: FETS zonder koelplaat die koud blijven, super snel van richting veranderen van de motor, wel spectaculair wat je met je driver uit een motortje krijgt.

mvg
Eddy

Lambiek

Special Member

Dat is leuk om te horen. Maak daar eens een filmpje van, of een paar foto's. Daar ben ik wel benieuwd naar. En waar heb je nu je encoder geplaast, op je motor of op de uitgaande as.

Als je haar maar goed zit, GROETEN LAMBIEK.

Beste
de encoder zit op de as van de motor, de encoder geeft 20 pulsen per omwenteling ( veelvoud van 10 , zie startpost).

Momenteel ben ik aan het nadenken over de PID. Eigenlijk is deze pid niet ideaal, daar de instelling afhankelijk is van de last op de motoren. Daar deze last variabel kan zijn ...

Ik had een PID frequentie van 1 khz voor ogen(1000 keer per seconde de pwm uitrekenen en aanpassen). Deze 1 khz moet doenbaar zijn, deze wordt ook gebruikt door de UHU PID regelaar.

Zou het niet sneller ontwikkelen door de positie info door te sturen naar een pc, daar het PID algoritme uit te voeren en dan het resultaat terug door te sturen naar de PIC?

Voordeel hiervan is dat ik een thuis match speel (ik heb heel veel vb.net werk ervaring) en dat mijn pc (64 bit op 2.4 ghz ) toch wel sneller is dan een PICje. Verder kan ik onbeperkt loggen.

Nadeel is dat ik afhankelijk ben van de 115200 bits per sec), en dat mijn pc niet real time is (een virus scanner …)

Hoe dan ook zou ik deze manier van werken enkel gebruiken voor de ontwikkeling, later moet alles terug op de PIC.

Bestaan er eigenlijk PIC met een seriële buffer die groter is dan 2 bytes? Of zou USB een oplossing kunnen zijn? Ik werk momenteel met PIC 18f4550, en die heeft een USB 2.0 aan boord. Zou USB wel snel genoeg zijn voor kleine hoeveelheden data ?

mvg

Eddy

PS De fotos volgen: mijn vrouw voor een paar dagen naar zee (met de kindjes en het fototoestel)

GJ_

Moderator

Dat geeft dan dus 8 delen per "motorstap". Waarom eigenlijk zo'n lage resolutie?

Beste GJ_
de sensor heeft 5 gleufjes, en de 2 fototransistor geven dus 20 flanken per omwenteling, dus maar 2 stappen per motor stap.

Waarom zo weinig : door de "pole clamping", zie vorige eerdere posts krijg ik het toch niet nauwkeuriger geregeld.

Waarom geen sensor op de uitgang : de mechanische reductie is heel moeilijk speling vrij te krijgen en een sensor met bvb 200 stappen per omwenteling kan ik zelf niet frezen dus...

Eddy

GJ_

Moderator

Ow, op die fiets. Dat noem je normaal een encoder met vijf pulsen per omwenteling.

Op 5 juli 2013 10:12:15 schreef eddy2:en een sensor met bvb 200 stappen per omwenteling kan ik zelf niet frezen

Zelf gemaakte encoder? Dat vind ik leuk. Foto?

EEn probleem met USB is dat er 1000 keer per seconde een "moment" is waarop een transactie kan beginnen. Dus ook over USB2 (480mbps) haal je met een harddisk die je aanstuurt met: "doe blockje X", "dankje, dan wil ik nu blockje X+1" haal je maar 1000 blockjes per seconde (ongeacht hoe groot een blockje is). Normaliter haal je veel meer doordat er met requests van minstens 64k gewerkt wordt.

Dus... Met PC en USB zou ik zeggen: ga je 1000 Hz niet halen. (alle twee de items zijn m.i. showstoppers).

Ik zou de basis van de PID in de PIC stoppen, en dan de parameters vanuit de PC laten bijstellen.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

@rew : slecht nieuws, ik heb namelijk geen echte seriële poort op mijn pc.

Ik los dit op door een serieel-usb convertor te gebruiken.

Gevolg daarvan is wel dat uw opmerking ook geldt voor mijn "seriële bus".....
Eddy

Maar het is ook helemaal niet logisch of handig om die control loop op de pc te draaien, dat kan die PIC toch prima zelf. Als je data wilt loggen, is de reactiesnelheid niet van belang, alleen de bandbreedte.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

@SparkyGSX
Ik zou dit enkel doen om het algoritme op punt te stellen.
Als het algoritme op punt staat zou ik alles proberen over te zetten op PIC.

Na heel veel over PID gelezen te hebben, vrees ik er voor dat gewone PID niet zal voldoen. Onder andere de ontwerper van de UHU controller heeft het er over dat de H parameter (verandering van snelheid = versnelling) in zijn laatste versie belangrijk is geworden. Dit is dus geen standaard PID meer. Verder zou ik er een oscillatie detectie willen inbouwen die parameters aan past wanneer motor begint te oscilleren. Daar dit dan zo complex wordt lijkt me beter dit allemaal in .NET te ontwerpen en dan over te zetten.

Voordelen hiervan lijken me
- betere log mogelijkheden van alle paramaters in programma ( ik kan deze onmogelijk allemaal van mijn PIC doorsturen)
- ik ben stukken beter in .net dan in proton
- grafiekjes om schommelingen in data zij heel eenvoudig
- debuggen is stukken makkelijker in .net dan in Proton
- overzetten van een programma is voor mij makkelijker dan een nieuw programma maken op basis van een analyse.

Ik heb ondertussen eens uitgerekend hoeveel data ik van en naar de pc moet sturen en dit valt echt mee.Op geen problemen te hebben met USB heb ik een PCI serieel poortje besteld.
mvg
Eddy

Heb je wel eens een PID regelaar gemaakt dan? Ik krijg niet echt de indruk dat je ervaring hebt met meet en regel techniek. Zelfs met een PCI seriële poort heb je het probleem dat je OS niet real-time is, en als ik het goed heb, is de timeslice van windows in usermode nog steeds 10ms,, wat betekend dat je reactietijd standaard zal variëren van 10 tot 20ms, en dat is als er nog niets raars is gebeurd in je OS. Met zo'n vertraging en jitter kun je de gain niet te hoog maken zonder in de problemen ter komen met de fase marge. E.e.a. is natuurlijk wel aanhankelijk van de tijdconstantes van je systeem.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Beste SparkyGSX
wat je zegt over PID op PC is hoogst waarschijnlijk correct, echter, ik ga het toch eens proberen met een mini programmatje op de PIC en PC. Verslag over de mislukking volgt ;-))))

Daar de seriële kaart nog niet binnen is ben ik bezig met iets te bedenken om de snelheid te meten van de motor.

Mijn idee was om bij de lagere toeren het aantal sensor uitlees interrupts( 16khz) te lezen gedurende 4 sensor flanken. Bij de hogere toeren zou ik het aantal interrupts tellen gedurende veelvouden van 4 sensor flanken.

Wanneer ik dit eens uitzet in een Excel blijkt dat het heel moeilijk is om de fout onder de 1 % te houden bij een meet frequentie van 1 kHz(geplande PID frequentie). De fouten die ik maak zijn timingsfouten ( interrupt zijn niet gesynkroniseerd met de sensor flanken) en afrondingsfouten.

Zijn er eigenlijk andere betere manieren om nauwkeurig en snel snelheid te meten?

eddy
ps de snelheidsmeting zou hoe dan ook op de PIC gebeuren.

Ja, de input capture periferal gebruiken.

1kHz kun je echt wel vergeten over USB met een applicatie in user-land.

Waarom wil je met alle geweld de control loop op de pc hebben? Als je snapt hoe zoiets werkt, is het bijna triviaal om het op de microcontroller te implementeren, en zolang je het niet snapt, gaat het sowieso niet lukken ongeacht het platform. Data loggen en visualiseren kan natuurlijk prima op de pc, dat hoeft niet real-time.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Lambiek

Special Member

Ik zou het ook via de pic doen, je krijgt het echt niet goed werkend via de pc. Ik ben het met SparkyGSX eens, via de usb kan je vergeten dat gaat niet lukken. Alleen al de snelheid van de usb, en de interrupts op je pc. Alleen als je een data stroom van je pc naar je pic wil doen, dat gaat goed via de usb als je de data opslaat in je eeprom van de pic, op die manier kan je de interrupts opvangen. Maar dat gaat bij jou niet op, om dat je data verkeer van twee richtingen komt, van de pc naar de pic, en van de pic naar je pc.

Als je haar maar goed zit, GROETEN LAMBIEK.

Beste
ik ben momenteel aan het experimenteren efficiënt serieel data over te zetten.

Probleem is dat ik een "record" met snelheid info en plaats info moet over zetten van pic naar pc.
De snelheid data is 2 bytes groot en positie verandering een byte groot.

Ik had gedacht aan het volgende

"S" doorsturen als start
byte 1 most significant byte van de snelheid
byte 2 least significant byte van de snelheid
byte 3 delta positie
byte 4 teller om gemiste data te detecteren

De "S" gebruik ik om aan de pc kant een nieuwe record te detecteren.

Probleem is dat iedere byte een "S" kan zijn, en ik dus niet zeker ben van de start positie van een record.
Is dit op te lossen zonder alles als string door te sturen (en zo veel meer communicatie te hebben?)

Eddy

Ja, daar zijn al 1001 oplossingen voor uitgevonden. Je zou er voor kunnen kiezen om per byte maar 7 bits te gebruiken voor de data, en het 8ste bit te reserveren voor het startbit. Een andere optie is bytestuffing; als de "magische" waarde in de data voorkomt, stuur je 2 bytes met die waarde. Als een reeks van een oneven aantal keer die magische waarde krijgt, was dat een start karakter en een aantal databytes met die waarde.

Ik vind het vreemd dat je zowel de snelheid als de afgelegde afstand verstuurt, aangezien dat dezelfde informatie is, aangenomen dat er een constante interval is tussen de datagrammen.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Beste
de snelheid en positie zijn nodig voor mijn pid op pc experiment. (seriel poort is wel nog niet binnen)

Wanneer enkel de snelheid doorstuur zorgt de afronding van de snelheid voor problemen bij het bepalen van de positie, wanneer ik enkel de positie doorstuur kan ik niet snel genoeg nauwkeurig de snelheid bepalen.

eddy
ps Uw 2 de optie lijkt me het beste, als de magische byte "s" voorbij komt, stuur ik het 2 keer door, en tel aan de pc kant of de S oneven keer door komt.

Als je nu gewoon als startcode "0xff" gebruikt, en zorgt dat je data niet 0xff bevat. Voor de twee-byte waarde moet je 0xffxy gewoon niet voor laten komen (veel te hoge snelheid)_ en 0xxyff moet je afronden naar 0xxyfe.

Of je zegt: 0xff is de startcode, 0xfe de escape code. 0xfe fe is een echte 0xfe,
terwijl 0xfe 0xf0 een data-ff is. Zo ben je af van het "tellen" en wordt de boel dus betrouwbaarder. Een 0xff is ALTIJD een start-code.

Je kan natuurlijk ook "S" als startcode blijven gebruiken.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

@rew
Beste
ik had ook de optie om de positie absoluut door te sturen in gedachte, en dit via een 32 bit integer. Daar wordt uw oplossing wel moelijker, aanpassen van absolute positie data in de hogere bytes kan de regelaar serieus van stuk brengen.

Eddy

ps Volgens de spec's van mijn seriële kaart( nr 972208 van Conrad) kan deze 1 mbytes/sec per seconde aan. is dit realistisch? Ik kan het niet testen daar de kaart nog niet binnen is.

ps Op het kaartje zit tevens een parallel poort die 1.5 mbytes/sec zou aankunnen. Ik heb deze gekozen omdat ik nog een oude plotter heb die ik opnieuw wil gebruiken. Zou ik deze ook nog kunnen gebruiken voor PIC communicatie???

Met 1 milibyte per seconde per seconde duurt het bijna 20 minuten voordat je op een snelheid van 1 byte per seconde zit.

Als je warrige statments maakt EN de eenheden verkeerd doet snap ik het niet meer.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Beste
ik bedoelde megabytes per seconde, is "mbytes" milibytes???
Megabytes per seconde is dan waarschijnlijk Mbytes/sec ( met hoofdletter?)

mvg
eddy

Ondertussen is de juiste seriële poort binnengekomen, en heb ik test programmatjes voor PIC en PC geschreven om de discussie over de PID op PC af te ronden.

De pc stuurt 1 byte naar de PIC en wacht op zijn beurt tot de PIC er 4 terug gestuurd heeft, waarop de pc op nieuw een byte doorgestuurd ect... Voorlopig wordt enkel fake data doorgestuurd.

Deze loop herhaalt zich 1001 keer, en dat in 981.477 milliseconden.
Deze tijd is gemeten op de pc, met de stopwatch functionaliteit die heel nauwkeurig is, ook voor heel kleine tijdspannen)

De 1 kHz communicatie is dus ( nipt) haalbaar, en als ik de PID berekening in aan andere PC thread laat lopen , zou dit ook moeten lukken.

De truc was om aan de pc kant niet het standaard "data recieve event" van de seriële poort te gebruiken maar continu in een loop te kijken of er iets binnen kwam. Dit is een beetje resource verspilling, maar wel heel snel. Mijn pc heeft 8 kernen, beetje verspilling legt de boel niet stil.

Aan de PIC kant was het belangrijk de PIC (18f4550) op 48 Mhz te laten draaien (20 Mhz kristal via enkele fuses)

De PC is een HP Z220 workstation van 1 jaar oud, pc software is vb.net 2012, PIC de software is Proton vb.

Wat niet lukt is de seriële kaart sneller dan 115200 te laten lopen.

Eddy

ps Dit lukt natuurlijk niet voor een "productie" systeem, ik zou enkel het prototype maken op de pc en dan overzetten op PIC