TIA Portal edycja offsetów w DB, PLC tags vs DB

Witam kolegów po fachu mam dwa pytania odnośnie DB/plc tags

  1. Chciałbym zapytać czy jest sposób na ręczną edycje adresów offsetów w DB w TIA Portal v13. Wiem tyle, że po odznaczeniu “optimized block acces” oraz kompilacji nowego DB TIA Portal przydziela automatycznie adresy


    Czy jest jakiś sposób gdzie mogę w tym oknie zmienić ręcznie te adresy? np. zamiast 0.1 chciałbym 2.0 itp.

  2. Oraz chciałbym się dowiedzieć jaka jest różnica jeśli zmienne do komunikacji z HMI/SCADA będę zapisywał w PLC tags a jeśli utworze do tego specjalny blok DB

Z góry dziękuje za odpowiedzi i zaangażowanie w pomoc początkującym :wink:

  1. Sposób jest ale osobiście nie polecam, adresowanie bezpośrednie prowadzi w ostateczności do dramatu podczas diagnostyki i adresowanie po nazwie jest jedyną słuszną metodą

  2. Są dwie główne różnice:
    2.1. Tagi możesz dowolnie dodawać bez wpływu na pozostałe dane (tagi), natomiast zmiana w datablocku prowadzi do konieczności reinicjalizacji,
    2.2. na szczęście jest od którejś w wersji TIA Portal mechanizm snapshot pozwalający na zrobienie “zdjęcia” danych i późniejsze przepisanie

  3. Niepisana zasada z jaką się spotkałem podczas pisania programów różnych producentów (TIA/Studio5k/Automation Studio/Sysmac) jest taka, że globalne tagi służą głównie do IO i danych globalnych, natomiast DB’ki i zmienne lokalne służą wewnątrz poszczególnych programów - w świecie Siemensa jest to trudne do zobrazowania bo wszystko jest jednym wielkim programem, co u innych producentów jest rzadko spotykane.

  4. Co do wymiany ze SCADA/HMI, polecam stworzenie DB_HMI (przykładowa nazwa) i mapowanie danych program <> DB_HMI, tak aby móc dowolnie zmieniać rzeczy w programie bez wpływu na wymianę danych ze światem, pozwala to uniknąć wielu roboczogodzin podczas zmian

No dobrze, robię specjalnego DB’ka do komunikacji z HMI gdzie zdefiniuje sobie stany alarmowe. Załóżmy, że dla przejrzystości programu chce zrobić

0.0 - podprogram 1 alarm 1
0.1 - podprogram 1 alarm 2
0.2 - podprogram 1 reset alarmów

1.0 - podprogram 2 alarm 1
1.1 - podprogram 2 reset alarmu

Mój tok rozumowania jest taki żeby jeden bajt (0-7) przydzielić do alarmów konkretnego podprogramu zostawiając rezerwę. Czy stosuje się takie rozwiązanie dla lepszej czytelności? Jeśli tak to jak właśnie przydzielić adresy zmiennych w offsetach tak aby kilka bitów zostało wolnych?

Wg mojej wiedzy nie ma. To kwestia zarządzania pamięcią i wykonuje się to automatycznie.

Można zarządzać pamięcią przypisywaną do tagów PLC, ale wydaje mi się, że nie da się edytować pamięci w DB. Jeśli rzeczywiście się da to bardzo chętnie dowiem się jak.

Różnica polega na tym, że zmienne PLC tags i DB niezoptymalizowane to adresowanie absolutne, a DB zoptymalizowane to adresowanie symboliczne. Ogółem w dzisiejszych czasach przeważa adresowanie symboliczne.
Ponieważ zmienne są wyszukiwane po nazwie komunikacja jest szybsza jeśli nazwy zmiennych są krótsze.

Rozwiązanie z jakim miałem ostatnio do czynienia - od strony SCADY, to zdefiniowana struktura w S7, którą czytam jako całość w SCADzie. Struktura ma zdefiniowane słowa - rozkaz, status, alarmy itd. Czytam strukturę przy pomocy skryptu zmieniając tylko offset, wszystkie czytane struktury są czytane tylko z jednego DB - DB100.DBW[offset]
Zysk jest taki że zużywam tylko 20 bajtów licencji czytając 20 urządzeń. Każdy przeczytana struktura jest ładowana do zmiennych lokalnych - skrypt odświeża dane cyklicznie. To tak w skrócie od strony praktycznej.
W innej aplikacji bez struktury dla każdego urządzenia były zdefiniowane 2 słowa, alarmy były zamknięte w jednym DB z którego cyklicznie były czytane słowa i ładowane lokalnych zmiennych.
Cał zabieg upychania alarmów w słowa jest dla oszczędzenia ilości wykorzystanych linków PLC-SCADA.
1 bajt słowa i jeden bit podłączony bezpośrednio ze SCADą zajmuje 1 punkt licencji - tak jest w większości programów. Część programów nie liczy zmiennych wewnętrznych do licencji więc takie zabiegi przepisywania zmiennych czytanych cyklicznie dają wierną finansową korzyść.