Witam kolegów po fachu mam dwa pytania odnośnie DB/plc tags
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.
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
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ą
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
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.
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
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ść.
