Być może któryś z klubowiczów spotkał się z takim problemem:
sterownik, wyspa IO zwykle, wyspa IO bezpieczne, 5x Lenze falowniki o mocy max 5,5kW, ETAP, wszystko spięte w DLR
moduly IO bezpieczne przechodzą w krótkotrwały błąd, na module sieciowym AENTR miga na czerwono dioda bus status
powoduje to zadziałanie systemu bezpieczeństwa i zatrzymanie maszyny
występuje całkowicie losowo, na postoju, w trakcie klikania (estop np.), w trakcie ruchów rzadziej
Konfiguracja sieciowa jest defaultowa, ponieważ niewiele się tam zmienia, moduły IO są skonfigurowane poprawnie, moduł sieciowy również - uruchamiałem już kilka systemów z identycznym zestawem IO i połączeń i nie miałem takich sytuacji.
Podejrzenia: uszkodzenia sprzętowe.
Pytanie: czy ktoś spotkał się z podobnymi objawami lub jak wykluczyć uszkodzony moduł?
A wersje firmware/rewizje wszystkich urządzeń są takie same?
Napisałeś, że na modułach safe IO pojawia się błąd, ale nie napisałeś jaki. Jeśli nie jesteś w stanie sprawdzić jaki, bo sytuacja dzieje się losowo to zawsze można napisać kod do logowania błędu tego modułu.
Napisałem kawałek kodu rejestrującego kod błędu modułu (GSV -> fault code) ale nic nie wykrywa, sterownik też nie loguje błędów niestety.
Jak ustawiłem opcje „Major Fault On Controller If Connection Fails While in Run Mode” w konfiguracji wyspy to sterownik przechodził w błąd, ale nie logował żadnej informacji dlaczego wystąpił ten błąd.
Oprócz GSV -> Module -> FaultCode możesz jeszcze spróbować GSV -> Module -> EntryStatus, żeby sprawdzić czy wykryje zmianę stanu na tym module i na jaki.
Pozostaje mi jeszcze doradzić wgranie najnowszych firmware, gdzie tylko się da, a potem jak to nie pomoże zadzwonić na pomoc techniczną do RAControls (pewnie też doradzą podniesienie rewizji do najnowszych - jak zawsze).
Mieliśmy podobną sytuację - winowajcą było obciążenie prądowe (za dużo modułów za jednostką komunikacyjną), takie na granicy. W konfiguratorze pokazywało że jest wszystko ok, natomiast na obiekcie wyspa się “sypała” raz na jakiś czas. Pomogło “rozszczepienie” wyspy na dwie osobne. Tu widzę, że samych modułów jakoś strasznie dużo nie ma, ale może to będzie dobry kierunek dla ewentualnej diagnostyki.
Nie jest to kwestia zbyt dużej ilości modułów niestety.
Udało mi się zarejestrować takie informacje - poniżej:
Fault code:
16#0203 (d505), Connection Timed Out, target can be reached but does not respond
Entry status history: chronologia od dołu w górę
16#4000 (d16384) Running. All connections to the module are established and data is transferring.
16#3000 (d12288) Connecting. The Module object is initiating connections to the module.
16#7000 (d28672) Waiting. The parent object upon which this Module object depends is not running.
16#2000 (d8192) Validating. The Module object is verifying Module object integrity prior to establishing connections to the module.
16#1000 (d4096) Faulted. Any of the Module object’s connections to the associated module fail. This value should not be used to determine if the module failed because the Module object leaves this state periodically when trying to reconnect to the module. Instead, test for Running state (16#4000). Check for FaultCode not equal to 0 to determine if a module is faulted. When Faulted, the FaultCode and FaultInfo attributes are valid until the fault condition is corrected.
16#0000 (d0) Standby. The controller is powering up.
16#5000 (d20480) Shutting down. The Module object is in the process of shutting down all connections to the module.
Pomoc dla tego błędu dostępna na stronie Rockwella (https://rockwellautomation.custhelp.com/app/answers/detail/a_id/62938):
The POINT I/O, ArmorPOINT I/O and ArmorBlock modules should be used with the latest firmware on Ethernet device bridge modules. This module fault is mostly seen when using newer versions of these modules with older firmware ethernet modules and controllers. If using the adapter or blocks with a 1756-ENBT module, 1768-ENBT module or Control/CompactLogix processor, use the following required firmware versions for these modules:
1756-ENBT firmware version 4.006 or greater
1768-ENBT firmware version 2.003 or greater
1788-ENBT firmware version 2.4 or greater
Processor firmware version 17 or greater.
Note: Earlier revisions may work, but have not been tested to check if they successfully connect.
If all firmware revisions are compatible there may be other reasons for this error. Refer to 50924 - Difference in 16#0203 and 16#0204 for information on troubleshooting
Wykluczasz to rozwiązanie problemu? Moduły inne, ale może do Twojej sytuacji też pasuje.
Jak masz tyle informacji odczytanych z modułu to proponuję też maila do RAControls na pomoc techniczną.
podejrzewamy, że za zakłócenia winny jest 1783-ETAP i wstępnie testy potwierdzają, że był przyczyną, dam znać po odbiorach. Wstępnie wiadomo, że DIP switche wszystkie były ustawione na OFF, przy czym pierwsze dwa odpowiadają za konfigurację adresu (czy to DHCP/static itp.), natomiast trzeci odpowiada za DLR supervisor:
ON: Enables Ring Supervisor mode with the current supervisor-related parameters(2)
OFF: Allows Ring Supervisor mode and supervisor-related parameters to be enabled and configured by software
Po zmianie OFF-> ON, przestały występować problemy z siecią (przynajmniej chwilowo)
Cześć
Stawiam na problem z backplane. Jak nasz podobną wyspę to podmień podstawki i obserwuj czy problem się “przeniósł”. Jeśli masz możliwość to złóż wyspę bez zapinania na listwie DIN, może coś źle jest złożone i np. wibracje maszyny powodują “niekontakt” na magistrali.