KNX Forum

Nu krijg ik de laatste tijd problemen met programmeren.
Lezen is geen enkel probleem, echter het schrijven is Error welke busdeelnemer dan ook.
Zo af en toe pak hij er wel een.
Wie kan mij helpen??

Hier de controle, alles zit op de zelfde lijn.
Voeding is een 320mah met geintergreerde smoorspoel van MDT (http://www.mdt.de)
1.2 Bungalow : Het aantal smoorspoelen in lijn "1.2 Bungalow" komt niet overeen met het aantal voedingen.
1.2 Bungalow : Totaal stroomverbruik voor lijn "1.2 Bungalow" bedraagt 78 mA (geen gegevens beschikbaar voor 1 devices, deze werden op 5 mA per stuk geschat), [Dit is een Zennio ZAS}

Hierbij de foutcode:

Busdeelnemer met het individueel adres kon niet gevonden worden.

EDI: Standard USB EDI
Params: Device=0;Path=\\?\hid#vid_16d0&pid_0491#6&23e7a90e&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Last messages (cEMI):
18:23:46.616 S M_PRPR.req 0008 01 33 1 001
18:23:46.629 R M_PRPR.con 0008 01 33 1 001 00 02
18:23:46.630 S M_PRPR.req 0008 01 34 1 001
18:23:46.689 R M_PRPR.con 0008 01 34 1 001 00
18:23:46.690 S M_PRPW.req 0008 01 34 1 001 00
18:23:46.745 R M_PRPW.con 0008 01 34 1 001
18:23:46.745 S M_PRPR.req 0008 01 34 1 001
18:23:46.786 R M_PRPR.con 0008 01 34 1 001 00
18:23:46.788 S M_PRPW.req 0000 01 39 1 001 FF
18:23:46.842 R M_PRPW.con 0000 01 39 1 001
18:23:46.842 S M_PRPW.req 0000 01 3A 1 001 FF
18:23:46.902 R M_PRPW.con 0000 01 3A 1 001
18:23:46.974 S L_DATA.req (OPR/) 90 60 0000 1206 00 80
18:23:46.982 R L_DATA.con (OPR/) B1 60 FFFF 1206 00 80
18:23:46.982 S L_DATA.req (NDT-0/DeviceDescriptor_Read) 90 60 0000 1206 01 43 00
18:23:47.014 R 03
18:23:47.038 R L_DATA.con (NDT-0/DeviceDescriptor_Read) B0 60 FFFF 1206 01 43 00
18:23:50.138 S L_DATA.req (NDT-0/DeviceDescriptor_Read) 90 60 0000 1206 01 43 00
18:23:50.162 R L_DATA.con (NDT-0/DeviceDescriptor_Read) B0 60 FFFF 1206 01 43 00
18:23:53.262 S L_DATA.req (NDT-0/DeviceDescriptor_Read) 90 60 0000 1206 01 43 00
18:23:53.286 R L_DATA.con (NDT-0/DeviceDescriptor_Read) B0 60 FFFF 1206 01 43 00
18:23:55.634 R L_DATA.ind (UDT/GroupValue_Write) BC E0 1206 1C00 03 00 80 0C 60
18:23:56.386 S L_DATA.req (NDT-0/DeviceDescriptor_Read) 90 60 0000 1206 01 43 00
18:23:56.409 R L_DATA.con (NDT-0/DeviceDescriptor_Read) B0 60 FFFF 1206 01 43 00
18:23:59.510 S L_DATA.req (NDT-0/DeviceDescriptor_Read) 90 60 0000 1206 01 43 00
18:23:59.530 R L_DATA.con (NDT-0/DeviceDescriptor_Read) B0 60 FFFF 1206 01 43 00
18:24:02.467 R L_DATA.ind (UDT/GroupValue_Write) BC E0 1204 1C02 03 00 80 0C 73
18:24:02.631 S L_DATA.req (CLR/) 90 60 0000 1206 00 81
18:24:02.654 R L_DATA.con (CLR/) B0 60 FFFF 1206 00 81
18:24:02.655 S M_RSET.req

Ik zou beginnen met het loskoppelen van de busdeelnemers en dan kijken of het wel werkt met 1 busdeelnemer.
Vervolgens de rest 1 voor 1 weer aansluiten.
Wellicht vind je zo een deelnemer welke de storing veroorzaakt?

Als dat niet werkt zou ik de busdeelnemers loskoppelen en een opstelling maken waarbij de deelnemers op tafel liggen om te zien of het dan wel werkt en het misschien met de bedrading te maken heeft.
Eerst alleen maar de voeding + 1 deelnemer en je KNX/USB data-interface.

Als dat ook niet werkt is het wellicht je data-interface of een fout in je ETS installatie.

Ik kan totaal verkeerd zijn maar,

Volgens mij kan je de laatst toegevoegde voeding of drossel gewoon rechts op klikken en verwijderen.
De fysieke adressen controleren van je modules doe je door in ETS diagnose/individueel adres/controleer en/of led knipperen. Zodat de rode programmeer led knippert.
Als de adressen niet juist staan, de bus van de modules met het verkeerde adres even losmaken (niet de draadjes maar het blokje losmaken) en de fysieke adressen terug programmeren.
Als de fysieke adressen juist staan, en je hebt de modules al één keer helemaal geprogrammeerd, de volgende keren alleen gedeeltelijk programmeren met applicatie en groepsadres.

Maar ik kan het dus verkeerd begrepen hebben

Ik heb al individueel getest, maar zonder resultaat. Omdat het probleem niet altijd voorkomt. Soms kan ik wel programmeren.
Ook ben ik er zeker van dat alle adressen juist zijn.
Bedrading is nieuw en getrokken door loze leiding, slechts 3 punten komen uit bij 230v voor bewegingsmelders en brandmelder. Dit zou nog niet moeten storen.
Alleen zegt ETS dat er niet voldoende drossels zijn, maar 1 lijkt me toch voldoende in een kleine installatie.
Verder werkt ook alles naar programmatie, niks geen problemen of storingen. alleen met programmeren.
Voeding ook al uit ETS gehaald en opnieuw toegevoegd maar dit lijkt me niet de storing te zijn. Dit is immers niet te programmeren, puur controle van/voor je project.

Vandaar, weet iemand de betekenis van de foutcode?

1.2 Bungalow : Totaal stroomverbruik voor lijn "1.2 Bungalow" bedraagt 78 mA (geen gegevens beschikbaar voor 1 devices, deze werden op 5 mA per stuk geschat), [Dit is een Zennio ZAS}

Dit is als ik het mij goed herinner niet echt correct. Ik dacht mij te herinneren vanuit een vorig project bij een klant dat deze knoppen van zenio 16.5mA per stuk verbruiken... (ook problemen gehad met voeding...) Hierbij kan het probleem misschien direct opgelost worden.

@ hfx: Je hebt het niet verkeerd begrepen, maar als je ieder fysiek adres zo wil gaan controleren ben je wel even bezig bij een groot project... Maar het is inderdaad ook goed mogelijk dat de installatie vastzit door de fysieke adressen die storing geven op elkaar. Dit zou ook niet de eerste keer zijn dat ik dat tegenkom. Heb het eens voorgehad met nieuwe dimmers van siemens... De gehele installatie werkt, dimmers bij aansluiten en hele installatie slaat tilt. Was enkel in route te steken door 1 dimmer aan te sluiten, fysiek adres programmeren, daarna volgende dimmer en fysiek adres programmeren en zo verder. Geen problemen meer gehad erna...

patriekvb schreef:

1.2 Bungalow : Totaal stroomverbruik voor lijn "1.2 Bungalow" bedraagt 78 mA (geen gegevens beschikbaar voor 1 devices, deze werden op 5 mA per stuk geschat), [Dit is een Zennio ZAS}

Dit is als ik het mij goed herinner niet echt correct. Ik dacht mij te herinneren vanuit een vorig project bij een klant dat deze knoppen van zenio 16.5mA per stuk verbruiken... (ook problemen gehad met voeding...) Hierbij kan het probleem misschien direct opgelost worden.

@ hfx: Je hebt het niet verkeerd begrepen, maar als je ieder fysiek adres zo wil gaan controleren ben je wel even bezig bij een groot project... Maar het is inderdaad ook goed mogelijk dat de installatie vastzit door de fysieke adressen die storing geven op elkaar. Dit zou ook niet de eerste keer zijn dat ik dat tegenkom. Heb het eens voorgehad met nieuwe dimmers van siemens... De gehele installatie werkt, dimmers bij aansluiten en hele installatie slaat tilt. Was enkel in route te steken door 1 dimmer aan te sluiten, fysiek adres programmeren, daarna volgende dimmer en fysiek adres programmeren en zo verder. Geen problemen meer gehad erna...

11.5ma meer doet t hem niet, ik zou dan nog dik 220ma over hebben

Net nog een keer geprobeerd met alleen voeding, usb en 1 module.
Blijft foutmelden

EDI: Standard USB EDI
Params: Device=0;Path=\\?\hid#vid_16d0&pid_0491#6&23e7a90e&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Last messages (cEMI):
21:04:36.141 S M_PRPR.req 0008 01 33 1 001
21:04:36.150 R M_PRPR.con 0008 01 33 1 001 00 02
21:04:36.151 S M_PRPR.req 0008 01 34 1 001
21:04:36.210 R M_PRPR.con 0008 01 34 1 001 00
21:04:36.210 S M_PRPW.req 0008 01 34 1 001 00
21:04:36.307 R M_PRPW.con 0008 01 34 1 001
21:04:36.307 S M_PRPR.req 0008 01 34 1 001
21:04:36.334 R M_PRPR.con 0008 01 34 1 001 00
21:04:36.335 S M_PRPW.req 0000 01 39 1 001 FF
21:04:36.394 R M_PRPW.con 0000 01 39 1 001
21:04:36.394 S M_PRPW.req 0000 01 3A 1 001 FF
21:04:36.454 R M_PRPW.con 0000 01 3A 1 001
21:04:36.515 S L_DATA.req (OPR/) 90 60 0000 1298 00 80
21:04:36.526 R L_DATA.con (OPR/) B1 60 FFFF 1298 00 80
21:04:36.527 S L_DATA.req (NDT-0/DeviceDescriptor_Read) 90 60 0000 1298 01 43 00
21:04:36.534 R 03
21:04:36.598 R L_DATA.con (NDT-0/DeviceDescriptor_Read) B0 60 FFFF 1298 01 43 00
21:04:39.699 S L_DATA.req (NDT-0/DeviceDescriptor_Read) 90 60 0000 1298 01 43 00
21:04:39.727 R L_DATA.con (NDT-0/DeviceDescriptor_Read) B0 60 FFFF 1298 01 43 00
21:04:42.827 S L_DATA.req (NDT-0/DeviceDescriptor_Read) 90 60 0000 1298 01 43 00
21:04:42.850 R L_DATA.con (NDT-0/DeviceDescriptor_Read) B0 60 FFFF 1298 01 43 00
21:04:45.951 S L_DATA.req (NDT-0/DeviceDescriptor_Read) 90 60 0000 1298 01 43 00
21:04:45.978 R L_DATA.con (NDT-0/DeviceDescriptor_Read) B0 60 FFFF 1298 01 43 00
21:04:49.078 S L_DATA.req (NDT-0/DeviceDescriptor_Read) 90 60 0000 1298 01 43 00
21:04:49.103 R L_DATA.con (NDT-0/DeviceDescriptor_Read) B0 60 FFFF 1298 01 43 00
21:04:52.205 S L_DATA.req (CLR/) 90 60 0000 1298 00 81
21:04:52.228 R L_DATA.con (CLR/) B0 60 FFFF 1298 00 81
21:04:52.229 S M_RSET.req

Rutger schreef:Ik heb al individueel getest, maar zonder resultaat. Omdat het probleem niet altijd voorkomt. Soms kan ik wel programmeren.

Dus wanneer je een testopstelling maakt op tafel met slechts de voeding en 1 busdeelnemer en je programmeert deze geeft het dezelfde fout?
Uit je eerste posting begreep ik dat schrijven zelden goed gaat.
Als dit schrijven wel steeds goed gaat in een test opstelling zit de fout dus in de bedrading of in de niet aangesloten modules.
Met foutzoeken probeer ik altijd zo klein mogelijk te beginnen, zo min mogelijk variabelen/componenten.

Indien mogelijjk, probeer eens met een andere usb-datainterface.... Mogelijks zal het probleem dan daar zitten, veel adere opties heb je niet en de voeding zou mij eigenlijk sterk verwonderen...

Oeps, had je laatste reactie niet gelezen.
Was dat met alle andere componenten losgekoppeld of had je de test opstelling zeg maar op een tafel gemaakt?
Welke usb-datainterface gebruik je?