Rozjeté vzorkování u komunikace po RS485 – Hardware – Fórum – Programujte.com
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu

Rozjeté vzorkování u komunikace po RS485 – Hardware – Fórum – Programujte.comRozjeté vzorkování u komunikace po RS485 – Hardware – Fórum – Programujte.com

 
Hledat
Moderní platforma pro vytvoření vašeho nového webu – Wix.com.
Nyní už můžete mít web zdarma.
Vytvořte si vlastní webové stránky. Snadno, rychle a levně přes Saywebpage.com
Vybavení pro Laser Game
Spuštěn Filmový magazín
Laser Game Brno
Laser Game Ostrava

Toto vlákno bylo označeno za vyřešené.
Navara0
Newbie
24. 2. 2020   #1
-
0
-

Zdravím,

Mám problém s komunikací dvou počítačů po sběrnici 485. Použitá technologie: na jedné straně průmyslový počítač AutoCont s komunikační kartou MOXA IC-132, na druhé straně jakýkoliv počítač, který má mým vlastním programem simulovat PLC, připojené k tomu průmyslovému počítači.

Nejprve jsem pomocí převodníku 485/232 a terminálu poslouchal jak moxa vysílá opakovaně jakási data. Podle specifikace protokolu by to měl být telegram s obsahem 10-00-21-69-6A-16 (hex). Komunikační rychlost 2400 baud je známá, zbytek nastavení neznámý. Při použití jakéhokoliv nastavení parity, počtu bitů ve znaku a počtu stopbitů však výstup na terminálu poslouchajícího PC neodpovídal, nebo odpovídal jen částečně (první a poslední znak apod). Zkusil jsem tedy odposlech osciloskopem a logickým analyzáorem, ze kterého vypadlo krásně čitelných 66 bitů, tedy 6 znaků po 11 bitech, které přesně odpovídaly znakům 100021696A16 se sudou paritou a jedním stopbitem. Nastavení přenosu by tedy mělo být 2400bd 8/O/1.

Ověřoval jsem pomocí osciloskopu rychlost komunikace, zda si "neujíždí" vzorkování, a podezření se potvrdilo. Pokud správně počítám, při 11 bitech (startbit + 8bitů znak + parita + 1 stopbit) a rychlosti 2400 by se mělo přenášet 26400 bitů za sekundu, což znamená 0.0378ms na jeden bit. Když vysílá moxa v průmyslovém počítači, trvá jí jeden bit 0.0384ms a když vysílá můj PC pomocí redukce, trvá mu jeden bit 0.0418ms.

Předpokládal bych, že tak jak je můj PC zabrzděn při odesílání dat, bude zabrzděn i při vzorkování přijímaného signálu, takže vzorkuje o něco pomaleji než dostává data, a tím vzniká v některých místech přenosu přeslech, a lezou z něj jen mírně poškozená data (například namísto 10-00-21-69-6A-16 terminál vypisuje 10-00-01-7F-90-16, odpovíá začátek a konec kde se náhodou vzorkování zrovna "trefilo").

Můj dotaz tedy zní - existuje způsob, jak srovnat (mírně zrychlit do nějakého tolerančního rámce) vzorkování na straně obyčejných PC s převodníkem 485/232 (popřípadě 485/USB - vyzkoušel jsem několik převodníků na několika počítačích, USB redukce i nativní COM porty, výsledky byly vesměs obdobné)?

Je nutné zůstat u nastavení 2400bd 8/O/1, SW v průmyslovém PC to tak má napevno nastavené.

Díky, N.

Nahlásit jako SPAM
IP: 46.135.41.–
Navara0
Newbie
24. 2. 2020   #2
-
0
-

Oprava... počítám to špatně, každopádně změřená hodnota platí, jeden bit trvá průmysláku 0.384ms a převodníku na druhé straně 0.418.

Nahlásit jako SPAM
IP: 46.135.41.–
gna
~ Anonymní uživatel
1114 příspěvků
24. 2. 2020   #3
-
0
-

Tak zkus netrvat na těch hodnotách a vyzkoušej, jestli ti to skousne to, co pozoruješ. 2600 E.

Nahlásit jako SPAM
IP: 213.211.51.–
24. 2. 2020   #4
-
0
-

Jak máš zapojený hardware? Při připojování jednočipů na COM a pokusech o navázání komunikace jsem zjistil, že často zapojení RxD, TxD a GND nestačí. Je potřeba na straně PC ještě propojit další piny konektoru. Jestli si dobře vzpomínám, odpovídalo to zapojení null modem. Při pokusech s převodníky USB - UART zase stačilo použít softwarové řízení, pokud data obsahují např. <CR> pak xOn, xOff. nikdy jsem neměřil baudrate na straně PC, měl jsem za to, že je generováno hardwarově dělením kmitočtu krystalu a tedy přesné.

hu
 

Nahlásit jako SPAM
IP: 2001:af0:ffe4:85f4:1d9f:d535:1fd0:92e7...–
Navara0
Newbie
24. 2. 2020   #5
-
0
-

Ono je to celé trošku jinak, já jak jsem to špatně spočítal tak se ukázal problém přesně obráceně.

Ve skutečnosti je to tak, že moje strana je v pořádku, 1 bit má být 0.416ms a moxa má 1 bit 0.384ms, takže moxa je mírně rychlejší než by měla být. Celý systém je 20 let starý, celé to běží na DOSu a nejspíš to počítá i s pomalejším železem. Překvapivé je že na tom stejném průmyslovém počítači se to před zrušením v ostrém provozu provozovalo také a PLC s tím nemělo problém.  

Uživatelské baudrate mi jen tak nějaký HW a terminál nenabídne, ve svém SW se o to pokusit mohu, jen mám obavu že to neprojde právě přes HW. Mám za to, že oscilátor pro sběrnici je věc té karty, takže podtaktovat ten průmyslák nejspíše nepomůže. Maximálně bych mohl v turbopascalu (dělám v Delphi) napsat něco co by používalo standardní 232 port a tvářilo se pro ten řídící SW jako ser-drv který používá ta moxa... Asi by to bylo zdlouhavé a je otázka jestli to vůbec pomůže a nebude klasický com taky rychlejší. 

Zapojení v originále bylo po 422 čtyřmi vodiči, nic dalšího (tedy bez GND, viděl jsem konektory, použito jen 1+2 Tx, 3+4 Rx), moxa je přepínatelná mezi 422 a 485 a převodník na duplexní 422 jsem zkoušel též, při obojím byl problém stejný - průmyslák vysílá prostě o trošku rychleji než by měl. 

Nahlásit jako SPAM
IP: 46.135.46.–
25. 2. 2020   #6
-
0
-

Spočítej si odchylku - pokud jsem dobře počítal, dělá to 8%, což je hodně. Otázka je, jak přesně jsi měřil a jak přesná je časová základna osciloskopu. Spíš bych hledal problém v nastavení na straně PC který to má přijímat. Zapojení konektoru jako null modem bylo u PC s XP a vyšší nutností. Zajímavé je, že na starých křápech s W98 jsem tohle nikdy neřešil a vždy to fungovalo. Dále je důležité mít v terminálu správně nastavený Start bity, délku dat, paritu a Stop bity. V tomto případě se možná stalo, že jsi zapomněl na paritu, která není až tak obvyklá. Po těchto obvyklých věcech bych pak v nouzi zkusil na straně PC uživatelský baudrate. Pokud to neumí použitý COM, zkusil bych nějaký USB-COM u kterého by to mohlo jít nastavovat (tuším FTDI to uměly)

Pokud opravdu vysílá vyšší rychlostí, zajímal bych se o příčinu, např. vadný krystal.

hu

Nahlásit jako SPAM
IP: 195.178.67.–
Navara0
Newbie
26. 2. 2020   #7
-
0
-

Problém je skutečně v krystalu.

Porovnával jsem použité krystaly svých karet a karet u kolegů se stejným zařízením, a moje karta jelikož patřila původně k jinému zařízení, měla záměrně vyměněn krystal za jiný a vzhledem ke stáří zařízení se na to nejspíše zapomnělo...

V kartě mám napíchnutý AEL 1210BSN 16.000MHz namísto původního 14.7456MHz. Již je objednán správný, tak doufám že nahrazení problém vyřeší. Podám info.

Nahlásit jako SPAM
IP: 46.135.43.–
26. 2. 2020   #8
-
0
-

Krystal 16MHz bude asi příčinou. Pak to opravdu vychází na tebou naměřené hodnoty. Navíc, co jsem kde viděl, baudrate nikde nebyl odvozován z krystalu s "celými" MHz, vždy to bylo nějaký desetinný číslo.

Vůbec jsem nepředpokládal nějakou takovou úpravu. Její pravý smysl mi uniká.

hu

Nahlásit jako SPAM
IP: 195.178.67.–
Navara0
Newbie
29. 2. 2020   #9
-
0
-

Výměna (naštěstí volně vyměnitelného - patice) krystalu opravdu zabrala. 

Účel prý vycházel z dříve (počítej na desetiletí) používaných komponent systému které to vyžadovaly.

Nahlásit jako SPAM
IP: 46.135.38.–
Zjistit počet nových příspěvků

Přidej příspěvek

×Vložení zdrojáku

×Vložení obrázku

Vložit URL obrázku Vybrat obrázek na disku
Vlož URL adresu obrázku:
Klikni a vyber obrázek z počítače:

×Vložení videa

Aktuálně jsou podporována videa ze serverů YouTube, Vimeo a Dailymotion.
×
 
Podporujeme Gravatara.
Zadej URL adresu Avatara (40 x 40 px) nebo emailovou adresu pro použití Gravatara.
Email nikam neukládáme, po získání Gravatara je zahozen.
-
Pravidla pro psaní příspěvků, používej diakritiku. ENTER pro nový odstavec, SHIFT + ENTER pro nový řádek.
Sledovat nové příspěvky (pouze pro přihlášené)
Sleduj vlákno a v případě přidání nového příspěvku o tom budeš vědět mezi prvními.
Reaguješ na příspěvek:

Uživatelé prohlížející si toto vlákno

Uživatelé on-line: 0 registrovaných, 2 hosté

Podobná vlákna

Komunikace — založil Zelenáč

Com komunikace v C — založil Bedla

Asynchronní komunikace — založil Jan Knížek

 

Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032020 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý