A: Tak - drajwery do komunikacji ze sterownikami Beckhoff umożliwiają taki szybki odczyt danych. Inne drajwery nie ,  ale istnieje  "furtka", która pozwala wymusić odczyt zmiennych z innym okresem ( krótszym ) niż zadeklarowany w module Asmen. Należy w tym celu utworzyć prosty skrypt w VBS lub JScript. Dla optymalizacji procesu odświeżania zmiennych (obciążenia kanału komunikacyjnego) zaleca się wyłączać mechanizm szybkiego odświeżania, gdy nie jest ono niezbędne.

A: Ponieważ , format %nd stosuje się do zmiennych czterobajtowych, stałoprzecinkowych (integer). W przypadku zmiennych z funkcją przeliczającą NIC należy użyć formatu %nhd, gdzie n oznacza liczbę znaków w treści alarmu.

A: Funkcja konwersji trendów dostępna w module Architekt systemu asix5 umożliwia przekonwertowanie plików *.DAT zawierających definicje trendów utworzonych w starszych wersjach asixa do formatu definicji trendów w plikach *.TRNX, obsługiwanych przez najnowszą wersję programu AsTrend 5 zawartą w pakiecie asix5.

Konwerter wywoływany jest z poziomu Architekta z menu Narzędzia. Wymaga podania ścieżki dostępu do źródłowego pliku *.DAT z definicją trendów, wskazania bazy definicji zmiennych, w której zdefiniowane są zmienne trendów oraz zadeklarowania katalogu wyjściowego, do którego zapisane zostaną nowe trendy.

Konwersja umożliwia zachowanie wszystkich dotychczasowych ustawień konwertowanych trendów oraz dodanie nowych cech w oparciu o wzorcowy plik *.TRNX, który można zadeklarować w opcjonalnym polu konwertera. W przypadku różnych wartości tej samej własności trendu, pierwszeństwo mają ustawienia z pliku *.DAT.

Zastosowanie konwertera trendów pozwala zminimalizować czas/koszt wykonania ręcznych przeróbek definicji starych trendów na nowe, w szczególności przeróbek akcji operatorskich (np. na stacyjkach analogowych) wywołujących stare trendy. asix po rozpoznaniu akcji operatorskiej starego trendu w miejsce definicji z pliku *.DAT otwiera nowy skonwertowany trend z pliku *.TRNX.

Konwerter ma duże znaczenie użytkowe podczas przechodzenia w istniejących aplikacjach ze starych wersji systemu asix na wersję 5 z minimalną ingerencją w aplikację.

A: Przyczyną kłopotów ze znalezieniem klucza HASP jest niezainicjalizowany drajwer klucza. Procedura inicjalizacji nie skończyła się, a aplikacja zdążyła już się uruchomić. Rozwiązaniem problemu jest opóźnienie startu aplikacji przez dołożenie dodatkowego parametru w skrócie uruchamiającym asix.  

asix w wersji 2 do 4:

Zaznaczony na czerwono parametr powoduje opóźnienie o 10 sekund startu aplikacji zdefiniowanej w pliku MojaAplikacja.ini

 

asix w wersji 5:

Zaznaczony na czerwono parametr spowoduje opóźnienie o 10 sekund start aplikacji dla komputera o nazwie Komp1 według definicji projektu z pliku MojaApl.xml.

Podany tu czas 10s jest przykładowy – należy doświadczalnie dobrać możliwie najkrótszy  czas dający gwarancję poprawnego startu aplikacji.

A:

Rozwiązaniem takiego problemu jest użycie prostego skryptu, który ‘sklei’ potrzebne bity z różnych zmiennych i umieści wynik tego sklejania w nowej zmiennej. Ta nowa zmienna powinna być zadeklarowana w kanale z protokołem NONE i mieć funkcję przeliczającą NIC_BYTE, NIC lub NIC_DW (w zależności od potrzeb). Jeśli zmienna docelowa nie będzie archiwizowana, to nie będzie wliczana do puli zmiennych dostępnych w danej licencji.

Przykładowy skrypt może wyglądać tak:  pobierz plik beety.rar  (2 KB). 

Skrypt ustawia 16 bitów w zmiennej o nazwie Bity_00_15.

Deklaracja użycia skryptu zależy od wersji pakietu. W przypadku pakietu asix w wersji 3 lub 4 użycie skryptu należy zadeklarować w pliku INI w następujący sposób:

[skrypty]

_Bity_ = skrypty\beety.js //watek:nowy,4

gdzie:

_Bity_ - nazwa skryptu, pojawia się np. w Panelu Kontrolnym przy wyprowadzaniu komunikatów

Skrypty\beety.js – nazwa pliku wykonywanego wraz ze ścieżką

//watek:nowy,4 – deklaracja utworzenia oddzielnego watku o priorytecie 4 do wykonywania tego skryptu.

W przypadku pakietu asix w wersji 5 deklarację skryptu należy wykonać w odpowiedniej zakładce Architekta (patrz rysunek poniżej). Znaczenie wpisów podobne jak w przypadku deklaracji w pliku INI aplikacji.

A: Tymczasowe przełączenie na czas projektowania i testowania aplikacji systemu asix wszystkich kanałów fizycznych na typ drajwera NETWORK lub NONE  umożliwia okno ‘Zarządzanie kanałami’,  uruchamiane komendą Zarządzaj kanałami…  z menu Obszary i komputery.

Szczegóły na ten temat zawiera poniższy plik PDF: 

 Architekt - przełączanie kanałów (186 KB)

A: Sprawa jest prosta: AsBase odwołuje się do systemowego pola Nazwa, które jest niewidoczne w normalnej edycji zestawu zmiennych w danej grupie receptur. Dodatkowo, zazwyczaj projektant definiuje własne pole Nazwa, zawierające nazwę receptury, co powoduje, że komunikat jest nieczytelny - o które pole chodzi?

Aby rozwikłać ten problem, należy definiując zestaw zmiennych, odsłonić również systemowe pola rekordu definicji receptury. W tym celu należy kliknąć prawym klawiszem myszki na wierszu nagłówków kolumn w widoku zestawu zmiennych

powiększ

i wybrać opcję Pokaż wszystkie pola. Spowoduje to odkrycie pól systemowych.

powiększ

Teraz systemowemu polu Nazwa należy przypisać zmienną zawierającą nazwę receptury (zakreślona na czerwono). Zmienna może być równocześnie przypisana do pola zdefiniowanego przez projektanta (tu: _Nazwa_).

Na masce należy zdefiniować obiekt NAPIS, który pozwoli na wyświetlenie nazwy aktualnie wybranej receptury. Jeśli niezbędne jest umożliwienie użytkownikowi definiowania nowych receptur, to właśnie ten obiekt pozwoli na podanie nowej nazwy receptury. Wprowadzenie nowej nazwy receptury (w obiekcie NAPIS) i potwierdzenie sterowania, a nastepnie wykonanie akcji ASBASE z opcją DODAJ (oraz identyfikatorem połączenia do AsBase'a) spowoduje dodanie nowej receptury.

 

A: Podstawowe narzędzie archiwizacji danych, Aspad, przeznaczone jest do cyklicznej archiwizacji zmiennych analogowych i binarnych.

Czasem jednak w aplikacji istnieje konieczność zadeklarowania zmiennych tekstowych (liczba elementów > 1, funkcja przeliczająca NIC_TEXT) do przechowywania, wprowadzania i wyświetlania nazw produktu, numeru partii, zamówienia lub nazwy receptury. W takim przypadku do archiwizacji tych zmiennych należy użyć modułu AsBase, dostępnego w każdym pakiecie bez dodatkowych dopłat.

AsBase to moduł obsługi baz danych MS SQL (serwer SQL dostarczany jest z asixem na płytce instalacyjnej). Jego głównym przeznaczeniem jest obsługa receptur (tworzenie, edycja, zadawanie) oraz archiwizacja dowolnie skonfigurowanego rekordu, zawierającego dane z aplikacji asix. Dane te mogą być dowolnego typu (również tekstowe) i archiwizowane w zadanym reżimie czasowym (podobnie jak archiwizacja przy użyciu Aspada) lub w odpowiedzi na zdarzenie w aplikacji, sygnalizowane na zmiennej synchronizującej zapis. Co więcj, zmienna synchronizująca zapis może służyć do zwrotnego potwierdzenia sterownikowi dokonania czynności archiwizacyjnych. System archiwizacji AsBase’a pozwala na tworzenie zapisów odnoszących się do konkretnych partii wyrobów lub pojedynczych egzemplarzy identyfikowanych po nazwie, numerze seryjnym, numerze partii, dacie i czasie lub tp.

Receptury i archiwa mogą być przeglądane na maskach aplikacji z użyciem standardowych obiektów wizualizacyjnych (LICZBA, NAPIS – teksty i inne) i przez zastosowanie akcji ASBASE z odpowiednimi parametrami.

Szczególnie interesująco przedstawia się tu możliwość zapamiętania czasu rekordu archiwalnego i przypisania go do zmiennej stałoprzecinkowej 32-bitowej (funkcja przeliczająca NIC_DW). Otóż podczas przeglądania archiwum wartości czasu będą podstawiane do tej zmiennej i wyświetlane na ekranie (format wyświetlania w obiekcie LICZBA: ‘D’). Jeśli użyje się tej zmiennej jako parametru przekazującego czas w akcji ASTREND - wykonywanej gdy na ekranie jest wyświetlany żądany rekord, to początek czasu w oknie programu AsTrend będzie ustawiony właśnie na wartość odczytaną z AsBase’a. Pozwala to na natychmiastowe odszukanie w archiwach Aspada przebiegu zmian wielkości analogowych związanego z danym rekordem (czytaj: partią, szarżą, wyrobem). 

A: asix może poprawnie pracować na systemie MS Windows 2003 Server, jednak wymaga pewnej ręcznej korekty ustawień systemowych. Winnym takiego zachowania się aplikacji w systemie MS Windows 2003 Server jest mechanizm DataExecutionPrevention. Należy dodać program _as32.exe do listy wyjątków. W przypadku systemu MS Windows XP (podobnie w MS Windows 2003 Server) dojście do listy wyjątków realizowane jest poprzez:

Mój komputer > Właściwości > Zaawansowane > Wydajność_Ustawienia > Zapobieganie wykonywaniu danych

A: Mając aplikację w wersji 3 lub 4 pakietu asix, wykorzystującą bazę zmiennych Asmena w formacie Paradox (pliki ZEZ/db), można ją użyć w aplikacji w wersji 5 pakietu asix. W tym celu:

1. Należy w Architekcie w zakładce bazy zmiennych zadeklarować użycie bazy w starym formacie (asix 2-4):

2. W zakładce parametrów startowych należy zadeklarować nazwę pliku ZEZ i jego lokalizację, która może być dowolna i wybrana przyciskiem [...] ):



3. Następnie należy sprawdzić, czy baza jest widoczna w Architekcie - z menu u góry okna Architekta należy wybrać Baza definicji zmiennych > Pokaż... Jeśli wszystko jest poprawnie zadeklarowane i baza jest dostępna, to powinno pojawić się okno bazy zmiennych takie jak w asixie 3 i 4.

A: Korzystając z definicji zmiennych zawartych w starej bazie, można wygenerować nową bazę w formacie używanym przez asix 5 (baza Jet/MDB). Szczegóły na ten temat zawiera poniższy plik PDF:

 Etapy konwersji bazy z wersji asixa 3 / 4 do formatu bazy asixa 5  (710 KB)

A: Jeśli w odpowiednim arkuszu skoroszytu MS Excel z definicjami zmiennych są poprawnie zadeklarowane argumenty funkcji przeliczających, a w wygenerowanej bazie odpowiednie pola pozostają niewypełnione - powodem takiego stanu rzeczy są pewne błedy formatu komórek arkusza kalkulacyjnego lub nieprawidłowe działanie drajwera MDAC firmy Microsoft. Najprostszym rozwiązaniem problemu jest bądź zainstalowanie nowszego drajwera plików XLS z pakietu MS Office 2007, bądź wybór drajwera wbudowanego w pakiet asix. Sposób wyboru został opisany w:

„Q: Po przeniesieniu aplikacji z komputera projektanta i przy zachowaniu dokładnie takiej samej lokalizacji składowych elementów aplikacji wszystko działa poprawnie, ale z poziomu Architekta nie udaje się wygenerować bazy zmiennych. Dlaczego?”  (2008-08-25).

 

A: Jeśli pliki MS Excel dają się zlokalizować, lecz próba generowania bazy kończy się komunikatem o niemożności odczytania ich, najprawdopodbniej przyczyną jest to, że komputer docelowy nie posiada zainstalowanych drajwerów do odczytu plików MS Excel. Aby umożliwić asixowi odczyt skoroszytów MS Excel, należy w Architekcie wybrać, dostarczony wraz z pakietem asix, odpowiedni drajwer. W tym celu należy wybrać z lewego panela Architekta zakładkę Bazy danych:

,

a następnie w Opcjach, w zakładce Źródła danych przełącznikiem dokonać wyboru tzw. silnika odczytu plików XLS - jak pokazano na rysunku poniżej:

A: Jeśli z dowolnych przyczyn lokalizacja aplikacji na komputerze operatorskim musi być inna niż na komputerze projektanta aplikacji, to należy tak sparametryzować dostęp do elemetów aplikacji (maski aplikacji, raporty, pliki wykonywanych skryptów etc.), by wszystkie ścieżki dostępu podane były względem domyślnego katalogu aplikacji. Najwygodniej w tym celu utworzyć katalog domyślny aplikacji, w którego podkatalogach umieszczone będą wszystkie elemety składowe aplikacji (tak właśnie postępuje kreator nowej aplikacji). Mając taki układ kartotek aplikacji i zapewniając deklarację względną wszystkich składowych aplikacji, wystarczy przekopiować całość aplikacji do dowolnej kartoteki na komputerze docelowym. Ważne też, by skrót uruchamiający aplikację miał we właściwościach zadeklarowany katalog domyślny (Rozpocznij w...) aplikacji.

 

A: Szczegółowy opis postępowania, wraz z przykładami okienek oprogramowania SimaticNet, w przypadku podanym w pytaniu znajduje się w dokumencie PDF:

Konfiguracja kart CP5611 i PC Software V6  (1,54 MB)

A: Drajwer MODBUS_TCPIP wymaga podania dla każdego kanału numeru portu, adresu IP i numeru węzła w sieci Modbus. Zazwyczaj projektanci, sugerując się tym, że węzły są odróżniane przez swój adres IP, nie podają prawidłowego numeru węzła w sieci Modbus. Jest on jednak konieczny i musi być unikatowy.

A: Przyczyn takiego stanu może być kilka. Do najważniejszych należy zaliczyć nieuzgodnienie parametrów transmisji po stronie mastera i slave’a (prędkość transmisji, liczba bitów danych etc), użycie niewłaściwego sposobu adresowania zmiennych (zawsze należy sprawdzić w dokumentacji producenta sprzętu, jaki jest sposób adresowania rejestrów). Inną przyczyną może być adres nieadekwatny do stosowanego w PLC formatu zapisu rejestrów (format Intela lub Motoroli).

A: Pierwszym krokiem powinno być sprawdzenie, czy jakikolwiek drajwer klucza HASP jest zainstalowany i odinstalować go. W tym celu najprostszym sposobem jest uruchomienie okienka konsoli (Start -> Uruchom: cmd).

W okienku konsoli należy zmienić katalog na ten, w którym zainstalowany jest pakiet asix, a następnie uruchomić instalator drajwera klucza HASP zleceniem: Hinstall –r co spowoduje usunięcie zainstalowanego drajwera lub wyświetlenie o błędzie, w przypadku gdy drajwer nie był zainstalowany.

Kolejnym krokiem jest zastąpienie w katalogu zawierającym pakiet asix programów obsługi klucza HASP: Hinstall.exe oraz haspds_windows.dll (Uwaga: w pakiecie 2.xx systemu asix znajduje się jedynie pierwszy z wymienionych plików) plikami pobranymi z naszej witryny (-> o asiksie -> materiały do pobrania -> software).

Po zastapieniu plików należy uruchomić instalator w okienku konsoli:

Hinstall –i

Jeśli w komputerze używany jest klucz określonego typu, to wskazane jest użycie opcji deklarującej jego typ:

Hinstall –i –ks=USB dla klucza USB lub

Hinstall –i –ks=Parallel dla klucza na porcie drukarki.

A: Najczęściej przyczyną takiego stanu rzeczy jest nieodpowiednia dla nowego systemu operacyjnego (zazwyczaj MS Windows XP) wersja drajwera klucza zabezpieczającego HASP. W celu usunięcia niedomagania systemu należy pobrać nowy drajwer klucza HASP (> o asiksie > materiały do pobrania > software) i zainstalować go.