Proč jsou údaje o údržbě nezbytné pro spolehlivost průmyslových zařízení
Údržbová data propojují pracovní příkazy, signály ze senzorů, historii zařízení, náklady a znalosti techniků. Při správném využití zlepšují plánování, spolehlivost, prediktivní údržbu, kontrolu náh...
Přerušovaný nekontrolovaný rozjezd saní je událostí ohrožující bezpečnost stroje
Osa, která se pohybuje bez očekávaného příkazu, není běžná závada při uvádění do provozu. Jde o událost nekontrolovaného pohybu, která může poškodit nástroje, konstrukci stroje, obrobky, přípravky i osoby. Riziko se hůře řídí, když se saně po mnoho hodin chovají normálně a poté se náhle pohybují neočekávanou rychlostí nebo neočekávaným směrem.
Stroj popsaný v tomto případě používá Siemens SIMATIC S7-200 CPU 226, jednotku SIMOVERT MASTERDRIVES pro osy saní, měnič MICROMASTER 440 pro vřeteno a ovládací panel TP 170A. Příkazová a stavová data se přenášejí prostřednictvím sériové komunikační sítě USS.
Uvedený problém se vyskytuje na jedněch nebo obou saních. K události může dojít jednou či dvakrát během pracovního dne, po čemž následují dva nebo tři dny normálního provozu. Předchozí pokusy zahrnovaly oddělení vřetenového frekvenčního měniče od hlavního rozvaděče a zlepšení uzemnění. Tato opatření závadu neodstranila.
Tento průběh často vede ke spekulativnímu hledání závady. Technici mohou vyměnit enkodér, přesměrovat kabel, upravit parametr měniče nebo přidat další uzemňovací vodič. Jedna změna může dočasně změnit příznak a vyvolat dojem, že problém byl vyřešen. Událost se poté vrátí, protože skutečná cesta příkazu nebyla nikdy prokázána.
Spolehlivé šetření musí určit první okamžik, kdy se očekávané chování stane abnormálním. Tým musí vědět, co požadoval HMI, co přijal PLC, co PLC odeslalo, co přijala měničová jednotka, co měnič interně aktivoval a co skutečně provedl motor.
Bezpečnostní varování: Po nekontrolovaném pohybu saní nepokračujte v testování výroby bez dozoru. Zajistěte nezávislou ochranu proti překročení zdvihu, omezte přístup, snižte dostupnou rychlost a sílu a před zahájením diagnostického provozu ověřte odborně navržený způsob zastavení.
Začněte potvrzením každého instalovaného zařízení
Starší systémy Siemens často zůstávají v provozu dlouho poté, co původní tým pro uvedení do provozu odešel. Ve výkresech mohou být ručně zapsané změny. Zálohy parametrů mohou být neúplné. Náhradní moduly mohly být osazeny bez aktualizace dokumentace. Identifikace hardwaru proto musí předcházet interpretaci parametrů.
Z výrobního štítku každého zařízení opište úplné objednací číslo. Nespoléhejte pouze na strojopisný seznam zařízení. Uvedené číslo CPU S7-200 obsahuje znaky, které mohly být nesprávně opsány. Skutečný řídicí systém může odpovídat zařízení Siemens 6ES7216-2BD23-0XB0 SIMATIC S7-200 CPU 226, napájecí zdroj a varianta výstupů však musí být potvrzeny přímo na instalovaném zařízení.
Jediný nesprávný znak může vést k použití nesprávné příručky, schématu svorek nebo náhradního dílu. Písmeno O se často zaměňuje za nulu. Číslice jedna se může zaměnit za písmeno I. Chybějící přípona může také skrývat důležitou hardwarovou volbu.
Stejná kázeň platí pro jednotku SIMOVERT MASTERDRIVES. MASTERDRIVES je široká produktová řada, nikoli jeden pevně daný návrh pohonu. Řídicí desky, verze softwaru, možnosti enkodéru, technologické desky a konfigurace Vector Control nebo Motion Control mohou měnit dostupné parametry a interní směrování signálů.
Je také nutné ověřit objednací číslo MICROMASTER 440. Ačkoli MM440 řídí vřeteno, nikoli saně, sdílí prostředí rozvaděče a může sdílet komunikační cestu USS. Jeho spínací události, vedení kabelů, konfigurace adres a časování komunikace mohou ovlivňovat celý systém.
Zaznamenejte model TP 170A, verzi projektu HMI, nastavení komunikace a připojené adresy PLC. Panel může obsahovat události tlačítek, funkce receptur, spouštěcí hodnoty nebo chování tagů, které nelze identifikovat pouze z programu PLC.
Před změnou jakéhokoli parametru vytvořte úplné zálohy programu PLC, projektu HMI, sady parametrů MASTERDRIVES a sady parametrů MM440. Vyfotografujte stínění kabelů, přepínače na deskách, připojení svorek a volitelné moduly. Tato výchozí dokumentace umožní porovnat každou pozdější úpravu a v případě potřeby ji vrátit zpět.

Definujte, co obsluha rozumí nekontrolovaným pohybem
Slovo „nekontrolovaný pohyb“ může označovat několik různých událostí. Zrychlení na plnou rychlost se liší od krátkého nechtěného pohybu jogem. Pohyb během spouštění se liší od pohybu během automatické sekvence. Diagnostický postup se mění podle přesného průběhu události.
Vyslechněte každou osobu, která byla svědkem poruchy. Ptejte se na pozorování, nikoli na závěry. „Selhal enkodér“ je závěr. „Saně se rychle pohybovaly v kladném směru, zatímco HMI zobrazovalo nulovou rychlost“ je pozorování.
Zaznamenejte dotčenou osu, směr, odhadovanou rychlost, dobu trvání, počáteční polohu, režim stroje, stav vřetena, aktivní krok programu a způsob, kterým byl pohyb zastaven. Určete, zda pohyb začal z klidu, nebo vznikl během již probíhajícího pohybu.
Pokud se saně zrychlují směrem k maximální rychlosti, prověřte polaritu zpětné vazby, aktivní zdroje požadované hodnoty, pořadí povolování a regulaci pohonu. Pokud se pohybují pouze o krátkou vzdálenost, prověřte bity jogu, duplicitní spouštění náběžnou hranou, zastaralé příkazy a přechody stavů sekvence.
Pokud se událost objevuje pouze v automatickém režimu, je logika sekvence významnější. Pokud se objevuje i v ručním režimu, zaměřte se na arbitráž povelů sdílenou oběma režimy. Pokud se osa pohybuje během zapnutí napájení, přechodu CPU, resetu pohonu nebo opětovného připojení HMI, je třeba okamžitě prověřit inicializaci při spuštění.
Chování při zastavení poskytuje cenné důkazy. Pokud odstranění signálu PLC pro povolení pohonu zastaví osu, výkonový stupeň může stále reagovat na očekávanou cestu povolení. Pokud pohyb pokračuje až do odpojení hlavního napájení, prověřte hardware pohonu, externí zapojení povolení, chování stykačů a zdroje povelů mimo PLC.
Zjistěte také, zda pohon vygeneroval varování nebo poruchu. Událost bez poruchy nedokazuje, že pohon byl v pořádku, ale naznačuje, že pohon mohl považovat povel a zpětnou vazbu za platné.
Považujte stroj za kompletní řetězec povelů
Povel k pohybu může začínat na ovládacím panelu TP 170A. Tlačítko, číselný vstup, receptura, událost obrazovky nebo automatická sekvence nastaví paměťovou hodnotu v PLC. S7-200 tento požadavek ověří a vypočítá rychlost nebo žádanou hodnotu pohybu. Komunikační rutina USS poté sestaví telegram obsahující řídicí a procesní data.
Jednotka MASTERDRIVES přijme telegram a předá řídicí slovo a žádanou hodnotu svou interní strukturou signálů. Konečný aktivní povel může také zahrnovat pevné rychlosti, analogové vstupy, povely na svorkách, doplňkové žádané hodnoty, vstupy pro krokování nebo interní funkční bloky.
Zpětná cesta je stejně důležitá. Motor nebo zátěž může používat inkrementální enkodér, resolver, tachometr nebo jiné zařízení zpětné vazby. Pohon tento signál interpretuje jako otáčky nebo polohu. Některé skutečné hodnoty pak mohou být přenášeny do PLC.
Mechanické koncové spínače, snímače nulové polohy, spínače překročení pojezdu, stykače, brzdy a kontakty připravenosti pohonu vytvářejí další cesty. Každá z nich může ovlivnit, zda se pohyb zahájí, pokračuje nebo zastaví.
Každá fáze by měla mít měřitelnou hodnotu. V PLC zaznamenávejte surový požadavek z HMI, zvolený provozní režim, stav sekvence, konečnou validovanou žádanou hodnotu, směr, povel k aktivaci a výsledek komunikace. Na pohonu sledujte přijaté řídicí slovo, přijatou žádanou hodnotu, aktivní interní žádanou hodnotu, skutečné otáčky, stav zpětné vazby, proud, varování a poruchy.
Nula zobrazená na HMI nedokazuje, že PLC vyslalo nulu. Nula v jednom registru PLC nedokazuje, že jiný zdroj povelu byl neaktivní. Správný telegram USS nedokazuje, že pohon byl nakonfigurován tak, aby tento telegram používal jako jediný zdroj žádané hodnoty.
Šetření by mělo určit první místo, kde se očekávaná hodnota neshoduje se zaznamenanou hodnotou. Tento bod rozděluje problém na logiku HMI, aplikaci PLC, komunikaci, konfiguraci pohonu, zpětnou vazbu, výkonovou elektroniku nebo mechaniku.

Nejdůležitější diagnostické rozdělení
První technická otázka je jednoduchá: obdržel pohon oprávněný příkaz k pohybu?
Během události porovnejte čtyři hodnoty:
- Konečná zadaná hodnota pohybu z PLC.
- Zadaná hodnota přijatá pohonem.
- Aktivní interní zadaná hodnota pohonu.
- Skutečný naměřený pohyb motoru nebo suportu.
Pokud se konečná zadaná hodnota v PLC stane nenulovou a pohon ji sleduje, může pohon fungovat správně. Nežádoucí pohyb vznikl v nadřazené části systému. Prověřte události HMI, sekvenční logiku, zachované hodnoty, přechody mezi režimy a vícenásobné zápisy do konečného příkazu.
Pokud konečná zadaná hodnota pohybu v PLC zůstává nulová, ale pohon přijímá nenulovou hodnotu, prověřte sestavení telegramu, mapování paměti, měřítko, zpracování vyrovnávací paměti a provádění komunikačního bloku. Přesná neočekávaná hodnota může určit mechanismus. Opakující se pevná hodnota často ukazuje na zachovaná nebo zastaralá data. Extrémní kladná nebo záporná hodnota může signalizovat problém s číslem se znaménkem nebo pořadím bajtů.
Pokud pohon přijímá nulu, ale jeho aktivní interní zadaná hodnota se stane nenulovou, prověřte konfiguraci pohonu. Aktivní může být pevná rychlost, analogová reference, funkce jog, vstup svorkovnice, doplňková zadaná hodnota, motorizovaný potenciometr nebo technologická volba.
Pokud zadaná hodnota z PLC, přijatá zadaná hodnota i interní zadaná hodnota zůstávají nulové, zatímco motor zrychluje, je událost závažnější. Prověřte chování zpětné vazby, regulaci pohonu, napájení řídicí desky, hardware pohonu, chování výstupního stupně a mechanické spojení.
Tato metoda se čtyřmi signály brání nekontrolované výměně součástí. Zároveň vytváří technicky obhajitelný závěr. Porucha je určena podle zaznamenaných důkazů, nikoli podle předpokladů.
Zpětná vazba je podezřelá s vysokou prioritou, nikoli však automatickým důkazem
Přerušovaná porucha enkodéru nebo tachometru je možná, zejména když se událost mění v závislosti na vibracích, teplotě, pohybu kabelu nebo poloze suportu. Předpoklad, že jakákoli ztráta zpětné vazby automaticky způsobí maximální rychlost, je však příliš obecný.
Správně nakonfigurovaný pohon by měl obvykle detekovat chybějící nebo nepravděpodobnou zpětnou vazbu a reagovat podle nastavení monitorování a poruch. Přesná reakce závisí na verzi řídicího systému, možnosti zpětné vazby, konfiguraci a aplikaci.
K nebezpečnému chování může dojít i tehdy, když je zpětnovazební signál přítomen, ale nesprávný. Opačná polarita, nesprávná fáze, nestabilní amplituda signálu, poškozené kanály, nesprávný typ enkodéru, nesprávné měřítko, uvolněné spojky nebo nevhodná konfigurace regulátoru mohou způsobit, že pohon zareaguje nesprávným směrem.
Přerušovaný výpadek kabelu se zřídka projeví jako dokonale rozpojený obvod. Jeden vodič se může oddělit pouze při ohnutí kabelu. Pin konektoru může ztratit kontakt jen při silných vibracích. Napájení enkodéru může poklesnout při sepnutí stykače. Proud ve stínění může zkreslit jeden diferenciální kanál, aniž by signál zcela zanikl.
Porovnejte skutečnou rychlost hlášenou měničem s nezávislým měřením. Ruční otáčkoměr, dočasně připojený ověřený snímač nebo vhodné měření osciloskopem může zjistit, zda interní skutečná hodnota odpovídá fyzickému pohybu.
Pokud měnič hlásí nulovou rychlost, zatímco se hřídel otáčí, je podezřelá cesta zpětné vazby. Pokud měnič hlásí správnou rychlost, zatímco se příkaz stává nesprávným, zpětná vazba může fungovat normálně.
Nikdy neprovádějte test zpětné vazby tak, že vystavíte osoby pohybujícímu se suportu. Použijte zábrany, sníženou rychlost, řízené testovací podmínky a nezávislý způsob zastavení.
Zkontrolujte celý obvod zpětné vazby
Systém zpětné vazby zahrnuje více než jen enkodér. Snímač, mechanická spojka, kabel, konektor, napájení, stínění, způsob uzemnění, vstupní deska i konfigurace měniče ovlivňují měřenou hodnotu.
Začněte mechanickým spojením. Ověřte, že hřídel enkodéru, řemen, ozubené kolo ani pružná spojka nemohou prokluzovat. Zkontrolujte náboje spojky, pera, stavěcí šrouby, praskliny, znečištění a nesouosost. Mechanicky odpojený enkodér může dál vytvářet signál, který již neodpovídá skutečnému pohybu zatížení.
Každý konektor prohlédněte při dobrém osvětlení a se zvětšením. Hledejte zatlačené kontakty, nekvalitní krimpy, ohnuté piny, korozi, znečištění olejem, poškozené odlehčení tahu a napnutí kabelu. Ověřte, že náhradní konektory používají správný typ kontaktů.
Kontinuitu testujte s odpojeným strojem, ale nespoléhejte pouze na statickou zkoušku odporu. Přerušený vodič může při narovnání vést a při ohnutí se rozpojit. Během schváleného testu s nízkým rizikem sledujte signál zpětné vazby, zatímco se kabelový nosič pohybuje v rámci běžného pracovního rozsahu.
Změřte napájení enkodéru přímo u enkodéru při provozním zatížení. Stabilní napětí uvnitř rozvaděče nedokazuje, že napětí zůstává stabilní u snímače. Zaznamenejte minimální hodnotu během zrychlování vřetena, reverzace osy, brzdění a činnosti stykače.
U inkrementálního enkodéru zkontrolujte amplitudu kanálů, jejich symetrii, fázový vztah a případně indexový impulz. Diferenciální páry by měly zůstat vyvážené. Výboje rušení, chybějící impulzy nebo pokles amplitudy mohou signalizovat problémy s kabelem, stíněním, napájením nebo snímačem.
Ověřte typ enkodéru, počet impulzů, polaritu, měřítko a zdroj zpětné vazby v sadě parametrů nainstalovaného měniče. Nepředpokládejte, že číslo parametru z jiného manuálu MASTERDRIVES platí pro tuto řídicí desku.

Chyby USS by neměly být redukovány na náhodné změny bitů
Komunikace USS probíhá prostřednictvím strukturovaného telegramu. Protokol zahrnuje kontrolu chyb, takže poškozený telegram by měl být obvykle odmítnut, nikoli přijat jako nesouvisející platná požadovaná rychlost.
To neznamená, že lze USS ignorovat. Problémy s komunikací mohou k nekontrolovanému rozběhu stále přispívat chováním aplikace. PLC může vytvořit nesprávné slovo procesních dat. Podepsaná hodnota může být interpretována nesprávně. Může dojít k prohození vyššího a nižšího bajtu. Ve vysílacím bufferu mohou zůstat stará data. Pokud odpověď chybí, může zůstat aktivní předchozí požadovaná hodnota.
Matoucí chování mohou způsobovat také duplicitní adresy slave zařízení. Každý měnič v síti musí mít jedinečnou adresu. Sekvence dotazování PLC musí každou odpověď přiřadit ke správnému slave zařízení a správné oblasti paměti.
Řídicí slovo si zaslouží stejnou pozornost jako požadovaná rychlost. Měnič může zůstat aktivní, zatímco program PLC předpokládá, že byl zastaven. Potvrzení poruchy, příkazy ZAP/VYP, bity směru a logika restartu mohou být během obnovování komunikace zpracovány nesprávně.
Počítejte úspěšné transakce, vypršení časových limitů, odmítnuté rámce, po sobě jdoucí chyby a události obnovení komunikace. Jediný bit „porucha komunikace“ poskytuje příliš málo informací. Diagnostická data by měla určovat, který slave byl dotazován a která transakce selhala.
U měniče MICROMASTER 440 souvisí parametr P2010 s konfigurací přenosové rychlosti USS. Neměl by být považován za obecné nastavení časového limitu telegramu. Parametr P2011 se běžně spojuje s adresou USS. Význam všech parametrů je však stále nutné ověřit ve správném manuálu MM440 a v konfiguraci rozhraní.
Delší časový limit není automaticky bezpečnější. Pokud měnič během čekání na vypršení časového limitu nadále používá předchozí nenulovou požadovanou hodnotu, prodloužení této prodlevy může prodloužit nežádoucí pohyb. Nejprve definujte požadovanou reakci na ztrátu komunikace.
Na fyzické vrstvě RS-485 stále záleží
I když jsou poškozené rámce odmítnuty, nestabilní síť RS-485 může způsobovat opakované pokusy, zastaralá data, vynechané aktualizace stavů a nepravidelné časování aplikace. Fyzická síť proto vyžaduje kompletní kontrolu.
Dokumentujte sběrnici od komunikačního portu S7-200 ke každému měniči. Ověřte, že zapojení používá správnou liniovou topologii. Dlouhé odbočky ve tvaru hvězdy mohou vytvářet odrazy a je třeba se jim vyhnout, pokud je dokumentace nainstalovaného rozhraní výslovně nepovoluje.
Ověřte, že všechna zařízení používají shodné komunikační nastavení. Patří sem přenosová rychlost, parita, struktura telegramu, délka procesních dat a adresa slave zařízení. Nastavení si zaznamenejte, místo abyste je měnili zpaměti.
Ukončení musí odpovídat požadavkům konkrétních rozhraní a konektorů Siemens. Obecný rezistor 120 ohmů by se neměl přidávat automaticky. Nesprávné zakončení nebo předpětí může zhoršit signál.
Zkontrolujte typ komunikačního kabelu, spojitost stínění, propojení konektorů a vedení kabelů. Kabel RS-485 by neměl být na dlouhé vzdálenosti veden podél výstupních kabelů motoru, vodičů brzdného rezistoru, kabeláže stykačů ani jiných vysokofrekvenčních výkonových obvodů.
Tam, kde je oddělení omezené, křižujte napájecí a signální kabely přibližně v pravém úhlu. Zajistěte záměrné ekvipotenciální pospojování mezi rozvaděči a částmi stroje. Vyhněte se dlouhým vývodům stínění, které snižují účinnost při vysokých frekvencích.
V případě potřeby použijte vhodnou diferenciální sondu osciloskopu ke kontrole průběhu signálu. Hledejte odrazy, nadměrné napětí v souhlasném režimu, doznívající kmity, pomalé hrany, krátké výboje rušení a změny amplitudy při zrychlování vřetena nebo brzdění osy.
Připojený notebook nebo převodník USB může změnit uzemnění a zatížení sběrnice. Zaznamenejte, zda se porucha změní po připojení diagnostického zařízení.
Komponenty používané v průmyslové komunikaci a síťování by měly být posuzovány společně s topologií, stíněním, zakončením, adresováním a zpracováním transakcí v PLC. Výměna jednoho konektoru slabý stavový automat komunikace neopraví.

Zkontrolujte program S7-200 jako stavový automat
Přerušované poruchy při uvádění do provozu se často objevují během přechodů, nikoli při ustáleném provozu. Stroj se může při nepřetržitém chodu chovat správně, ale selhat při přepnutí mezi ručním a automatickým režimem, dokončení najíždění do výchozí polohy, zotavení po alarmu, změně receptury nebo obnovení komunikace.
Prohledejte křížové odkazy programu a vyhledejte každou instrukci, která zapisuje do proměnných konečné rychlosti, směru a povolení. Starší programy často zapisují stejné slovo V-paměti v několika sítích. Výsledek určuje poslední provedený zápis, což může vytvářet chování, které působí náhodně.
Vytvořte jednu jasně vymezenou fázi arbitráže příkazů. Ruční krokování, automatický pohyb, najíždění do výchozí polohy, nastavovací funkce a údržbové příkazy by do této fáze měly vstupovat jako samostatné požadavky. Konečná žádaná hodnota by měla být generována až po ověření režimu, limitů, zpětné vazby, komunikace a bezpečnostních podmínek.
Zkontrolujte logiku jednorázových impulzů a detekce hran. Příkaz určený pouze pro jeden cyklus může zůstat aktivní, protože jeho paměť hrany byla znovu použita, zachována nebo přepsána. Příkaz se také může znovu spustit při změně bitu režimu.
Prozkoumejte každou západku. Určete podmínku, která ji nastavuje, a každou podmínku, která ji resetuje. Pohybová západka závislá pouze na pozdějším kroku sekvence může zůstat aktivní, pokud je sekvence přerušena poruchou.
Zkontrolujte zpracování znaménkových dat. Záporné celé číslo interpretované jako neznaménkové slovo se může změnit na velkou kladnou hodnotu. Při násobení může dojít k přetečení. Slovo zkopírované v nesprávném pořadí bajtů může vytvořit extrémní žádanou hodnotu.
Ověřte škálování z technických jednotek na procesní hodnotu USS. Kladné a záporné limity aplikujte až po finálním výpočtu, nikoli pouze na vstupu HMI.
Starší řídicí systémy Siemens SIMATIC S7 mohou spolehlivě fungovat po desetiletí, ale jejich aplikace často obsahují úpravy z několika fází uvádění do provozu. Strukturovaná kontrola křížových odkazů je cennější než předpoklad, že se hardware CPU stal nestabilním.
Stavy spuštění a obnovení vyžadují samostatné testování
Neinicializovaná nebo zachovaná data mohou způsobit vzácný pohyb po přerušení napájení, stažení softwaru, přechodu CPU ze STOP do RUN, resetech pohonu nebo opětovném připojení HMI.
Identifikujte všechny oblasti retentivní paměti používané programem pohybu. Určete počáteční hodnotu příkazu rychlosti, směru, povolení, režimu, kroku sekvence, bitů jogování a stavu komunikace po každém typu restartu.
Spouštěcí rutina by měla nastavit všechny požadavky na pohyb na nulu. Měla by vymazat čekající příkazy jogování a automatického provozu, ověřit zpětnou vazbu, potvrdit stav koncových spínačů, navázat komunikaci a vyžadovat záměrnou novou sekvenci povolení.
Zachovaná nenulová žádaná hodnota se nikdy nesmí aktivovat pouze proto, že se pohon připraví dříve, než PLC dokončí inicializaci.
Otestujte studený start, teplý restart, přechod CPU ze STOP do RUN, reset pohonu, opětovné připojení HMI a obnovení komunikace se selhavším USS slave. Tyto testy provádějte s mechanicky zajištěným strojem a sníženou dostupnou rychlostí.
Během napájecích událostí sledujte řídicí napájení 24 V. PLC, enkodér, HMI, komunikační rozhraní, stykače a řídicí elektronika pohonu se mohou resetovat při různých napěťových prahových hodnotách. Krátký pokles napětí může ponechat jedno zařízení v chodu, zatímco jiné se restartuje.
Zaznamenejte pořadí zapnutí řídicího napájení, přechodu PLC do režimu RUN, navázání správné komunikace, připravenosti pohonu, uvolnění brzdy a povolení pohybu. Toto pořadí musí být jednoznačné a opakovatelné.
HMI může vytvářet příkazy, které už nejsou viditelné
Projekt TP 170A musí být přezkoumán společně s programem PLC. Příkaz z HMI může být zapsán při stisknutí tlačítka, uvolnění tlačítka, otevření obrazovky, zavření obrazovky, stažení receptury, aktualizaci tagu nebo obnovení komunikace.
Tlačítko pro krátké jogování může vytvořit nebezpečný stav, pokud stisknutí nastavuje bit a uvolnění jej maže. Pokud během stisknutí tlačítka selže komunikace, příkaz k vymazání se do PLC nemusí nikdy dostat.
Obsluha později vidí neuvolněné tlačítko, ale bit v PLC zůstává aktivní. Jiný přechod režimu nebo povolovací podmínka pak může umožnit, aby se zastaralý požadavek ručního posuvu dostal do výsledného příkazu pohybu.
Robustní funkce ručního posuvu by neměla spoléhat pouze na dvojici stisknutí a uvolnění. PLC by mělo vyžadovat průběžné obnovování příkazu, použít krátkou dobu platnosti, ověřit provozní režim a při neplatné komunikaci příkaz odstranit.
Zkontrolujte každou událost HMI spojenou s ručním posuvem, zadáním rychlosti, směrem, resetem, volbou režimu, najížděním do referenční polohy a řízením automatického cyklu. Vyhledejte duplicitní značky odkazující na stejnou adresu PLC.
Číselné vstupy vyžadují kontrolu rozsahu jak v panelu, tak v PLC. PLC musí odmítnout hodnoty mimo povolený technický rozsah, i když pole HMI vypadá správně nakonfigurované.
Starší systémy Siemens SIMATIC HMI mohou obsahovat chování na úrovni obrazovek, které není v logice PLC viditelné. Samostatné zaznamenávání nezpracované značky HMI vedle ověřeného příkazu PLC pomáhá určit skutečný zdroj příkazu.
MM440 může ovlivnit událost, aniž by řídil posuv
MICROMASTER 440 řídí vřeteno, ale přesto může ovlivňovat prostředí řízení posuvu. Jeho vstupní usměrňovač, stejnosměrný meziobvod, motorový výstup, brzdný obvod a spínací frekvence mohou vytvářet rušení vedené po vodičích nebo vyzařované.
Nejsilnější rušení může vznikat při zrychlování, zpomalování, proudových špičkách nebo brzdění vřetena, nikoli při ustáleném provozu. Porovnejte časová razítka nekontrolovaného rozjezdu se stavem vřetena.
Zaznamenávejte spuštění a zastavení vřetena, změny rychlosti, proud, stav stejnosměrného meziobvodu, historii poruch a brzdění. Zjistěte, zda ke každé události dochází během podobného přechodu stavu vřetena.
Pokud MM440 a jednotky MASTERDRIVES sdílejí sběrnici USS, vřeteno ovlivňuje také časování komunikace. PLC musí dotazovat každý podřízený přístroj předvídatelně a zpracovat každou odpověď ve správné paměťové struktuře.
Ověřte, že datové oblasti USS vřetena a posuvu se nepřekrývají. Aplikace Compact S7-200 někdy znovu používají paměť V bez jasného oddělení. Blok zapisovaný pro vřeteno může přepsat část příkazu posuvu.
Přemístění MM440 mimo rozváděč jeho vliv zcela neodstraní. Kabely motoru, uzemňovací cesty, vedení komunikace a sdílené napájecí zdroje mohou zůstat propojené.
Používejte měření, nikoli opakované přemisťování. Prověřte oddělení kabelů, připojení stínění, síťové tlumivky nebo filtry určené pro měnič, pospojování rozváděče, zakončení kabelu motoru a časovou souvislost mezi spínacími událostmi a chybami komunikace.
Audit MASTERDRIVES podle funkce signálu
Audit parametrů MASTERDRIVES by měl sledovat celou signálovou cestu. Nezačínejte seznamem čísel parametrů zkopírovaným z jiné instalace.
Nejprve ověřte nainstalovanou verzi řízení, vydání softwaru, řídicí desku a volbu zpětné vazby. Poté zkontrolujte režim řízení, data motoru, typ zpětné vazby, škálování zpětné vazby a zdroj zpětné vazby.
Identifikujte každý zdroj, který může řídit příkazy ZAPNUTO/VYPNUTO pohonu. Může jít o řídicí slova USS, svorkové vstupy, pevné příkazy, interní binektorová propojení nebo technologické funkce.
Identifikujte každý zdroj, který může přispívat ke konečné žádané hodnotě rychlosti nebo polohy. Zkontrolujte hlavní žádanou hodnotu, doplňkové žádané hodnoty, pevné rychlosti, funkce pomalého posuvu, analogové vstupy, funkce motorizovaného potenciometru a interní funkční bloky.
Zkontrolujte kladné a záporné limity rychlosti, rampy zrychlení, rampy zpomalení, proudové limity, momentové limity a omezení směru. Konzervativní dočasná nastavení mohou snížit diagnostické riziko, ale nepředstavují nezávislou bezpečnostní ochranu.
Prověřte monitorování zpětné vazby a reakci na poruchu. Zjistěte, co je pohon nakonfigurován udělat, když zpětná vazba chybí, je nestabilní, obrácená nebo nepravděpodobná.
Před vymazáním načtěte historii varování a poruch pohonu. Varování, které se zdá nesouvisející, může zaznamenávat okamžik změny řídicí podmínky.
K prohlížení interních konektorů a skutečných hodnot použijte nainstalovanou inženýrskou metodu, například DriveMonitor, PMU, OP1S nebo jiné schválené rozhraní. Hodnoty vybírejte podle konkrétní verze řízení.
Tento funkční přístup se vztahuje na starší i současné systémy pohonů a řízení pohybu Siemens. Řídicí software, možnosti zpětné vazby a interní směrování se mohou lišit, i když dva pohony vypadají fyzicky podobně.
Vytvořte záznamník událostí se spouštěním
Událost, ke které dochází jednou denně, nelze vyřešit nepřetržitým sledováním HMI. Systém potřebuje diagnostický záznamník, který zachytí období před abnormálním pohybem i po něm.
Vytvořte kruhový buffer PLC obsahující nezpracovaný příkaz z HMI, ověřený příkaz, konečnou žádanou hodnotu rychlosti, směr, povolení, režim, stav sekvence, vstupy koncových spínačů, stav připravenosti pohonu, výsledek transakce USS a čítač vzorků.
Na pohonu zachyťte přijaté řídicí slovo, přijatou žádanou hodnotu, aktivní interní žádanou hodnotu, skutečnou rychlost, stav zpětné vazby, výstupní proud, proud vytvářející točivý moment, pokud je k dispozici, varování a poruchy.
Spouštěcí podmínkou může být skutečná rychlost vyšší než malý práh, zatímco konečný příkaz PLC je nulový. Jiná spouštěcí podmínka může detekovat pohyb mimo schválený stav sekvence. Záznam může spustit také nesoulad mezi požadovaným a naměřeným směrem.
Zachovejte data před spuštěním. Pokud se záznam začne pořizovat až po pohybu saní, iniciační podmínka již může být pryč.
Komunikační diagnostika by měla rozlišovat úspěšné transakce, chybějící odpovědi, odmítnuté zprávy, po sobě jdoucí chyby a události obnovení. Zaznamenejte, který podřízený účastník byl během chyby aktivní.
Diagnostickou logiku udržujte stručnou. S7-200 má omezenou paměť a kapacitu skenování. Ověřte, že zaznamenávání nenarušuje časování stávajících rutin USS.
Po každé události data exportujte. Ukládejte je s datem, stavem stroje, protokolem svědka a veškerými fyzickými pozorováními. Posloupnost několika událostí může odhalit vzorec, který jedna událost odhalit nedokáže.
Používejte diagnostické čítače, které zodpovídají konkrétní otázky
Čítače jsou užitečné pouze tehdy, když je jejich význam jasný. Obecný čítač příkazů a obecný čítač zpětné vazby se mohou z mnoha běžných důvodů lišit.
Počítejte každý přijatý požadavek HMI na pohyb. Počítejte každý příkaz pohybu přijatý konečnou arbitráží PLC. Počítejte každý úspěšně dokončený přenos USS. Počítejte každou platnou odpověď přijatou od pohonu osy.
Počítejte také komunikační časové limity, události, kdy pohon není připraven, aktivace limitů, změny režimu a vypršení platnosti příkazů.
Ukládejte poslední odeslanou hodnotu rychlosti a řídicí slovo. Ukládejte poslední platnou přijatou skutečnou hodnotu a stavové slovo. Pokud je to praktické, přidejte do struktury příkazu pořadové číslo.
Při výskytu události mohou čítače zodpovědět několik otázek:
- Vygenerovalo HMI požadavek?
- Schválilo PLC tento požadavek?
- Odeslal PLC nový telegram?
- Vrátil pohon platnou odpověď?
- Začal skutečný pohyb bez nového schváleného příkazu?
Čítač by se neměl automaticky resetovat při každém spuštění, pokud jeho historická hodnota není nepotřebná. Zvažte ukládání čítače událostí v retentivní paměti a současné nastavení samotných příkazů pohybu na bezpečnou spouštěcí hodnotu.
Nezávislá ochrana proti překročení pojezdu nesmí záviset na běžné logice
Softwarové limity polohy jsou užitečné, ale nemohou být jedinou obranou proti poruše, která může vzniknout v programu PLC, komunikační cestě nebo běžném regulátoru pohonu.
Každá osa by měla mít správně navrženou ochranu proti překročení koncové polohy. V závislosti na posouzení rizik stroje to může zahrnovat pevně zapojené koncové spínače, bezpečnostní snímače polohy, bezpečnostní relé, obvody blokování pohonu, stykače, brzdy nebo jinou ověřenou architekturu.
Standardní vstup PLC, který zapisuje příkaz nulové rychlosti, není automaticky bezpečnostní funkcí. Stejná chyba logiky, která pohyb vyvolala, může zabránit zpracování tohoto příkazu k zastavení.
Odstranění požadované rychlosti rovněž nezaručuje odstranění točivého momentu. Pohon může zůstat aktivní, může zůstat aktivní sekundární požadovaná hodnota nebo může uložená mechanická energie nadále pohybovat zátěží.
Nezávisle otestujte nouzové zastavení, blokování ochranných krytů, koncové spínače, kontakty poruchy pohonu, brzdy a stykače. Ověřte, že po aktivaci ochrany vyžaduje opětovné spuštění vědomý zásah.
Během diagnostického provozu snižte maximální rychlost, zrychlení, moment a podle technických možností i dostupný rozsah pohybu. Dočasné mechanické dorazy se smí použít pouze tehdy, pokud jsou navrženy pro možnou energii nárazu.
Žádný diagnostický cíl neospravedlňuje vystavení člověka ose, která již prokázala nekontrolovaný pohyb.
Příklad: Kabel, který selhává pouze při změně směru
Představte si sanici, která se při pomalé statické zkoušce chová normálně, ale při rychlé změně směru se prudce pohybuje. Protokol PLC ukazuje stabilní příkaz. Záznam pohonu ukazuje náhlé rušení měřené rychlosti, po němž následuje velký korekční výstup.
Zkouška průchodnosti kabelu enkodéru při zastaveném stroji projde. Kabel však prochází pohyblivým energetickým řetězem. Jeden vodič je nalomený u minimálního poloměru ohybu a rozpojí se pouze tehdy, když řetěz dosáhne určité polohy.
Měření osciloskopem na vstupu pohonu ukáže zhroucení jednoho kanálu enkodéru během změny směru. Příkaz zůstává správný a není zaznamenána žádná porucha USS.
Kabel se nahradí správným typem pro trvalé ohýbání. Obnoví se odlehčení tahu a zakončení stínění. Napájení enkodéru a kvalita průběhu signálu se otestují v celém rozsahu pohybu sanice.
Konečné ověření zahrnuje opakované změny směru při snížené rychlosti, po nichž následuje řízený provoz běžnou výrobní rychlostí. Nový průběh signálu v pořádku se uloží jako referenční.
Tento případ ukazuje, proč je třeba poruchu zpětné vazby ověřit dynamicky. Statická zkouška odporu může projít, i když kabel během provozu selhává.
Příklad: Příkaz ke krokování přetrvá po ztrátě komunikace HMI
U jiného stroje stisknutí tlačítka krokování nastaví bit PLC. Uvolnění tlačítka jej vynuluje. Během držení tlačítka dojde ke ztrátě komunikace HMI, takže příkaz k uvolnění se do PLC nikdy nedostane.
V daném okamžiku jiná blokace brání pohybu. Zastaralý bit krokování zůstává skrytý. Později obsluha změní režim stroje. Konečná logika PLC nyní přijme starý požadavek na krokování a sanice se nečekaně pohne.
Pohon se řídí platnou žádanou hodnotou z PLC. Komunikace USS je při zahájení pohybu v pořádku. Výměna enkodéru ani přidání dalšího připojení stínění problém nevyřeší.
Upravená logika PLC vyžaduje průběžně obnovovaný požadavek na krokování. Platnost příkazu po krátké době vyprší. Je přijat pouze ve správném režimu, při platné komunikaci a splnění požadované podmínky povolení.
Logika při spuštění vymaže všechny požadavky na pohyb. Akce uvolnění na HMI zůstává, ale již není jediným mechanismem, který odstraňuje příkaz.
Záznamník událostí potvrzuje, že nezpracovaný bit HMI zůstal aktivní i po předchozím selhání komunikace. Příčinou nebylo poškození komunikace, ale nebezpečné zpracování platného, avšak zastaralého příkazu.
Příklad případu: Rušení odhalí slabé zpracování bufferu USS
U třetího stroje dochází při zrychlování vřetena k časovým limitům USS. Poškozené telegramy jsou odmítnuty, takže síť přímo nepřevádí jeden příkaz rychlosti na jiný.
Aplikace PLC však po neúspěšné transakci nezneplatní předchozí příkaz osy. Rutina USS navíc běží podmíněně, což vytváří nepravidelné intervaly dotazování.
Během přechodu mezi sekvencemi se nový nulový příkaz zapíše na jedno místo v paměti, zatímco přenosový buffer stále obsahuje starší nenulovou hodnotu. Následující úspěšný telegram odešle platná, ale zastaralá data.
Měnič obdrží správně strukturovaný příkaz a reaguje normálně. Rušení na fyzické vrstvě odhalilo slabinu softwaru, místo aby přímo vytvořilo požadovanou hodnotu.
Nápravné opatření zlepšuje vedení kabelů a připojení stínění. Komunikační rutina PLC je následně přepracována tak, aby každý měnič používal vyhrazenou paměť. Konečná ověřená požadovaná hodnota se zkopíruje do přenosového bufferu bezprostředně před transakcí.
Nepřijatá odpověď označí data jako neplatná. Naprogramovaná reakce na ztrátu komunikace se ověřuje řízeným testováním.
Tento případ ukazuje, proč musí řešení problémů s komunikací pokrývat elektrický průběh i životní cyklus aplikačních dat.
Praktický postup vyšetřování přímo na místě
Krok 1: Zajistěte stroj. Zajistěte nezávislou ochranu proti přejetí, snižte zkušební energii a omezte přístup personálu.
Krok 2: Potvrďte hardware. Zaznamenejte úplná objednací čísla, verze softwaru, volitelné desky, snímače zpětné vazby a rozhraní.
Krok 3: Vytvořte zálohy. Uložte program S7-200, projekt TP 170A, sadu parametrů MASTERDRIVES a parametry MM440.
Krok 4: Definujte událost. Zaznamenejte směr, rychlost, dobu trvání, provozní režim, polohu, stav vřetena a chování při zastavení.
Krok 5: Zmapujte řetězec příkazů. Identifikujte každý zdroj požadované hodnoty, povolení, směru, pevné rychlosti, krokování a doplňkové reference.
Krok 6: Přidejte synchronizované protokolování. Zachycujte příkazy PLC, data USS, interní hodnoty měniče, zpětnou vazbu, proud, limity, varování a poruchy.
Krok 7: Testujte stavy spouštění. Prověřte studený start, teplý restart, přechody CPU do režimu RUN, opětovné připojení HMI a obnovení komunikace.
Krok 8: Dynamicky kontrolujte zpětnou vazbu. Testujte napájecí napětí, kvalitu průběhu, vazbu, konektory, stínění a ohýbání kabelu.
Krok 9: Proveďte audit USS a RS-485. Zkontrolujte adresování, topologii, zakončení, datové oblasti, časování a zpracování chyb.
Krok 10: Prověřte křížové reference PLC. Najděte každý zápis do výsledné žádané hodnoty, směru a povolení měniče.
Krok 11: Proveďte audit směrování signálů měniče. Ověřte každý zdroj příkazu a každý prvek přispívající k aktivní žádané hodnotě.
Krok 12: Měňte vždy pouze jednu položku. Zaznamenejte původní stav, nový stav, důvod, výsledek testu a způsob návratu k předchozímu stavu.
Dlouhodobé zvýšení odolnosti musí řešit architekturu
Po nalezení bezprostřední příčiny se ptejte, proč mohla jediná porucha vyvolat nebezpečný pohyb. Jediný timeout komunikace, přerušení kabelu nebo chyba HMI by neměly obejít všechny ochranné vrstvy.
Oddělte generování příkazů, ověřování příkazů, přenos komunikace, řízení měniče a bezpečnostní ochranu. Každá vrstva by měla mít jasně definovanou odpovědnost.
PLC by mělo generovat omezený příkaz ověřený z hlediska stavu. Komunikační rutina by měla přenášet aktuální data s jasnou platností a čerstvostí. Měnič by měl uplatňovat nakonfigurované provozní limity a monitorovat zpětnou vazbu. Nezávislé bezpečnostní funkce by měly řídit nebezpečný pohyb.
Zvažte, zda architektura S7-200 a USS zůstává podporovatelná. Migrace na novější platformu PLC a měničů může zlepšit diagnostiku, časová razítka, dostupnost komponent, přehled o síti a správu záloh.
Novější síť automaticky neznamená, že je stroj bezpečný. Samotný PROFINET nenapraví slabou arbitráž příkazů, špatnou logiku spuštění ani nedostatečnou ochranu proti překročení pojezdu.
Modernizace by měla zahrnovat HMI, výkresy, řízení verzí softwaru, bezpečnostní architekturu, strategii náhradních dílů a školení personálu. Výměna pouze PLC může problém přesunout na jinou platformu.
U náročných polohovacích aplikací vyhodnoťte, zda by se profil pohybu neměl provádět v dedikovaném měniči nebo pohybovém kontroléru namísto opakovaného odesílání sériových příkazů rychlosti. Správné rozhodnutí závisí na přesnosti polohování, synchronizaci, době cyklu, architektuře zpětné vazby a rizicích stroje.
Ověření je víc než čekání na návrat poruchy
Sedm dní bez incidentu je povzbudivých, ale nedokazuje to odstranění kořenové příčiny. Ověření by mělo záměrně reprodukovat podmínky, které dříve zvyšovaly riziko.
Provádějte opakované cykly s plným pojezdem při řízené rychlosti. Zahrňte rychlé změny směru, zrychlování vřetena, brzdění vřetena, zahřátý rozvaděč, maximální běžné zatížení a pohyb kabelového nosiče.
Opakujte testy spuštění a zotavení. Cyklicky zapínejte řídicí napájení podle schváleného postupu. Otestujte přechod CPU ze STOP do RUN, reset měniče, opětovné připojení HMI, výpadek jednoho podřízeného zařízení USS a obnovení komunikace.
Ověřte reakci na poruchu zpětné vazby pomocí schválené testovací metody. Neodpojujte enkodér ve výrobním provozu, pokud jsou pracovníci vystaveni pohybu.
Otestujte každý hardwarový limit, softwarový limit, vstup poruchy měniče, nouzové zastavení, brzdu a nezávislé zařízení pro omezení pojezdu. Potvrďte požadovanou reakci při zastavení a chování při opětovném spuštění.
Během každého testu porovnávejte konečný příkaz PLC, příkaz přijatý měničem, aktivní interní žádanou hodnotu a skutečný pohyb.
Před testováním definujte kritéria přijetí. Vhodná kritéria mohou zahrnovat:
- Žádný nezamýšlený pohyb během jakéhokoli spuštění nebo zotavení.
- Žádná nezpracovaná porucha komunikace USS.
- Po ztrátě komunikace HMI nezůstává žádný příkaz k pohybu.
- Stabilní napájení zpětné vazby a průběh signálu v celém rozsahu pojezdu.
- Správná funkce každého nezávislého zařízení pro omezení pojezdu.
- Zaznamenaná shoda mezi příkazem, přijatou žádanou hodnotou, aktivní žádanou hodnotou a skutečným pohybem.
Během počátečního provozu udržujte záznamník událostí v chodu. Úspěšné nápravné opatření by mělo odstranit jak fyzický příznak, tak abnormální diagnostický vzorec, který jej způsobil.
Kořenová příčina se objeví tam, kde se signály poprvé rozcházejí
Přerušovaný nekontrolovaný rozjezd saní v systému Siemens S7-200 a MASTERDRIVES by neměl být bez důkazů připsán „šumu“, „enkodéru“ nebo „USS“.
Rozhodující metodou je porovnat konečný příkaz PLC, příkaz přijatý měničem, aktivní interní žádanou hodnotu a skutečnou mechanickou odezvu.
Pokud se příkaz PLC stane nesprávným, prozkoumejte HMI a aplikační logiku. Pokud se přenášená nebo přijímaná hodnota stane nesprávnou, prozkoumejte práci s pamětí, škálování, konstrukci telegramu a síť RS-485.
Pokud měnič aktivuje zdroj příkazu, který PLC nezamýšlelo, zkontrolujte interní konfiguraci měniče. Pokud všechny příkazy zůstávají bezpečné, zatímco motor zrychluje, prozkoumejte zpětnou vazbu, napájení řídicí desky, hardware měniče a mechaniku.
Poruchy zpětné vazby zůstávají věrohodné, ale musí se testovat jako celé obvody. Problémy USS zůstávají věrohodné, ale neaktuální platná data a slabá logika zotavení jsou často pravděpodobnější než náhodně poškozený telegram, který se stane platným příkazem maximální rychlosti.
Stroj by se měl vrátit do běžného provozu až poté, co je účinná nezávislá ochrana, spouštěcí mechanismus je podložen zaznamenanými důkazy a řízené testování ověřilo jak nápravné opatření, tak reakci na budoucí poruchy.
Tento disciplinovaný přístup vyžaduje více přípravy než spekulativní výměna komponent. Přináší také hodnotnější výsledek: stroj, jehož dráha pohybu je pochopena, zaznamenána, zdokumentována a chráněna před další jednotlivou poruchou.