Doporučíte mi datalogger pro 400/230V a 24V?
Hynek Havliš:
Citace: F.Prajza 14.02.2018, 19:26
Pokud vám problikávají logické signály a vypadává IO-Link to vše napájené z jednoho zdroje, pak bych v první řadě vyzkoušel vyměnit zdroj 24V. PLC a ostatní zařízení krátké výpadky nerozhodí, jelikož budou mít v sobě další DC/DC konvertor pro napájení vlastní elektroniky. IO-Link ale běží "přímo" na 24V, dovolená mez je 20-30V, a když se sejde pár špiček mohl by jít zdroj do mžikového proudového omezení(mrkněte na specifikaci IO-Link). Za úvahu by stálo rozdělit napájení 24V na dva zdroje, jeden pro PLC a druhý pro IO-Link, pokud to zapojení umožňuje.
Na tom by mohlo něco být. Výměnu zdroje zvážím (i když, jak jsem psal, s těmito zdroji mám dobré zkušenosti). Ony i ty IO-Link moduly v sobě nějaký zdroj mít budou, ale jsou rozměrově menší, tedy tam budou nutně i menší kondenzátory.
Rozdělení na dva zdroje - staří maráci, kteří mě kdysi učili, by byli určitě pro:), ale poslední dobou jsem dost deformovaný automotive průmyslem = jeden pořádný zdroj na úplně všechno (zjednodušeně řečeno).
Když to tak prokazatelně spolehlivě fugnuje na svařovacích linkách, kde se dělají auta, tak mi už dva zdroje u reletivně nevelké pracovní stanice přijdou jako zbytečný luxus.
Pořád dumám, jestli na to jdeme ze správného konce. Zažil jsem podobnou závadu s RFID bezpečnostními čidly a po dlouhých peripetiích a reklamaci jejich (celkem renomovaný) výrobce prohlásil: Chyba firmware:) - stroj několikkrát týdně spadl do nouzového zastavení od dveří... Po přehrátí firmware vše v pohodě...
A tehdy taky kolem chodili odborníci a říkali souběhy, rušení...
Jan Budai:
A jištění pro 24V je provedeno elektronickým jisticim modulem (něco na styl MICO od murr) nebo jinak?
Pokud ano, zkusil bych hledat závadu zde.
Použity jsou přímo IO link snimace nebo klasicke sensory jsou zapojeny do IO link slucovacu?
Jan Bocek:
Citace: Hynek Havliš 14.02.2018, 19:56
Pořád dumám, jestli na to jdeme ze správného konce. Zažil jsem podobnou závadu s RFID bezpečnostními čidly a po dlouhých peripetiích a reklamaci jejich (celkem renomovaný) výrobce prohlásil: Chyba firmware:) - stroj několikkrát týdně spadl do nouzového zastavení od dveří... Po přehrátí firmware vše v pohodě...
A tehdy taky kolem chodili odborníci a říkali souběhy, rušení...
A je jisté, že "problíkavají" všechny IO signály, anebo jen některé větve.....
typoval bych to na špatné spoje. Zaměřil bych se také na všechny interlogy.
Při revizích mnohých linek nebo NC strojů jsou velice často právě interlogy vyřazovány z provozu. Jsou obvykle zapojeny v obvodech ES a při "probliknutí" shodí celý stroj. A pak jak obsluha tak údržba si "nějak" pomáhá....
Při takových poruchách staří machři učili: rozpojit a vše znovu zapojit. Jenže to nebyly tak obvodově složité stroje. Nedělal se v poslední době na tem stroji nějaký up grade? A řemeslně to někdo zbabral.....ch ce to v odstávce fyzicky projit všechny spoje. Myslím si, že analýzou sítě i napájení nic moc nezjistíte.
F.Prajza:
Upřímně nezávidím vám... :-) Vadných může být spousta věcí, včetně firmware ve snímači, IO-Link masteru, komunikačním bloku v PLC, nebo ve vlastním sw. Analyzujte co jde ze statusu komunikace...s nímač, master, komunikační blok. Zkuste zpomalit komunikaci, pokud to je možné, nejen komunikační rychlost, ale i počet čtení v čase.
Synchronizujte čtení, tak aby v jednom okamžiku komunikoval vždy jen jeden master.
Potom co jsem shlédnul pár katalogových listů výrobců IO-Link masterů a výrobce čipů IO-Link masteru(Maxim), tak bych se ještě více přikláněl k použití samostatného zdroje pro každý víceportový master. Master generuje komunikaci přímo z napájecích 24V, ty slouží také pro napájení snímače, rychlost je relativně pomalá detekční meze H a L relativně široké, ale je tu také spousta dalších proměnných jako např. min.18V pro napájení snímače, aby byl připraven pro "wake-up", který dělá master pomocí proudového impulsu min.0,5A(cca 70-80mikrosec). Je to zkrátka spousta věcí, které se může pokazit jak nekvalitním hw , tak chybami v sw na všech stranách.
Také jsem zažil chyby ve firmware, ale to byl Modbus, resp. Modbus TCP a na analýzu stačí běžné PC, tady to bude složitější. Příklad 1: Modbus RTU rychlost max. dle manuálu, komunikace ok, ale asi jen po dobu několik desítek minut, potom restart přístroje. Zachoval jsem rychlost, ale snížil četnost čtení asi na 1x/30s a vše bylo ok....uznaná chyba firmware.. zařízení v ceně několika desítek tisíc Kč.
Příklad 2: Modbus TCP, komunikace živá, ale jen v odpovědi chybového kodu.....chybn ý kontrolní součet...lehký důkaz z Wiresharku...p rogramátor evidentně vůbec netestoval komunikaci s jiným zařízením...op rava obratem.
Příklad 3:Nefunkční Modbus na S7-300..programátor nepočkal na dokončení příjmu předchozího paketu a vyslal další dotaz dřív, než mu potvrdil komunikační blok dokončení akce.
Hynek Havliš:
Pánové, děkuji_ všem za množsví podnětných názorů.
Svoje jsem prezentoval průběžně. Bohužel já jsem jenom projektant, ty věci, které se více týkají (mohou týkat) SW budu muset řešit ve spolupráci s programátorem.
Včera (během odstávky - na řešní na místě, včetně úprav, jsou k dispozici 2 hodiny týdně) kolega některé snímače přepojil přímo na karty PLC - uvidíme, co se stane (mimochodem, včera opět pozoroval na pneumatickém válci oba sepnuté spínače - po zahýbání válcem normálně vzduchem porucha "zmizela").
Shrnul bych to tak, že podle mého názoru kdykoli se nasadí nová, relativně složitá věc, tak z toho vzniknou jenom problémy.
Zkusím to probrat na Ampéru nezávazně s dodavateli některých výše diskutovaných komponent.
To tuto situaci neřeší, ale je možné si z toho vzít poučení pro příště.
Navigace
[0] Index zpráv
[#] Další strana
[*] Předchozí strana