Upload z PLC Siemens S7 315-2DP celem wykonania opisów - dlaczego nie działa

Witam.

Przyszła kryska na matyska. Myślałem że o PLC co nieco wiem, ale się myliłem. Ostatnio "znalazłem" na moim zakładzie pracy sterownik PLC zabudowany w systemie filtrów do którego nie było projektu PLC. Zrobiłem upload programu ze sterownika, zmieniłem nazwy symboliczne wejść, wyjść, niektórych markerów i niby było ok. Problem pojawił się gdy zacząłem zmieniać nazwy w sekcji Interface bloków FB. Zmienić można, ale nie można zapisać bloku FB. Wywala komunikat save 30:17 (screen).

Poszedłem jeszcze raz na maszynę i ponownie zrobiłem upload ze sterownika i.... po otwarciu bloku FB i próbie zapisania "gołego" bloku FB bez żadnej ingerencji prosto po zgraniu z PLC wyskakuje ten sam błąd. Program PLC działa i jest wgrany w sterownik przez producenta maszyny.

W sekcji stats bloku FB są liczne odwołania do struktur innych bloków FB (screen).

Po ich usunięciu blok spokojnie da się zapisać. Bloki FB do których struktury odwołuje się ten nieszczęsny bloczek FB są oczywiście w projekcie a struktura ich sekcji interface jest spójna z interface bloku z którym mam problem.

Pousuwałem wszystkie dane typu "stat" z bloku a następnie odtworzyłem je zgodnie z tym co było wcześniej. Błąd przy zapisie nadal występuje.

Na kopii tego FB sprawdziłem czy problem występuje gdy usunę część z tych zmiennych lokalnych typu stat (i powiązanych z nimi networków). Blok zapisał się bez problemów (no jeszcze z pointerami problem, ale o tym później będę myślał).

Wszyscy wiemy jak ciężko cokolwiek zrobić w takim projekcie gdy wszystkie używane zmienne mają nazwy "stat" i "temp". Chcę ten projekt jakoś wyprowadzić, dlatego zwracam się do was z prośbą o pomoc, bo mi się pomysły kończą.

Czy możliwe że obszar danych typu stat jest za duży? Ostatni adres to 778.0 + jeszcze obszar samej struktury czyli około 50 bajtów. Jeśli tak to jak udało się stworzyć taki blok FB producentowi maszyny?

Próbowałeś kompilować całość? Prawym na Blocks -> Check Block Consistency. Jakie błędy wtedy zgłasza?
Jeśli możesz to zamieść program.

Nawet nie pomyślałem o skompilowaniu całości

Wywala błędy jak na screenie:


2019_01_05 - projekt z zapisanymi zmianami (tablica symboli)
RSM_1 - niemal goły projekt, ten co ściągałem z PLC jest na innym PG i dziś nie mam dostępu. Tego znalazłem gdzieś na dysku, bo chyba ktoś przede mną już się do tego przymierzał.

Będę jutro od 6, bo zmiana mi się kończy

Witam,

Czasami multiinstancje się dają do wiwatu i trzeba uważać. Taki wsteczny Enginering daje sobie znać. Czasami też nie ma możliwości się cofnięcia z STL do FBD i też pojawiają się "schody".

Poszedłem na obiekt i ponownie zrobiłem upload sterownika. Od razu zrobiłem kompilację całości. Błędy wywaliło, ale w zupełnie innych blokach FB niż poprzednio (jest na screenie)


Jako załącznik zrobiony upload.

Bloku FB1 nadal nie można zapisać, mimo że kompilator w nim akurat błędu się nie dopatrzył.

Dodano po 6 [godziny] 6 [minuty]:

Na razie walczę z opisami w tych blokach w których błędów nie ma, ale jak ktoś ma pomysł jak to działa to chętnie przyjmę wszelkie rady włącznie z tymi typu "po ch.... pan to robisz?" (takie w pracy słyszę od niektórych co bardzo się znają na rzeczy).

Marek_t3 wrote:

chętnie przyjmę wszelkie rady włącznie z tymi typu "po ch.... pan to robisz?"

Dla sportu i dla pokoleń No i jakby sterownik spłonął razem z kartą.
Do rzeczy. Wrzuciłem do Twojego projektu bloki standardowe FB41, FB42 oraz FC105 z biblioteki i wygląda, że się da coś z tym zrobić.
Czasem, jeśli blok używa innego, który nie posiada danych o symbolach (podczas otwierania wyskakuje okienko z informacją). Wtedy trzeba otworzyć i zapisać ten blok, żeby info nie wyskakiwało. Odbudowuje się wtedy dane w wersji offline i "naprawiają się" niektóre zależności.

Pięknie dziękuję.

Blok zapisuje się jak należy

Nigdy bym nie wpadł na to by otwierać inne bloki tylko po to by je zapisać ;)

Dodano po 1 [minuty]:

Temat zostawię jeszcze jako otwarty, bo coś widzę że jeszcze parę kwiatków się urodzi związanych z tym projektem. Już widzę co najmniej dwa, ale najpierw sam pokombinuję i poproóbuję.

Teraz inne pytanko. Jak producent to zrobił że zmienna typu OUT w insterfaces w bloczku FB jest używana jako wejście i przeszło im to przez kompilator. Mi nie przechodzi.
Oczywiście mogę to obejść dodając nową zmienną w STAT typu bool i nią się posługiwać w tych miejscach zaznaczonych na rysunku. Mogę też te OUT8 przenieść do sekcji InOut, lub jeśli ten blok FB jest wywoływany tylko raz równolegle do wysterowania OUT8 dorzucić wysterowanie markera i tam gdzie OUT8 jest użyte jako dana wejściowa podpiąć tego markera. Ale mnie po prostu ciekawi jak oni to zrobili.



Dodano po 1 [godziny] 14 [minuty]:

No i coś nowego mam

Na warsztacie mam taki sterownik CPU o numerze zamówieniowym 315-1AF3-0AB0.

Robię na nim różne próby wgrywając kawałki softu itd. Przy jednej z prób coś nie pykło. No i teraz mam problem, bo nie idzie do sterownika wgrać bloku.. OB1...



Inne bloki można bez problemu wgrywać. Tylko OB1 nie chce się wgrać. Zrobiłem procedurę Clear/reset dostępną w menu PLC/diagnostic/setting, wyczyściłem kartę MMC, wgrałem na kartę program... Nic to nie dało. W dispay accessibles nodes widać wszystkie wgrane bloczki, ale OB1 nie istnieje i nie daje rady go wgrać.



Zastanawiam się czy nie uziemiłem sterownika )

Marek_t3 wrote:

Teraz inne pytanko. Jak producent to zrobił że zmienna typu OUT w insterfaces w bloczku FB jest używana jako wejście i przeszło im to przez kompilator. Mi nie przechodzi.

Teoretycznie taka konstrukcja jest możliwa, ale ja osobiście nigdy nie czytam wejść z zasady.
Co do Twojego kodu to ciekawe z czego to wynika, ale ten blok kompiluje się tylko w STL (z resztą w widoku STL zobaczysz, że z LAD i FBD niejawnie wykonane jest kopiowanie OUT8 na L1.0, a dopiero ta zmienna tymczasowa wchodzi na wejście FC).
Co jeszcze ciekawsze, to po zapisaniu bloku w STL, można przełączyć widok do LAD lub FBD i wszystko wygląda dobrze i można zapisywać zmiany. Dopiero po kompilacji bloku w Check consistency się rozpada, ale tylko pod warunkiem, że kompiluje coś innego niż STL
Można to obejść podając na wejście tego FC np.: OUT8 & OUT8.

Co do OB1, to czy przypadkiem nie zdefiniowałeś w nim czegoś dużego w obszarze Temp? Ogólnie dobrą praktyką jest nie ingerować w obszary bloków OB.
Jeśli nie jesteś pewny to skopiuj OB1 z biblioteki standardowej. Po rozmiarze Twojego wnioskuję, że nie jest to puste OB1.

Masz rację. W ogóle nie wziąłem pod uwagę tego że w moim ob1 w projekcie może być przyczyną problemu. Jutro popróbuję, bo dziś już wracam do domu.

Ja też z reguły nie czytam wyjść, ale nie ja to programowałem Pracuję w utrzymaniu ruchu i na różne "kwiatki" trafiam i często się zastanawiam jak to może działać... Gdy już sam nie umiem dojść czemu jest tak a nie inaczej zadaję pytanie mądrzejszym.

czy to nie jest UF membranowy ?

Tak. Membramowy.