valse bezetmeldingen met DDW

[eenop87]

Sinds enkele weken ben ik overgestapt van MRdirect naar DDW in combinatie met Koploper.
Ik gebruik de S88 terugmeldingmodules van Conrad en koppel die met UTP kabels aan elkaar.
Het probleem is dat ik zeer veel valse bezetmeldingen krijg, die ik in combinatie met MRdirect niet had.

Ik heb geexperimenteerd met de Clock Reduction, echter zonder resultaat.
Eerlijk gezegd is mij ook niet duidelijk wat effect van deze Clock Reduction is (help file is daar ook niet duidelijk over).
Ook als ik de treindetectie los koppel van de S88 modules blijven de meldingen komen.

Kennelijk ontstaan er stoorpulsen op de verbingskabels ( de langste is ongeveer 2 meter) die door MRdirect worden genegeerd maar niet door DDW.

Heeft iemand ervaringen met dit probleem in combinatie met DDW en zo ja hoe is dit op te lossen?

m.v.g.
Gerrit

[Wim Ros]

Welke versie van DDW gebruik je? En hoe heb je de s88 aan DDW gekoppeld.
Meestal is dit een probleem met de common-ground aansluiting.

Mvg
Wim.

[eenop87]

Ik gebruik versie 7.9
De S88 modules zijn gekoppeld aan de PC via CD4050 buffers zonder opto couplers en de grounds van alle units zijn doorgekoppeld en aangesloten aan de ground van de LPT1 poort van de PC.

m.v.g.

Gerrit

[Wim Ros]

Ik werk met een directe verbinding zonder buffers en dan werkt het hier probleemloos.
Je gebruikt in ieder geval de juiste versie van DDW.

Mvg
Wim.

[eenop87]

Hoewel ik mij niet kan voorstellen dat de buffers hiervan de oorzaak zijn, zal ik morgen eens proberen om de buffers er tussen uit te laten.
Zou het zinvol zijn om de datalijnen na elke S88 module met een weerstand naar de ground af te sluiten om zo de storingsgevoeligheid te verminderen?

Gerrit

[Wim Ros]

Nee, het werkt gewoon, en gewoon het exacte aantal te scannen modules opgeven. Zal morgen in de loop van de dag nog eens voor je testen, met heeeele lange kabels.

Mvg
Wim.

[eenop87]

Het aantal te scannen modules wordt kennelijk door koploper doorgegeven. Want in het debug scherm van DDW wordt het aantal pas weergegeven als Koploper is gestart. Dat aantal is 4 en klopt ook met het aantal aanwezige modules.

Ik wacht met belangstelling je probeersel met lange kabels af .

In ieder geval vast bedankt voor je inspanning.

m.v.g.

Gerrit

[Wim Ros]

Gerrit, het gelijk maar even aangsloten. De eerste zit met een bandkabel van 3 meter aangesloten, een tweede met een bandkabel van 1 meter een derde met een patch-kable van 1 meter. de vierde eveneens. Het geheel is rotsvast.
refresh 50 clock 35
Mvg
Wim.

[eenop87]

Wim bedankt.

Morgen maar weer eens verder experimenteren.

m.v.g.

Gerrit

[eenop87]

Wim, het werkt !!

Ik heb de instellingen voor refresh en clock ingesteld zoals jij aangaf, en dat blijkt te werken.
Ik heb hem nu een uur draaiend zonder ook maar één valse melding.

Jammer dat van deze kennelijk belangrijke instellingen maar zo weinig in de helpfile staat.

Wim geweldig bedankt 


m.v.g.

Gerrit

[Wim Ros]

Gerrit geen dank. Is een beetje lastig om dit in de handleiding op te nemen denk ik. Het is van veel factoren afhankelijk, dus trail and error is hier de beste oplossing.
Het belangrijkste is dat het nu werkt, en je verder kunt.

Mvg
Wim.

[eenop87]

Ik had met deze instellingen al vele trials gedaan maar leverden steeds errors op 

Maar gelukkig is er altijd nog dit forum 

m.v.g.

Gerrit

[eenop87]

Ter lering ende vermaeck!!

Op 7 september had ik iets te vroeg gejuicht. De spontane valse meldingen  waren wel verdwenen, maar dat was met een statische situatie op de baan, dus zonder rijdende treinen.
Op het debug venster van DDW verschenen inderdaad geen meldingen meer, echter toen ik daarna de treinenloop startte, verschenen ook de valse meldingen met alle rampzalig gevolgen van dien!!

Daarna nog heel wat configuratie-combinaties van refresh en clock uitgetest, zonder resultaat.

Kennelijk had dit probleem niets met timing te maken, maar alles met stoorsignalen op het S88 systeem.

Eerst maar eens extra ontkoppelcondensatoren op de voedingspunten van de S88 units gezet, zonder merkbaar resultaat.

De koppelingen tussen de S88 terugmelders had ik uitgevoerd met RJ45 en utp kabel, echter niet volgens de s88-N norm. Ik had indertijd een kabelindeling gevonden op internet, ik dacht op "Avontuur in Miniatuur". Ik meen zelfs dat de s88-N norm later is ontstaan, maar zag wel dat dit een betere indeling was in verband met adertwisting met de ground.
Maar om nu alle S88 units te voorzien van nieuwe verloopprintjes ging mij even te ver.

Om storing op de kabels te vermijden besloot ik om de UTP kabeltjes door metalen pijp te laten lopen en de pijp met de ground van de S88 units te verbinden. Toevallig had ik nog een partijtje oude stalen electrapijp liggen waar de RJ45 plugjes precies doorheen gingen.
De valse bezetmeldingen waren inderdaad flink afgenomen, echter nog onvoldoende voor een veilige treinenloop, ik was dus op de goede weg.

Uiteindelijk besloten toch maar nieuwe printjes te ontwerpen en te etsen zodat de bedrading voldeed aan de s88-N norm. Zo gezegd zo gedaan: oude printjes er afgesloopt en de nieuwe gemonteerd. Voor alle zekerheid achter de S88 terugmelders extra afschermplaatjes gemonteerd om de achterliggende bedrading af te schermen (ik was nu toch bezig).

De boel weer aangesloten en getest: En ja hoor eindelijk zonder valse meldingen. 

De metalen pijpjes zijn misschien niet meer nodig, maar baat het niet, het schaadt ook niet.

Ik heb nu alleen nog een probleem met het programma RAILYPROG. Als ik dat programma gebruik krijg ik met geen mogelijkheid signaal op de compoort. Het programma draait kennelijk alleen met het SRCP 0.73 protocol. De communicatie met de DDW server lijkt goed te verlopen, maar output ho maar. Misschien heeft iemand hier ervaring mee. In de documentatie kan ik hier niets over ontdekken hoewel ik moet toegeven dat mijn Duits te wensen overlaat.


Groet
Gerrit

[Wim Ros]

Nou het zal wel, weet alleen dat het hier storingvrij werkt met de normale standaard bandkabels en dat de langste tussen de s88 modules (zelfbouw) 3 meter is.

Mvg
Wim.