OM32, OC32 and LichtOrgel

Posted by Leon van Perlo on 2011-09-05 11:30

Hallo Remco,

Ik weet niet of de tool van Hans deze setup ondersteunt. Ik zou het wel verwachten, maar heb het zelf niet getest. Hans kan daar ongetwijfeld antwoord op geven.

Om te controleren:

• Ik neem aan dat het een standaard UCCI is (dus met USB interface)
• Staat de jumper op UCCI op RS232?
• Staat de jumper op de OC32 op RS232?

Je zou het ook kunnen testen met OM32Config. Daarmee kun je een test "via Dinamo" doen. Als je de OC32 als OM32 aanstuurt moet je even een apparaat selecteren. Als je het via Aspects doet kun je voor een hele module met 1 druk op een button "aspect aansturing" kiezen. Uiteraard alleen voor de test, je hoeft het niet op te slaan.

Nu ik er over nadenk: Misschien ook wel handig om die testmogelijkheid in OC32Config in te bouwen

Nog een testmogelijkheid: DinamoUsersCC
Hoef je niks te installeren, alleen DinamoUsersCC downloaden en de .exe starten.

Kies tabblad "Uitgangen/Configuratie"
OM32 Commando 1 = Set Aspect, Uitgang = Pin nummer, Parameter = de gewenste Aspect.

Mvg,
Leon

(voor de overzichtelijkheid 3 antwoorden samengevoegd)

Posted by Remco de Jong on 2011-09-05 11:59

Hoi Leon,

Bedankt voor de snelle en uitgebreide reactie.

We hebben het hier inderdaad over een UCCI met USB (dus geen UCCI-s)
De jumper op de OC32 staat zover ik weet inderdaad op RS232 en niet op TTL
De jumper op de UCCI wordt in de handleiding volgens mij niet genoemd, maar staat dacht ik wel op RS232.

Ik ben dinsdagavond weer op de club en zal dan het hele spul eens nog eens dubbel checken (bekabeling, stand van de jumpers enz.) evenals de tests met de tools.
Ik zal mijn bevindingen uiteraard hier posten.

Bedankt zover!

Groeten
Remco

Posted by Remco de Jong on 2011-09-06 21:27

Hallo,

Vanavond op de club het eea geprobeerd, echter zonder het gewenste eind resultaat...

Jumpers gecheckt, deze staan goed.
OM32Config geeft steeds aan dat dinamo niet reageert..
Als we een commando geven via JDinamoCC2, dan flits de gele led even op de UCCI, ofwel "Er wordt een bericht gestuurd naar een OM32 module"

Tevens de OC32 nog even rechtstreeks aan de laptop gehad via de RS232 interface en ook dan zijn de servo's te besturen.

De tool DinamoUsersCC heb ik niet kunnen vinden in de bestandgallerij.

wellicht handig om te weten: OC32 firmware versie 0.0.1.5
UCCI versie (volgens de sticker 1.02)
JDinamoCC2 zegt te maken te hebben met een RMH v.3.10

Wie kan ons nog een zetje de goede richting op geven?

Groeten
Remco

Posted by Leon van Perlo on 2011-09-06 23:05

Remco,

En heb je bij OM32Config dan aangevinkt "Via Dinamo" en "Versie 3.0" ?

DinamoUsersCC staat gewoon in de file galleries

Als het gele LEDje aanflitst lijkt de poort te worden aangesproken. Flitst ook het oranje LEDje op de OC32? Dat is namelijk een indicatie dat de OC32 het ook ontvangt.

Mvg,
Leon

Posted by Remco de Jong on 2011-09-09 16:54

Hoi Leon,

Inderdaad beide vinkjes in de OM32Config aangevinkt, echter zonder resultaat.

DinamoUsersCC heb ik inderdaad gewoon overheen gekeken, die staat er inderdaad keurig bij (heb alleen maar in de submappen van software gekeken )

Of de gele led op de OC32 ook reageert weet ik niet, dit zal ik even controleren, evenals de test met DinamoUsersCC.
Met deze bevindingen zal ik me weer melden.

Groeten
Remco

Posted by Leon van Perlo on 2011-09-13 21:40

Remco,

Als de oranje LED op de OC32 niet reageert kan het zijn dat hij geen commando ontvangt. Het kan ook zijn dat hij wel een commamndo ontvangt maar op een verkeerd adres.
DinamoUsersCC moet het gewoon doen. Dat is bij mij zo en bij tientallen anderen
OM32Config moet het ook gewoon doen. UCCI is qua protocol gewoon een Dinamo 3.x systeem. OM32Config werkt via Dinamo bij tientallen, zo niet honderden gebruikers. Als dat bij jou niet zo is stel je iets verkeerd in.

Je schrijft dat je de OC32 met RS232 aan de PC hebt gekoppeld. Ik neem dus aan niet via de U485, want dat is geen RS232. Ik schrijf "ik neem aan" want jij schrijft het zo. De vraag is of je het ook zo bedoelt. RS232 is niet RS485. Op de OC32 is dat fysiek een andere aansluiting.

Mvg,
Leon

Posted by Remco de Jong on 2011-09-13 22:02

Beste Leon

vanavond het een en ander uitgeprobeert maar helaas,
de storing blijft er in zitten we hebben diverse mogelijkheden uit geprobeert maar tot nu toe geen resultaat.
we gaan volgende week verder met een ander OC32, en kijken dan wel wat er gebeurt.

we houden je op de hoogte

groetjes
Remco en Theo

Posted by Leon van Perlo on 2011-09-13 22:18

Remco,

Je schrijft dat de OC32 werkt op RS485 EN op RS232. Je schrijft dat je beide geprobeerd hebt aan een PC. Dan is de OC32 dus in orde qua communicatie (overigens twijfel ik daar ook niet echt aan) en is het "proberen" van een andere zinloos.

Je schrijft dat OM32Config niet werkt met UCCI. Dat is vreemd, want UCCI werkt wel aan je PC. Dan kan het simpelweg niet zo zijn dat OM32Config niet werkt, behalve als je je COM poort bezet houdt.

DinamoUsersCC moet ook werken, idem.

Het enige wat ik niet zeker weet is of JdinamoCC de OC32 achter een UCCI correct aanstuurt. Daarom het advies het met een van de andere programma's te doen. Daarvan weet ik wel zeker dat ze goed werken en kun je dat als oorzaak uitsluiten.

Proberen heeft geen zin, gestructureerd werken en oorzaken uitsluiten wel.

Heb je mijn eerste zin en de vorige post gelezen: Heb je de OC32 inderdaad met RS232 aan een PC gehad, dus NIET via de U485?

Mvg,
Leon

Posted by Remco de Jong on 2011-09-14 08:32

Goedemorgen Leon,

Heb er even een nachtje over geslapen.

Dat de OC32 niet correct functioneerd, daar twijfel ik eigenlijk ook niet aan. Het zal inderdaad een andere oorzaak moeten hebben.
Gisterenavond hebben we overigens getest met DinamoUsersCC. Deze commniceert probleemloos met de UCCI. Status van de bezet melders e.d. wordt keurig weergegeven.

Ik begrijp dat testen met JdinamoCC een onbetrouwbaar beeld kan geven, gezien het feit we niet zeker weten of dit werkt.

De OC32 hebben we inderdaad werkend gehad met twee verschillende interfaces: RS232, via de laptop mbv een serial to USB converter. Vervolgens kunnen we (via COM4) opdrachten versturen naar de OC32.
Ook hebben we de OC32 via RS485 aan de laptop gehad. Dit op de daarvoor bestemde aansluiting op de OC32, en aan de laptop kant met de mee geleverde U485, de RS485 to USB converter. Ook dan kunnen we opdrachten versturen (en ook uilezen) naar de OC32 (via COM9).
Deze beide tests, zowel de RS232 test als de RS485 test zijn gedaan met OC32config. Dit hebben we meerdere malen gedaan, met de OC32 gejumperd als adres 1 en als adres 0.
Met deze wetenschap is in mijn ogen de OC32 zogoed als uitgesloten.

Vreemd blijft het feit dat, zodra we opdrachten versturen riching de UCCI (COM8), bedoeld voor de OC32, de UCCI netjes reageert door de gele led te laten oplichten. Maar de CO32 geeft niet thuis.
Verdachte is dan de kabel verbinding tussen de twee prints.
Zoals ik al eerder heb gepost, delen de twee prints op dit moment de zelfde voeding. Vervolgens loopt er een draad van de UCCI output (pin2) naar de K1 van de OC32 (de RS232 interface) op pin 4. Ook de draad zelf is doorgemeten en is heel.

Als ik het zo even voor me zelf resumeer, dan lijkt het wel als of de opdrachten voor de OC32 de UCCI niet verlaten. Vandaar de gedachten om eens een andere OC32 te proberen.
Een andere troef die ik nog heb, is misschien om de UCCI ipv de USB verbinding via RS232 aan de laptop te hangen? Of wellicht een andere pc?

We gaan hier uiteraard mee verder, we houden je op de hoogte,

Groeten,
Remco

Posted by Leon van Perlo on 2011-09-14 12:37

Remco,

Ok, geeft een redelijk compleet beeld zo.

• De OC32 moet goed zijn, je kun immers communiceren via RS485 en RS232 en hij reageert correct op opdrachten. Kan dus redelijkerwijs als oorzaak worden uitgesloten.
• Je PC communiceert via USB en RS232. Lijkt me dus ook uitgesloten als oorzaak.
• Je gebruikt testprogramma's waarvan we weten dat die correct werken op dit punt, kan inmiddels dus redelijkerwijs ook worden uitgesloten.
• Het draadje tussen UCCI en OC32 zit goed zoals je het beschrijft. Als je hem ook hebt doorgemeten kan ook dat het niet zijn.

Blijft volgens mij 1 mogelijke oorzaak over: UCCI zendt geen RS232 signaal. Dat kan komen door:

• Het niet (correct) plaatsen van de jumper op UCCI. Er zijn 2 posities (uit mijn hoofd): "TRM" en "232". Hij moet in de stand 232 staan (in elk geval NIET op "TRM".
• Er is een MAX3082 driver geplaatst op UCCI (in het 8 pins voetje dat standaard af fabriek leeg is). Als deze geplaatst is werkt de 3 pins connector op RS485. De jumper moet dan ofwel in de "TRM" positie staan (als je de afsluitweerstand wilt activeren) of geheel verwijderd zijn (geen afsluitweerstand). De RS232 functie kun je dan op die poort niet gebruiken. Wil je dat wel, MAX3082 verwijderen.
• De RS232 poort op UCCI is defect.

Mvg,
Leon

Posted by Remco de Jong on 2011-09-15 08:44

Hallo Leon,

Gisteravond was ik nog even op de club en heb ik even snel bijgevoegde foto van de UCCI geschoten.
Ik denk dat je vermoedens kloppen.
Zoals je op de foto kunt zien is de jumper juist geplaatst.
Op de foto is ook duidelijk te zien dan het 8 pins voetje bezet is!

Vermoedelijk is deze driver geplaatst omdat we dus de UCCI in een later stadium in onze "grote" baan willen gaan gebruiker achter een RM-U.
Voor nu zullen we dus de driver moeten verwijderen.
Was gisteravond niet in de gelegenheid om het eea te testen, maar ik laat zsm weten of dit de oorzaak is.

Groeten,
Remco

Posted by Leon van Perlo on 2011-09-15 14:18

Remco,

Voor nu zullen we dus de driver moeten verwijderen

.. of de UCCI jumper op "TRM" zetten en de OC32 met RS485 op UCCI aansluiten. Dat komt er dan namelijk uit.

Mvg,
Leon

Posted by Remco de Jong on 2011-09-21 14:08

Hoi Leon,

Even een kleine update..
Gisteravond even snel wat getest (met DinamoUsersCC).
Driver verwijderd en de OC32 op RS232 aangesloten, maar helaas geen response van de OC32, zelfs geen opflitsend geel ledje (wel op de UCCI).

Ook nog getest met RS485, driver terug gezet, jumper om op de UCCI (op TRM). De kabel tussen de OC32 en de UCCI is degene die ik anders gebruik tussen de OC32 en de U485 (zelfde stekkers).
Ook hier geen response van de OC32, ook geen ledje wel op de UCCI)...

Hebben we misschien iets kapot gemaakt door een RS485 signaal als RS232 aan te sluiten?

Groeten,
Remco

Posted by Leon van Perlo on 2011-09-21 21:47

Hallo Remco,

Ik kan je niet verder helpen dan dit.
Als je denkt dat de UCCI defect is stuur je hem op. Dan wordt-ie getest en als de RS232 poort defect is wordt-ie gerepareerd.
Ik neem aan dat het adres bekend is, anders ff een persoonlijke mail graag.

Mvg,
Leon

Posted by Remco de Jong on 2011-11-16 18:33

Hoi Leon,

Even een korte inleinding voor de "meelezers". Ik beschrijf even kort wat hoe ik het eea begrepen heb. Correct me if I'm wrong.

Inmiddels hebben we de UCCI naar je toegestuurd om deze te controleren. Je hebt geconstateerd dat deze kern gezond is en hem om die reden dan ook weer terug gestuurd naar ons. We hebben hem weer keurig ontvangen en ik ben er gisteravond op de club mee aan de slag gegaan.

Omdat we de OC32 op RS232 achter de UCCI wilde hebben, hebben we nu allereerst de MAX3082 verwijderd en de bijbehorende jumper gezet op "TRM". Vervolgens de UCCI verder aangesloten, de draad naar de OC32, de rijdraden en terugmelders aangesloten en het hele spul onder stroom gezet.

USB verbinding in orde gemaakt, en de poort geopend in DinamoUsersCC. De USB verbinding werkt; de terugmelding van de melders wordt namelijk keurig zichtbaar. Ook auto's reageren correct op commando's gegeven met DinamoUsersCC.

We kunnen een tabbald verder:
We willen de servo wissel aansturen op de 4e poort op de OC32 met adres 1, deze kent twee standen, recht en rond, ofwel aspect 0 en 1.
Met die gegevens gaan we naar het kopje OM32 (op dit punt kunnen we voor OM32 ook OC32 lezen) Hier zijn 3 opties: Uitgang, Commando, Parameter.

de uitgang is 36.
Als OC32 het adres 0 heeft, hebben we het over pinnen 1 t/m 32. Nu hebben we het over adres 1, dus de uitgangen 33 t/m 64. de vierde pin geeft dus adres 36

Het commando is 1.
Dit betekend zoveel als zet servo is stand x.

parameter 0 of 1.
Deze waarde komt overeen met de aspect die gemaakt is met OC32Config.

Nu komt het moment van de waarheid, klik op zend.

Ik durf het haast niet te zeggen, maar de OC32 reageert direct en de servo schiet in de stand die hem zojuist opgedragen wordt. Opdrachten met variaties op de uitgang en de parameter worden ook allemaal keurig uitgevoerd. Het werkt dus allemaal zoals het zou moeten.

Nu is natuurlijk de vraag, waarom deed de UCCI het niet al vanaf het begin?

Ik heb daar eigenlijk geen antwoord op. Ik denk dat we in het begin al op het verkeerde been gegaan zijn door dat we niet wisten dat de UCCI alleen RS485 kan kletsen als de MAX3082 is geplaatst. Toen we hier achter kwamen en de boel dus juist hebben aangesloten, hebben we wellicht niet goed doorgetest met het geven van commando's.

Ik wil Leon dan ook hartelijk danken voor de gedane moeite en het meedenken in deze.
Wij kunnen nu eindelijk, met een werkend proefbaantje, verder met onze hobby!

Groeten,
Remco

Posted by Leon van Perlo on 2011-11-16 20:32

Hallo Remco,

Mooi dat het werkt. Je ziet nu dat het niet zo heel ingewikkeld is. Waarom het eerst niet gewerkt heeft weet ik ook niet, je hebt waarschijnlijk ergens iets over het hoofd gezien.

Voor de meelezers: je schrijft "hebben we nu allereerst de MAX3082 verwijderd en de bijbehorende jumper gezet op TRM". 2 Opmerkingen:

1. De jumper staat niet op "TRM" maar op "232", anders kan het simpelweg niet werken, dus je hebt het ongetwijfeld nu wel goed gedaan, maar je beschrijft het verkeerd.
2. De meeste 'normale' gebruikers hoeven hier niet naar te kijken, UCCI wordt standaard uitgeleverd zonder MAX3082 en de jumper in de RS232 stand. Jullie hebben een RS485 versie gevraagd i.v.m. toekomstige uitbreidingen, dus jullie moesten die 'special' even terugdraaien als je de normale werking terug wilt.

Veel plezier verder met testen en bouwen!

Mvg,
Leon

Posted by Remco de Jong on 2011-11-16 21:00

Hoi Leon,

Het is inderdaad 232. Het is natuurlijk wel handig, dat als je RS232 gebruikt, je de jumper ook in die stand zet . Inderdaad wel goed uitgevoerd, maar door mij verkeerd beschreven.
Zoals je zelf al eerder schreef is de "TRM" stand van deze jumper bedoeld om de afsluitweerstand te activeren bij een RS485 setup, die we inderdaad straks in onze modulebaan willen gaan gebruiken.

Groeten,
Remco