Witam,

Problem mój dotyczy przemysłowego monitora dotykowego z interfejsem
RS232. Monitor ten przy dotknięciu powłoki dotykowej wysyła przez RS232
ciąg bajtów. Komunikuje się on bez problemów z komputerem PC
posiadającym fizyczny port RS232 (wysyłane bajty są odbierane z portu
RS232 PC np. przy pomocy HyperTerminala), natomiast nie chce
współpracować z innymi urządzeniami, tj.:
- sterownikiem Beckhoff CX9001 z modułem CX9000-N030 z dwoma portami
RS232 (na współpracy monitora z tym urządzeniem najbardziej mi zależy),
- komputerem PC przez konwertery RS232<->RS485 ADAM 4520 (testowałem
konfigurację: monitor [RS232] -> ADAM1 <-[RS485]-> ADAM2 -> PC[RS232], w
której monitor nie komunikował się z PC - aby wykluczyć problemy z
konwerterami, podłączyłem w miejsce monitora drugi port RS232 PC,
komunikacja między portami - przesyłanie znaków przez HyperTerminal -
działała poprawnie).

Wykluczyłem możliwość uszkodzenia portów RS232 w/w urządzeń (te w module
CX900-N030 były testowane z czytnikiem kodów kreskowych, także
komunikacja między komputerem PC a sterownikiem Beckhoffa, przy
połączeniu kablem nullmodem działała poprawnie - przez HyperTerminal
były odbierane/wysyłane znaki). Także parametry transmisji były we
wszystkich opisanych przypadkach identyczne (9600 b/s, 8 bitów danych, 1
bit stopu, brak sterowania przepływem - zgodnie z instrukcją monitora).

W związku z powyższym, nie doszukując się żadnych programowych przyczyn
problemów, postanowiłem zbadać poziomy napięć generowane przez interfejs
RS232 monitora w trakcie przesyłania danych.
Poniżej zamieszczam link do oscylogramu napięcia na pinie Tx interfejsu
RS232 monitora w trakcie transmisji (dotknięcia powłoki dotykowej).
Napięcie logicznej "1": -7V, logicznego "0": 6.8V, więc niby mieszczą
się w specyfikacji RS232.
http://kni.prz.edu.pl/~tom/rs232/monitor_levels.jpg

Dla porównania zbadałem napięcie na nóżce Tx portu RS232 PC (z którym
wspomniany powyżej sterownik Beckhoffa bez problemów komunikuje się) w
trakcie transmisji znaków - napięcie logicznej "1": -10.8V, logicznego
"0": 11.4V.
Jest to o 3.8V mniej dla logicznej "1" i o 4.6V więcej dla logicznego
"0" niż w monitorze!
http://kni.prz.edu.pl/~tom/rs232/pc_levels.jpg


Na podstawie tych testów doszedłem do wniosku, iż powodem kłopotów może
być brak tolerancji RS232 w CX9001-N030 oraz w konwerterze ADAM na
niższe (chociaż mieszczące się w specyfikacji RS232) poziomy napięć.
Postanowiłem zatem dopasować poziomy napięć generowanych przez RS232
monitora do górnych granic określonych w standardzie RS232, gdyż .

Moim pierwszym pomysłem było użycie układu MAX232A:
monitor [RS232] -> MAX232A [RS232->TTL->RS232] -> PC [RS232].
W tym celu podłączyłem sygnał z pinu Tx monitora do pinu R1_IN MAX232,
zmostkowałem piny R1_OUT i T1_IN, wyjście na pinie T1_OUT.
Napięcie logicznej "1" zostało w takim układzie obniżone do -15.6V,
natomiast problem pojawił się z napieciem logicznego "0" - przy
rozpoczęciu nadawania "0", występuje krótka "szpilka" napięcia 14V, po
czym napięcie spada do poziomu -2V, a monitor nadal nie współpracuje z
"problematycznymi" urządzeniami :-( MAX232A jest wyposażony, zgodnie z
datasheetem, w kondensatory 0.1uF (tantalowe), zasilany 5V.
Poniżej zamieszczam oscylogram napięcia na nóżce T1_OUT w trakcie
transmisji z monitora.
http://kni.prz.edu.pl/~tom/rs232/max232_monitor_leve
ls.jpg


Chciałbym zatem zapytać, w jaki sposób dokonać w opisanej sytuacji
zmiany poziomów napięć generowanych przez interfejs RS232 monitora (bez
ingerencji wewnątrz monitora - raczej w postaci układu pośredniczącego
między monitorem a urządzeniem "klientem"), aby mieściły się w górnej
granicy specyfikacji RS232?
Czy jest to w ogóle możliwe do osiągnięcia?
Czy powinienem dodać coś do opisanego MAX232A/zmienić parametry
kondensatorów, aby generowane dla logicznego "0" napięcie znajdowało się
na poziomie początkowej "szpilki"?
Może należałoby zastosować jakiś inny układ (jaki)?


Z góry dziękuję za wszelkie odpowiedzi i pozdrawiam,

--
Tomek

do góry

Użytkownik "TM" <t...@e...pl_I_HATE_SPAM> napisał w wiadomości
news:hp2l19$f4$1@news.dialog.net.pl...

> W związku z powyższym, nie doszukując się żadnych programowych przyczyn
> problemów

Raczej jednak szukaj przyczyn programowych, napięcia są OK, nie ma sensu
ich zwiększać. Port w PC-cie jest bardzo tolerancyjny, zdarza się, że ma
jeden próg przełączania w okolicach 1V z niewielką histerezą.
Stawiam na to, że jednak jest jakieś sterowanie przepływem (które
konwerter na RS485 potrafi dodatkowo zkaszanić) albo gdzieś Ci się zrobił
niepożądany przeplot. BTW, kiedy został zrobiony ten oscylogram? W czasie
bezpośredniego połączenia do PC? Jeśli tak, sprawdź co się dzieje na Tx
wtedy, gdy transmisja nie działa.

e.

do góry

entroper wrote:
> Raczej jednak szukaj przyczyn programowych, napięcia są OK, nie ma sensu
> ich zwiększać. Port w PC-cie jest bardzo tolerancyjny, zdarza się, że ma
> jeden próg przełączania w okolicach 1V z niewielką histerezą.
Zgadzam się, jednak tolerancja portu we wspomnianym przez mnie
sterowniku przemysłowym Beckhoffa (czy też w konwerterze ADAM) już może
chyba nie być tak duża jak w PC?

Swego czasu miałem wypożyczony pewien czytnik kodów kreskowych z RS232,
który nie chciał współpracować z w/w Beckhoffem, natomiast PC już
odbierał z tego czytnika dane (niestety było to już ponad rok temu i nie
przyszło mi wtedy do głowy, żeby badać napięcia na linii Tx
problematycznego czytnika - został on po prostu wymieniony na inny
model, komunikujący się poprawnie z Beckhoffem).

> Stawiam na to, że jednak jest jakieś sterowanie przepływem (które
> konwerter na RS485 potrafi dodatkowo zkaszanić) albo gdzieś Ci się zrobił
> niepożądany przeplot.
Po stronie monitora nie ma raczej (według producenta) zaimplementowanego
sterowania przepływem. Na wszelki wypadek zwarłem jednak we wtyczkach
DE-9 kabla połączeniowego piny 7 z 8 oraz 1 z 4 i 6 - nic to nie zmieniło.

> BTW, kiedy został zrobiony ten oscylogram? W czasie
> bezpośredniego połączenia do PC? Jeśli tak, sprawdź co się dzieje na Tx
> wtedy, gdy transmisja nie działa.
>
Rozumiem, że masz na myśli oscylogram napięcia na linii Tx interfejsu
RS232 monitora? Jeżeli tak, został on zrobiony bez podłączenia monitora
do PC. Poniżej zamieszczam oscylogram tego napięcia przy braku transmisji.
http://kni.prz.edu.pl/~tom/rs232/monitor_idle.jpg


> e.
>
Dzięki za odpowiedź i pozdrawiam,

--
Tomek

do góry

W dniu 2010-04-01 19:27, TM pisze:
> Witam,
>
> Problem mój dotyczy przemysłowego monitora dotykowego z interfejsem
> RS232. Monitor ten przy dotknięciu powłoki dotykowej wysyła przez RS232
> ciąg bajtów. Komunikuje się on bez problemów z komputerem PC
> posiadającym fizyczny port RS232 (wysyłane bajty są odbierane z portu
> RS232 PC np. przy pomocy HyperTerminala), natomiast nie chce
> współpracować z innymi urządzeniami, tj.:
> - sterownikiem Beckhoff CX9001 z modułem CX9000-N030 z dwoma portami
> RS232 (na współpracy monitora z tym urządzeniem najbardziej mi zależy),
> - komputerem PC przez konwertery RS232<->RS485 ADAM 4520 (testowałem
> konfigurację: monitor [RS232] -> ADAM1 <-[RS485]-> ADAM2 -> PC[RS232], w
> której monitor nie komunikował się z PC - aby wykluczyć problemy z
> konwerterami, podłączyłem w miejsce monitora drugi port RS232 PC,
> komunikacja między portami - przesyłanie znaków przez HyperTerminal -
> działała poprawnie).


> Moim pierwszym pomysłem było użycie układu MAX232A:
> monitor [RS232] -> MAX232A [RS232->TTL->RS232] -> PC [RS232].
> W tym celu podłączyłem sygnał z pinu Tx monitora do pinu R1_IN MAX232,
> zmostkowałem piny R1_OUT i T1_IN, wyjście na pinie T1_OUT.
> Napięcie logicznej "1" zostało w takim układzie obniżone do -15.6V,
> natomiast problem pojawił się z napieciem logicznego "0" - przy
> rozpoczęciu nadawania "0", występuje krótka "szpilka" napięcia 14V, po
> czym napięcie spada do poziomu -2V, a monitor nadal nie współpracuje z
> "problematycznymi" urządzeniami :-( MAX232A jest wyposażony, zgodnie z
> datasheetem, w kondensatory 0.1uF (tantalowe), zasilany 5V.
> Poniżej zamieszczam oscylogram napięcia na nóżce T1_OUT w trakcie
> transmisji z monitora.
> http://kni.prz.edu.pl/~tom/rs232/max232_monitor_leve
ls.jpg

Coś masz źle połączone bo fizycznie nie może być -15V gdy MAX232 jest
zasilany z +5V. W układzie jest podwajacz oparty na pompie ładunkowej.
Powinno byc blisko dziesięciu woltów. Sprawdź czy dobrze połączyłeś
kondensatory. Ponadto może urządzenia mają masy na różnych potencjałach.
Zmień także kondensatory ze 100nF na 1uF a nawet 4,7uF. Zwiększy to
wydajność podwajacza w sytuacji gdy np. wejście Rx sterownika bierze za
dużo prądu ( na przykład z powodu uszkodzenia).
Problem z napięciami jest tu chyba jednak problemem tworzonym przez
Ciebie przez błędnie skonstruowany konwerter napięć.

>
> Chciałbym zatem zapytać, w jaki sposób dokonać w opisanej sytuacji
> zmiany poziomów napięć generowanych przez interfejs RS232 monitora (bez
> ingerencji wewnątrz monitora - raczej w postaci układu pośredniczącego
> między monitorem a urządzeniem "klientem"), aby mieściły się w górnej
> granicy specyfikacji RS232?
> Czy jest to w ogóle możliwe do osiągnięcia?
> Czy powinienem dodać coś do opisanego MAX232A/zmienić parametry
> kondensatorów, aby generowane dla logicznego "0" napięcie znajdowało się
> na poziomie początkowej "szpilki"?
> Może należałoby zastosować jakiś inny układ (jaki)?

Jednak problem dotyczy chyba protokołu. Spróbuj wysłać łańcuch z panela
na Hyperterminal i zapisać go a potem odesłać z peceta do PLC. Ponadto
możesz podsłuchiwać oba kierunki transmisji Panel<->PLC dopinając się
do nich liniami Rx z dwóch portów RS w PC i oglądać na terminalu czy PLC
odpowiada jakimkolwiek znakiem.



--
Pozdrawiam
MD

do góry

Mario wrote:
> Coś masz źle połączone bo fizycznie nie może być -15V gdy MAX232 jest
> zasilany z +5V. W układzie jest podwajacz oparty na pompie ładunkowej.
> Powinno byc blisko dziesięciu woltów. Sprawdź czy dobrze połączyłeś
> kondensatory. Ponadto może urządzenia mają masy na różnych potencjałach.
> Zmień także kondensatory ze 100nF na 1uF a nawet 4,7uF. Zwiększy to
> wydajność podwajacza w sytuacji gdy np. wejście Rx sterownika bierze za
> dużo prądu ( na przykład z powodu uszkodzenia).
> Problem z napięciami jest tu chyba jednak problemem tworzonym przez
> Ciebie przez błędnie skonstruowany konwerter napięć.
>
Rzeczywiście, masy MAX232A i monitora były na różnych potencjałach. Po
ich połączeniu, poziomy napięć na wyjściu MAX232A zmieniły się na +8.80V
i -8.80V.

Co najważniejsze, po zrównaniu potencjałów mas i podłączeniu monitora za
pośrednictwem tego "konwertera" z MAX232A do Beckhoffa, Beckhoff zaczął
komunikować się z monitorem - odbierać bajty wysyłane przez monitor w
momencie dotykania warstwy dotykowej :-)

Bardzo dziękuję za tą sugestię! Jeszcze pozostaje instalacja driverów
monitora dla Windowsa CE i przetestowanie współpracy z systemem, ale
samo uruchomienie komunikacji monitora z Beckhoffem to ogromny postęp :-) .

> Jednak problem dotyczy chyba protokołu. Spróbuj wysłać łańcuch z panela
> na Hyperterminal i zapisać go a potem odesłać z peceta do PLC. Ponadto
> możesz podsłuchiwać oba kierunki transmisji Panel<->PLC dopinając się do
> nich liniami Rx z dwóch portów RS w PC i oglądać na terminalu czy PLC
> odpowiada jakimkolwiek znakiem.
>
To nie jest typowy panel współpracujący bezpośrednio z PLC, tylko zwykły
monitor LCD VGA z warstwą dotykową ( konkretnie ten model:
http://tnij.org/gdt6 ) - jest możliwa tylko jednokierunkowa komunikacja
monitor -> urządzenie.

Na sterowniku Beckhoffa działa Windows CE, monitor ten służy do obsługi
aplikacji pracującej pod kontrolą tego systemu.

--
Tomek

do góry

TM wrote:
> Co najważniejsze, po zrównaniu potencjałów mas i podłączeniu monitora za
> pośrednictwem tego "konwertera" z MAX232A do Beckhoffa, Beckhoff zaczął
> komunikować się z monitorem - odbierać bajty wysyłane przez monitor w
> momencie dotykania warstwy dotykowej :-)
>
> Bardzo dziękuję za tą sugestię! Jeszcze pozostaje instalacja driverów
> monitora dla Windowsa CE i przetestowanie współpracy z systemem, ale
> samo uruchomienie komunikacji monitora z Beckhoffem to ogromny postęp :-) .
>
Informuję o ostatecznych rezultatach - po instalacji drivera dla Windows
CE, warstwa dotykowa monitora działa poprawnie we współpracy ze
sterownikiem CX9001 Beckhoffa.

Jeszcze raz bardzo dziękuję za wszystkie odpowiedzi, szczególnie koledze
'Mario', gdyż to dzięki jego sugestii odnośnie mas układów udało mi się
problem rozwiązać :-) .

> To nie jest typowy panel współpracujący bezpośrednio z PLC, tylko zwykły
> monitor LCD VGA z warstwą dotykową ( konkretnie ten model:
> http://tnij.org/gdt6 ) - jest możliwa tylko jednokierunkowa komunikacja
> monitor -> urządzenie.
>
Z tą komunikacją jednokierunkową jednak się pomyliłem - wymagane są
obydwie linie (Tx i Rx), inaczej monitor nie jest wykrywany przez driver.

> Na sterowniku Beckhoffa działa Windows CE, monitor ten służy do obsługi
> aplikacji pracującej pod kontrolą tego systemu.
>


--
Tomek

do góry

Użytkownik "TM" <t...@e...pl_I_HATE_SPAM> napisał w wiadomości
news:hp2q9c$3eg$1@news.dialog.net.pl...

> Zgadzam się, jednak tolerancja portu we wspomnianym przez mnie
> sterowniku przemysłowym Beckhoffa (czy też w konwerterze ADAM) już może
> chyba nie być tak duża jak w PC?

Bardziej skłaniam się ku temu, że Beckhoff i ADAM mają wsadzone od wejścia
"solidne" dociążenie 3k i napięcie mocno siada. PC-et może mieć 2x tyle
albo w ogóle wartość z kosmosu i dlatego działa. Ale to by oznaczało, że
port w tym panelu jakiś badziewny jest (napięcia siadają np wtedy, gdy
użyje się MAX232 (lub odpowiednika) z za małymi kondensatorami
podwajacza) - domyślam się, że w panelu wolisz jednak nie grzebać :).

> > BTW, kiedy został zrobiony ten oscylogram? W czasie
> > bezpośredniego połączenia do PC? Jeśli tak, sprawdź co się dzieje na
Tx
> > wtedy, gdy transmisja nie działa.
> >
> Rozumiem, że masz na myśli oscylogram napięcia na linii Tx interfejsu
> RS232 monitora? Jeżeli tak, został on zrobiony bez podłączenia monitora
> do PC. Poniżej zamieszczam oscylogram tego napięcia przy braku
transmisji.
> http://kni.prz.edu.pl/~tom/rs232/monitor_idle.jpg

Może źle się wyraziłem - chodziło mi o oscylogram na Tx w momencie, gdy
panel transmituje ale dane nie są odbierane (czyli np. po podłączeniu do
Beckhoffa) - aby sprawdzić, czy przypadkiem napięcia nie siadają za
bardzo.

e.

do góry

W dniu 2010-04-01 22:48, TM pisze:
> TM wrote:
>> Co najważniejsze, po zrównaniu potencjałów mas i podłączeniu monitora za
>> pośrednictwem tego "konwertera" z MAX232A do Beckhoffa, Beckhoff zaczął
>> komunikować się z monitorem - odbierać bajty wysyłane przez monitor w
>> momencie dotykania warstwy dotykowej :-)
>>
>> Bardzo dziękuję za tą sugestię! Jeszcze pozostaje instalacja driverów
>> monitora dla Windowsa CE i przetestowanie współpracy z systemem, ale
>> samo uruchomienie komunikacji monitora z Beckhoffem to ogromny postęp
>> :-) .
>>
> Informuję o ostatecznych rezultatach - po instalacji drivera dla Windows
> CE, warstwa dotykowa monitora działa poprawnie we współpracy ze
> sterownikiem CX9001 Beckhoffa.
>
> Jeszcze raz bardzo dziękuję za wszystkie odpowiedzi, szczególnie koledze
> 'Mario', gdyż to dzięki jego sugestii odnośnie mas układów udało mi się
> problem rozwiązać :-) .

Cieszę się, że mogłem pomóc :)


--
Pozdrawiam
MD

do góry

TM pisze:

> Problem mój dotyczy przemysłowego monitora dotykowego z interfejsem
> RS232. Monitor ten przy dotknięciu powłoki dotykowej wysyła przez RS232
> ciąg bajtów. Komunikuje się on bez problemów z komputerem PC
> posiadającym fizyczny port RS232 (wysyłane bajty są odbierane z portu
> RS232 PC np. przy pomocy HyperTerminala), natomiast nie chce
> współpracować z innymi urządzeniami, tj.:
> - sterownikiem Beckhoff CX9001 z modułem CX9000-N030 z dwoma portami
> RS232 (na współpracy monitora z tym urządzeniem najbardziej mi zależy),
> - komputerem PC przez konwertery RS232<->RS485 ADAM 4520 (testowałem
> konfigurację: monitor [RS232] -> ADAM1 <-[RS485]-> ADAM2 -> PC[RS232], w
> której monitor nie komunikował się z PC - aby wykluczyć problemy z
> konwerterami, podłączyłem w miejsce monitora drugi port RS232 PC,
> komunikacja między portami - przesyłanie znaków przez HyperTerminal -
> działała poprawnie).

Nie wiem, jak ten CX9001, ale w przypadku konwertera 485->232 masz
zapewne niepełny port RS, czyli tylko Tx i Rx, prawda? Sądzę, że
domyślnie, w PCcie na którymś pinie portu COM występuje któryś stan
logiczny, podczas gdy w urządzeniach posiadających "niepełny" port COM
pin ten "wisi" ALBO TEŻ domyślnie znajduje się w innym stanie...
Pierwszy mój pomysł był taki, że monitor wymaga transmisji ze
sterowaniem przepływem. Ale jeśli nie - może po prostu jakoś sprawdza
któryś pin albo jest z niego zasilany (w co wątpię - zapewne o zasilaniu
pamiętasz ;)).
Zacząłbym kombinowanie od podłączenia do kompa poprzez jakiś
"zredukowany" kabel (tylko Tx, Rx i masa) i zobaczymy, czy zadziała
:)... Możesz zrobić "przedłużacz" o długości kilku cm z dwóch wtyczek i
3 kabelków ;)... Potem można połączyć pojedynczymi kabelkami i metodą
prób i błędów dojść do tego, które piny są niezbędne do działania...
Szczerze wątpię w to, że w przemysłowym monitorze zastosowano układ
interfejsu RS232, który nie jest zgodny z normą i źle interpretuje
poprawne stany logiczne...

--
Pozdrawiam
Konop

do góry