BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: rjr op 28 March 2009, 20:05:48
-
Hoi,
Ik gebruikte het roco systeem met de Xpressnetli interface met "oude" Viessmann S88 terugmeld systemen, maar had resent de BMD16N en BMD16N-SD besteld, en deze vandaag eens onder de baan gebouwd, en nu werkt het dus niet meer, dus wat aan het testen gegaan opzoek naar het probleem, en iets gevonden wat ik niet kan verklaren. Heb verschillende netwerkkabels liggen, van 0.5m, 1m, 2m, 3m, 5m.
De opstelling was:
xpressnetli --> netwerkkabel 3 m --> BMD16N --> netwerkkabel 2m --> BMD16N-SD.
Dit werkte niet goed: terugmeldpunt 2 kwam als 1 terug in koploper, terugmeld punt 1 gaf alle 16 terug. de rest gaf niets terug.
Dit terug melden ging niet altijd direct, soms duurde het wel 1 minut voor het terug kwam in koploper.
toen ben ik gaan testen, de BMD16N weer helemaal los gehaalt, en getest via een los draadje die ik op de verschillende punten hierl met volgende resultaten:
xpressnetli --> netwerkkabel 0.5m --> BMD16N dit werkt
xpressnetli --> netwerkkabel 3 m --> BMD16N dit werkt.
Xpressnetli --> netwerkkabel 3 m --> BMD16N --> netwerkkabel 0.5m --> S88N adapter --> viessmann S88 dit werkt
Xpressnetli --> netwerkkabel 3 m --> BMD16N --> netwerkkabel 1 m --> S88N adapter --> viessmann S88 dit werkt
Xpressnetli --> netwerkkabel 3 m --> BMD16N --> netwerkkabel 2 m --> S88N adapter --> viessmann S88 dit werkt helemaal NIET!!!, niets komt terug.
Vervolgens Xpressnetli --> netwerkkabel 2m (zelfde als hierboven ) --> S88N adapter --> viessmann S88 dit werkt.
Ook bovenstaande getest via de S88N adapter op de xpressnetli, dus
Xpressnetli --> S88N adapter --> netwerkkabel 3 m --> .... Dit gaf hetzelfde resultaat.
Hieruit concludeer ik:
De BMD16N werkt goed.
De viessmann S88 werkt goed.
Gezamelijk werken ze goed zolang de afstand tussen de twee maar kort is.
De netwerk kabel van 2 meter werkt ook goed.
Alleen als ik die dus tussen de BDM16N en de viessmann S88 zet gaat het fout, en dan doet de BMD16N dus ook niets meer. Vervang ik hem voor een kortere kabel werkt het wel.
Heb 2 kabels van 2 meter gebruik, ook getest met een kabel van 5 meter, resultaat is zelfde.
(De BMD16N-SD heb ik verder even buiten de testen gehouden omdat die wat verder van mijn testopstelling af lag, die kon ik niet via een korte kabel aansluiten)
Iemand een idee waar hem dit in kan zitten? Was juist naar de S88N gegaan om probleemloos met langere kabels te kunnen gaan werken, en nu lijken lange kabels juist extra problemen te geven.
Groet,
Roelco
-
Nadat het leek dat ik wat resultaten geboekt had en weer wat meer aan wilde sluiten waren de resultaten toch weer zelfde. Dus nog verder teruggegaan.
Op dit moment heb ik het volgende:
S88Xpressnetli --> netwerkkabel 5 m --> S88N adapter --> S88 viessmann.
0f
S88Xpressnetli --> s88N adapter --> netwerkkabel 5m --> S88N adapter --> S88 viessmann.
Heb de punten nagemeten, en 5V heb ik op de print als 4.96, data, clock, gnd, load en reset zijn correct verbonden.
maar als ik met een kort draadje uitgang 1 van de S88 viessmann verbind met de massa krijg ik bijna alle contacten terug:
65 5- 6- 7- 8x
65 1- 2x 3- 4-
65 1- 2x 3x 4-
65 1- 2x 3x 4x
66 5x 6- 7- 8-
66 5x 6x 7- 8-
66 5x 6x 7x 8-
66 5x 6x 7x 8x
66 1x 2- 3- 4-
66 1x 2x 3- 4-
66 1x 2x 3x 4-
66 1x 2x 3x 4x
66 5x 6- 7- 8x
66 5x 6x 7- 8x
66 5x 6x 7x 8x
65 1- 2- 3x 4x
65 1- 2- 3- 4x
65 1- 2- 3- 4-
65 5- 6x 7x 8x
65 5- 6- 7x 8x
65 5- 6- 7- 8x
65 5- 6- 7- 8-
66 1- 2x 3x 4x
66 1- 2- 3x 4x
66 1- 2- 3- 4x
66 1- 2- 3- 4-
66 5- 6x 7x 8x
66 5- 6- 7x 8x
66 5- 6- 7- 8x
66 5- 6- 7- 8-
Verbind ik ingang 2 met massa dan krijg ik terug dat ingang 1 bezet is.
65 1x 2- 3- 4-
65 1- 2- 3- 4-
de rest van de ingangen kan ik rustig verbinden, geeft geen resultaat.
Doe ik precies het zelfde maar dan met een kabel van 1, 2 of 3 meter dan krijg ik gewoon dat wat ik verwacht en komen alle punten netjes terug.
Blijkbaar heeft de XpressnetLi problemen om de signalen goed binnen te krijgen als ik kabels langer dan 5 meter gebruik ( Bij mijn vorig post begonnen de problemen ook als de beide kabels meer dan 5 meter werden )
Iemand een idee waar dit aan zou kunnen liggen?
de S88XpressnetLi heb ik direct achter in mijn laptop zitten. Systeem is een Dell laptop met Windows XP.
Groet,
Roelco
-
Roelco, ik kan het verhaal niet helemaal volgen. Ik krijg de indruk dat het probleem speelt bij gebruik van 'n 5m kabel. Heb je ook met een andere 5m kabel getest, het zou kunnen dat die ene 5m kabel niet goed is.
Sander
-
hoi!
Ik kan je wel de tip geven om de kabels zo kort mogelijk te houden. dat is altijd beter
-
Roelco, ik kan het verhaal niet helemaal volgen. Ik krijg de indruk dat het probleem speelt bij gebruik van 'n 5m kabel. Heb je ook met een andere 5m kabel getest, het zou kunnen dat die ene 5m kabel niet goed is.
Sander
Heb twee nieuwe 5 meter kabels gebruikt, en die geven dezelfde resultaat.
3 meter kabel is goed, die van 2 ook, maar als ik die aan elkaar doe ( met een terugmelder er tussen en 1 aan het eind ) krijg ik dezelfde resultaten als met alleen die van 5.
En kabels kort houden had ik altijd. Terugmelders allemaal bij elkaar, en die korte kabels er tussen, maar dan moet ik meer draden trekken dan bij analoog het geval was, en ook alles nog centraal terugbrengen. Juist om dat dus tegen te gaan ben ik naar netwerk kabels gegaan.
En al zou ik ze dus gebruiken van 0.5 meter dan zal ik na 10 terugmelders waarschijnlijk hetzelfde probleem krijgen ( 10 X 0.5 is weer die 5 meter )
Ga eens testen met een andere centralle dan de S88XpressNetLi, misschien dat dat betere resultaten geeft.
Groet,
Roelco
-
die 5 meter kabels mogen gene problemen geven.
Gebruik onder mijn baan er nu ook 2 naar volle tevredenheid.
Niet ergens last van HF signalen???
Dat was namelijk mijn probleem wat betreft terugmelding.
mvg,
Sander
-
Sander,
Hoe kom ik daar achter?
Ik heb precies dezelfde opstelling met een kabel van 3 meter en die van 5 meter met verschillende resultaten. Ok die kabel van 5 meter hangt iets meer op de grond dan die van 3 meter, maar dat is ook het enige verschil.
En ik hoop niet dat ik zo lang nodig heb als jij voor het probleem gevonden is, maar gezien het aantal reacties is dit niet echt een eenvoudig probleem.
Groet,
Roelco
-
Roelco,
Het algemene advies bij de S88 is geen verbindingen langer dan 2 meter tussen de verschillende modules. Een Patch-kabel is niet storingsongevoeliger of beter dan een s88 bandkabel, hij is alleen goedkoper en gemakkelijker verkrijgbaar.
Bij de Viessmann S88 zit een kabeltje van 20 cm. In het begin zaten hier kalels van 1 meter lang bij, maar omdat er teveel klachten waren, wegens storingen en niet functioneren zijn de kabel aangepast in lengte. Laat dit al een belletje rinkelen??
Verder werkt de s88XPRessNetLI uitstekend met de S88SD16-n en de s88-n van de aanbieders van deze schakeling, en heb je dus geen last van deze problemen.
Mvg
Wim.
-
even offtopic: kan ik met de s88-n een roco multimaus systee aansluiten op de pc?
-
Een Patch-kabel is niet storingsongevoeliger of beter dan een s88 bandkabel, hij is alleen goedkoper en gemakkelijker verkrijgbaar.
Wim, nu breekt mij de klomp. Het minder storingsgevoelig zijn van de netwerkkabel is op dit forum al vaker aan de orde geweest. Op de site van openDCC wordt dat ook gesteld, nota bene in een alinea waar jouw naam ook wordt genoemd. En ik heb jou dat nog nooit horen tegenspreken. Is er nu sprake van vernieuwd inzicht?
-
even offtopic: kan ik met de s88-n een roco multimaus systee aansluiten op de pc?
Nee, die kun je aansluiten met een s88XPressnetLI.
Mvg
Wim.
-
Het algemene advies bij de S88 is geen verbindingen langer dan 2 meter tussen de verschillende modules. (....)
Waarom konden bij de S88XpressNetLI aanbiedingen kabels tot 10 meter meegeleverd worden ?
Sander
-
Nee Klaas, er is geen nieuw inzicht, de verkrijbaarheid van de kabel en de prijs is gewoon een factor, hij zal iets minder storingen oppikken, twisted pair.
Maar er is geen afscherming of wat dan ook. Het blijft een draadje met een bepaalde eigen weerstand.
Mvg
Wim.
-
Wim, twisted pair is toch ook een bepaalde mate van afscherming? Zo wordt het op de OpenDCC site tenminste gesteld, de meest gevoelige dynamische signalen worden samengevoegd met een statische draad in hetzelfde paar.
Wat ik dan wel weer vreemd vind is dat ze draad 8 ongebruikt laten, en dat ze adviseren om een eventueel aanwezige afscherming niet aan te sluiten.
-
Ja, Klaas ik weet het.
Mvg
Wim.
-
Heb vanavond getest met een andere centrale, verder dezelfde setup,
centrale --> S88 adapter --> 5 meter kabel --> S88 adapter ---> viessmann S88 terugmelder
En de gehele avond dat ik getest heb ( nog niet super lang maar toch ) niet, let wel NIET 1 valse melding binnen gekregen, alle meldingen komen perfect door.
Vervang ik de centrale voor de S88XpressNetLi dan is het net anders om, of te wel: niet, let wel NIET 1 GOEDE melding binnen gekregen, alleen maar valse meldingen volgens het lijstje zoals eerder door mij neergezet.
(hoofdletters niet bedoeld als schreeuwen, maar om de nadruk te leggen op die woorden)
Dit maakt mij eigenlijk wel heel benieuwd naar wat er zou gebeuren met een terugmelder van jouw, en nog meer, wat daar dan wel anders op is? ( als die zich inderdaad anders zou gedragen )
Toch wil ik wel kijken of ik nog meer info kan krijgen waarom dit niet goed werkend te krijgen is?
Als extra info, ik weet dat je via S88 spookmeldingen kunt krijgen, mijn ervaringen boven in dit topic beschreven zijn in mijn ogen alleen geen spookmeldingen, maar fout gedrag, omdat ik dit voor 100% kan reproduceren. (waar deze fout in zit weet ik echter nog niet )
Met een kabel van 5 meter krijg ik bij activeren van ingang 1 die hele lijst, met precies die bezetmeldingen en vrijgaves op all die punten. Dus eerst alles in volgorde bezet, daarna alles in volgorde weer vrij.
Bij ingang 2 krijg ik altijd netjes terug dat ingang 1 geactiveerd is, bij loslaten wordt ingang 1 altijd weer netjes vrij gegeven, en bij de andere ingangen gebeurt er niets. Activeer ik 1 van de andere ingangen heb ik geen resultaat, er komt niets binnen.
En als ik niets doe gebeurd er ook niets. Dus niets spookachtigs aan, maar reproduceerbaar gedrag.
Groet,
Roelco
-
Roelco, wat voor type netwerkkabels gebruik je eigenlijk?
-
Klaas, er worden op dit moment wat testen uitgevoerd met verschillende types. Als hier echte resultaten over en bij bekend zijn, volgt er een verslag.
Mvg
Wim.
-
Klaas,
Ik gebruik een SF-UTP CAT.5E kabel, maar het schijnt wel uit te maken welke kabel je gebruikt.
Heb hier ook nog een stuk CAT 6 kabel liggen, maar daar moet ik eerst nog connectors aan maken om daar mee te testen. En ben nog wat andere testen aan het uitvoeren ook. Resultaten volgen als die binnen zijn.
Roelco
-
Dat zijn dus afgeschermde kabels. De afscherming wordt bij de S88N niet aangesloten.
"Google" eens op "Afgeschermde kabel de afscherming niet aansluiten" dan kom je allerlei interesante draadjes tegen.
Ik ben ook benieuwd naar de uitkomst van de test van Wim.
Groeten Jan.
-
Hoi,
Was niet Wim's test ;)
Maar ik heb vanmiddag even het volgende gedaan:
Splinternieuwe 5 Meter lange patchkabel: SFTP Cat5e
Scoop op de Reset --> Perfect signaal ( mooie rechte pulsjes )
Scoop op de Clock --> Perfect signaal ( mooie rechte pulsjes )
Scoop op de Load --> Bagger, dwz meest van de tijd 5V !! :-\ en hier en daar een spike naar 0 ( en dat terwijl het signaal meest van de tijd, 1/16e, op 0V moet staan...
Resultaat: geen terugmelding.
Opmerkelijk: Niet alleen aan het 'lange eind' van de kabel gemeten ( bij de s88 ) maar ook direct aan het interface: Beide metingen gelijk !!
Ietwat oudere 5 Meter lange patchkabel: UTP Cat 6
Scoop op de Load --> Perfect signaal ( mooie rechte pulsjes )
Scoop op de Reset --> Perfect signaal ( mooie rechte pulsjes )
Scoop op de Clock --> Perfect signaal ( mooie rechte pulsjes )
Resultaat: perfecte terugmelding.
Splinternieuwe 2 Meter lange patchkabel: SFTP Cat5e
Scoop op de Load --> Perfect signaal ( mooie rechte pulsjes )
Scoop op de Reset --> Perfect signaal ( mooie rechte pulsjes )
Scoop op de Clock --> Perfect signaal ( mooie rechte pulsjes )
Resultaat: perfecte terugmelding.
Conclusie: ??? ??? ??? :-\
Constatering: Het verminkte signaal op de 'Load' aan de 5v op de kabel is dermate 'hard' dat ook een weerstand van 1 k naar 0 geen verandering in de zaak brengt...
Wie het weet mag het zeggen. Bij mij is het licht even uit ;) ( op verzoek wil ik de scoop beelden wel plaatsen hier ;) )
Grtzz,
Karst
-
Sorry, die SF-UTP CAT.5E kabel is niet afgeschermd.
Jan.
-
Euhhh... Jan
Wel dus he :P
SFTP: Screened Fully-shielded Twisted Pair zie ook hier (http://en.wikipedia.org/wiki/Screened_fully-shielded_twisted_pair#Screened_Shielded_Twisted_Pair_.28S.2FSTP.29) hoe dat er van binnen uit ziet. ( even naar benedenscrollen )
En... SF-UTP, is dat Science Fiction UTP ;) ;D
Grtzz,
Karst
-
Karst, zou je je test nog eens kunnen herhalen met 4 melders met elk 2 meter SUTP kabel ertussen?
-
Naar ik aanneem heb je nog wel gekeken naar een ander exemplaar van de 5 meter SFTP Cat5e .... Stel eens voor dat je naar een rotte connector verbinding zit te kijken.
Sander
-
Euhhh... Jan
Wel dus he :P
SFTP: Screened Fully-shielded Twisted Pair zie ook hier (http://en.wikipedia.org/wiki/Screened_fully-shielded_twisted_pair#Screened_Shielded_Twisted_Pair_.28S.2FSTP.29) hoe dat er van binnen uit ziet. ( even naar benedenscrollen )
En... SF-UTP, is dat Science Fiction UTP ;) ;D
Grtzz,
Karst
Helaas staan er een paar foutjes in het Wiki artikel, die wellicht leiden tot verwarring. ???
- De U staat voor Unshielded, dus in het geheel geen afscherming.Kabelcode U/UTP of vroeger UTP
- De F staat voor Foiled, dus een folie als afscherming. Deze folie kan zijn aangebracht rondom de totale bundel van 4 aderparen maar ook rondom elk aderpaar.Kabelcode F/UTP of U/FTP, beide vroeger FTP, voor de laatste variant is ook PIMF gebruikt (pair in metal foil).
- De S staat voor Shielded, met een "breiwerkje" rondom de totale bundel van aderparen, meestal in combinatie met een folie rondom elk aderpaar. Kabelcode S/FTP of vroeger STP.
Niet alleen de S afscherming moet vrij worden gehouden van de aders, maar ook de folie! De gebruikte connector moet ook passen bij de toegepaste patchkabel.
Ik ben alleen bang dat hierin niet de oorzaak van het probleem zit.
Groet,
Ronald
-
Mijn kabel is inderdaad S/FTP ( op een verpakking stond de aanduiding als SF-UTP, misschien omdat ze daar gaan slash konden printen:( )
En Sander, Karst en ik meten dus hetzelfde met verschillende kabels. Heb het ook bij een kabel van 2 en 3 meter aan elkaar, die afzonderlijk gewoon goede resultaten teruggeven. Het heeft dus echt met die lengte te maken.
Roelco
-
Goed, het wordt er dus allemaal niet duidelijker op. Ik ga morgen eens een list verzinnen, en breng dan gewoon een nieuwe standaard uit. En ik noem het s88-Kut
Mvg
Wim.
-
Ja, en daar begon ik te twijfelen en dat moet je niet doen.
Maar hoe zit het dan met die niet aangesloten afscherming, die zou als antenne kunnen gaan werken, dat zou dan nog slechter zijn dan helemaal geen afscherming. Of zijn jullie daar niet bang voor.
Jan
-
Maar hoe zit het dan met die niet aangesloten afscherming, die zou als antenne kunnen gaan werken, dat zou dan nog slechter zijn dan helemaal geen afscherming. Of zijn jullie daar niet bang voor.
Jan, dat was waar ik naar toe wilde met mijn vraag aan Roelco over het type kabel.
Op de sites van OpenDCC en s88-N.eu wordt gesteld dat je de eventuele afscherming niet moet aansluiten. Ik vind dat een onzinnige opmerking, want een niet aangesloten afscherming doet in het gunstigste geval niets, en in een ongunstig geval kan het naar mijn mening nog schadelijker zijn dan helemaal geen afscherming.
Maar goed, we wachten de verdere testen even af.
-
Karst, zou je je test nog eens kunnen herhalen met 4 melders met elk 2 meter SUTP kabel ertussen?
Hi Peter,
Hier een testje gedaan met wat melders en kabels.
2 x S88 met stroomdetectie (oermodel) verbonden met een 20 cm kabel. (bandkabel)
1 s88 (6088) origineel Märklin verbonden 2 m lange (bandkabel)
1 s88n vorbonden met een 1 meter lange bandkabel.
1 s88SD16-n verbonden met een 5 meter lange sftp cat 5E kabel,
Resultaat een perfect werkende terugmelding zonder ook maar enige storing. Ook getest met s88LN, Intellibox (s88), een s88LPT en een directe verbinden op een LPT-Poort met DDW.
Dus schiet mij maar lek.
Mvg
Wim.
-
1 s88SD16-n verbonden met een 5 meter lange sftp cat 5E kabel,....
Dat is dus een kabel die zowel een folie als een gevlochten scherm heeft. Zat die afscherming ergens aangesloten, en zo ja waaraan?
-
Bij mij zat deze in elk geval nergens aangesloten. Heb van Karst intussen wel wat extra info ontvangen. Hij heeft toch iets gevonden, zal zelf wel uitleggen hoe het precies zit, maar ik heb vanavond weer wat te testen. En hopelijk is het dan opgelost.
Groet,
Roelco
-
Hoi Allemaal,
Nou, probleem geanalyseerd, gevonden, en opgelost ;D ;D
Wat was/is er aande hand...
Vooraf: 1 van de Boosdoeners is in ieder geval de SFTP kabel. Door zijn opbouw werkt deze als condensator ( zeker bij niet aangesloten afscherming. Klaas zat dus aardig in de goede richting met: in een ongunstig geval kan het naar mijn mening nog schadelijker zijn dan helemaal geen afscherming
Waarom dit schadelijk is komt later.
Verder vooraf eerst getest met de langst in huis voorradig zijnde UTP kabel: 25 meter :o GEEN probleem, zeer nette, strakke en harde signalen, zowel direct aan de interface als ook aan de s88 module.
Toen een 'willekeurige' combinatie van UTP en SFTP aan elkaar en tussen de s88 en Interface gekoppeld. Daarbij bleek, dat zodra een, ononderbroken, SFTP stuk langer is dan ca 2.50 meter, de fout optreedt.
Maar... waarom dan alleen het 'Load' signaal verminkt ??? Alle signalen uit de Interface komen immers uit dezelfde PIC, vanaf dezelfde poort, met dezelfde uitgangskarakteristieken. En waarom is het 'Load' signaal, gewoon 'hard' 5v ???
Wel, daarvoor moeten we even bij de internals van de 12Fxxx en 16Fxxx PIC range zijn.
Voor het zetten van 1 bit van een poort kent de PIC de instructie BSF, voor het resetten BCF. Echter om deze instructies daarwerkelijk uit te voren, leest de PIC microcode eerst de hele poort, schakelt het gewenste bit om en schrijft dan weer de hele poort.
Voor het activeren van de 'Load' ( BSF ), was de vorige instructie het laag zetten van de 'Clock' ( BCF ). voor het Laag zetten van 'Load' ( BCF ), de volgende instructie het hoog zetten van 'Reset' ( BSF ).
Nu wil het geval, dat vanwege het 'back-to-back' uitvoeren van deze instructies, het 'Load' signaal, door de verhoogde capaciteit van de kabel, nog niet op < 0.7 volt was aangekomen, terwijl de volgende instructie ( Reset Hoog ) al werd uitgevoerd. Hierdoor werd dus ook in het 'Load' bit weer een hoog geschreven !!
Zoeken op diverse fora, leverde o.a. deze post (http://www.mikroe.com/forum/viewtopic.php?p=97217&sid=3c276667cef845576cb140b8d9ace65f) op ( iets naar beneden scrollen tot de bijdrage van Stefan Uhlemayr )
Oplossing van het probleem:
1) Standaard UTP kabels gebruiken. Deze is hier inmiddels in huis getest met lengtes tot 25 meter.
2) Een mail aan mij sturen met het verzoek tot een ruil-PIC, daar het probleem inmiddels ook in de S88XPressNetLI firmware is opgelost, door tussen de twee bit-set operaties twee NOPs ( No Operation ) in te bouwen. Deze oplossing werkt in iedergeval voor SFTP tot 15 meter ( meer had ik niet in huis... )
Kortom, zoals zo vaak, een combinatie van factoren, waaronder foutief/onnodig gebruik van afgeschermde kabel, en...
...this is a fault of the baseline- and midrange-PIC's. The higher PIC's like the PIC18 has output-latches, and if you access them, the PIC doesn't read back the present state on his pins if you set another output with BSF...
een design-flaw in de gebruikte microcontroller. Achteraf, als je het allemaal weet niet zo spectaculair. Maar het kost weer even een dag van je schaarse modelbouwtijd :'(
Grtzz,
Karst
-
te laat :-X
-
Waarmee :-\
-
Hmm, geinig verhaal, ik zal hier goed op letten als ik zelf met Selectrix en PICjes bezig ben...
Ook weer een illustratie van Murphy's Law en dat het bouwen van 'standaard producten' toch wat anders is dan alleen iets voor jezelf in elkaar hannesen.
Op het gebied van software ben ik altijd weer verbaasd hoe er uit een systeem dat al jarenlang perfect draait toch weer een interessante bug tevoorschijn komt.
Als ik het goed begrijp was dit nummer 2 voor de XpressnetLi, hopelijk is het ook de laatste.
En zoniet, de support is van hoog nivo, dus dan komt het vast wel weer goed! ;)
-
Op het gebied van software ben ik altijd weer verbaasd hoe er uit een systeem dat al jarenlang perfect draait toch weer een interessante bug tevoorschijn komt.
Even voor de goede orde... Hardware 'bug' oplosbaar dmv software :P
Als ik het goed begrijp was dit nummer 2 voor de XpressnetLi, hopelijk is het ook de laatste.
Hoop ik ook ;D Maar ja, de Intellibox is inmiddels bij versie 1.55.... en de 2.0 laat al heeeeeeeeeeeeel lang op zich wachten ;)
Grtzz,
Karst
-
Waarmee :-\
Met mijn reactie, waarin ik schreef dat je een berichtje zou gaan dichten.
Mvg
Wim.
-
Even voor de goede orde... Hardware 'bug' oplosbaar dmv software :P
Hoop ik ook ;D Maar ja, de Intellibox is inmiddels bij versie 1.55.... en de 2.0 laat al heeeeeeeeeeeeel lang op zich wachten ;)
Grtzz,
Karst
Yep en dan nog maar te zwijgen over de IB-Basic. :-X
Mvg
Wim.
-
Gisteravond de pic van het nieuwe programma voorzien, en daarna draait het inderdaad goed, ook bij een kabel van 5 meter.
Bedankt voor de hulp,
Heb ook het oude programma getest met de afscherming van de kabel wel aangesloten, en dat werkte niet, kreeg helemaal geen rectie terug, reden heb ik verder niet uitgezocht omdat het met het nieuwe programma wel werkt, zowel met als zonder aangesloten afscherming. Maar er zal vast iets nog fout hebben gezeten in de eerst situatie.
Roelco
-
Hoi,
Da's mooi Roelco ;D
Misschien een tip aan de moderators: Veranderen van de titel in:
'Problemen bij gebruik lange SFTP patchkabels icm S88XPressNetLI '
Grtzz,
Karst
-
Titel is aangepast.