Arduino --> Nokia 5110 display aansturing problemen (?)

[ehtweak]

Wat info vooraf:
Ja, ik knutsel al veel langer met elektronica.
Nee, dit is niet m'n eerste Arduino knutselproject.
Ja, ik weet dat er veel spreiding is in de eigenschappen van die (veel hergebruikte) Nokia displays.
De vraag is alleen echter, zou een nieuw/ander display soelaas bieden (duurt wel weer een paar weken voordat het binnen is). Of kan het iets anders zijn, waar ik nu wat aan kan doen, zonder nieuwe parts te hoeven bestellen?

Begonnen met een compleet verse setup. Op basis van dat project van vorig jaar. Maar met een veel krachtigere stappenmotor en een veel grotere rail constructie.

Het 'probleem':
Nokia 5110 display wordt aangestuurd vanuit een Arduino.
afkomstig van dit project: http://pulsar124.wikia.com/wiki/Fast_Stacker
Nu heb ik vorig jaar eenzelfde soort setup gemaakt en toen moest ik ook wat fröbelen om het LCD correct en contrastrijk aan te sturen. Maar die tips stonden alhier: http://pulsar124.wikia.com/wiki/Troubleshooting#LCD_issues
Schema: https://farm9.staticflick...09756585_494d5d592e_o.png

Nu werkt dit echter niet goed. Of liever gezegd, da's nou juist het rare, af en toe wel, af en toe niet.
Ik voorzie het geheel van power, het display licht op met de juiste tekstuele informatie, en een paar seconden later (als de Arduino s/w compleet geïnitialiseerd is), scrambled de tekst weer op het display, of niet. Of het tekstblok wordt één donker geheel. Of niet Soms blijft het ook goed werken. Waarom wel/waarom niet?

Wat ik al geprobeerd heb:

• RC circuit wat aan de RST pin van de Nokia module hangt, aangepast. de 100nF condensator verdubbelt in capaciteit. Zelfs een 10uF elco er over heen gezet; geen succes.
• Extra 10uF elco tussen Vcc en GND van de Nokia; geen succes
• Extra 10uF elco tussen LED en GND van de Nokia; geen succes.
• SPI frequency in stacker.ino module aangepast "SPI.setClockDivider(SPI_CLOCK_DIV16);" (zowel DIV16 als DIV8 geprobeerd; geen succes.
• Software SPI gebruikt ipv hardware SPI; dat was in ieder geval nodig, anders kreeg ik helemaal geen beeld.
• Al dan niet background LED aansturing achterwege gelaten (LED op Nokia module); maakt geen verschil
• Getest met verschillende contrastinstellingen "command(PCD8544_VOP | 0x47);" in pcd8544.cpp library; dit heeft wel effect op het contrast, maar lost niet het genoemde probleem op.

Iemand een idee of door s/w en/of h/w aanpassingen dit te verhelpen is? En/of ervaring met dit issue?
Of dat ik toch een andere Nokia 5110 zal moeten bestellen?

Veelal kost het me een aantal power on cyclussen om beeld te krijgen en te behouden op het display. M.a.w. je zou denken dat het toch iets met de RST initialisatie heeft te maken. Maar wat doe ik dan fout?

[ Voor 11% gewijzigd door ehtweak op 01-12-2016 13:07 ]

[NeOTheMaTriXM]

Heb zelf geen Nokia display bij de hand, maar in de tutorial van Adafruit maken ze gebruik van een level shifter zodat de Uno 5V data omgezet wordt naar 3.3V , in je schema kom ik deze niet tegen.

Tutorial van Adafruit: https://learn.adafruit.co...0-monochrome-lcd?view=all

Moet zeggen dat ik wel een ongelofelijke Arduino/Electro noob ben, en een grote kans dat dit niet de oplossing is

[ehtweak]

NeOTheMaTriXM schreef op donderdag 1 december 2016 @ 14:51:
...

... en een grote kans dat dit niet de oplossing is

Idd. Daar heeft 't niks mee te maken.

Blijkbaar zijn die gerecyclede Nokia schermpjes niet allemaal gelijk c.q. even betrouwbaar.
Dit exemplaar doet het af en toe wel, af en toe niet, heb ik gemerkt.
Gevoed via USB van de Arduino (als je nieuwe s/w in de Arduino laadt) gaat het vrijwel continu fout.
Wanneer het hele project gevoed wordt via een stabiele vaste voeding, geeft 'ie meestal wel beeld. Maar soms valt 'ie weg (terwijl de background keurig blijft branden).


MacroRailProj2-Casing2 by Erik Haak, on Flickr
En het ziet er juist zo strak uit, keurig in de frontplaat van de stuurunit.

Toch maar een vers exemplaar van zo'n Nokia display besteld. Nu weer een aantal weken geduld, voordat het binnen is...

Jammer dat er geen ervaringsberichten alhier te bespeuren zijn voor deze combinatie (Nokia 5110 + Arduino).

[ Voor 15% gewijzigd door ehtweak op 12-12-2016 09:11 ]

[Boudemaniak]

NeOTheMaTriXM schreef op donderdag 1 december 2016 @ 14:51:
Heb zelf geen Nokia display bij de hand, maar in de tutorial van Adafruit maken ze gebruik van een level shifter zodat de Uno 5V data omgezet wordt naar 3.3V , in je schema kom ik deze niet tegen.

Tutorial van Adafruit: https://learn.adafruit.co...0-monochrome-lcd?view=all

Moet zeggen dat ik wel een ongelofelijke Arduino/Electro noob ben, en een grote kans dat dit niet de oplossing is

ehtweak schreef op maandag 12 december 2016 @ 09:09:
[...]

Idd. Daar heeft 't niks mee te maken.

Nou... daar heeft hij wel een punt. Nu zal het misschien niet de interferentie veroorzaken, maar je beschadigt wel degelijk je scherm. Kan best dat de core van het display hierdoor ook kapot gaat.


Je hebt gelukkig wel een 10k weerstand, maar je hebt nu eigenlijk een 5V pad gemaakt naar de 3V3 met 10k en een diode. Ik heb met andere projecten hier vaker last van gehad (en zelfs chips kapot gekregen).

[Boudemaniak]

Nog een extra dingetje:

ehtweak schreef op donderdag 1 december 2016 @ 12:59:

• Extra 10uF elco tussen LED en GND van de Nokia; geen succes.

Je voedt een backlight vanuit een microcontrollerpin? Nu kan ik nergens de backlight spec. vinden, maar ik zie meestal 4 LEDs, dus dat zal wel meer dan 20mA moeten zijn. Niet slim!

Ik ga ervan uit dat je de SPI lijnen op het breadboard goed hebt gescheiden van je motor?

[ehtweak]

Nu snap ik 'm ff niet (meer)...

Veel voorbeeldschema's knopen de Arduino outputs via een weerstandje aan de inputs van de Nokia.
In het bovenstaande voorbeeld wordt daarentegen weer een 4050 gebruikt als level shifter.

Maar als ik de datasheet bekijk, dan zouden alle input voltages (V_i) tussen -0,5V en V_dd +0,5V mogen liggen.
https://www.sparkfun.com/.../Monochrome/Nokia5110.pdf
M.a.w. de inputs van de Nokia via een 10K R aan de outputs van een Arduino (die met 5V gevoed wordt) zou gewoon ok zijn. Toch?

BTW: ik heb vorig jaar een soortgelijk project gedaan (zelfde s/w + h/w setup, maar andere motor/mechanische constructie) en die werkt nu al een jaar gewoon goed.

[ehtweak]

Boudemaniak schreef op maandag 12 december 2016 @ 09:54:
Nog een extra dingetje:


[...]

Je voedt een backlight vanuit een microcontrollerpin? Nu kan ik nergens de backlight spec. vinden, maar ik zie meestal 4 LEDs, dus dat zal wel meer dan 20mA moeten zijn. Niet slim!

Ik ga ervan uit dat je de SPI lijnen op het breadboard goed hebt gescheiden van je motor?

Backlight wordt apart aangestuurd idd met een serieweerstand van 330ohm en een 10uF tantaaltje.
Volgens dit:
https://learn.sparkfun.co.../graphic-lcd-hookup-guide
zou dat ook moeten werken.

Zoals ik al eerder zei, er zijn met deze setup al diverse projecten gemaakt. Maar blijkbaar zijn die Nokia
displays wat 'lastig'.

De motor wordt geheel apart gestuurd door een Big Easy Driver. De output pinnen van de Arduino zitten rechtstreeks via een 3 aderig kabeltje aan de inputs van Big Easy Driver. (Step, Dir, Enable)
En de GND en M+ van de Big Easy Driver zitten aan een aparte, zwaardere voeding, die voor de stappen motor power zorgt.
Of bedoel je wat anders?

[ Voor 11% gewijzigd door ehtweak op 12-12-2016 10:14 ]

[Boudemaniak]

ehtweak schreef op maandag 12 december 2016 @ 09:55:
Nu snap ik 'm ff niet (meer)...

Veel voorbeeldschema's knopen de Arduino outputs via een weerstandje aan de inputs van de Nokia.
In het bovenstaande voorbeeld wordt daarentegen weer een 4050 gebruikt als level shifter.

Maar als ik de datasheet bekijk, dan zouden alle input voltages (V_i) tussen -0,5V en V_dd +0,5V mogen liggen.
https://www.sparkfun.com/.../Monochrome/Nokia5110.pdf
M.a.w. de inputs van de Nokia via een 10K R aan de outputs van een Arduino (die met 5V gevoed wordt) zou gewoon ok zijn. Toch?

Input voltage is max 3.3V. Tel daar 0.5V bij op en je zit op 3.8V toch? Jij geeft als "hoog" signaal 5V. Omdat je stroom limiteert met een weerstand zal het niet zo snel kapot gaan als de interne diodes er ook daadwerkelijk inzitten. Maar dan heb je 3.3V + 0.7V = 4V. Dat is nog steeds teveel.

Ik zeg niet dat het meteen kapot gaat, maar ik kan wel garanderen dat de levensduur achteruit gaat en de performance negatief beïnvloed wordt. Ik zal je het hoe en waarom besparen.

ehtweak schreef op maandag 12 december 2016 @ 10:05:
[...]

Backlight wordt apart aangestuurd idd met een serieweerstand van 330ohm en een 10uF tantaaltje.
Volgens dit:
https://learn.sparkfun.co.../graphic-lcd-hookup-guide
zou dat ook moeten werken.

Want alles op internet is waar . Ik vind het alleen vreemd dat ze de arduino pin gebruiken om zo veel stroom te sourcen. Zo zou ik het nooit gedaan hebben.

Trouwens, ook hier waarschuwen ze voor de spanningsniveau's: This setup can work for 5V Arduino’s, ignoring the 3.6V limit on the VCC and data lines. We’ve done this. It works. But it may decrease your LCD’s life.

ehtweak schreef op maandag 12 december 2016 @ 10:05:
De motor wordt geheel apart gestuurd door een Big Easy Driver. De output pinnen van de Arduino zitten rechtstreeks via een 3 aderig kabeltje aan de inputs van Big Easy Driver. (Step, Dir, Enable)
En de GND en M+ van de Big Easy Driver zitten aan een aparte, zwaardere voeding, die voor de stappen motor power zorgt.
Of bedoel je wat anders?

Ik bedoel niet meer dan een fysieke afstand tussen je SPI lijnen en de A1,A2,B1,B2 lijnen van de motor. Die veroorzaken nogal wat storing.

ehtweak schreef op maandag 12 december 2016 @ 10:05:
Zoals ik al eerder zei, er zijn met deze setup al diverse projecten gemaakt. Maar blijkbaar zijn die Nokia
displays wat 'lastig'.

Dit scherm is niet 'lastig'. Maar door het op een eenvoudige en goedkope manier aan te sluiten maak je het lastig.

[ehtweak]

Boudemaniak schreef op maandag 12 december 2016 @ 10:32:
[...]


Input voltage is max 3.3V. Tel daar 0.5V bij op en je zit op 3.8V toch? Jij geeft als "hoog" signaal 5V. Omdat je stroom limiteert met een weerstand zal het niet zo snel kapot gaan als de interne diodes er ook daadwerkelijk inzitten. Maar dan heb je 3.3V + 0.7V = 4V. Dat is nog steeds teveel.

Ik zeg niet dat het meteen kapot gaat, maar ik kan wel garanderen dat de levensduur achteruit gaat en de performance negatief beïnvloed wordt. Ik zal je het hoe en waarom besparen.

Ok, duidelijk. Maar die Nokia displays (voor zover ik heb begrepen) zijn toch allemaal al 'oud'? Allemaal hergebruikte units? M.a.w. zou ik er eentje getroffen hebben die al bijna EOL is?

Lastige is, is dat dit hele project alweer ingebouwd zit. En compleet veranderen, nieuwe driver chips er tussen plakken is heel erg lastig. Nog los van het feit dat ik die niet in huis heb.
Blijft apart dat deze setup dan al diverse malen gebouwd is (door diverse mensen over de hele wereld) en dat dit specifieke issue nog niet aan de orde gekomen is; dat rechtstreekse aansturen van het Nokia display i.p.v. met een level shifter ertussen.

Boudemaniak schreef op maandag 12 december 2016 @ 10:32:
Want alles op internet is waar . Ik vind het alleen vreemd dat ze de arduino pin gebruiken om zo veel stroom te sourcen. Zo zou ik het nooit gedaan hebben.

Haha, maar datzelfde geldt natuurlijk voor jouw tekst...

Boudemaniak schreef op maandag 12 december 2016 @ 10:32:
Ik bedoel niet meer dan een fysieke afstand tussen je SPI lijnen en de A1,A2,B1,B2 lijnen van de motor. Die veroorzaken nogal wat storing.

Begrijp ik hieruit dat zelfs twee flatcables die vlak langs elkaar liggen, in de behuizing, al problemen zouden kunnen veroorzaken? Dus zoals hier te zien:

Hier zie je grondplaat, met daarop de Big Easy Driver (linksboven), de Arduino (rechtsboven), voedingsprintje (linksonder) en een experimenteerprint waarop de nodige flatcables zijn doorverbonden (+ serieweerstandjes e.d. voor het display).
De ene flatcable gaat naar het display, de andere naar het 4x4 matrix keyboard.
De zwarte sleevecable gaat van de output van de Big Easy Driver naar de DB-9 connector (doorverbinding naar motor/rail unit). Dit zijn wat dikkere draden i.v.m. forsere stromen (Big Easy Driver is afgeregeld op 1,75A)

Boudemaniak schreef op maandag 12 december 2016 @ 10:32:
Dit scherm is niet 'lastig'. Maar door het op een eenvoudige en goedkope manier aan te sluiten maak je het lastig.

Tja, ik kan ook een industriële PLC gestuurde custom oplossing kopen met big touchscreen OLEDs en dat gebruiken... Het gaat er nu juist om, om met beperkte middelen dit aan de praat te krijgen.

BTW: op dit moment ben ik aan het worstelen met de software. Want diverse parameters moeten voor deze specifieke uitvoering van het project weer totaal anders. Zo is de rail afstand per omwenteling veel groter. En de berekening in de routines gaat ergens de mist in. Ook de detectie van de microswitches (eindstops) gaat niet goed.
Was al lang blij dat de mechanische uitvoering goed werkt. Want een forse Durst vergroterrail voorzien van een stappenmotor aansturing was nog een hele uitzoekklus en veel geknutsel.

Al met al, dit houd je van de straat!

[ehtweak]

Boudemaniak schreef op maandag 12 december 2016 @ 10:32:
[...]

Ik bedoel niet meer dan een fysieke afstand tussen je SPI lijnen en de A1,A2,B1,B2 lijnen van de motor. Die veroorzaken nogal wat storing.

Bedankt voor die hint!

Ik heb contact gehad met de oorspronkelijk maker/bedenker van dit project en die kon zich ook herinneren dat hij soms 'vreemde' dingen had met zíjn setup.

Ook in mijn geval, naast het display probleem, had ik ook onverklaarbare detectie van de microswitches, terwijl die niet eens geactiveerd werden.

Ik heb uiteindelijk een ferrietkraal rond de signaaldraden naar de microswitches gezet. Of liever gezegd, die dradenstreng 2 wikkelingen rond een ferrietkraal gedraaid.
Ook de 4-draads verbinding naar de stappen motor voorzien van een ferrietkraal.

En, waarempel; het rail calibration proces loopt nu goed, zonder vreemde valse detecties van de microswitches. En ook het display blijft nu een stuk stabieler beeld geven.

Blijkbaar zijn idd de spikes die de motoraansturing veroorzaakt nogal storend op de rest van de signalen.
Is er wellicht een manier om dat anders/beter aan te pakken? (zonder al te ingewikkeld te doen c.q. hoge kosten te maken?)

Want nu zit er nog een paar centimeter verbindingskabel, gedurende de testfase, tussen motorunit en de stuurunit. Maar zometeen komt daar een langere kabel tussen. Valt er nog iets extra's te doen qua ontstoren? Iets van wat extra C-tjes op de signaalleidingen (t.o.v. massa) o.i.d?

[Boudemaniak]

ehtweak schreef op maandag 12 december 2016 @ 22:52:
Bedankt voor die hint!

[...]

Blijkbaar zijn idd de spikes die de motoraansturing veroorzaakt nogal storend op de rest van de signalen.
Is er wellicht een manier om dat anders/beter aan te pakken? (zonder al te ingewikkeld te doen c.q. hoge kosten te maken?)

Want nu zit er nog een paar centimeter verbindingskabel, gedurende de testfase, tussen motorunit en de stuurunit. Maar zometeen komt daar een langere kabel tussen. Valt er nog iets extra's te doen qua ontstoren? Iets van wat extra C-tjes op de signaalleidingen (t.o.v. massa) o.i.d?

Mooi dat het gelukt is.

Voor de rest kan ik eigenlijk niet echt een zinnig antwoord geven zonder te meten. Als je capaciteit op je signalen zet en je klokt met een hoge snelheid dan gaat niets het meer doen.

Wellicht is shielden een idee? Vergeet niet twee punten aan GND te knopen, anders heb je alleen een shield voor je E-veld en niet je M-veld (of andersom).

[ehtweak]

Hmmm idd, extra capaciteit op hoogfrequent signalen dempt de boel. Dat zal 'm niet worden.

Shielding? Tja, dat wordt heel lastig. De hele behuizing van beide units is weliswaar metaal en ligt aan GND. Maar de signaalvoerende bedrading zit natuurlijk allemaal binnenin die behuizing. Het is immers geen RF uitgekiend ontwerp. Zoals met high frequency radiogebeuren vaak wel het geval is.

En de verbindingskabel tussen motor- en stuurunit is een UTP kabel, gesoldeerd aan DB-9 connectors.
Waarbij alle signaal voerende leidingen braaf naast elkaar lopen (weliswaar getwist, maar toch)

De originele auteur van dit project gaf trouwens ook aan dat met de ene UTP kabel hij wel 'rare' dingen meemaakte en met een andere UTP kabel niet (niet eens zozeer een langere/kortere kabel, maar wel een ander merk). Bovendien gebruikte hij zelfs RJ-45 connectors, maar dat vind ik zelf te link; je moet het niet kunnen/willen verwarren met een echte Ethernet aansluiting. Bovendien kunnen DB-9 connectoren wat meer stroomsterkte per pincontact aan, dan een RJ-45 connector. Dit i.v.m. de redelijk hoge stromen voor de stappen motor aansturing.

Eigenlijk nooit van tevoren beseft dat dit soort stappen motor sturing zo'n storingsbron zou (kunnen) zijn en dat er meerdere signaalleidingen lopen die daarvoor gevoelig zijn.

Ik zal proberen of ik binnenin de stuurunit ook nog wat ferrietkraaltjes rond de stappen motor aansluitdraden en limit (microswitch) draad kan krijgen.

[joram.agten]

Ik zou in je behuizing ook een paar spullen van plaats wisselen (als dat nog kan).
Als je de big-easy driver en de experimenteer print verwisselt, dan liggen de stuurlijnen met veel stroom al verder van je gevoelige lijnen voor je display. Ook je power switch (veronderstel ik, die andere zwart gesleevde kabel naar je voedingsprint) zou beter aan de rand van je kast staan ipv in het midden, dan kruisen die draden ook niet.
Probeer op je experimenteer print ook de verschillende delen wat uit elkaar te zetten (kan niet goed zien of dat al het geval is).

Voor de level conversie tussen 5V en 3V3 zou je ook een ic kunnen gebruiken TXB0108.
http://www.ti.com/product/TXB0108
Probeer je gevoelige bedrading zo kort mogelijk te houden en ver weg van alle switchers (voeding, kabels die veel veranderlijke stromen hebben, ...)
Bovendien probeer je je stroomvoerende kabels ook zo kort mogelijk te houden.
Voedingskabels twisten (GND, VCC)

trouwens, op deze foto kruist alles al wat minder : https://www.flickr.com/photos/chasa-imago/30597163674/

Als ik het goed begrijp dan heb je een db-9 connector waar je de stappenmotoren hun signalen doorstuurt en ook de signalen van de limit switches. Hierop heb je dan een twisted pair kabel gesoldeerd.
Als je genoeg aders hebt, kan je per limit switch een twist gebruiken (de beide aders van de twist krijgen dan bijna dezelfde noise) en die aan een optocoupler hangen. De uitgang van de optocoupler hang je dan aan je arduino.
Aan de ingang van de optocoupler kan je dan eventueel nog een r-c filter zetten om wat bounce op te vangen en wat noise te onderdrukken.

[ehtweak]

Tja, het kan altijd beter/netter/doordachter.
En idd, voedingskabels zouden een kortere routering kunnen volgen. Maar ja, je begint op een gegeven moment ergens. Dit is eigenlijk gebouwd terwijl het project onderweg was. M.a.w. veel improvisatie.
Uiteraard ben ik blij met alle technische tips. Van dit soort projecten steek je enorm veel op.

Maar helaas, ook al heb ik de behuizing ruim opgezet, nu nog de layout omgooien, betekent alles eigenlijk opnieuw doen. En het voorgaande knutselwerk (solderen, zagen, boren, frezen, passen, meten) heeft al dagen gekost.

Zoals het nu werkt, werkt het eigenlijk goed. En de grondplaat is op maat geboord/gezaagd met de diverse printjes erop. Was al lang blij, dat na alles opbouwen, het functioneerde, en ik geen rookwolken kreeg... Vervolgens gooiden 'vage' storingen wat roet in het knutselplezier, maar ook daar zijn vrijwel altijd oplossingen voor.

Het kan altijd nog erger; zo ziet het er bij de oorspronkelijke bedenker uit:
https://farm9.staticflick...00856012_8596781de4_o.jpg
Die heeft letterlijk alles op elkaar gepropt.

En ja, het kan altijd luxer, uitgebreider. Maar ik wilde juist met zoveel mogelijk voorhanden materialen dit bouwen. En dat is tot nu toe aardig gelukt. De behuizing en de stappenmotor waren het eigenlijk het duurste onderdeel (bij elkaar 3 tientjes).
Nog meer IC's, optocouplers, nog meer uitzoekerij en afhankelijkheden; dat zat er ff nog niet in. Al met al is het een behoorlijk (voor mijn doen) gecompliceerd mechanisch/elektronisch DIY project. Behalve een schema van de oorspronkelijk auteur en zijn beschrijvingen, moest ik voor de rest alles zelf uitdokteren. Tot nu toe, redelijk gelukt.
De limitswitches staan trouwens in serie; het is slechts één verbreekcontact detectie. M.a.w. 1 signaal t.o.v. GND wat verbreekt.
Allemaal met doel zo meteen focus stacking geautomatiseerd te laten verlopen d.m.v. een DSLR gemonteerd op een gerecycleerde Durst vergrotingsstandaard.

[ Voor 12% gewijzigd door ehtweak op 13-12-2016 15:43 ]

[joram.agten]

@ehtweak
ik begrijp volkomen dat je niet meer alles kan aanpassen. Je zou nog wel kunnen proberen die lange kabels een andere weg te laten volgen (die van de steppers achter je voeding door) als je de behuizing toedoet en je voedingskabels te twisten.
Ook de voeding voor de easy drive en de arduino zijn gekruist, als dat dezelfde spanningen zijn kan je die eventueel ook omwisselen.
Er loopt ook nog een bruine draad van je voeding naar je DB9 connector, die zou misschien ook een beetje rondgeleid kunnen worden. En als daar nog een massa draad bijhoort ?, die dan twisten.

Ik zou het gewoon jammer vinden dat het na een poosje weer kuren begint te vertonen. Nu zit alles nog fris in je geheugen. (bij mij althans is het zo dat het na een poos meer moeite kost om terug fouten uit te gaan zoeken)

Ik ben stiekem wel jaloers op je mooie behuizing, daar steekt zeker heel wat werk in!

[ehtweak]

Helaas, de voedingskabels voor de Arduino (die hangt aan een gestabiliseerde 5V) en de Big Easy Driver (die heeft ca. 18V) zijn apart.

De behuizing ben ik idd wel blij mee. Is goed gelukt, al zeg ik het zelf.

In het oorspronkelijke ontwerp is er eigenlijk nooit nagedacht over een veel krachtigere stappenmotor, en als gevolg daarvan, de hogere stuurstromen en de daaruit voortvloeiende (blijkbaar?) stoorsignalen.
Ik heb zelf het oorspronkelijke design 'opgewaardeerd', zowel elektrisch als mechanisch.
En ja, dan loop je uiteraard tegen bepaalde problemen aan. Die, voor het zich nu laat aanzien, grotendeels opgelost zijn.

Uiteindelijk, alles is nu dichtgeschroefd, heb ik de volgende zaken toegepast om de storingsgevoeligheid te verminderen:

• Dradenparen van de motoraansturing zoveel mogelijk getwist (A+/A- en B-/B+).
• Signaalleiding van de eind(micro)switches getwist met z'n GND leiding + ferriet kraaltje eromheen.
• [url=https://flic.kr/p/NZPShd][img=240,159]https://c5.staticflickr.com/1/28/30846791004_4a79b30413_m.jpg[/img][/url]
• Klein 100nF keramisch Ctje over bovengenoemde signaalleiding gesoldeerd richting GND.
• Nieuwe verbindingskabel van massief CAT5 gemaakt (met DB-9 connectoren aan beide zijden). Gezorgd dat de motorstuurleidingen in ieder geval over getwiste paren lopen.
• Extra 100uF elco over de M+/GND voeding van de Big Easy Driver.
• De motoraansturing leidingen zowel binnen de motorunit alsmede de stuurunit, getwist en voorzien van een ferriet kraal.

Tot nu toe werkt alles, zelfs met de langere verbindings (UTP CAT-5) kabel tussen motorunit en stuurunit.
Heel af en toe wilt het beeld op het display niet opkomen (terwijl voor de rest wel alles werkt).
Misschien toch een 'gammel' 5110 exemplaar? (nieuwe is besteld, maar dat duurt altijd een paar weekjes via eBay). Of (te) kritisch RC reset circuit?

Iedereen bedankt voor het meedenken!

T.z.t. zal ik een apart topic maken van het voltooide exemplaar.
Nu moet ik eerst m'n bureau weer opruimen en alle soldeerklodders die in de rondte vlogen, wegschrapen.