Domotica-Owners Forum

Hallo,

ik ben nieuw op dit forum, ben een autodidact elentrieker (elec gelegd in eerste en tweede bouw en die van m'n broer en ben nu weer bezig in nieuwbouw appartementen). In m'n eigen bouw heb ik 5 jaar geleden gekozen om Nikobus te leggen. Er is echter 1 probleem (van in den beginne) waarvan ik nog steeds de oorzaak niet ken. De bus blokkeert hier soms (10 tal seconden) dat is heel vervelend. Je ziet dan het buslampje branden op de modules terwijl er zelfs niemand een toets gedrukt heeft... Je staat dan daar te wachten aan een toets om het licht aan te doen...

Heeft iemand een idee wat hiervan de oorzaak zou kunnen zijn ?

vast bedankt.

Hoi,
Volgens mij zit er een defecte busdrukknop :

Tijdens het versturen van een telegram trekt de busdrukknop de spanning nikobus naar 6V. op 6V gaat de led aan op de schakelmodule).

Als het ook steeds ongeveer 10 seconden (8?) is : dit komt overeen met de maximum tijd een busdrukknop een bericht kan uitsturen.

dit moet nog bij het vorige bericht :

de defecte knop trekt de spanning voor zijn maximum periode op 6V, houdt dus de nikobus voor 8s bezet en
ofwel verstuur de knop een correct adres (een circuit shakelt ongewenst)
ofwel verstuur de knop nonsense (je zit de led op de module flikkeren maar er gebeurt niks)
ofwel verstuur de knop niks (led op module flikkert niet, nikobus constant op 6V, geen wissel tussen 8 en 6V)

Dit zou heel goed kunnen, misschien zit ergens een drukknop geforceerd.

Het is wel een mooie job om tebeginnen zoeken naar die slechte verstuurder.

Zeker als je met meerdere drukpunten zit.

Groeten philippe

www.png-tech.be

Kan je bij nikobus het verkeer niet monitoren via een pc ofzo ? Dan zou je snel weten welke blijft hangen, als je zelf nergens een toets aanraakt, maar je ziet het commando voorbijkomen, dan weet je welke toets het zou zijn ...


bart

Hoi,

Ik heb een schakeling die het verkeer op de nikobus uitleest (deze schakekeling kan ook een telegram op de nikobus kan zetten).
Het enige (voor zover ik het busprotocol correct ontrafeld heb) wat een busdrukknop doet is een 'header' versturen die de schakelmodule herkent, gevolgd door zijn uniek adres.
Dit wordt herhaald totdat de kop losgelaten wordt of een maximum tijdslimiet overschreden wordt.
Alle schakellogica wordt door de schakelmodule afgehandeld.

(opmerking : de shakelmodule doet om de 15min iets met de nikobus, dit heb ik nog niet bekeken, ik vermoed dat het gewoon een gecontroleerd reset signaal is voor de knoppen).

Als voor het gestelde probleem geen circuit door een shakelmodule ongewenst aangeschakeld wordt, betekent dit dat er geen herkenbaar patroon verstuurd wordt.
Alle knoppen zitten in serie op de bus. Het is dus onmogelijk om de defecte knop te vinden zonder ze een voor een uit het circuit te halen. Een beetje hetzelfde als het zoeken naar een defect lampje in de kerstboomverlichting.

Groeten,
Wim

Doet me denken aan die goede (??) oude coax-netwerken tijd ...

het wordt een titanewerkje maar misschien kan de slechte knop zo gevonden worden :

----(nikobus + )------------|----------------
----(nikobus - )-----|----- | ------------------
| |
| / schakelaar
| |
busdrukknop

iedere busdrukknop parrallel aan sluiten op de nikobus. Als de nikobus blokeert, een aantal busdrukknoppen loskoppelen van de nikobus door de schakelaar te openen. De defecte wordt drukknop maakt de bus vrij (led op schakelmodule gaat uit.


/Wim

Wat mij nu al heel de tijd bezig houd, is het feit dat elke actor geen ID meestuurd op de bus ... Dit lijkt me iets wat zeker in dit geval, veel problemen had kunnen voorkomen ...

Wanneer bij elke opdracht die op de bus gezet wordt, een ID van de actor in kwestie meegestuurd wordt, is het ook voor ander soort debugging een must !

Mvg,

Bart

Elke actor (schakel-, dimmermodule) en elke sensor (drukknop, binaire-interface, PC-logic) stuurt over de bus zijn/haar adres mee. Mits ze geactiveerd worden.
Sensors : indrukken drukknop of schakelen ingang. Actors : pollen via de RS232c poort (commando 12/17).
Ik heb niet gemerkt dat er spontaan iets over de bus gaat.
Alleen commando 11 en 20 via de RS232c zijn adresloos (info voor voor alle aangesloten devices (indien van toepassing)).
Zelfs in een kort ACK-message staat het adres van de actor.

Hoe komt dan, dat er hier niet aan de ID kan gezien worden, welke de probleem veroorzakende drukknop is ?

Misschien een domme vraag hoor, maar we kunnen er maar uit bijleren dan !

Mvg,

bart

De bus kent 3 spanningsniveau's:
9V de bus is idle
7,5-8V de bus is bezet
< 6V begin cq einde van een 1 of 0 bit of een reset
Deze spanningsdip duurt slechts ca 0,2msec.
De tijd tussen 2 spanningsdipjes geeft aan welke informatie er wordt verzonden:
ca. 0,8 msec = 1
ca. 1,6 msec = 0
ca. 3,2 msec is een reset (dit geeft het begin van een bitpatroon aan)
Allereerst wordt de bus naar ca. 8V gebracht. Dit geeft aan dat de bus bezet is.
Vervolgens zend een busdrukker een paar start bits, een resetbit en een bitpatroon van 24 bits. Hierin is het adres (22 bits) en de toets (A,B,C of D) opgenomen. Zolang de toets gedrukt blijft wordt dit bitpatroon herhaald (max ca. 9 sec).
Er kan slechts 1 sensor gelijktijdig actief zijn anders wordt het bitpatroon verminkt en kan geen enkele actor het bitpatroon herkennen.
Dit gebeurt als je 2 busdrukkers nagenoeg gelijktijdig bediend. Bij normaal gebruik komt dit nauwelijks voor.

Een normale busdrukker heeft geen externe voedingsbron en moet zijn energie uit de bus halen. Dit betekend dat elke busdrukker een klein accuutje heeft om de energie even op te slaan als de bus door het zenden van een bitpatroon eventjes laag wordt.
Als dit accuutje slecht of defect is kan de busdrukker teveel stroom uit bus halen en de busspaning lager dan 8V maken. Dit wordt herkend als \"Bus bezet\" en werken de meer intelligente modules zoals PC-logic etc. ook niet meer. Deze zullen nooit een bitpatroon op de bus zetten als deze bezet is.
Als een defecte busdrukker spontaan gaat zenden wordt een volledig bitpatroon op de bus gezet en is dit m.b.v. een geheugenscoop te lezen en kan het adres bepaald worden.

Daarnaast kan t.g.v. van de spanningsdipjes een defecte busdrukker spontaan toch even een of meerdere spanningsdipjes veroorzaken en het bitpatroon verminken.
Dan is het probleem groter omdat je een verminkt bitpatroon hebt wat je waarschijnlijk ook met een geheugenscoop niet meer kunt herkennen.
Zonder een geheugenscoop of als de laatste situatie van toepassing is dan is er maar een manier op de defecte busdrukker op te sporen:
De helft van de sensors loskoppelen.
Blijft de storing dan weer de helft loskoppelen, anders de andere helft weer aanlsuiten en de hele procedure herhalen.
Uiteindelijk blijft er een busdrukker over en die is dan de veroorzaker.

Actors (schakelmodule etc) zenden onder normaal bedrijf nooit bitpatronen.
Alleen bij het opvragen van de status en het programmeren via de PC en PC-link zenden deze informatie (met adres).
Het is onwaarschijnlijk dat een actor de veroorzaker is maar onmogelijk is het niet.

En als je op één of andere manier een lijst kon maken van adressen die je wel ziet doorkomen met de geheugenscoop, kan je daaruit afleiden welke je mist, en heb je de foutieve ook ? Maar weet niet eens of dit kan.

In ieder geval wel een heel duidelijke uitleg !!

Mvg,

bart

Natuurlijk dit is ook mogelijk on4cet.
Vermits je een PC-Link in de in de installatie hebt heb je de lijst al.
Onder Programmeren - Wijs adressen toe zie je in de rechter kolom welke adressen er allemaal al toegewezen zijn.
Klik Luisteren aan en wacht totdat de storing optreed. Als de betreffende busdrukker spontaan gaat zenden verschijnt het adres (met de tijd) in de linker kolom.
Dus als het een toets is die af en toe blijft hangen vindt je de defecte eenvoudig op deze manier.
Komt tijdens de storing geen adres dan is het bericht verminkt en zul je het op de eerder vermelde methode moeten doen.