Een technisch projectje ter vervanging van de (iets te complexe) GIP, dat zal lopen naast een baantje dat ik wil bouwen. Ik wil het midden zoeken tussen de PLC en de microcontroller, alles uitgeschreven op pdfje:
www.treinbaanrian.be/downloads/Micro-PLC.pdf
Ik zet het hier, en niet in de µC-hoek op het forum (waar misschien enkel "specialisten" gaan kijken), wie weet trek ik met het project geïnteresseerden over de streep om ook eens met de µC te werken.
Enkele ideeën die ik heb waarvoor het zou kunnen dienen: aansturing straatverlichting op de baan, automatisatie van schaduwstations, overweginstallatie...
Wat denk je? Zie je nog functies mankeren? Zou je ook zo'n printje overnemen van me als ik ze laat maken? Het zit nog maar in de ontwerpfase, alles kan nog gebeuren.
Rian je gaat snel gister breek je je vorige project af en vandaag sta je alweer met een nieuw project op het forum.
Ziet er interessant uit, ik zou daar zeker belangstelling voor hebben maar als ik je pdf bestand bekijk, dan gaat dit al snel boven mijn pet. Ik heb hiervan totaal geen kaas gegeten, zal je draadje wel blijven volgen maar zal helaas weinig kunnen bijdragen. Maar voldoende mannen hier op het forum die dat wel kunnen. Succes.
Ik zie persoonlijk meer heil in specifieke, kleinere projecten dan in een groot "universeel" I/O-board.
Zo'n grote printplaat ga je immers nooit volledig gebruiken.
Zonde van de hardware en het soldeerwerk,
en je hangt er een hoop toeters en bellen aan die een "beginner" afschrikken
Citaat van: Gerolf op 04 augustus 2014, 09:22:22 AM
Ik zie persoonlijk meer heil in specifieke, kleinere projecten dan in een groot "universeel" I/O-board.
Citaat van: Gerolf op 04 augustus 2014, 09:22:22 AM
Zo'n grote printplaat ga je immers nooit volledig gebruiken.
Als ik het ding veel gebruik kan er altijd een "mini" uitvoering komen met een kleinere PIC met minder I/O.Citaat van: Gerolf op 04 augustus 2014, 09:22:22 AM
Zonde van de hardware en het soldeerwerk,
en je hangt er een hoop toeters en bellen aan die een "beginner" afschrikken
Het is mijn bedoeling om telkens dezelfde print te gebruiken, maar telkens specifiek te bestukken met enkel dat wat je nodig hebt
En... al 6 kanalen toegevoegd voor stroomdetectie
Zal dat eens lezen als ik iets anders dan een tablet ter beschikking heb. Allesinds, je project uitschrijven is een goede stap. Beste zou zijn om nu even aan die baan te werken en dit binnen een week of twee nog eens te lezen en te herkauwen. Je vindt dan altijd dubbel werk, logisch fouten of een betere aanpak.
Moet zeggen dat ik je idee van plc wel zie zitten.
Beste Rian,
`
Als je de gemiddelde modelspoorder, grotere groep dus, wilt bereiken, dan is het vergeefse moeite, als je de elektronici onder de modelspoorders wilt bereiken, dan prima.
Ik ben iemand die geen liefhebber is van de computer/programma/digitale centrale, maar ook niet van de kant die jij op wilt, dus werk ik met een microprocessor die voorzien is van de nodige hardware/software om zowel digitale centrale als wel automatiseerder te zijn.
Groet, Anne W
Rian, dit nieuw project van je heb ik 20 jaar geleden ook al eens toegepast. Wel geen PIC µC maar eentje met een Thomson µC (toen 800Bfr stuk !!!). Een zelf geprogrammeerde micro PLC met een eenvoudige instructielijst. Diverse in en uitgangen al of niet digitaal/analoog. En dit op een euro-formaat printje (inclusief 220V voeding erop). Een ULN 2803 kende ik toen nog niet, dit was met transistors en relais. Nu nog draait deze micro PLC voor het aansturen van mijn sproeisysteem (tuin). Dit was mijn eerste groot µC project. En de ervaring die toen heb opgedaan gebruik ik nu nog altijd ...
Ik volg je in dit project, ik zal je helpen indien nodig, maar ik heb ondertussen al begrepen dat je een µC projectjes toegankelijker moet maken voor niet µC techneuten.
Geert
Ik denk niet dat ik er relais op zal zetten... Neemt veel plaats in, en mogelijkheden genoeg: relais op Din rail voet of Velleman Relaiskaartjes kunnen dienen als alternatief. De ULN 2803 kan die dan wel inschakelen
Hi Rian,
Ik vrees dat je weerom wat veel hooi op je vork gaat nemen. Zoals Gerolf al zei, er komt heel wat bij kijken. Ik zou inderdaad ook met kleinere projectjes werken omdat ze veel sneller te realizeren zijn en ook makkelijker om te programmeren. Later kan je nog altijd die kleinere projectjes samenvoegen tot één groot.
Als ik lees wat je allemaal wil bekomen, denk ik dat je de power van de PIC16F887 een beetje te ruim inschat. Probeer eerst de 'losse' modules te voorzien: stroom/massa-detectie, motor sturingen, simpele mosfet uitgangen, ... En één moduletje kan je meteen aan beginnen: een protocol analyzer voor DCC, Mfx, s88 en anderen die je op de modelbaan tegenkomt. Daar doe je al heel wat kennis mee op...
Citaat van: Sattrickske op 04 augustus 2014, 12:39:22 PM
Hi Rian,
Ik vrees dat je weerom wat veel hooi op je vork gaat nemen. Zoals Gerolf al zei, er komt heel wat bij kijken. Ik zou inderdaad ook met kleinere projectjes werken omdat ze veel sneller te realizeren zijn en ook makkelijker om te programmeren. Later kan je nog altijd die kleinere projectjes samenvoegen tot één groot.
Als ik lees wat je allemaal wil bekomen, denk ik dat je de power van de PIC16F887 een beetje te ruim inschat. Probeer eerst de 'losse' modules te voorzien: stroom/massa-detectie, motor sturingen, simpele mosfet uitgangen, ... En één moduletje kan je meteen aan beginnen: een protocol analyzer voor DCC, Mfx, s88 en anderen die je op de modelbaan tegenkomt. Daar doe je al heel wat kennis mee op...
Eens een wissel of stopsectie inschakelen, de straatverlichting op de baan aan/uitzetten enzo moet toch lukken, als ik zie wat ik de 2 16f887 in de GIP heb laten doen. Moest het toch iets te ingewikkeld zijn, maar dat denk ik niet, met de baan kan ik altijd voortdoen, onafhankelijk van de voortgang van dit. Alle verschillende mogelijkheden zijn voorzien op de print, maar ben niet verplicht die te gebruiken!
Nee je bent inderdaad niet verplicht alle mogelijkheden ineens te gebruiken, maar probeer om er één werkende te krijgen, en maak dan weer een nieuwe. En uiteindelijk voeg je alles samen tot het mega-idee dat je hebt. Maar de eerste stap zal zowiezo het communicatie protocol worden; zonder dat protocol staat je schakeling er helemaal alleen voor.
Citaat van: Sattrickske op 04 augustus 2014, 19:48:01 PM
het communicatie protocol worden
Ideaal zou zijn moesten deze modules allen data kunnen uitwisselen met elkaar, maar ik denk dat dat een project opzich is om dat aan te leren. Tussen twee µC onderling kan ik (dankzij Peter) al werken met de seriële poort van de µC.
Citaat van: Sattrickske op 04 augustus 2014, 19:48:01 PM
Nee je bent inderdaad niet verplicht alle mogelijkheden ineens te gebruiken, maar probeer om er één werkende te krijgen, en maak dan weer een nieuwe. En uiteindelijk voeg je alles samen tot het mega-idee dat je hebt. Maar de eerste stap zal zowiezo het communicatie protocol worden; zonder dat protocol staat je schakeling er helemaal alleen voor.
Denk dat dit het punt is waar ik een ander idee heb dan de rest van het forum. Protocollen en de synchronisatie zzijn moeilijk, processingpower is goedkoop. Voor mij is een pc met een bundel domme io een veel eenvoudigere weg. Je moet je niet druk maken over de efficiencie van je code en of die wel in dat processortje past. Tools genoeg ook.
Citaat van: conducteur op 05 augustus 2014, 00:06:21 AM
Citaat van: Sattrickske op 04 augustus 2014, 19:48:01 PM
het communicatie protocol worden
Ideaal zou zijn moesten deze modules allen data kunnen uitwisselen met elkaar, maar ik denk dat dat een project opzich is om dat aan te leren. Tussen twee µC onderling kan ik (dankzij Peter) al werken met de seriële poort van de µC.
Daar heb je me verkeerd begrepen. Met het communicatie protocol bedoelde ik de communicatie met de rest van je baan, zijnde een centrale (Marklin CSII, ESU Ecos, PC, ...). Tenzij je natuurlijk alles zelf gaat ontwikkelen, maar dan neem je weer enorm veel hooi op je vork.
Mijn voorbeeld: ik heb een CSII en een PC. Voorlopig gaat alle communicatie over de CSII naar de PC. Bijna al mijn modules (servo controller voor de wissel, wagon licht decoders, MOSFet sturingen, ...) praten met de CSII via het DCC protocol. De terugmelders (s88) gebruiken een serieel protocol dat eigen is aan s88.
Op langere termijn wil ik de CSII eruit en m'n eigen centrale bouwen. Maar daar begin ik nu nog niet aan, wegens geen tijd en enorm complex.
Citaat van: Havoc op 05 augustus 2014, 09:54:01 AM
Citaat van: Sattrickske op 04 augustus 2014, 19:48:01 PM
Nee je bent inderdaad niet verplicht alle mogelijkheden ineens te gebruiken, maar probeer om er één werkende te krijgen, en maak dan weer een nieuwe. En uiteindelijk voeg je alles samen tot het mega-idee dat je hebt. Maar de eerste stap zal zowiezo het communicatie protocol worden; zonder dat protocol staat je schakeling er helemaal alleen voor.
Denk dat dit het punt is waar ik een ander idee heb dan de rest van het forum. Protocollen en de synchronisatie zzijn moeilijk, processingpower is goedkoop. Voor mij is een pc met een bundel domme io een veel eenvoudigere weg. Je moet je niet druk maken over de efficiencie van je code en of die wel in dat processortje past. Tools genoeg ook.
Zo anders is dat niet hoor ;)
De PC is inderdaad een (zwaar) alternatief voor de microcontroller, alleen een stukje groter ;D Door het toevoegen van een bundel I/O benader je de µC, maar het blijft wel benaderen want je mist toch nog een boel dingen (PWM, timers, HW interrupts, ...) die de meeste µC ingebakken hebben. Maar je hebt wel veel minder beperkingen qua geheugen (RAM/ROM), dus de ontbrekende hardware kan je eenvoudig emuleren via de software.
Of dat nu de beste oplossing is of niet, dat moet ieder voor zich uitmaken... Persoonlijk vind ik van niet, de PC laat je toe om 'dirty' te werken (omwille van de gigantische resources); de µC is veel minder vergevingsgezind, dus dit verplicht je om properder te programmmeren. Maar nogmaals dat is mijn gedacht hierover; ieder doet wat 'm het beste acht en waar ie het beste mee overweg kan. Als dat voor je de PC is en je bent tevreden van het resultaat, dan moet je echt niet verder gaan zoeken...
Citaat van: Sattrickske op 05 augustus 2014, 11:36:27 AM
Citaat van: conducteur op 05 augustus 2014, 00:06:21 AM
Citaat van: Sattrickske op 04 augustus 2014, 19:48:01 PM
het communicatie protocol worden
Ideaal zou zijn moesten deze modules allen data kunnen uitwisselen met elkaar, maar ik denk dat dat een project opzich is om dat aan te leren. Tussen twee µC onderling kan ik (dankzij Peter) al werken met de seriële poort van de µC.
Daar heb je me verkeerd begrepen. Met het communicatie protocol bedoelde ik de communicatie met de rest van je baan, zijnde een centrale (Marklin CSII, ESU Ecos, PC, ...). Tenzij je natuurlijk alles zelf gaat ontwikkelen, maar dan neem je weer enorm veel hooi op je vork.
Mijn voorbeeld: ik heb een CSII en een PC. Voorlopig gaat alle communicatie over de CSII naar de PC. Bijna al mijn modules (servo controller voor de wissel, wagon licht decoders, MOSFet sturingen, ...) praten met de CSII via het DCC protocol. De terugmelders (s88) gebruiken een serieel protocol dat eigen is aan s88.
Op langere termijn wil ik de CSII eruit en m'n eigen centrale bouwen. Maar daar begin ik nu nog niet aan, wegens geen tijd en enorm complex.
hmm.. Zeker dingen die ik wil aanleren (DCC, S88 met µC, ...) maar voorlopig zijn de projecten die ik er mee van plan ben als ik de printjes (laat) maken wel een stuk eenvoudiger denk ik...
Ik heb al een paar printen laten maken bij iTead studio (Chinezen). Dubbelzijdige prints, doorgemetaliseerd, kosten 20 USD voor 10 stuks + verzendkosten (8 USD dacht ik). Voor die prijs kan ik ze meestal zelf niet maken... 't zijn wel 10 dezelfde prints natuurlijk.
Als ik aan een project begin, gebruik ik een development board of discovery kit van de betreffende microcontroller. Deze verbind ik dan met een gewoon breadboard waar ik de rest van de schakeling op zet. Eens de boel getest en de software marcheert, zet ik alles in een CAD programma en ontwerp ik de print. Ofwel frees ik ze zelf (als ik niet 100% zeker ben) ofwel gaat ze naar China en 4 weken later zit alles netjes in m'n brievenbus...
Voila, de file nog eens bijgewerkt. Ik denk dat het ondertussen wel al van voldoende mogelijkheden is voorzien om "universeel" inzetbaar te zijn. Indien er toch tekortkomingen zijn, er zijn mogelijkheden voorzien voor uitbreiding, of kunnen altijd op V2.0 komen indien ik er nog eens moet laten maken.
Eerst eens kijken hoe dat zit om die GERBER-files aan te maken en de text op het silk-screen kan plaatsen/verwijderen in EAGLE (kan allicht niet zo moeilijk zijn?).
Iemand geïnteresseerd in één of meerdere? Dan laat ik er voldoende maken...
Ik zou toch eerst via een breadboard werken, de software voor het grootste deel ontwikkelen en dan pas de prints (laten) maken.
Gerber in Eagle is inderdaad niet moeilijk. In de Control Panel: File - Open... - CAM Job... Selecteer de gerb274x.cam. Dan in de CAM Processor: File - Open - Board... en de rest zie je wel...
In Eagle zijn er scrips waar je gewoon kiest welk type (2-, 4-laags) en dan gewoon laten runnen. Maar best eerst bij de fabrikant gaan zien welke de rules zijn (min restring, imp vs metric, min gatdiameter etc) die instellen en een drc runnen. Sommige fabrikanten aanvaarden ook gewoon .brd files. Maar dan moet je wel officiele soft hebben. Tekst gewoon aanklikken en met de opties op de goeie laag zetten. Zit 600km van de pc, lastig om meer detail te geven.
Heb hun processor gedownload, heb je al meteen de juiste namen en instellingen voor de bestanden ;)
Nu wachten tot het geld op Paypal staat en dan bestellen...
Rian, heb nu ik terug achter een echte pc met scherm en toetsenbord zit je .pdf eens gelezen. Leest goed, maar een blokschema zou direct meer duidelijk maken. Enig ding dat ik zou toevoegen zijn op zijn minst serieweerstandjes op de io lijnen die de print afgaan. Zou daar zelfs RC kringetjes opzetten. En een zekering/polyfuse aan de ingang. En een ledje op de power :) Maar dat is natuurlijk mijn beroepskant die bovenkomt. Heb op mijn eigen printen tussen de pc en de controller zelfs translating buffers gezet en tristate buffers én emifil's op elke io-lijn naar buiten. Waarschijnlijk overdreven maar met meters draad en motoren neem ik geen risico's.
Snap alleen niet waarom je denkt dat als je enkelvoudige gelijkrichting gebruikt je denkt geen aansluitingsproblemen te hebben tussen modules. Je dwingt jezelf daarmee direct dubbel zo grote elco's op. Persoonlijk zou ik kiezen voor een centrale gelijkrichter (of een gekochte DC voeding) en enkel DC naar je modules laten gaan. Bvb 8-9V of zoiets en dan bij elke ingang een seriediode (tegen verkeerd verbonden) en altijd een 7805. Kan je altijd een 9V stekkerblok gebruiken of zelfs een batterij als je snel iets wil testen. Tenzij je die wisselspanning voor iets anders nodig hebt zou ik geen wisselspanning ronddelen.
Citaat van: Sattrickske op 05 augustus 2014, 19:53:06 PM
Ik heb al een paar printen laten maken bij iTead studio (Chinezen). Dubbelzijdige prints, doorgemetaliseerd, kosten 20 USD voor 10 stuks + verzendkosten (8 USD dacht ik). Voor die prijs kan ik ze meestal zelf niet maken... 't zijn wel 10 dezelfde prints natuurlijk.
Ben daarnet eens gaan kijken bij die mannen maar 5 europrinten komen op $65.00 en dan gaan waarschijnlijk de mannen van de douane weer lastig doen. Lastige keuze... Snap eigenlijk niet eens wat ik zou terugkrijgen als ik een eurokaart formaat opstuur. Denk dat ik een 100x200 zou krijgen.
Bedankt voor je inbreng ;) Het ledje tussen 5V en GND is wel degelijk voorzien hoor ;
CiteerSnap alleen niet waarom je denkt dat als je enkelvoudige gelijkrichting gebruikt je denkt geen aansluitingsproblemen te hebben tussen modules. Je dwingt jezelf daarmee direct dubbel zo grote elco's op.
Als je de massa van de 5V moet doorverbinden tussen twee modules moeten die elk een aparte transfo toch hebben bij dubbelzijdige gelijkrichting? De Elco's lijken me geen probleem... Ik denk dat als zo'n bordje 100mA verbruikt dat het véél zal zijn... (en dus geen zo grote condensator nodig, en er is een regelaar voorzien).
Edit: nu naar keuze enkel of dubbelzijdige gelijkrichting.
Die 20 usd is als je printje in een vierkant van 10 bij 10 past, maar het moet geen rechthoek te zijn. Ik zit daar ook een beetje buiten, maar 't valt nog mee. Maar volgende keer probeer ik 't op die éné dm² te krijgen indien mogelijk.
CiteerAls je de massa van de 5V moet doorverbinden tussen twee modules moeten die elk een aparte transfo toch hebben bij dubbelzijdige gelijkrichting?
Waarom zou dat verschillend zijn tussen enkel- en dubbelzijdig gelijkgericht? Of ga je de "massa" aan elkaar hangen voor de gelijkrichters? Maar waarom zou je wisselstroom verdelen tussen je printen in de eerste plaats? Mijn indruk is dat je het maken van een voeding wil vermijden door gewoon een stevige transfo zijn aansluitingen te verdelen. Maar denk eraan wat er gebeurt als je dan een kortsluiting op die verbindingen maakt. Beter zou zijn om toch een minimale voeding te maken met enkele (lager gezekerde) uitgangen.
CiteerIk denk dat als zo'n bordje 100mA verbruikt dat het véél zal zijn...
Ik dacht dat je 2 stuks ULN2803 op 1 print kon zetten volgens je .pdf (poort B en D). Dat is een maximum van 5A als de 2 ic's maximaal belast worden. (1) Hou er ook rekening mee als die relais moeten schakelen dat op dat moment je spanning niet te laag mag zakken dat je processor in de problemen komt. Of je moet je processor de relais sequentieel laten schakelen met minstens 20ms ertussen zodat de elco terug kan opladen bij de volgende periode.
Een simpel 5V relais is zo'n 150 Ohm spoelweerstand. Dat is dan 33 mA per relais dat je stuurt. Dus 8 relais is een 270mA.
Andere oplossing is natuurlijk een aparte "power" ingang voorzien voor de ULN's maar dan ga je maatregelen moeten nemen dat je niet langs de power kant de logica kant voedt als er 1 voeding te laat is of defect. Moet je ook rekening houden met hoe je de massa's gaat scheiden/verbinden tussen de power kant en de logica kant.
(1) 500mA max voor 1 uitgang, 2.5A max voor het substraat (je GND pin) en dat is dan het totaal van de uitgangen. Je kan geen 4A schakelen met 1 ULN. En je hebt het zelfs over transistoren voor nog meer stroom.
Foutje van mijn kant: ik denk teveel aan de situatie waarin we in de treinclub een "probleem" mee hadden. Daar hing de massa van de 12v (7812) voeding met dubbelzijdige gelijkrichting via via terug aan de massa (diverse massa's moesten met elkaar verbonden worden) van de transfo waaruit die gevoed werd, en dat gaf vonken, maar normaalgezien zou het nu geen probleem mogen geven. Ga de diode en jumper dan deleten.
De ULN2803 en BD 679 transistor: de verbruikers die daaraan hangen hoeven toch niet gestuurd te worden met de 5 volt van op de print? Ik wil mijn wissel aandrijvingen met die ULN's gaan sturen, dus dat werkt al niet op 5V. Dus rest enkel nog de stroom voor de µC (weinig), de ledjes, de basisstromen voor de ULN, allemaal beperkt toch?
CiteerDe ULN2803 en BD 679 transistor: de verbruikers die daaraan hangen hoeven toch niet gestuurd te worden met de 5 volt van op de print? Ik wil mijn wissel aandrijvingen met die ULN's gaan sturen, dus dat werkt al niet op 5V. Dus rest enkel nog de stroom voor de µC (weinig), de ledjes, de basisstromen voor de ULN, allemaal beperkt toch?
Klopt, je kan dat doen zoals je wil. Vergeet dan geen aansluiting voor de COM van de ULN naar buiten te brengen. Die moet aan de + van de voeding van je relais/wisselmotoren etc. En de stroom loopt via de GND aansluiting van je ULN, vergeet dat ook niet, dus je moet de massa van de voeding van je relais/wisselmotoren aan die van je processor hangen.
Maar je zou bvb wel relais of leds direct via die voeding kunnen aansturen als je voeding erop berekend is.
Er is zeker een connector voorzien voor de GND
Eens benieuwd wat dat zal geven, die printjes uit China. Vandaag betaald en files opgestuurd :D Als dat goed gaat probeer ik zoveel mogelijk m'n designs op 10x10 te krijgen. Voor 14€ heb ik amper de printjes ervoor gekocht. Zeker als ik er enkele moet doen...
Nu een dikke maand wachten op de levering. Ik had met mijn prints geen enkel probleem en er zelfs 2 extra gekregen omdat m'n ontwerp geen topgeheim was ;-) De printjes zijn inderdaad zeer goedkoop wanneer je binnen de dm² blijft. Eurocards zijn inderdaad wat duurder, maar als je zeker van je ontwerp bent, valt zelfs die prijs nog mee.
Zolang je de design specificaties van iTead respecteert, zijn dit kwalitatief zeer goede prints. Voor deze prijzen kan ik de dubbelzijdige prints niet zelf maken.
Ik heb je specificaties nog eens doorgenomen en persoonlijk had ik de relais achterwege gelaten en met MOSFETs gewerkt. En inderdaad 2 voedingen voorzien, eentje voor de logica en eentje voor de randapparatuur. Die voor de logica kan zelfs heel simpel zijn: na de bruggelijkrichter kan een zener met een weerstandje en een paar condensatoren al volstaan omdat je PIC weinig stroom verbruikt.
Met een (stevige ) (logic-level) Mosfet kun je toch geen DCC schakelen? Er staan géén relais op de print nu, kan altijd via ULN 2803 voorzien worden... (bv op Din Rail naast het printje)
http://www.onsemi.com/pub_link/Collateral/NTP75N06-D.PDF (http://www.onsemi.com/pub_link/Collateral/NTP75N06-D.PDF)
Erik ;D
Citaat van: conducteur op 12 augustus 2014, 20:56:55 PM
Met een (stevige ) (logic-level) Mosfet kun je toch geen DCC schakelen? Er staan géén relais op de print nu, kan altijd via ULN 2803 voorzien worden... (bv op Din Rail naast het printje)
Jawel hoor, ik heb al met MOSFETs gewerkt die 2 kW kunnen schakelen (niet voor modelbouw maar soit, zie maar naar die van Erik). Het enige dat je met zulke MOSFETs hoeft te doen is er een transistor-schakeling aan de gate bijzetten; de gates van zulke MOSFETs schakelen dikwijls niet op lage spanning én een goede koeling!
En inderdaad goed dat je geen relais rechtstreeks op de print zet (pakt veel plaats en maak je print bijgevolg duurder). Ik dacht dat je kloeg over te weinig stroom met de ULN2803, dus dacht ik een paar MOSFETjes. Ik gebruik AO3401 en AO3402 (schakelen al bij 2V) en leveren 1W (kortstondig mag je daar over gaan, max 30V en/of max 4A), deze zijn niet sterk genoeg om spoelen mee van stroom te voorzien, maar perfect om servomotoren, ledjes ed. mee aan te sturen. Deze mag je rechtstreeks aan de µC koppelen zonder current limiter resistor.
Als je meer power wil, bv. D10N05; hier heb je wel een voorschakeltransistor nodig.
Ja, maar je hebt toch nog altijd geen DCC ingeschakeld met je MOSFET, of een ander signaal waarvan de polariteit periodisch omdraait?
Citaat van: conducteur op 12 augustus 2014, 21:27:49 PM
Ja, maar je hebt toch nog altijd geen DCC ingeschakeld met je MOSFET, of een ander signaal waarvan de polariteit periodisch omdraait?
Rian, ik kan een deel van je vraag niet volgen. Is het de bedoeling dat je een DCC signaal wil opwekken?
PS:ik heb wel niet al de info die je aan andere forumleden mogelijk hebt doorgegeven....
Geert
Niet direct, Geert. Ik heb het meer op schakelen van stopsecties voor in het schaduwstation. (= inschakelen van DCC van de Multimaus)
Triac.
Erik
Ja, maar die valt telkens uit. (nu ook weer geen zo'n groot probleem denk ik)...
En zoek je dan nooit eens uit waarom ? (die altijd uitvalt)
Erik
Weet wel hoe zo'n ding werkt hoor 8) Echter nog nooit mee "gewerkt" om die reden.
Ik volg niet.
Je hebt er nog nooit mee gewerkt, maar hij valt altijd uit. Hoe weet je dat dan ?
Erik
Als de stroom bij een DIAC Thyristor /TRIAC onder een bepaalde waarde gaat, "valt" die toch uit, voor zover ik weet? Dus elke keer het DCC of ander signaal door 0V gaat "valt" hij toch uit?
Als hij uitvalt moet hij minstens 1 keer gestart zijn...
Waarom kan hij niet meer terug starten (in geleiding gaan) ?
Erik
EUREKA! Als je blijft stroom geven op de gate... Blijft die open (?) Ik zat voortdurend met een korte puls als aansturing in mijn gedachten, en dan moet je hem wel elke keer terug aansteken.
Goed zo.
Erik
Telkens opnieuw een puls wordt toegepast bij bvb netspanning-dimmers: zoveel milliseconden na elke nuldoorgang ;)
Citaat van: Gerolf op 13 augustus 2014, 10:52:00 AM
Telkens opnieuw een puls wordt toegepast bij bvb netspanning-dimmers: zoveel milliseconden na elke nuldoorgang ;)
...maar ook met een continue puls toch? Het moet geen dimmer worden... Iemand een typnr voor een TRIAC voor +/- 1,5A.
Je moet naar de TRIAC curve kijken. Je kan wat spanningsverlies hebben over de TRIAC waardoor je minder overhoud voor de lok. Ook zal deze niet direct geleiden, er moet een minimum spanning over staan. Nu is dat bij DCC redelijk snel, maar toch kan er mogelijk wat tijdverlies zijn?
Zal een relais niet eenvoudiger zijn ...
Geert
CiteerDie voor de logica kan zelfs heel simpel zijn: na de bruggelijkrichter kan een zener met een weerstandje en een paar condensatoren al volstaan omdat je PIC weinig stroom verbruikt.
Toch liever een 78L05 of zo, dan heb je direct kortsluitbeveiliging, overtemperatuur etc ingebouwd. Je kan zelfs SOT23 versies hebben die niet meer plaats innemen dan een zener.
Dacht ook niet dat je DCC met een mosfet kon schakelen, maar andere verbruikers (leds, relais) waarschijnlijk wel. Zou anders fet-relais kunnen gebruiken, maar als je er wat stroom doorwil worden die guaw prijzig. Andere mogelijkheid is een fet in een brug zetten (en dan de fet+brug) als schakelement gebruiken. Wordt soms gedaan. Ideeën:
http://www.electro-tech-online.com/threads/electronic-switch-with-optocoupler-and-irf350-mosfet.95604/ (http://www.electro-tech-online.com/threads/electronic-switch-with-optocoupler-and-irf350-mosfet.95604/) ga naar post #11
http://easy-electronics4u.blogspot.be/2012/02/switch-ac-loads-using-mosfets-as-relay.html (http://easy-electronics4u.blogspot.be/2012/02/switch-ac-loads-using-mosfets-as-relay.html)
www.irf.com/technical-info/designtp/dt94-5.pdf (http://www.irf.com/technical-info/designtp/dt94-5.pdf)
Citaat van: conducteur op 13 augustus 2014, 10:55:51 AM
...maar ook met een continue puls toch? Het moet geen dimmer worden... Iemand een typnr voor een TRIAC voor +/- 1,5A.
Google kapot ?
Heb je nu echt geen andere elegantere methode om een trein te stoppen in een stopsectie via het DCC-signaal ? (Geen DCC : lok en lokdecoder zijn dood)
Erik :(
Citaat van: Geert op 13 augustus 2014, 11:25:34 AM
Zal een relais niet eenvoudiger zijn ...
Geert
...Dat dacht ik eerst ook...
Citaat van: Geert op 13 augustus 2014, 11:25:34 AM
Je moet naar de TRIAC curve kijken. Je kan wat spanningsverlies hebben over de TRIAC waardoor je minder overhoud voor de lok. Ook zal deze niet direct geleiden, er moet een minimum spanning over staan. Nu is dat bij DCC redelijk snel, maar toch kan er mogelijk wat tijdverlies zijn?
Zal een relais niet eenvoudiger zijn ...
Geert
Ik heb net even een datasheet bekeken (standaard-Triac BT134): 10 tot 50A/µsec stijgtijd. Lijkt me snel genoeg voor DCC.
Niettemin dacht ik, zoals eve, dat er betere manieren waren om een digitale loc te doen stoppen ...
Hoopje connectoren en µC en paar kleinigheden al toegekomen.
In afwachting van de printjes ga ik dit toch eens uitproberen op breadboard, tenzij iemand zegt dat het fout zal aflopen:
(http://treinbaanrian.be/elektronica/rs485.png)
Idee is om via de TX/RX pinnen te gaan communiceren met meer dan 2 µC, waarbij master een voor een telkens de slavestoestemming geeft om even de bus te gebruiken. Mag je zomaar die pinnen aan elkaar knopen zoals ik getekend heb? Ik zie niet direct waarom niet?
Ingangen kan je aan elkaar knopen, uitgangen niet
Waarom RX/TX en niet I2C ?
...Om paar meter te kunnen overbruggen... Dat gaat toch niet met I²C?
http://store.fungizmos.com/items/343 (http://store.fungizmos.com/items/343)
...you can extend your I2C bus at least 10x the normal length...
Erik
Citaat van: eve op 15 augustus 2014, 11:19:19 AM
http://store.fungizmos.com/items/343 (http://store.fungizmos.com/items/343)
...you can extend your I2C bus at least 10x the normal length...
Erik
Zeker eens te bekijken! Dank je!
CiteerIngangen kan je aan elkaar knopen, uitgangen niet
Als je de uitgangen van de slaves in tri-state kan zetten als je niets uitzendt is dat mogelijk. Je gaat ook zeker moeten zijn dat tijdens het opstarten (als nog niet alles geconfigureerd is) die uitgangen in tri-state staan of als ingang. En ook dat als er een niet opstart dat die de hele zaak niet stoort (of erger).
Als je dat niet kan dan moet je in serie met de TX uitgang van de slave een tri-state buffer zetten (type 125 moet ok zijn) die je aanstuurt met een uitgang van de slave. Als je iets te sturen hebt de buffer actief maken, als je gedaan hebt de buffer terug in tri-state.
Nu ga je toch moeten opletten als je dat wil doen over enige afstand (je spreekt over meters in een verdere post) en bij een redelijke snelheid. Je gaat zeker aandacht moeten besteden aan afsluiten van je kabel.
Citeer...Om paar meter te kunnen overbruggen... Dat gaat toch niet met I²C?
Je kan I2C verder gebruiken. Naar aanleiding van de discussie over seriële protocollen ben ik daar naar gaan kijken. Gevolg is dat ik dat voor mijn sturing ga gebruiken om zelf niks te moeten uitvinden. Met de juiste ic's kan je tot 100 meter gaan. De 2 documenten die hierover een pak nuttige info geven zijn:
www.nxp.com/documents/...note/AN10658.pdf (http://www.nxp.com/documents/application_note/AN10658.pdf)
phillips-talking-about-long-i2c-busses.pdf (http://pidome.files.wordpress.com/2013/10/phillips-talking-about-long-i2c-busses.pdf)
Voor jouw toepassing zou die P82B715 ok zijn. Ik ga naar de P82B96 omdat niet alleen de afstand groot is (7-8 meter) maar er ook tientallen receivers zijn. Geeft ook geen problemen als er bvb een remote print geen spanning krijgt.
Zonder zo'n tussenliggende drivers kan je beter niet tussen verschillende pcb's gaan, zelfs al is het maar 20cm.
EDIT: links
Dank voor aanvulling, Johan!
EDIT: in mijn JAL-boek van Bert Van Dam gevonden:
(http://www.treinbaanrian.be/elektronica/rxtx2.png)
Een pull-up heb je altijd nodig voor I2C. Dacht dat 1k5 zowat de standaard was. Op de manier hierboven kan je ook verschillende zenders met elkaar verbinden. Maar als door een of ander probleem 1 van de uitgangen permanent laag is, kan niemand zenden. Normaal zou de master dat moeten zien en reset vragen. Ook de slaves als ze te lang (meer dan 9 klokken of zo) dat zien zouden moeten resetten. Maar daar wordt nogal eens van afgeweken.
Ja... maar met het plaatje heb ik het niet over I²C, maar over gewone seriele communicatie via RX&TX pinnen (RS232, maar dan op 0 &5V)
Daar ben ik zo geen voorstander van tenzij je enkel lage snelheden gaat gebruiken. Probleem met een pull-up is dat de stijgsnelheid van je signaal enkel door de pull-up en de capaciteit van je bekabeling bepaald wordt. En processoren vragen aan de ingang van IO zeker minimum waarden daarvoor (datasheet). De vraag is dan ook als je weerstanden neemt die klein genoeg zijn om die stijgtijden te halen of je TX uitgang die nog wel laag genoeg kan trekken in de tijd van 1 puls.
RS-485? Kan snel en ver...
Citaat van: MickeyMouse op 15 augustus 2014, 18:26:25 PM
RS-485? Kan snel en ver...
Zoiets min of meer wil ik bekomen, maar heb nog niet gevonden of dat kan/ hoe het moet om dat te programmeren in JAL...
en aja, veel ongevoeliger voor storingen.
RS-485 is geen protocol, enkel een elektrische standaard. Kan inderdaad ver en snel maar is beperkt tot 256 punten mits de juiste transceivers, de meeste laten maar 32 punten toe.
Citaat van: Havoc op 15 augustus 2014, 19:16:29 PM
RS-485 is geen protocol, enkel een elektrische standaard. Kan inderdaad ver en snel maar is beperkt tot 256 punten mits de juiste transceivers, de meeste laten maar 32 punten toe.
Inderdaad!!
Met 32 Kun je toch al iets doen, zeker als het uit te breiden valt naar 256... Veel meer moet dat niet.
Citaat van: conducteur op 16 augustus 2014, 00:38:39 AM
Met 32 Kun je toch al iets doen, zeker als het uit te breiden valt naar 256... Veel meer moet dat niet.
Het aantal nodes hangt af van de gebruikte transceiver, best meteen starten met de juiste voor 256.
Lig niet wakker van afstanden bij communicatie bij gebruik van microcontrollers op je modelbaan. (Of deze moet al tientalle meters groot zijn)
De in output poorten voor communicatie zijn speciaal ontworpen en op elkaar afgestemd voor optimaal verzend en ontvangst, zeker onderling wat toch de bedoeling is.
Op deze link: http://www.mikroe.com/chapters/view/7/chapter-6-serial-communication-modules (http://www.mikroe.com/chapters/view/7/chapter-6-serial-communication-modules) staat meer info over communicatie met de PIC 16F887 microcontroller.
Geert
Citaat van: MickeyMouse op 16 augustus 2014, 09:27:41 AM
Citaat van: conducteur op 16 augustus 2014, 00:38:39 AM
Met 32 Kun je toch al iets doen, zeker als het uit te breiden valt naar 256... Veel meer moet dat niet.
Het aantal nodes hangt af van de gebruikte transceiver, best meteen starten met de juiste voor 256.
Ja, je moet direct beginnen met de goeie tranceiver. Nadeel van de versie met 256 nodes is dat dit meestal ook "langzame" types zijn tot 1Mbps en niet zo gemakkelijk te vinden (toch niet voor hobby). Dikwijls ook 3.3V types. Langs de andere kant zijn dit meestal standaard footprints dus je kan later zonder aanpassingen een ander type zetten. Beginnen met de makklijk te krijgen standard load (ADM/LTC/MAX1485) en dan later de 1/8 load type in de plaats. Kijk bvb eens naar de SN65LVD12.
CiteerLig niet wakker van afstanden bij communicatie bij gebruik van microcontrollers op je modelbaan. (Of deze moet al tientalle meters groot zijn)
Ken genoeg voorbeelden waar I2C tegen de lamp loopt in het echt eenmaal je de pcb afgaat, zelfs binnen hetzeflde toestel. (*) Eenmaal je de print afgaat moet je specifieke interface chips inschakelen. Kabels driven, storingen, esd als je inplugt etc. Gewoon je processor aan een kabel hangen is een risico. Zo'n drivers zijn gemaakt om tegen wat mishandeling te kunnen. En je stuurt nog al de rommel die op de voeding van een cpu zit mee die kabel op ook.
(*) niet meer dan een I2C thermometer waarmee de temperatuur aan de connector werd uitgelezen. Zelfs in een volledig metalen doos hangt dit zodra je het licht inschakelt. Ander geval is een master die 4-16 slaves beheert, slaves hangen met een flatcable aan de master max 1 meter. Hangt regelmatig zonder dat er iets speciaals gebeurt. Ook allemaal in dezelfde behuizing.
Inderdaad, je wilt niet weten wat het 'antenne'-gehalte van een paar meters draad is. Als deze rechtstreeks aan uw microcontroller hangt en je gaat er dan mee buiten uw print dan vangt die vanalles op, en dan maar uitzoeken waarom die controller hangt en/of reset.
maar met een checksum kun je toch telkens controleren of de "boodschap" just is? Of is zo'n systeem geen echte waterdichte oplossing om fouten weg te filteren?
Ja, dat kan een oplossing zijn. Maar een checksum maken langs de ene kant, die eruit halen langs de andere kant, controleren en als het fout is de andere kant verwittigen om opnieuw te sturen en alles opnieuw te beginnen vraagt tijd, bandbreedte en processingpower. Elke fout die er niet is is pure winst. In het slechtste geval is je aanvraag om opnieuw door te sturen ook verminkt en begint het spel van 2 nodes die elkaar steeds maar opnieuw hetzelfde vragen en er nooit uitkomen. Livelock heet dat. En in het geval van I2C kan je in een situatie komen dat de communicatie stilvalt. En vermits het volgens de standaard ok is om dat te doen...
Je hebt natuurlijk gelijk als je stelt dat je altijd crc checks of zoiets moet inbouwen, anders weet je nooit of er fouten zijn. Zelfs als je denkt dat je communicatie perfect is doe je dat. Maar beter alles op voorhand robuust maken.
Hi Rian,
Als ik dat hier allemaal lees, denk ik dat er toch een paar misvattingen zijn over de lengtes die kunnen gebruikt worden bij dit soort (seriële) comunicatie...
De beperkingen liggen bij de frequentie, puls-vorm en het soort bekabeling. Elke kabel heeft zijn eigen specifieke weerstand per meter en ook een capaciteit per meter; de kabel gedraagt zich als een low-pass RC-filter. Des te langer de kabel, des te lager de cut-off frequentie.
Dus zeggen dat je geen I2C wil gebruiken ten voordele van een ander protocol of standaard is een beetje kort door de bocht. Als je dezelfde bekabeling gebruikt, zal je steeds tegen dezelfde beperking botsen. Ik heb al afstanden gehaald van meer dan 100m met I2C, wel met buffering. Kijk hier maar eens naar: http://www.nxp.com/documents/application_note/AN10658.pdf (http://www.nxp.com/documents/application_note/AN10658.pdf)
Transmissie lijnen en de bijhorende hardware zijn jammer genoeg niet eenvoudig te ontwerpen, wat je ook doet/kiest, kijk goed uit!
En Johan heeft het al wat aangehaald, zelf een protocol gaan schrijven is een pak werk
Bedankt... Als ik een paar meter ver wil geraken niet te snel willen gaan...
Citaat van: conducteur op 16 augustus 2014, 22:45:54 PM
Bedankt... Als ik een paar meter ver wil geraken niet te snel willen gaan...
...is ordinaire RS-232 nog zo slecht niet. Interface ic's zijn er met hopen en kosten niet veel en je processor heeft een ingebouwde mogelijkheid om te adresseren dacht ik. Ook geen probleem om aan een pc te hangen en je data te loggen om te zien wat er gebeurt etc. Asynchroon dus geen aparte klokken, niet bi-directioneel op dezelfde draden en met 3 draden kom je toe.
KISS!
EDIT: Zelf een protocol schrijven is niet alleen een pak werk, het testen om zeker te zijn dat het in alle omstandigheden werkt is nog meer werk.
Citaat van: Havoc op 17 augustus 2014, 11:47:05 AM
Citaat van: conducteur op 16 augustus 2014, 22:45:54 PM
Bedankt... Als ik een paar meter ver wil geraken niet te snel willen gaan...
...is ordinaire RS-232 nog zo slecht niet. Interface ic's zijn er met hopen en kosten niet veel en je processor heeft een ingebouwde mogelijkheid om te adresseren dacht ik. Ook geen probleem om aan een pc te hangen en je data te loggen om te zien wat er gebeurt etc. Asynchroon dus geen aparte klokken, niet bi-directioneel op dezelfde draden en met 3 draden kom je toe.
KISS!
EDIT: Zelf een protocol schrijven is niet alleen een pak werk, het testen om zeker te zijn dat het in alle omstandigheden werkt is nog meer werk.
Zat in de fiddle yard (zonder MAX232 oid) en ging zonder problemen over de 4 meter kabel, maar dat gaat maar tussen 2 µC
Ik heb RS232 gebruikt om te communiceren vanuit één master naar 8 slaves.
Mits het gebruik van een derde lijn naar elke slave, die signaleert dat er communicatie "mag", kan het wel
Dan heb je toch weer het probleem dat je uitgangen aan elkaar knoopt?
(http://treinbaanrian.be/elektronica/rs485.png)
Ja, je gaat met externe circuits de uitgang moeten enabelen als je iets moet sturen en disabelen als je niks te sturen hebt (met een io pin). Moet je meenemen in je software.
Probleem met de 16887 is dat om de receiver te enabelen je de transmitter moet enabelen, je kan niet beiden onafhankelijk sturen.
Citaat van: conducteur op 18 augustus 2014, 12:55:06 PM
Dan heb je toch weer het probleem dat je uitgangen aan elkaar knoopt?
diodes ;)
Idd een mogelijkheid, zoals de oplossing uit het boek maar dan "omgekeerd" en kan de pull-up ook vervallen..
(http://www.treinbaanrian.be/elektronica/rxtx2.png)
Citaat van: conducteur op 18 augustus 2014, 18:13:33 PM
Idd een mogelijkheid, zoals de oplossing uit het boek maar dan "omgekeerd" en kan de pull-up ook vervallen..
(http://www.treinbaanrian.be/elektronica/rxtx2.png)
Werkt niet als je er drivers (max232 of zo) tussenzet.
Klopt. Die diodes zijn wél OK voor een "korte" opstelling én µC-to-µC én niet héél snel (38400 baud)
Chance: al toegekomen, vrij vlot dus!
Zet eens op foto, ben benieuwd ;)
Geert
Citaat van: Geert op 27 augustus 2014, 11:52:01 AM
Zet eens op foto, ben benieuwd ;)
Geert
De kwaliteit ziet er bijzonder goed uit, dit krijg ik met de cnc niet zo proper gedaan.
(http://www.treinbaanrian.be/images/uplc/uplctop%20(Small).JPG)
(http://www.treinbaanrian.be/images/uplc/uplcbottom%20(Small).JPG)
klik voor hoge resolutie
http://www.treinbaanrian.be/images/uplc/uplctop.JPG
Zeer mooi ontwerp, hopelijk werkt het zoals je het wilde.
Geert
Dank je. Zo moeilijk was het routen hiervan nu ook weer niet.
Dit was mijn bescheiden micro PLC 20 jaar geleden, op een eurokaartje en met eigen 220V voeding:
(https://lh6.googleusercontent.com/-A9rKDDAJb48/U_3qgF1Di9I/AAAAAAAAANk/EdL2PFQruNY/w648-h389-no/PLC%2B1994.jpg)
de gebruikte µC was nog met ROM geheugen die je 15 minuten onder een UV lamp moest plaatsen voordat je deze kon herprogrammeren. (het venstertje op de IC moest je ook telkens afdekken met tape tegen lichtinval...) Dat waren nog tijden dat je heel veel tijd in je hobby stak :D
het stof is vergaard over deze periode....
Geert
Ja amai 8) . En ie doet 't nog altijd...?
Dit jaar weet ik niet of deze nog werkt. Ik heb deze micro PLC geprogrammeerd als automatische sproei-installatie voor de tuin. ;)
(https://lh6.googleusercontent.com/-cvoOQF8p7kA/U_3zG3zakLI/AAAAAAAAAPA/OPXc66b_NRo/w962-h577-no/WP_20140827_003.jpg)
Geert
Ja... dan is die voorlopig technisch werkloos. Het absolute minimum op een van de printjes gezet om eens te testen: connector voor voedingspanning, ledje + weerstand, header voor de programmer en de µC in z'n voetje. Straks "blink a led", mag geen probleem geven.
Heb op de printjes wat 1206 smd'tjes staan... Het gaat wel, maar niet altijd even proper. Iemand tips?
Citaat van: conducteur op 28 augustus 2014, 11:57:20 AM
...Iemand tips?
http://www.digital-bahn.de/info_bau/loeten.htm
http://www.bolte.de/uploads/media/smd-anleitung.pdf
Wel beiden in het Duits.
1206? Verkopen ze dat nog :D
Ik begin met bvb de 10k (volg mijn stuklijst wel), dan plaats ik mijn print zo dat al die weerstanden (of toch zoveel mogelijk) dezelfde kant opstaan, horizontaal voor mij. Dan al de pads langs de rechterkant een klein stipje soldeer geven. vervolgens 1-voor-1 de weerstanden met een pincet in mijn linkerhand plaatsen en de rechterkant vastsolderen. Als die er allemaal opstaan print 180° draaien en de 2-de kant solderen. Dan de volgende waarde etc. Van de platste component naar de dikkere.
En je bout goed heet zetten zodat je héél kort kan werken. Als je te lang moet verwarmen is de flux uitgewerkt voor het soldeer smelt. Eigenlijk moet het genoeg zijn om binnen de seconde je component vast te zetten. Geen te kleine punt nemen, die koelt te snel af en kan ook niet veel warmte toevoegen. Diameter 1mm is een goeie maat.
Met de grote vlakken van DPAK en D2PAK lukt dat natuurlijk niet en moet je langer verwarmen. Maar weerstanden, caps (geen grote elco's), sot23, sot 223, en ander klein grut best te doen.
Voor IC's eerst de diagonalen vastzetten. Dan flux aan de rij doen en met 1 druppel soldeer langsgaan. Teveel afnemen met wat litze.
Citaat van: PeterC op 28 augustus 2014, 12:53:51 PM
Citaat van: conducteur op 28 augustus 2014, 11:57:20 AM
...Iemand tips?
http://www.digital-bahn.de/info_bau/loeten.htm (http://www.digital-bahn.de/info_bau/loeten.htm)
http://www.bolte.de/uploads/media/smd-anleitung.pdf (http://www.bolte.de/uploads/media/smd-anleitung.pdf)
Wel beiden in het Duits.
Da's limburgs met een vreemd accent, niet zo moeilijk om te begrijpen.
Citeer1206? Verkopen ze dat nog [size=0px] [/size]
Ja, blijkbaar wel toch. 't Was niet direct om het formaat te doen, maar eerder om aan de onderkant nog plaats te hebben voor de baantjes, dan moet je jezelf 't toch niet zo moeiljk maken.
CiteerJa, blijkbaar wel toch. 't Was niet direct om het formaat te doen, maar eerder om aan de onderkant nog plaats te hebben voor de baantjes, dan moet je jezelf 't toch niet zo moeiljk maken.
Hoe kleiner de componenten hoe meer plaats voor banen. :D Alhoewel als je maar 2 lagen hebt is het inderdaad soms handig een groter formaat te nemen omdat je dan tussen de poten kan. Maar als je zelf etst is dat dan soms weer een probleem...
Ik werk altijd met 0805, soms met 0603. En zoals Johan al zei: één kant van de padjes een tikje soldeer geven, met een pincet hou je de 1206/0805/0603 vast en tik je effe het vertinde padje aan, daarna de het ander padje vast solderen met een klein drupje tin (ook weer effe aantikken wanneer je de soldeerdraard ertegen houdt).
Ik gebruik een afgeknotte, konische punt (redelijk groot), deze verhit sneller de padjes dan een fijne kegel punt. De soldeertip kies je zelf, gebruik eentje waarmee je het beste overweg kan.
Maar mooie printjes in ieder geval!
(http://www.treinbaanrian.be/images/uplc/tinyplc.JPG)
Een "zijsprong" van het µPLC project is een klein printje van amper 5*5 cm. Het was eerst ontworpen als soort "ULN2803" maar dan met 8 aparte darlingtontransistoren voor meer stroom. Dit met de bedoeling om ook peco-wisselmotoren te kunnen aansturen, die nogal erg hoge stromen trekken. De bedoeling was om dit aan te sturen met de µPLC met de 10 polige connector hier onderaan (niet gesoldeerd op dit printje). Er was nog wat plaats op de onderkant, heb dan maar een SOIC 28 pins µC op gezet voor besturing hiervan ook mogelijk te maken via I²C of serieel. Ooit van iemand voor bijna niets 25*16f876A µC kunnen overnemen. Dedju toch dat die geen interne oscillator hebben, en ik geen plaats op het kleine printje heb voorzien (en er is ook geen plaats, denk ik). Daar gaat mijn plan om die eens nuttig te gebruiken.
Ik loop met het gekke idee om zo'n printje te gebruiken om er een wisseldecoder mee te bouwen. Hoe begin je aan zoiets? Waar vind je de uitleg van het DCC-protocol?... een uitdaging :)
Citaat van: conducteur op 02 september 2014, 00:18:55 AM
Waar vind je de uitleg van het DCC-protocol?... een uitdaging :)
Hier bijvoorbeeld: http://www.nmra.org/node/171/ (http://www.nmra.org/node/171/)
En dan in het bijzonder S-9.1, S-9.2 en S-9.2.1
Ha, was al op de website gaan kijken, maar niet lang genoeg gezocht allicht :)
HIER (http://users.telenet.be/RedDeBist/MBAAN/Servo_aansturen_digitaal_2.htm#Opbouw%20DCC%20signaal%20om%20wissels/seinen%20aan%20te%20sturen:) heb ik beknopt uitgelegd hoe het DCC protocol werkt om bv. wissels aan te sturen.
Geert
dank je!
Op basis van Geert zijn site al een hoop code in elkaar gestoken. Theorethisch zou mijn code "werken", maar dat zal allicht niet waar zijn.
Deze routine moet uitmaken of de puls "0" of "1" is, maar met gewoon delays zal ik voor dit programma allicht veel te veel tijd verliezen? Moet nu ook nog kijken voor een oplossing voor die controllers zonder interne klok : rc kring op het printje foefelen, of nieuwe?
procedure bitdetect is
while !dcc loop ; wacht op dcc-puls
end loop
_usec_delay(80) ; wacht (58µs (1) <80µs <100µs (0)
if dcc then ;is puls "0" of "1"
dccbit=false ;ontvangen bit is 0
else
dccbit=true ; ontvangen bit is 1
end if
end procedure
rest programma:
-------------------------------------------------------------------------------
;wisseldecoder met uplc module
;pic 16f886
;v1.0
-------------------------------------------------------------------------------
include 16f886
pragma target osc INTOSC_NOCLKOUT -- HS crystal or resonator
pragma target clock 8_000_000 -- oscillator frequency
pragma target WDT control -- WDT off
pragma target LVP disabled -- no low voltage programming
alias dcc is pin_c7
pin_c0_direction = input ;dcc signaal op rc7
alias dipswitch is porta_low
porta_low_direction = input
alias wissels is portb
portb_direction = output
include delay
var bit dccbit
var bit startbit
var byte ontvangst ; bytes worden "ontvangen" door routine en opgeslaan in de variabele
var byte adres ; ingesteld adres
var byte adresbyte ; byte met verzonden adres
var byte databyte ; byte met verzonden data
var byte checksum ;controlebyte
--------------------------------------------------------------------------------
;is puls "1" of "0"
--------------------------------------------------------------------------------
procedure bitdetect is
while !dcc loop ; wacht op dcc-puls
end loop
_usec_delay(80) ; wacht (58µs (1) <80µs <100µs (0)
if dcc then ;is puls "0" of "1"
dccbit=false ;ontvangen bit is 0
else
dccbit=true ; ontvangen bit is 1
end if
end procedure
--------------------------------------------------------------------------------
;receive byte - ontvang 1 byte
--------------------------------------------------------------------------------
procedure receiveByte is
ontvangst=0
for 8 loop
bitdetect
ontvangst=(ontvangst+dccbit)<<1
end loop
end procedure
--------------------------------------------------------------------------------
;procedure receive "0"; voor ontvangst "0" tussen bytes
---------------------------------------------------------------------------
procedure receive0 is
startbit=false
while !startbit loop
bitdetect
if dccbit then
startbit=!startbit
end if
end loop
end procedure
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
;procedure receive "1"- voor ontvangst "1" op einde pakket
--------------------------------------------------------------------------------
procedure receive1 is
startbit=false
while startbit loop
bitdetect
if dccbit then
startbit=!startbit
end if
end loop
end procedure
adres = 0x80 + dipswitch ;adres instellen 4 bit dip switch
forever loop
teller=0
while (teller<=10) loop
bitdetect
if dccbit then
teller=teller + 1
else
teller=0
end if
end loop
receiveByte ; ontvang adres
adresbyte=ontvangst
receive0 ;ontvang 0
receiveByte ;ontvang data
databyte=ontvangst
receive0
receiveByte ;ontvang checksum
checksum=ontvangst
receive0
if ((adresbyte^databyte^checksum)==0)&&(adresbyte==adres) then
case (databyte) of
0xF8: block
wissels=0x01
end block
0xF9: block
wissels=0x02
end block
0xFA: block
wissels=0x04
end block
0xFB: block
wissels=0x08
end block
0xFC: block
wissels=0x10
end block
0xFD: block
wissels=0x20
end block
0xFE: block
wissels=0x40
end block
0xFF: block
wissels=0x80
end block
otherwise block
end block
end case
delay_1ms(250)
wissels=0
end if
end loop
Je kan de pulsdetectie van DCC op verschillende manieren bekomen.
Jouw manier is de simpelste, maar je verliest veel nuttige processor tijd door de delay routine. De code die je hebt is correct (ben wel niet zeker van die 80 µsec, 'k zal thuis eens in de specs moeten gaan piepen).
De tweede manier is via 2 interrupts: één interrupt op de rising flank van het DCC signaal en één op een timer van 80 µsec (zelfde opm als hierboven, ben niet zeker). Van zodra je de rising flank ziet (eerste interrupt), start je de timer die exact na 80 µsec de 2e interrupt genereert. Dan lees je het DCC signaal opnieuw en beslis je of het 0 of 1 was.
Een derde manier is zeer gelijkaardig: 1 interrupt en een free running timer. De interrupt is op het DCC signaal, maar level based (ziet dus de overgang van 0 naar 1 en 1 naar 0). Bij de overgang van 0 naar 1 registreer je de tijd van de free running timer. Bij de overgang van 1 naar 0 neem je weer de tijd op en trek daarvan af de tijd voor de overgang van 0 naar 1. Je hebt dan een exacte pulsbreedte en dus kan je weer beslissen of het een 0 of een 1 was.
Hier bestaan nog heel wat varianten op (hardware en software), maar het principe valt steeds terug op één van de hierboven beschreven methodes.
Mijn C-bibliotheek gebruikt de 2e methode, als je die code wil, stuur je me maar een PB...
Gewoon met delay kan dit zeker werken. Als je een correct data pakket hebt ingelezen (om wissels aan te sturen!), dan zal de DCC centrale een redelijke lange pauze (een lange nul) doorsturen. Dan kan je de data verwerken. Klopt het adres?, spoel aan, spoel uit enz... . Na verwerking begin je weer de eerste reeks préamblebits in te lezen, adresbyte, databyte en tenslotte errorbyte.
Wil je tegelijkertijd wel andere dingen doen, servopulsen opwekken bv. dan moet dit inlezen van de bits best via interrupt.
Geert
Je 80µs is goed. Heb hier (http://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.1_electrical_standards_2006.pdf) de standaard gevonden en op pag. 1 paragraaf 3 en 4:
Citeer
In a "1" bit, the first and last part of a bit shall have the same duration, and that duration shall nominally be 58 microseconds2, giving the bit a total duration of 116 microseconds. Digital Command Station components shall transmit "1" bits with the first and last parts each having a duration of between 55 and 61 microseconds. A Digital Decoder must accept bits whose first and last parts have a duration of between 52 and 64 microseconds, as a valid bit with the value of "1".
In a "0" bit, the duration of the first and last parts of each transition shall nominally be greater than or equal to 100 microseconds. To keep the DC component of the total signal at zero as with the "1" bits, the first and last part of the "0" bit are normally equal to one another. Digital Command Station components shall transmit "0" bits with each part of the bit having a duration of between 95 and 9900 microseconds with the total bit duration of the "0" bit not exceeding 12000 microseconds. A Digital Decoder must accept bits, whose first or last parts have a duration between 90 and 10,000 microseconds, as a valid bit with the value of "0". Figure 1 provides
an example of bits encoded using this technique.
Dus elke delay of timer >64 µs én <90 µs is voldoende.
Citaat van: Geert op 02 september 2014, 12:51:04 PM
Gewoon met delay kan dit zeker werken. Als je een correct data pakket hebt ingelezen (om wissels aan te sturen!), dan zal de DCC centrale een redelijke lange pauze (een lange nul) doorsturen. Dan kan je de data verwerken. Klopt het adres?, spoel aan, spoel uit enz... . Na verwerking begin je weer de eerste reeks préamblebits in te lezen, adresbyte, databyte en tenslotte errorbyte.
Wil je tegelijkertijd wel andere dingen doen, servopulsen opwekken bv. dan moet dit inlezen van de bits best via interrupt.
Geert
We blijven voorlopig eenvoudig. Het principe van die 80µs zou idd moeten werken, maar de vraag is: heb ik na die 80µs nog tijd genoeg over om de rest van de opdrachten in het programma uit te voeren? Riskeer ik op die manier niet de volgende puls te missen?
Als je een 1 inleest heb 58x2 is 116 microseconden. Dan blijft er na die 80 er nog 36 over. Bij 8Mhz zijn dat een 80 tal ASM instructies. C taal leunt daar dicht bij aan, dus ik denk geen probleem.
Geert
Rian, die print ziet er toch goed gesoldeerd uit? Veel netter is dat bij mij ook niet.
Voor die pics kan je ook een kristal van 32.768 kHz gebruiken. Die bestaan in hel kleine afmetingen: bvb de 1009261 van Conrad. Die is 2x1.2x0.6 mm... Krijg je toch wel nog ergens in een hoekje. :D
Ja, dat zijn die dingen om een real-time-clock mee op te bouwen. Ik vermoed dat het daarmee niet zal lukken? De 8 weerstandjes tussen de transistoren zin goed gelukt, die andere 4 op een rijtje daarentegen ben ik niet zo content van.
Je kan op de µC ook gewoon een logische externe klok van bijvoorbeeld 4 MHz aanluiten. Deze kan dan weer afkomstig zijn van een ander printje waar wel plaats is voor een nauwkeurige kristal. Deze externe klok kan je voor meerdere µC gebruiken en via een extra pin op je printje plaatsen. Zie datasheet bij oscilator mogelijkheden µC ....
Geert
Ik denk dat het eenvoudigste is gewoon kijken voor een µC met een interne klok aan te kopen, en die die ik heb nog even in het schuifje laten liggen ipv alle "gepruts". Volgende keer dan niet vergeten voor het kristal te plaatsen.
Citaat van: conducteur op 02 september 2014, 14:05:05 PM
Ja, dat zijn die dingen om een real-time-clock mee op te bouwen. Ik vermoed dat het daarmee niet zal lukken? De 8 weerstandjes tussen de transistoren zin goed gelukt, die andere 4 op een rijtje daarentegen ben ik niet zo content van.
Volgens de datasheet kan de pic daarmee werken.
Ik denk dat Rian bedoeld dat deze kristal gewoon te traag is ;) voor DCC detectie
Geert
Inderdaad... 32768 is niet toevallig gelijk aan 2^15, wat het eenvoudig maakt om daarmee seconden te gaan tellen, met een 16 bit binaire teller. Elke keer deze een overflow genereert is (vrij) nauwkeurig 1 seconde verstreken.
Citaat van: Geert op 02 september 2014, 14:56:19 PM
Ik denk dat Rian bedoeld dat deze kristal gewoon te traag is ;) voor DCC detectie
Geert
Hoe? Heeft die rommel geen ingebouwde multiplier?
Als ik het goed voor heb wordt de frequentie intern zelf gedeeld door 4. Wat het nut daarvan is moet je aan de experts hier vragen.
Meestal is dat om intern te kunnen synchroniseren. Zoiets van fetch, decode, ececute, store. Ben niet gewoon iets met pics te doen. Meestal hebben de processoren waar ik mee werkte ingebouwde multipliers en die maken dan van de externe frequentie een veelvoud waar ze mee werken. Je kan dan bij programering die multipliers en delers instellen.
Citaat van: Havoc op 02 september 2014, 19:32:42 PM
. Meestal hebben de processoren waar ik mee werkte ingebouwde multipliers en die maken dan van de externe frequentie een veelvoud waar ze mee werken. Je kan dan bij programering die multipliers en delers instellen.
De meer recente PIC's hebben ook clock multipliers.
Geert
Citaat van: conducteur op 02 september 2014, 18:10:13 PM
Als ik het goed voor heb wordt de frequentie intern zelf gedeeld door 4. Wat het nut daarvan is moet je aan de experts hier vragen.
PICs zijn spotgoedkope microcontrollers, de multipliers zijn niet te ver doorgedreven omwille van de prijs. De multipliers zijn in feite PLL's, hoe groter de multiplicatie, des te groter de onstabiliteit. PICs zijn (zeker de 8 bit versies) zijn niet gebouwd om rekenpower te leveren, daarom dat de PLL niet meer dan een factor 4x levert.
Mijn functiedecoder (PIC12F683) werkt aan 8MHz en dat is goed genoeg om DCC correct uit te lezen, maar veel lager met de clock zal ik toch niet moet zakken.
Wil je meer rekenpower, dan moet je eerder bij PIC24/PIC32 gaan zoeken, of bij ARM...
Om echt op safe te spelen, zou ik zeker interrupts gebruiken, dan ben je zeker dat je nooit een puls gaat missen...
Een handje vol 16f886 onderweg... Kan dan alvast beginnen te "testen".
Ondertussen het printje aan het her-tekenen, als ik er zou extra laten maken dat ik plaats heb voor een kristal. Het eerste dat moest verdwijnen om plaats te maken voor het kristal was de dip-switch, met dank aan Geert voor zijn "tip" met de jumper. Nu ben ik aan het uitzoeken of ik de grote darlingtons kan vervangen door iets kleiner, IRLML2030TRPBF doet het blijkbaar ook vrij goed op 5V, tenminste als ik de juiste grafiek heb bekeken. (en kost me nauwelijks per 8 nauwelijks meer dan een ULN, en zou, als ik het mag geloven in zo'n kleine behuizing toch aardig wat stroom kunnen verwerken).
-->waarom plaatst men soms een weerstand voor de gate van de mosfet? Die weerstand intern is toch al héél groot?
Citaat van: conducteur op 05 september 2014, 00:31:27 AM-->waarom plaatst men soms een weerstand voor de gate van de mosfet? Die weerstand intern is toch al héél groot?
Een (mos)fet is iets heel anders dan een (darlinton)transistor.
Fets hebben inderdaad een heel grote ingangsimpedantie
... en precies daarom een extra weerstand (100k of zo) tussen gate en massa
=> om stoorpulsen te onderdrukken en hem niet "toevallig" te laten geleiden ;)
Mosfets hebben een heel kleine weerstand "in geleiding",
en zijn daarom geschikt voor grotere stromen
en/of wanneer je iets "dichtbij de voedingslijn" wil schakelen
Die IRLML2030 heeft als je die met 5V stuurt nog een weerstand van 0.154 Ohm. Dat is niet echt schitterend. Als je daar de 2.2A doorstuurt heb je 0.33V spanningsval, dat is niet veel beter dan een transistor in verzadiging.
Meestal zet men een weerstandje in serie tussen driver en gate maar 100k lijkt me toch wel enorm. Die heeft een ingangscapaciteit van 110 pF die je moet opladen. Als dat te traag gaat komt hij te langzaam in geleiding en dan is de dissipatie hoger. En die sot-23 kan niet veel hebben. Zou eerder 100 Ohm of zoiets zetten.
Een weerstand tussen gate en massa zoals Gerolf zegt kan ook maar dat is dan soms om te vermijden dat de gate (juist omwille van de hoge impedantie) storingen oppikt en zo een beetje in geleiding komt. Zeker als je direct vanuit bvb een cpu stuurt en je zet de uitgang in tri-state (ook hoge impedantie) of als die zo staat bij opstarten zou anders je fet in geleiding kunnen komen. Geloof me, daar kan je lang achter zoeken...
Anders is er de IRLL2703PBF. Die heeft maar de helft van de weerstand en is in een iets grotere behuizing.
Citaat van: Gerolf op 05 september 2014, 01:25:21 AM
Citaat van: conducteur op 05 september 2014, 00:31:27 AM-->waarom plaatst men soms een weerstand voor de gate van de mosfet? Die weerstand intern is toch al héél groot?
Een (mos)fet is iets heel anders dan een (darlinton)transistor.
Fets hebben inderdaad een heel grote ingangsimpedantie
... en precies daarom een extra weerstand (100k of zo) tussen gate en massa
=> om stoorpulsen te onderdrukken en hem niet "toevallig" te laten geleiden ;)
Mosfets hebben een heel kleine weerstand "in geleiding",
en zijn daarom geschikt voor grotere stromen
en/of wanneer je iets "dichtbij de voedingslijn" wil schakelen
Ja, maar ik heb het op een weerstandje, vaak van bv 47R verbonden met de gate... (cfr de basisweerstand bij de transistor)
Johan: IRLML2030TRPBF kost 0,13€, IRLML2030TRPBF 1,7€ (13 keer meer) ::)
100k is tussen gate en massa. Tussen driver(µC-poort dus) en gate gebruik ik voor een mosfet geen weerstand.
smd-mosfets? Die kunnen vaak heel wat aan, en zijn prima betaalbaar (IRLML6244TRPBF kost mij 1.5 voor 10 - of 12 voor 100)
Die IRLML6244 ziet er beter uit. Maar 0.02 Ohm weerstand.
Dank je Gerolf voor de IRLML6244TRPBF-tip, het is zowat zoeken naar een naald in een hooiberg om "de juiste" te vinden... Ondertussen zijn de 16f886 in smd toegekomen...
Hardware klaar (om te testen). Software om eens te proberen is er ook. Hopelijk werken beide van de eerste keer:
Tjah: in Eagle zijn die smd elco's niet zo duidelijk vind ik. Per ongeluk een veel te grote footprint uitgekozen:
(http://www.treinbaanrian.be/images/uplc/decoder1%20(2).JPG)
(http://www.treinbaanrian.be/images/uplc/decoder1%20(1).JPG)
Het lukt alvast om de µC te programmeren met de PICkit 2 via de header. Da's alvast positief. Het is me goed gelukt om dat te solderen.
---> meet slechts 5*5 cm. Iemand die het kleiner kan mag het altijd laten weten ;) Zelf met de kleine 0603 en SOT 23 onderdelen geraak ik er nog niet om het kristal er nog tussen te krijgen en het geheel te routen.
--> 8 Open collector uitgangen. De Darlingtons kunnen tot 4A aan, maar de printbaantjes zijn daar denk ik niet breed genoeg voor, maar kan dus wel wat aan.
---> Aan te sturen om diverse manieren: Serieel, I²C, Parallel (via pin header, geen µc nodig : 8 lijnen, 1 voor elk + GND +5V ), eventueel als uitbreidingsmodule op de grote µPlc module. Ook Digitaal moet mogelijk zijn (DCC/Motorola/...)
--->reset knopje
--->4 bit dip schakelaar voor adres oid...
Morgen test als DCC wisseldecoder :D Hopelijk met glans geslaagd!
Wel Rian, ik heb geen idee wat dat allemaal is (ook al krijg ik cs&n én binnenkort software ontwikkeling), maar ik duim voor je , in de hoop dat het zal werken als dcc wisseldecoder.
Proper printje, Rian.
Geen idee hoe groot je ervaring is in programmatie of microprocessortjes, of in protocols als DCC ...
Ik duim voor een succesvolle testsessie ;)
Rian,
Het ziet er al goed uit!
Citaat van: conducteur op 06 september 2014, 23:56:57 PM
...Morgen test als DCC wisseldecoder...
Code 'gevonden' of eigen ontwerp via bit banging en/of interrupts?
Dit is mijn ontwerp om via DCC wisselspoelen en/of seinen aan te sturen.
De gebruikte methode om adressen in te stellen is dezelfde die ik gebruik om een servo met DCC aan te sturen. Een brugje zetten, dan een wissel of sein aan sturen, brugje weg en minstens 50 jaar zeker dat de schakeling zal blijven reageren op dat adres. Voor het gebruiksgemak zal deze ineens 16 wissels/seinen zijn adressen opeenvolgend opslaan.
Het printje is enkelzijdig en past net op 1/3 van een Euro printformaat. Altijd handig geen afval hebben :D
(https://lh5.googleusercontent.com/-BcTWF7rCjWI/VAwXR8WQjPI/AAAAAAAAAVY/rXu2IAsuD-w/w777-h540-no/schema%2BDCC%2B16%2Bwissels.png)
(https://lh4.googleusercontent.com/-_PeLONMoepE/VAwXPubUqbI/AAAAAAAAAVQ/27uIU6zJEqY/w561-h385-no/printontwerp%2BDCC%2B16%2Bwissels.png)
Geert
Citaat van: PeterC op 07 september 2014, 10:27:30 AM
Rian,
Het ziet er al goed uit!
Citaat van: conducteur op 06 september 2014, 23:56:57 PM
...Morgen test als DCC wisseldecoder...
Code 'gevonden' of eigen ontwerp via bit banging en/of interrupts?
Eigen ontwerp, interrupts/timers moet ik zeker nog eens bestuderen hoe dat moet. Het zou me sterk verwonderen dat mijn veel te eenvoudige delay zal werken 8)
Hi Rian,
Wat betreft je SMD electrolytische condensatoren in Eagle, ik gebruik enkel de modelletjes van Panasonic (PANASONIC_<X> in de CPOL-EU van de rcl library). De uitleg over <X> vindt je in de datasheet, bv. http://industrial.panasonic.com/www-data/pdf/ABA0000/ABA0000PE251.pdf (http://industrial.panasonic.com/www-data/pdf/ABA0000/ABA0000PE251.pdf) (p.173). Als de diameter van een elco van een andere fabrikant overeenkomt met die van Panasonic, werkt 't altijd (bij mij toch).
Ik zie dat je ondertussen al aardig wat opgeschoten bent...
De DIP schakelaar zou ik persoonlijk niet gebruiken om het adres in te stellen. Dat je kan rechstreeks programmeren, door een constante in je software te gebruiken, in de memory map het adres van deze constante opzoeken en dan effe de .hex file editeren. Voor serie werk is de DIP schakelaar natuurlijk wel handig, maar je hebt jezelf wel beperkt tot 16 addressen. Ik zou 'm eerder gebruiken om wat specifieke configuratie in te stellen (bv. wissel die traag of snel moet overgaan oid.)
Op de µC zijde van je print denk ik dat de pinnetjes 2 tem 7 niet goed gesoldeerd zijn...
PIN 2-7 waren op moment van foto nog niet gedaan, maar nu wel ;)
Allez dan, want ik heb het al voorgehad, een paar pinnetjes vergeten en zoeken maar waarom de software niet werkt :-\
Door een of andere reden beetje pech gehad: smd µC in rook opgegaan :(
Tijd voor plan B: op de "µPlC" een DIP 16f887 gestoken en daar begonnen het programma te testen (heb daar meer mogelijkheden om te testen, ook ledjes/knopjes).
Mijn ledje gaat niet uit, dus mijn systeempje om de "1"tjes te tellen is niet goed...
teller=0
led=on
while (teller<10) loop
bitdetect
if dccbit then
teller=teller + 1
else
teller=0
end if
end loop
led=off
"bitdetect": wacht op puls, en zal beslissen of ontvangen bit"1" of "0" is.
procedure bitdetect is
while !dcc loop ; wacht op dcc-puls
end loop
_usec_delay(80) ; wacht (58µs (1) <80µs <100µs (0)
if dcc then ;is puls "0" of "1"
dccbit=false ;ontvangen bit is 0
else
dccbit=true ; ontvangen bit is 1
end if
end procedure
Citaat van: conducteur op 08 september 2014, 20:53:34 PM
Door een of andere reden beetje pech gehad: smd µC in rook opgegaan :(
Maar daarvoor moet je toch al een serieuze hardware fout hebben gemaakt! Die PIC's kunnen tegen serieuze stoten!
...
...Maar troost je, ik heb er ook al opgeblazen 8)
...PIC zegt vaarwel met een serieuze rookpluim... ...stinken... ...vensters open om te verluchten, verbrande elektronica 'stinkt' :) :) :) ;)
Citaat van: PeterC op 08 september 2014, 21:41:44 PM
...Maar troost je, ik heb er ook al opgeblazen 8)
zelfs 220V kan op zulk ingangspinneke, maar dat is wel de limiet, ook zelf ondervonden.
Geert
Rian, moeilijk te zeggen waar het fout loopt. Niet opgeven, kan soms iets zeer stom zijn.
Geert
Citaat van: Geert op 08 september 2014, 21:46:49 PM
zelfs 220V kan op zulk ingangspinneke, maar dat is wel de limiet, ook zelf ondervonden.
Rian, iedereen schiet wel eens een kemel (http://www.vlaamswoordenboek.be/definities/term/kemel,+een+~+schieten). Al draaiend keer je, al doende leer je!
Vallen en direct terug opstaan!
...en toen ging het ledje even uit, maar dat was omdat ik mijn vinger tegen het pootje van het 120K weerstandje had geduwd... Nog steeds op zoek naar wat er fout gaat in dat ogenschijnlijk simpele lusje dat wacht tot 10 opeenvolgende "1"tjes "gezien" zijn...
Citaat van: conducteur op 08 september 2014, 22:52:44 PM
...en toen ging het ledje even uit, maar dat was omdat ik mijn vinger tegen het pootje van het 120K weerstandje had geduwd... Nog steeds op zoek naar wat er fout gaat in dat ogenschijnlijk simpele lusje dat wacht tot 10 opeenvolgende "1"tjes "gezien" zijn...
10 of meer eentjes, ik weet niet welke centrale je gebruikt....
Geert
Multimaus, Geert. Na die 10 is er nog een lusje dat wacht tot er een "0" komt... Daarna komen de "gegevens".
(ik volg toch wat op je site staat : http://users.telenet.be/RedDeBist/MBAAN/Servo_aansturen_digitaal_2.htm#Opbouw DCC (http://users.telenet.be/RedDeBist/MBAAN/Servo_aansturen_digitaal_2.htm#Opbouw%20DCC)signaal om wissels/seinen aan te sturen)
Voorlopig test ik enkel het lusje uit die de 10 opeenvolgende "1"tjes "zoekt".
edit:Voor vandaag stop ik ermee... Al heel de tijd zoeken wat het mogelijk zou kunnen zijn...
Ik denk dat je bitdetect routine niet deugt.
Je wacht 80µs om te beslissen of het 0 of een 1 is; dat is correct. Je beginvoorwaarde is echter niet juist.
while !dcc loop ; wacht op dcc-puls
end loop
Deze kan vertrekken midden in een puls. Je moet een stijgende flank detecteren anders loopt je timing in het honderd. Zonder interrupt kan je best als volgt werken:
while dcc loop ; wacht op einde dcc-puls
end loop
while !dcc loop ; wacht op start dcc-puls
end loop
Volgens mij heb je gelijk, maar het werkt nog steeds niet met de extra while. Verder zoeken naar een oplossing dus.
Ik ken je programmeertaal niet zo goed, maar kan je de bitdetect procedure niet vervangen door een functie (eentje die een waarde teruggeeft)? De functie is iets nauwkeuriger omdat je meteen de juiste waarde (0/1) terugstuurt.
Wat loopt er precies verkeerd? Ik zie aan je code dat je probeert om de DCC preamble (min. 10 1-bitjes) te detecteren. Hoeveel detecteer je er precies?
teller=0
led=on
while (teller<10) loop ;zolang géén 10 opeenvolgende "1"tjes "gezien" dit lusje doorlopen
bitdetect
if dccbit then
teller=teller + 1 ;teller houdt aantal opeenvolgende "1"tjes bij
else
teller=0 ; een 0 ontvangen reset de teller
end if
end loop
led=off
Voor dit lusje gaat het ledje aan (led=on), maar gaat nooit uit net na de while, wat wijst dat de controller voortdurend in dat lusje blijft ronddraaien, en allicht dus niet in slaagt de "1"tjes te detecteren...
Hola ik zie het al...
Zet een breakpoint bij teller=0 en kijk effe wat de waarde van teller is voordat je 'm op 0 zet. Ik denk niet hoger dan één. Die dccbit test mag niet je doen in je while loop, want die IS 0 op dat ogenblik. Een '1' is een korte puls in DCC; dus je code faalt daar. Op het ogenblik dat jij in de while loop dccbit uitleest tijdens een preamble, is die ALTIJD 0 (80µs na de flank, remember?).
Zoals ik gisteren al zei, verander je procedure in een functie en zorg dat de waarde van detectie terugstuurt (0 of 1), en zeker niet opnieuw proberen te lezen zoals je nu doet.
_usec_delay(80) ; wacht (58µs (1) <80µs <100µs (0)
if dcc then ;is puls "0" of "1"
dccbit=false ;ontvangen bit is 0
else
dccbit=true ; ontvangen bit is 1
end if
dccbit wordt toch telkens geset/gereset met 1/0, Waarom mag ik dan niet nagaan in de while of die variabele bit 0/1 is?
oeps mijn fout, dacht dat dccbit de verbinding met de dcc-lijn was. Klopt inderdaad wat je zegt...
Op dit ogenblik kan ik niet veel meer zeggen. Probeer te debuggen door breakpoints op een paar cruciale plaatsen te zetten en zo na te gaan waar het precies misloopt.
En zeker dat het signaal toekomt op 'dcc'?
Deze staat als input?
Geen pull-up nodig?
Probeer eens in een loop de waarde van dcc te kopieren naar een andere pin (output) en meet daar eens met een scoop.
Citaat van: MickeyMouse op 11 september 2014, 20:28:40 PM
En zeker dat het signaal toekomt op 'dcc'?
Deze staat als input?
Geen pull-up nodig?
Probeer eens in een loop de waarde van dcc te kopieren naar een andere pin (output) en meet daar eens met een scoop.
Het DCC signaal komt uit de roco multimaus, met 100K weerstandje in serie om die ingang te beveiligen.
Ja, kan ik eens proberen, als ik dan een signaal zie dan is dat een goed teken... Maandag meenemen naar de treinclub, waar de scoop nu ligt...
Hoe is 'dcc' trouwens gedefinieerd in de software?
alias dcc is pin_d7
pin_d7_direction = input
gewoon als ingang
R van 100k rechstreeks op een PIC ingang. Niks anders er tussen, zet er is een luidspreker op, je hoort DCC!
Geert
Citaat van: Geert op 11 september 2014, 20:41:06 PM
R van 100k rechstreeks op een PIC ingang. Niks anders er tussen, zet er is een luidspreker op, je hoort DCC!
Geert
Inderdaad!
Verlaag de weerstand eens naar 10K. Ik heb al meegemaakt dat op sommige PICs het DCC signaal te zwaar vervormd was met 100K.
En heb je al gedebugged? Kijk na met de debugger of je DCC bitdetect routine wel degelijk 0 én 1 terugstuurt.
Citaat van: Sattrickske op 11 september 2014, 23:06:42 PM
Verlaag de weerstand eens naar 10K. Ik heb al meegemaakt dat op sommige PICs het DCC signaal te zwaar vervormd was met 100K.
En heb je al gedebugged? Kijk na met de debugger of je DCC bitdetect routine wel degelijk 0 én 1 terugstuurt.
Ik dacht dat Rian nu testen uitvoerde met een 16F887, ik detecteer daarop DCC met een R van 200k, weliswaar in ASM, maar dat maakt niets uit...
Geert
Citaat van: Geert op 11 september 2014, 23:13:51 PM
Citaat van: Sattrickske op 11 september 2014, 23:06:42 PM
Verlaag de weerstand eens naar 10K. Ik heb al meegemaakt dat op sommige PICs het DCC signaal te zwaar vervormd was met 100K.
En heb je al gedebugged? Kijk na met de debugger of je DCC bitdetect routine wel degelijk 0 én 1 terugstuurt.
Ik dacht dat Rian nu testen uitvoerde met een 16F887, ik detecteer daarop DCC met een R van 200k, weliswaar in ASM, maar dat maakt niets uit...
Geert
Inderdaad 16f887
Niet opgeven Rian,
Vorig jaar zo is een tijdje bezig geweest om mfx te detecteren...
Het is me nog altijd niet gelukt ;D :o :-\
Geert
Staat niet in het woordenboek, Geert!
Ik weet niet of het iets helpt, maar speel is met de delay waarde. Mogelijk is de C code redelijk traag en ziet hij pas op dcc ingang als de logische '1' puls al voorbij is?
Geert
Naar 70,65 & 60 :geen oplossing.
Neem eens pin poort d0 tot d4 als dcc ingang, deze hebben geen extra functie. Pin d7 wordt ook gebruikt voor PWM uitgang, mogelijk is er een conflikt in de C compiler?
Geert
Nog een mogelijk foutje, ik verwacht nu niet dat Rian deze gaat maken, is dat je massa van de microcontroler verbonden moet zijn met de tweede draad van je digitale dcc voeding. De andere was reeds verbonden via een R aan je DCC pin.
Geert
Nee, dat is het niet... Misschien toch maar eens beginnen expirimenteren met timers / interrupts en uitzoeken hoe dat moet?
Of een andere hobby zoeken, gaan vissen of zoiets :)
Je zult er wel uit komen ;)
Stop, Geert, Stop! ;D Ik heb nu al te veel hobby's! (Piano, Huisomroep Blankenberge vrijwilliger, radio-amateur in spe, modelspoor & elektronica, zee-online.be-reporter, fietsen, ...)
Ik zal wel oplossingen "vissen".
Vandaag de scoop uitgehaald, maar nog niet voldoende kunnen uitzoeken wat er precies fout gaat.
Nu einde eerste week terug school. Dit semester embedded systems: ziet er interessant uit. (ook met FPGA). Zal allesinds helpen voor dit project!
En hoe staat het met dit project?
Geert
Aan het DCC decoderen niet echt veel meer voortgedaan.... Maar dat komt wel nog eens... Wel ondertussen al wat prutsen en experimenten gedaan met een controller op één van de printjes....