Doporučíte mi datalogger pro 400/230V a 24V?

[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...sní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...programátor evidentně vůbec netestoval komunikaci s jiným zařízením...oprava 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ě.

[Jan Bocek]

.....(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.

Možná jen zdánlivě nesouvisející poznámka.
Tam, kde je HW ve špatném stavu, tak nasazení automatizace způsobí realizátorům jen značné problémy. Na příklad odměřování délek se značnou přesností, kdy mechanika má značné vůle.
Již bylo napsáno, když se sejdou chyby HW a SW, tak je co řešit. Na začátku je ale špatný předpoklad. ( špatná analýza problému)

[Hynek Havliš]

Ano Honzo, to je pravda. Nicméně tento stroj je zánovní (pokud mě paměť neklame, asi rok a půl starý) a složený z kvalitních komponent (PLC Siemens, elektrické osy + pneumatika Festo, IO-Link zařízení Balluff... - veškerá kabeláž a díly originální).
Mechanika provedená rozumně a odpovídá místnímu (léty ověřenému) standardu i prostředí.
Takže tady se úplně nešetřilo a problémy prostě jsou (mimochodem, ty RFID bezpečnostní spínače, jak píšu výše, byly také na tomto stroji).

[Miroš Jan]

Hynku, ososbně bych prošel veškeré spoje. :)
Nám se jednou stalo, že se přerušil komunikační kebel uprostřed energořetězu, závada se projevovala velice nahodsile. Nakonec jsme kabel odpojily, vytáhly z energořetězu, a ejhle, opravdu byl přerušený. Povrchově se nic nenašlo. :(

[Jan Bocek]

Problém je v tom, že poruchy se vyskytují náhodně, bez zjevné příčiny a s frekvencí např. 1x denně.

S podobnou situaci se každý v oblasti elektro u strojního zařízení setkal.
Pokud jsem vedoucí projektu, musím ale situaci řešit.
Elektrikáři již ručí za správnost zapojení a dobré spoje.
Programátoři nenašli žádnou chybu.
Pracovník MaR také za vše ručí
Projektant tvrdí, že je to obvodově O.K.

Pak sestavím auditorské otázky.

1) na jaké směně se porucha projevuje  a jméno operatora
2) při poruše je nějaká souvislost se stejným tg procesem
3) výsledky diskuse se všemi operátory a lídrem výroby
4) lze zúžit místo poruchy na některý obvod stroje
5) jsou zde "zajímavé" signály údržby ( na příklad svítící ledky obou poloh válce)
6) není nastavená zbytečně rychlá sekvence mezi operacemi stroje
7) výsledky diskuse z jednotlivými aktéry projektu

Jako vedoucí projektu musím najít řešení. Některá opatření pro mnohé se mohou zdát i nesmyslná. Někdy jsem nařídil vyměnit některé části HW a někdy i personální změny v týmu. Nic není bez zjevné příčiny. Jsou je skryté....a často zde hraje roli i lidský faktor. Ale i technicky sladit desítky autonomních systému je role dirigenta....někde to skřípe a nakonec se ukáže špatně připojené opletení nějakého kabelu. A nikoho to nenapadlo ani ve snu....

Hynku, držím ti palce a věřím, že Tvé zázemí elektro do 3-4 generace ti také pomůže.
A až najdeš příčinu, budeme se divit.....