Niniejsze badanie waliduje automatyczne generowanie interfejsu użytkownika w sieci w oparciu o protokół zdalnej interoperacyjności (RIP) z wykorzystaniem dwóch odrębnych systemów LabVIEW — modelu wentylatora oraz modelu sterowania pozycją silnika prądu stałego — i dostarcza odtwarzalną procedurę konstruowania, rejestrowania, wdrażania i testowania obu przykładów.
Artykuł metodologiczny
Protokół automatycznego generowania interfejsów internetowych dla aplikacji LabVIEW z wykorzystaniem protokołu zdalnej interoperacyjności
W tym artykule
Podsumowanie
Streszczenie
Zdalne platformy eksperymentalne umożliwiają dostęp do lokalnych modeli symulacyjnych lub urządzeń fizycznych poprzez sieć, jednak konwencjonalne interfejsy WWW zazwyczaj wymagają osobnej strony, układu sterowania i logiki komunikacji danych dla każdego eksperymentu, co zwiększa koszty rozwoju. Niniejsza praca waliduje ustanowiony schemat automatycznego generowania interfejsu użytkownika (UI) WWW z wirtualnych instrumentów (VI) LabVIEW przy użyciu protokołu zdalnej interoperacyjności (RIP) i dostarcza odtwarzalny protokół jego implementacji. Schemat ten polega na budowie instrumentów LabVIEW VI, które definiują sterowniki wejściowe i wskaźniki wyjściowe na panelu przednim (Front Panel), rejestracji każdego VI w konfiguracji serwera RIP, odczycie wynikowych metadanych zmiennych oraz generowaniu odpowiadających im sterowników i wyświetlaczy wyjściowych w wersji WWW. Caddy jest wykorzystywany jako odwrotny proxy w celu ujednolicenia ścieżki do statycznych plików front-endu oraz ścieżki zapytań do interfejsu programistycznego (API) RIP. Schemat został oceniony na dwóch różnych systemach: modelu prędkości wentylatora oraz modelu proporcjonalno-całkująco-różniczkowego (PID) sterowania pozycją silnika prądu stałego (DC). W obu przypadkach strona WWW identyfikuje udostępnione zmienne, zapisuje dane wejściowe użytkownika w backendzie LabVIEW, odczytuje wyjścia modelu i generuje interfejs na podstawie metadanych RIP. Wyniki te potwierdzają poprawność tego samego procesu automatycznego generowania UI w dwóch różnych systemach dynamicznych i dokumentują kroki niezbędne do jego odtworzenia.
Wprowadzenie
Wraz z rozwojem zdalnych eksperymentów, nauczania online oraz technologii Internetu Rzeczy, zapewnienie dostępu przez sieć do lokalnych modeli symulacyjnych lub urządzeń doświadczalnych stało się ważnym kierunkiem rozwoju platform eksperymentalnych1,2,3,4. Niedawne prace doprowadziły do dalszej integracji laboratoriów wyposażonych w Internet Rzeczy z nauczaniem opartym na projektach oraz dostępem lokalnym lub zdalnym, co dowodzi ciągłego rozwoju elastycznych i sieciowych platform eksperymentalnych w edukacji inżynieryjnej5. W przypadku eksperymentów z systemami sterowania użytkownicy zazwyczaj muszą dostosowywać parametry wejściowe w przeglądarce i obserwować stany wyjściowe w czasie rzeczywistym6,7. Konwencjonalne metody zazwyczaj wymagają oddzielnej strony internetowej, logiki wiązania sterowania i interfejsu komunikacji danych dla każdego obiektu eksperymentalnego8,9. Gdy zmieniają się zmienne w modelu zaplecza (back-end), strona front-end często musi zostać odpowiednio zmodyfikowana, co powoduje znaczny powtarzalny nakład pracy programistycznej i ogranicza szybką rozbudowę platformy eksperymentalnej.
Protokół zdalnej interoperacyjności (Remote interoperability protocol, RIP) zapewnia warstwę pośrednią (middleware) pomiędzy eksperymentalnymi modelami backendowymi a front-endami WWW10,11. W podejściu do automatycznego generowania interfejsu użytkownika (UI) w oparciu o RIP, opisanym w poprzednich pracach, serwer RIP dostarcza metadane dla każdego eksperymentu, obejmujące nazwy zmiennych, atrybuty wejścia/wyjścia, typy danych, wartości minimalne i maksymalne, precyzję, opisy oraz dostępne metody odczytu i zapisu11. Klient WWW może następnie wykorzystać te metadane do utworzenia odpowiadających im elementów HTML, takich jak etykiety, numeryczne pola wprowadzania, suwaki, przełączniki logiczne oraz wyświetlacze wyjściowe, podczas ładowania lub odświeżania strony11. Niniejszy protokół nie implementuje ponownie ani nie redefiniuje specyfikacji RIP. Zamiast tego wykorzystuje istniejącą usługę RIP o otwartym kodzie źródłowym oraz logikę generowania UI HTML na podstawie metadanych RIP jako fundament do komunikacji i generowania interfejsów, skupiając się na powtarzalnej konstrukcji, rejestracji, wdrożeniu proxy i weryfikacji dwóch przykładów VI w środowisku LabVIEW.
W porównaniu z konwencjonalnym tworzeniem niestandardowych interfejsów WWW, automatyczne generowanie interfejsu użytkownika (UI) w oparciu o RIP ogranicza konieczność implementowania układów sterowania, logiki wiązania zmiennych oraz podstawowych funkcji komunikacyjnych w sytuacjach, gdy wiele eksperymentów w LabVIEW wykorzystuje porównywalne skalarne zmienne wejściowe i wyjściowe8,9,10,11. Po zarejestrowaniu nowego VI i udostępnieniu jego zmiennych serwerowi RIP, ta sama logika odczytywania metadanych i generowania elementów sterujących może zostać ponownie wykorzystana do budowy podstawowego interfejsu WWW10,11. Funkcja ta jest przydatna przy szybkim wdrażaniu, pokazach dydaktycznych oraz w platformach laboratoriów zdalnych, które wymagają spójnego dostępu do kilku podobnych eksperymentów3,8,9. Jednak automatycznie generowany interfejs posiada również ograniczenia. Nie wnioskuje on w pełni o relacjach fizycznych między zmiennymi, nie określa automatycznie mapowań wykresów ani nie projektuje specyficznych dla danej dziedziny wizualizacji i interakcji bezpieczeństwa11. Dlatego ręczne tworzenie interfejsu WWW pozostaje preferowane, gdy eksperyment wymaga wysoce spersonalizowanej grafiki, złożonych przepływów pracy użytkownika, zaawansowanej wizualizacji, sprzętowych blokad bezpieczeństwa lub arbitrażu zapisu dla wielu użytkowników.
Ogólny schemat procedury przedstawiono na Rysunku 1. W tym schemacie instrument wirtualny (VI) LabVIEW definiuje najpierw wymagane sterowniki wejściowe i wskaźniki wyjściowe na Panelu Przednim. Następnie VI jest rejestrowany w Konfiguracji Serwera RIP poprzez określenie nazwy eksperymentu i ścieżki do VI. Po rejestracji Serwer RIP odczytuje metadane wybranego eksperymentu i zapewnia dostęp do odczytu/zapisu dla dostępnych zmiennych. Strona internetowa XHTML wykorzystuje zwrócone metadane do automatycznego generowania odpowiednich sterowników wejściowych i wyświetlaczy wyjściowych, natomiast Caddy zapewnia ujednoliconą ścieżkę dostępu dla statycznej strony internetowej oraz tras komunikacyjnych RIP. Modele wentylatora i silnika prądu stałego zostały wykorzystane w niniejszej pracy jako dwie implementacje tego samego schematu działań. W przypadku innych eksperymentów w LabVIEW, które dostarczają kompatybilne zmienne skalarne, numeryczne i booleowskie, programiści mogą stosować ten sam schemat budowania-rejestracji-wdrażania-weryfikacji w celu stworzenia automatycznie generowanego interfejsu internetowego, dodając przy tym specyficzną dla danego eksperymentu wizualizację, logikę bezpieczeństwa lub złożoną obsługę danych, jeśli jest to wymagane.
Niniejszy artykuł nie proponuje nowej architektury RIP ani nie rozszerza zakresu typów danych obsługiwanych już przez RIP. Zamiast tego wykorzystuje RIP jako uznany mechanizm komunikacji i generowania interfejsu użytkownika (UI) w oparciu o metadane, koncentrując się na walidacji tego procesu w dwóch różnych systemach LabVIEW przy jednoczesnym udokumentowaniu odtwarzalnego protokołu implementacji. Wcześniejsze prace przedstawiły podstawową metodę automatycznego generowania interfejsu Web UI na podstawie metadanych RIP, wykorzystując w ramach studium przypadku eksperyment z serwomotorem online11. W poprzednich badaniach opisano również architektury zdalnych laboratoriów z dostępem przez sieć WWW, łączące interaktywne interfejsy z oprogramowaniem inżynieryjnym i LabVIEW9,12. Jednak podczas praktycznej reprodukcji niektóre modele LabVIEW w pierwotnym przypadku badawczym były obarczone problemami związanymi z wersją oprogramowania i kompatybilnością modułów, co utrudniało ich bezpośrednie zastosowanie w nowszym środowisku. Niniejsza praca rekonstruuje zatem dwa kompatybilne instrumenty wirtualne (VI) back-endu — model wentylatora oraz model sterowania położeniem silnika prądu stałego (DC) za pomocą regulatora proporcjonalno-całkująco-różniczkującego (PID) — i stosuje ten sam proces generowania UI sterowany metadanymi w obu przypadkach. Wkładem pracy jest walidacja uznanego przepływu pracy RIP w różnych systemach oraz szczegółowy protokół reprodukcji tego procesu, a nie rozszerzenie ogólności RIP.
Zamierzonymi użytkownikami niniejszego protokołu są badacze, instruktorzy i twórcy systemów laboratoryjnych, którzy korzystają już z VI LabVIEW i potrzebują udostępnić modele symulacyjne lub niskoryzykowe systemy eksperymentalne za pośrednictwem przeglądarki internetowej, bez konieczności niezależnego wdrażania pełnego, niestandardowego interfejsu front-end dla każdego modelu. Protokół jest szczególnie odpowiedni dla eksperymentów wykorzystujących standardowe zmienne numeryczne i logiczne, regulację parametrów oraz monitorowanie stanu w czasie rzeczywistym10,11. Jest on mniej odpowiedni jako samodzielne rozwiązanie dla eksperymentów wymagających złożonych struktur danych, specjalistycznej wizualizacji, rygorystycznych blokad bezpieczeństwa sprzętowego lub arbitrażu zapisu wieloużytkownikowego11. Celem niniejszej pracy jest walidacja automatycznego generowania interfejsu Web w oparciu o RIP przy użyciu dwóch różnych systemów LabVIEW oraz dostarczenie kompletnego, reprodukowalnego protokołu – od konstrukcji VI back-end po interakcję w przeglądarce. Protokół obejmuje definicję zmiennych wejściowych i wyjściowych, rejestrację eksperymentu w serwerze RIP, generowanie interfejsu użytkownika na podstawie metadanych, wdrożenie serwera proxy Caddy oraz weryfikację zdalnego odczytu i zapisu. Zastosowanie tego samego przepływu pracy dla modeli wentylatora i silnika DC wykazuje, że ustalony proces może zostać zreprodukowany bez konieczności ręcznego przepisywania pełnego front-endu Web dla każdego przykładu9,10,11.
Protokół
Wykonaj następujące kroki, aby zbudować, zarejestrować, wdrożyć i zweryfikować dwa eksperymenty LabVIEW dostępne przez RIP, zgodnie z przebiegiem prac przedstawionym na Rysunku 1. Wszystkie narzędzia i platformy wykorzystane w tej procedurze są wymienione w Tabeli materiałów.
1. Budowa i uruchomienie eksperymentu z modelem wentylatora
- Zbuduj model wentylatora VI.
- Uruchom program LabVIEW, utwórz nowy program VI i zapisz plik jako fengshan.vi. Zapisz program VI w dowolnym katalogu dostępnym dla procesu RIP WebService. Folder Private służy jedynie jako katalog przykładowy i nie jest na stałe wpisany w kod RIP. Podczas rejestracji eksperymentu w RIP podaj faktyczną ścieżkę do wybranego programu VI.
- Na panelu przednim dodaj sterowniki wejściowe dla modelu wentylatora. W tym przykładzie nazwij sterowniki wejściowe Włącz, PWM (modulacja szerokości impulsu), Obciążenie, Tau, Maksymalna prędkość obrotowa (KMaxRPM), i ZaburzenieUstawić Włącz jako kontrolę logiczną (Boolean) oraz ustawić PWM, obciążenie, tau, KMaxRPMi Zaburzenie jako numeryczne elementy sterujące typu double-precision floating-point (DBL). Patrz Tabela uzupełniająca 1 dotyczące fizycznego znaczenia i roli modelowej zmiennych wentylatora.
- Dodaj wskaźniki wyjściowe dla modelu wentylatora. W tym przykładzie nazwij wskaźniki wyjściowe PrędkośćRPM, StałaPrędkośćRPM, CzasS, PrędkośćZnormalizowana, PrądA, i PowerWUstaw wszystkie wskaźniki wyjściowe jako wskaźniki DBL.
UWAGA: Tabela 1 opisuje fizyczne znaczenie i rolę w modelu tych zmiennych wyjściowych. Gotowy przedni panel wentylatora przedstawiono na Rycina 2Nazwy zmiennych, zakresy i wielkości kroków przedstawione w Tabela 1 Opisano dwa przykłady zaimplementowane w niniejszym protokole. Nie stanowią one sztywnych wymagań systemu RIP. W przypadku innych eksperymentów w środowisku LabVIEW programiści mogą zdefiniować inne nazwy zmiennych na panelu przednim (Front Panel) oraz inne właściwości numeryczne. Serwer RIP odczytuje rzeczywiste nazwy zmiennych, typy danych, atrybuty wejścia/wyjścia oraz dostępne właściwości numeryczne z metadanych VI, a strona internetowa generuje odpowiadające im elementy sterujące i wyświetlacze na podstawie zwróconych metadanych. - Dodaj pętlę While do diagramu blokowego. Dodaj dwa rejestry przesuwne w celu przechowywania prędkość_poprzednia i czas_poprzednioraz zainicjuj obie wartości do 0.
- Dodaj węzeł formuły (Formula Node) wewnątrz pętli While. Połącz Włącz, PWM, Obciążenie, Tau, KMaxRPM, Zakłócenie, prędkość_poprz., i czas_poprzedni do lewych terminali wejściowych węzła Formula Node i ustaw SteadyRPM, speed_next, SpeedNorm, CurrentA, PowerW, i następny czas jako prawostronne terminale wyjściowe.
- Zbuduj Włącz logikę sterującą poza węzłem formuły. Użyj Włącz jako sygnał wyboru, tak aby u = PWM kiedy Włącz jest prawdziwe i u = 0 kiedy Włącz jest fałszywe.
- Wprowadź kod modelu wentylatora w węźle formuły. Użyj tego kodu do obliczenia prędkości stanu ustalonego, prędkości rzeczywistej, prędkości znormalizowanej, natężenia prądu, mocy oraz czasu pracy; pełny kod znajduje się w Uzupełniającym Pliku Kodowania 1.
- Podłącz przyspiesz_dalej wyjście węzła Formula Node do Prędkość RPM wskaźnik i podłączyć przyspieszenie_dalej powrót do prawego rejestru przesuwności dla prędkość_poprzedniaPodłącz StałeRPM do SteadyRPM wskaźnik
- Połącz następny_czas do TimeS wskaźnik i podłączyć następny_czas powrót do prawego rejestru przesuwnego dla czas_poprzedniPołącz SpeedNorm, CurrentA, i PowerW do odpowiednich wskaźników wyjściowych.
- Dodaj funkcję Wait (oczekiwanie) wewnątrz pętli While i ustaw czas oczekiwania na 50 ms. Dodaj przycisk Stop Local i podłącz go do terminala warunkowego pętli While.
- Zapisz plik fengshan.vi. Ukończony schemat blokowy wentylatora przedstawiono na Rycina 3.
PRZERWA: Po zapisaniu ukończonego VI dla wentylatora pracę można przerwać. Należy ją wznowić później, ponownie otwierając zapisane VI i upewniając się, że wszystkie elementy sterujące, wskaźniki na panelu przednim (Front Panel) oraz połączenia na schemacie blokowym (Block Diagram) są nadal obecne.
- Zarejestruj eksperyment z wentylatorem w serwerze RIP.
- Otwórz plik RIPWebService.lvproj w Eksploratorze Projektów LabVIEW (LabVIEW Project Explorer)
. - Otwórz plik Configuration.vi z drzewa projektu i zlokalizuj tabelę konfiguracji eksperymentu.
- Dodaj nowy wiersz eksperymentu. W polu Name wpisz fan. W polu pełnej ścieżki wskaż zapisaną plik fengshan.vi. Pola rejestracyjne dla eksperymentu fan są przedstawione w Rycina 4.
- Uzupełnij pozostałe pola konfiguracji. W polu Authors wpisz autora eksperymentu, w polu Keywords wpisz Fan, w polu Description wpisz fan speed model, a w polu Sampling Freq wpisz 200.
- W menu programu LabVIEW wybierz Edytuj > Ustaw aktualne wartości jako domyślneZapiszKonfigurację.vi.
- Zrestartuj usługę sieciową (WebService) RIP i potwierdź, że eksperyment z wentylatorem nadal widnieje w interfejsie konfiguracyjnym (Configuration) po ponownym uruchomieniu.
UWAGA: Nazwa eksperymentu rozróżnia wielkość liter. Wartość fan w konfiguracji RIP (RIP Configuration) musi być dokładnie zgodna z identyfikatorem eksperymentu (experiment ID) użytym w pliku XHTML front-endu. Aby wdrożyć inny instrument LabVIEW VI z tą samą logiką automatycznego generowania interfejsu użytkownika, należy dodać nowy wpis eksperymentu w konfiguracji RIP (RIP Configuration), ustawić nową wartość Name oraz wskazać Path do odpowiedniego pliku VI. Następnie należy użyć tej samej wartości Name jako identyfikatora eksperymentu w pliku XHTML. Strona front-endu nie wymaga ponownego pisania dla każdej zmiennej.
PUNKT ZATRZYMANIA: Po zapisaniu pliku Configuration.vi i ustawieniu aktualnych wartości jako domyślne, można przerwać proces. Należy go wznowić później, restartując RIP WebService i potwierdzając, że eksperyment z wentylatorem jest nadal zarejestrowany.
- Otwórz plik RIPWebService.lvproj w Eksploratorze Projektów LabVIEW (LabVIEW Project Explorer)
- Przygotuj stronę front-endową do eksperymentu z wentylatorem.
- Umieść plik Fan_Automatic_UI.xhtml w katalogu Client, który służy jako główny katalog front-endu.
- Otwórz plik Fan_Automatic_UI.xhtml za pomocą edytora tekstu.
- Zlokalizuj zmienną identyfikatora eksperymentu (experiment ID) w sekcji skryptu i ustaw jej wartość na fan.
UWAGA: Wartość ta musi być identyczna z wartością w polu Name eksperymentu typu „fan” w konfiguracji RIP (RIP Configuration). Ustawienia identyfikatora eksperymentu oraz wspólna logika generowania interfejsu użytkownika w oparciu o metadane dla plików XHTML front-endu są przedstawione w Rysunek 5. - Upewnij się, że strona pobiera aktualne źródło dostępu za pomocą window.location.origin i przesyła żądanie o metadane eksperymentu poprzez rip.info()i przekazuje zwrócone metadane do autobuildUI().
UWAGA: Strona nie powinna zawierać ręcznie wpisanych nazw zmiennych wentylatora, zakresów ani wielkości kroków. Zamiast tego zmienne zapisywalne są generowane z lista.zapisywalnych.meta, generowane są czytelne zmienne z lista.czytelnych.meta, a atrybuty numeryczne, takie jak min, max i step, są pobierane z metadanych zwróconych przez serwer RIP. - Zapisz plik Fan_Automatic_UI.xhtml.
UWAGA: Aby zastosować tę samą logikę generowania front-endu dla innego VI w środowisku LabVIEW, należy ustawić nowy identyfikator eksperymentu (experiment ID) w pliku XHTML oraz zarejestrować odpowiadającą mu nazwę eksperymentu (experiment Name) i ścieżkę do VI (VI Path) w konfiguracji RIP. Elementy sterujące stroną internetową oraz wyświetlacze wyjściowe są generowane zgodnie z metadanymi zwróconymi przez wybrany eksperyment.
- Skonfiguruj ścieżkę dostępu Caddy dla eksperymentu z wentylatorem.
- Otwórz plik Caddyfile za pomocą edytora tekstu.
- Ustaw główny katalog front-endu na katalog Client zawierający plik Fan_Automatic_UI.xhtml.
- Wybierz nieużywany lokalny port dla serwera Caddy, aby umożliwić dostęp przez przeglądarkę do strony internetowej oraz tras RIP. W niniejszym protokole jako przykładowy port dostępu proxy wykorzystano port 8090.
UWAGA: Port 8090 nie jest wymagany przez RIP ani Caddy. Jeśli port 8090 jest zajęty, należy zastąpić go innym niewykorzystanym portem lokalnym i użyć tego samego portu w adresie przeglądarki. - Dodaj trasę, która przekierowuje /fan na Fan_Automatic_UI.xhtml.
- Zidentyfikuj port usługi sieciowej RIP (RIP WebService) skonfigurowany w programie LabVIEW. W niniejszym protokole jako adres usługi sieciowej RIP wykorzystano http://localhost:8001.
UWAGA: Port 8001 jest portem zaplecza (back-end) usługi LabVIEW/RIP WebService stosowanym w środowisku testowym. Można go zmienić w konfiguracji LabVIEW/RIP WebService. Jeśli używany jest inny port, należy zastąpić adres http://localhost:8001 w pliku Caddyfile odpowiednim adresem usługi RIP WebService. - Dodaj regułę odwrotnego proxy, która przekierowuje żądania /RIP/SSE* pod adres usługi internetowej RIP WebService, na przykład http://localhost:8001.
- Dodaj regułę odwrotnego proxy (reverse proxy), która przekierowuje żądania /RIP* na adres usługi sieciowej RIP WebService, na przykład http://localhost:8001. Konfiguracja pliku Caddyfile przedstawiona jest w Rysunek 6.
- Otwórz Wiersz poleceń w systemie Windows. Przejdź do lokalnego katalogu pobierania lub instalacji programu Caddy, wpisując następujące polecenie:
cd /d D:\caddy
UWAGA: W niniejszym protokole ścieżka D:\caddy jest lokalną ścieżką pobierania lub instalacji programu Caddy wykorzystaną w środowisku testowym. Jeśli program Caddy znajduje się w innym katalogu, należy zastąpić D:\caddy odpowiednią ścieżką lokalną. - Uruchom program Caddy z określonym plikiem Caddyfile, wpisując następującą komendę:
caddy.exe run --config Caddyfile - Upewnij się, że program Caddy uruchamia się bez zgłaszania błędu konfiguracji. Otwórz adres http://localhost:8090/fan w przeglądarce internetowej i zweryfikuj, czy interfejs użytkownika (Web UI) aplikacji fan został wygenerowany, zgodnie z przedstawionym w Rysunek 7.
UWAGA: Jeśli przeglądarka zwróci błąd 502, należy potwierdzić, że usługa RIP WebService jest uruchomiona, że port usługi RIP WebService w programie LabVIEW jest zgodny z adresem odwrotnego proxy w pliku Caddyfile oraz że wybrany port dostępu Caddy nie jest zajęty.
- Zweryfikuj wyniki działania eksperymentu z wentylatorem.
- Zweryfikuj, czy strona front-end automatycznie generuje Włącz, PWM, obciążenie, tau, maksymalna prędkość obrotowa (KMaxRPM), i Zakłócenie kontrole wejściowe
- Zweryfikuj, czy strona front-end wyświetla PrędkośćRPM, StałeRPM, CzasS, PrędkośćNorm, PrądA, i PowerW zmienne wyjściowe
- Dostosuj PWM (Modulacja szerokości impulsu) i zaobserwuj, czy Prędkość RPM wraz ze wzrostem Modulacja szerokości impulsu (PWM) rośnie i maleje w miarę jak PWM (modulacja szerokości impulsu) spada.
- Dostosuj obciążenie i zaobserwuj, czy SteadyRPM i Prędkość (RPM) spada wraz ze wzrostem obciążenia.
- Dostosuj zakłócenie i zaobserwuj, czy PrędkośćRPM, PrądA, i PowerW zmiana w odpowiedzi na sygnał zakłócający.
- Zweryfikuj, czy TimeS nadal wzrasta, co potwierdza, że tylny wentylator VI pracuje w trybie ciągłym.
2. Budowa i wdrożenie eksperymentu sterowania położeniem silnika DC za pomocą regulatora PID
- Zbuduj model VI sterowania położeniem silnika prądu stałego za pomocą regulatora PID.
- Uruchom program LabVIEW, utwórz nowy VI i zapisz plik jako Motor.vi. Zapisz VI w dowolnym katalogu, do którego dostęp ma proces RIP WebService.
UWAGA: Folder Private służy wyłącznie jako przykładowy katalog i nie jest na stałe zaprogramowany w RIP. Podczas rejestracji eksperymentu RIP należy wprowadzić rzeczywistą ścieżkę wybranego VI. - Na panelu przednim (Front Panel) dodaj sterowniki wejściowe dla modelu regulacji pozycji silnika DC za pomocą regulatora PID. W tym przykładzie nazwij sterowniki wejściowe Wartość zadana, Kc, Ti, Td, Zakłócenieoraz Resetowanie kontroliUstawić Wartość zadana, Kc, Ti, Td, i Zakłócenie jako sterowniki numeryczne DBL, a sterownik Reset ustaw jako sterownik typu Boolean.
UWAGA: Tabela 1 opisuje znaczenie fizyczne, rolę w modelu oraz zalecany zakres zmiennych wykorzystanych w tym przykładzie. - Dodaj wskaźniki wyjściowe dla modelu sterowania pozycją silnika prądu stałego za pomocą regulatora PID. W tym przykładzie nazwij wskaźniki wyjściowe Położenie, Napięcie, Czas, i Zmierzona prędkość kątowaUstaw wszystkie wskaźniki wyjściowe jako wskaźniki DBL. Tabela 1 opisuje znaczenie fizyczne i rolę modelową tych zmiennych wyjściowych. Kompletny panel przedni (Front Panel) dla silnika przedstawiono na Rysunek 8.
UWAGA: Nazwy zmiennych i zakresy wymienione w Tabela 1 Opisz dwa przykłady zaimplementowane w niniejszym protokole. Nie stanowią one sztywnych wymagań dla przepływu pracy automatycznego generowania interfejsu użytkownika (UI) opartego na RIP. W przypadku użycia innego VI LabVIEW, RIP odczytuje rzeczywiste nazwy zmiennych, typy danych, atrybuty wejścia/wyjścia oraz dostępne właściwości numeryczne z metadanych VI. W związku z tym logika generowania front-endu nie musi zawierać na sztywno zakodowanych nazw zmiennych, wartości maksymalnych, wartości minimalnych ani kroków dla każdego eksperymentu. - Dodaj pętlę While do diagramu blokowego. Dodaj sześć rejestrów przesuwnych w celu przechowywania theta, omega, im, e_prev, integ, i czas, oraz zainicjuj wszystkie sześć wartości do 0.
- Dodaj węzeł formuły (Formula Node) wewnątrz pętli While. Zgodnie ze schematem modelu regulacji położenia silnika DC za pomocą regulatora PID przedstawionym w Rysunek 9wykorzystaj ten węzeł formuły (Formula Node) jako główny moduł obliczeniowy do wyznaczania błędów, sterowania PID, ograniczania napięcia, modelu elektrycznego, modelu mechanicznego oraz aktualizacji pozycji.
UWAGA: Wewnętrzne parametry silnika wykorzystane w tym modelu, takie jak R, L, J, b, Kt, Ke, i Vmax, są znormalizowanymi parametrami modelu dydaktycznego, a nie parametrami skalibrowanymi konkretnego silnika fizycznego. Zostały one dobrane w celu uzyskania stabilnej i możliwej do zaobserwowania odpowiedzi symulacyjnej przy wybranym kroku czasowym i ograniczeniu napięcia, tak aby efekty Wartość zadana, Kc, Ti, Td, i Zaburzenie można wyraźnie zademonstrować podczas pracy w środowisku internetowym. - Zestaw sp, theta, omega, im, e_prev, integ, Kc, Ti, Td, zakłócenie, reset, i dt aterminale wejściowe węzła Formula Node. Ustaw theta_następne, omega_następne, im_następne, e_następne, integ_następne, i napięcie elektryczne jako terminale wyjściowe węzła formuły (Formula Node).
- Podłącz Wartość zadana kontrola do Sposób wykonania (sp) wejście węzła formuły (Formula Node). Połącz Kc, Ti, Td, i Zakłócenie do Kc, Ti, Td, oraz dzaburzenie iodpowiednio wejścia węzła Formuła (Formula Node).
- Przekonwertuj logiczny sygnał sterujący Reset na sygnał numeryczny i podłącz go do resetuj wejście terminalne węzła Formuła (Formula Node). Wykonaj reset stanu, gdy reset nie jest równe 0, a następnie wykonaj sterowanie PID i aktualizację stanu silnika, gdy resetuj wynosi 0.
- Dodaj stałą numeryczną dt or ustaw jego wartość na 0,001 s. Podłącz dt do dt terminal wejściowy węzła Formula Node i wykorzystaj go do aktualizacji czasu.
- Ustaw wewnętrzne parametry modelu silnika prądu stałego w węźle Formula Node. Patrz Tabela uzupełniająca 2 dotyczącą znaczenia fizycznego i roli modelowej zmiennych motorycznych.
- Wprowadź kod sterowania pozycją silnika DC za pomocą regulatora PID do węzła Formula Node. Użyj tego kodu do implementacji logiki resetowania, obliczania błędu, obliczania składnika całkującego, obliczania składnika różniczkującego, sterowania PID, ograniczania napięcia, aktualizacji prądu, aktualizacji prędkości kątowej oraz aktualizacji pozycji; pełny kod znajduje się w uzupełniających plikach z kodem.
- Połącz theta_następny do Położenie wskaźnik oraz połączyć theta_następna powrót do odpowiedniego rejestru przesuwności dla theta Połącz omega_next do Wskaźnik zmierzonej prędkości kątoweji podłączyć omega_next powrót do prawego rejestru przesuwnika dla omega
- Podłącz napięcie do wskaźnika napięcia. Podłącz im_następne, e_następne, i integ_next powrót do prawych rejestrów przesuwnych dla im, e_prev, i integ, odpowiednio.
- Użyj funkcji Add poza węzłem Formula Node, aby obliczyć time_next = time + dt. Połącz następny_czas do Czas wskaźnik i podłączyć następny czas powrót do prawego rejestru przesuwnika czasu.
- Dodaj funkcję Wait wewnątrz pętli While i ustaw czas oczekiwania na 1 ms. Dodaj przycisk Stop i podłącz go do terminala warunkowego pętli While.
- Zapisz plik Motor.vi. Ukończony schemat blokowy silnika przedstawiono w Rysunek 10.
PUNKT ZATRZYMANIA: Po zapisaniu ukończonego instrumentu wirtualnego (VI) silnika można przerwać procedurę. Aby ją wznowić, należy ponownie otworzyć zapisany VI i upewnić się, że wszystkie elementy sterujące, wskaźniki na Panelu Przednim (Front Panel) oraz połączenia na Diagramie Blokowym (Block Diagram) są nadal obecne.
- Uruchom program LabVIEW, utwórz nowy VI i zapisz plik jako Motor.vi. Zapisz VI w dowolnym katalogu, do którego dostęp ma proces RIP WebService.
- Zarejestruj eksperyment motoryczny w serwerze RIP.
- Otwórz plik RIPWebService.lvproj w Przeglądarce Projektów LabVIEW (LabVIEW Project Explorer).
- Otwórz plik Configuration.vi z drzewa projektu i zlokalizuj tabelę konfiguracji eksperymentu.
- Dodaj nowy wiersz eksperymentu. W polu Name wprowadź Motor. W polu Path wprowadź pełną ścieżkę do zapisanego pliku Motor.vi. Pola rejestracji eksperymentu silnika przedstawiono w Rycina 11.
- Wypełnij pozostałe pola konfiguracji. W polu Autorzy ustaw autora eksperymentu, w polu Słowa kluczowe wpisz Silnik, w polu Opis wpisz Model sterowania położeniem silnika DC, a w polu Częstotliwość próbkowania wartość 200.
- W menu LabVIEW wybierz Edytuj > Ustaw aktualne wartości jako domyślne. Save Configuration.vi.
- Zrestartuj usługę sieciową (WebService) RIP i potwierdź, że po ponownym uruchomieniu eksperyment Motor nadal znajduje się na liście w interfejsie konfiguracji.
UWAGA: Nazwa eksperymentu jest rozróżniana ze względu na wielkość liter. Wartość Motor w konfiguracji RIP (RIP Configuration) musi być dokładnie taka sama, jak identyfikator eksperymentu użyty w pliku Motor_Automatic_UI.xhtml. Aby wdrożyć inny program LabVIEW VI z tą samą logiką automatycznego generowania interfejsu użytkownika, należy dodać nowy wpis eksperymentu w konfiguracji RIP, ustawić nową wartość Name oraz wskazać Path do odpowiedniego pliku VI. Następnie należy użyć tej samej wartości Name jako identyfikatora eksperymentu w pliku XHTML. Strona front-end nie musi być przepisywana dla każdej zmiennej.
MOMENT PRZERWANIA: Po zapisaniu pliku Configuration.vi i ustawieniu aktualnych wartości jako domyślne, można przerwać procedurę. Należy ją wznowić później, restartując RIP WebService i potwierdzając, że eksperyment Motor jest nadal zarejestrowany.
- Przygotuj stronę główną (front-end) dla eksperymentu motorycznego.
- Umieść plik Motor_Automatic_UI.xhtml w katalogu Client, który służy jako główny katalog front-endu.
- Otwórz plik Motor_Automatic_UI.xhtml za pomocą edytora tekstu.
- Zlokalizuj zmienną identyfikatora eksperymentu (experiment ID) w sekcji skryptu i ustaw jej wartość na Motor. Wartość ta musi być identyczna z polem Name eksperymentu motorowego w konfiguracji RIP (RIP Configuration). Strona front-endowa eksperymentu motorowego wykorzystuje tę samą logikę generowania interfejsu użytkownika w oparciu o metadane, która została przedstawiona w Rysunek 5; zmieniono jedynie identyfikator eksperymentu, aby był zgodny z wpisem Motor w konfiguracji RIP.
- Należy sprawdzić, czy strona zawiera logikę odczytu metadanych RIP, logikę generowania elementów sterujących HTML, funkcję zapisu RIP oraz funkcję aktualizacji wyjściowej.
UWAGA: Strona nie powinna zawierać ręcznie wpisanych nazw zmiennych silnika, zakresów ani wielkości kroków. Właściwości te są pobierane z metadanych zwracanych przez serwer RIP, zgodnie z opisanym wcześniej mechanizmem generowania treści HTML z metadanych w oparciu o RIP11. - Zapisz Motor_Automatic_UI.xhtml.
UWAGA: Aby wykorzystać tę samą logikę generowania front-endu dla innego instrumentu wirtualnego (VI) LabVIEW, należy ustawić nowy identyfikator eksperymentu w pliku XHTML oraz zarejestrować odpowiadającą mu nazwę eksperymentu i ścieżkę do VI w konfiguracji RIP. Elementy sterujące stroną internetową oraz wyświetlacze wyjściowe są generowane zgodnie z metadanymi zwróconymi przez wybrany eksperyment.
- Skonfiguruj ścieżkę dostępu Caddy dla eksperymentu motorycznego.
- Otwórz plik Caddyfile za pomocą edytora tekstu.
- Ustaw katalog główny front-endu na katalog Client, który zawiera plik Motor_Automatic_UI.xhtml.
- Wybierz niewykorzystany lokalny port dla Caddy, aby zapewnić dostęp przez przeglądarkę do strony internetowej i tras RIP. W niniejszym protokole w przykładzie wykorzystano port 8090 jako port dostępu do serwera proxy.
UWAGA: Port 8090 nie jest wymagany przez RIP ani Caddy. Jeśli port 8090 jest zajęty, należy zastąpić go innym niewykorzystanym portem lokalnym i użyć tego samego portu w adresie przeglądarki. - Dodaj trasę, która przekierowuje /motor do Motor_Automatic_UI.xhtml.
- Zidentyfikuj port usługi sieciowej RIP (RIP WebService) skonfigurowany w programie LabVIEW. W niniejszym protokole jako adres usługi sieciowej RIP wykorzystano http://localhost:8001.
UWAGA: Port 8001 jest portem zaplecza (back-end) usługi sieciowej LabVIEW/RIP WebService wykorzystywanym w środowisku testowym. Można go zmienić w konfiguracji LabVIEW/RIP WebService. W przypadku użycia innego portu należy zastąpić adres http://localhost:8001 w pliku Caddyfile odpowiednim adresem RIP WebService. - Dodaj regułę odwrotnego proxy (reverse proxy), która przekierowuje żądania /RIP/SSE* na adres usługi internetowej (WebService) RIP, na przykład http://localhost:8001.
- Dodaj regułę odwrotnego proxy, która przekierowuje żądania /RIP* do adresu RIP WebService, na przykład http://localhost:8001. Konfiguracja Caddyfile przedstawiona jest na Rysunku 6.
- Otwórz Wiersz poleceń w systemie Windows. Przejdź do lokalnego katalogu pobierania lub instalacji programu Caddy, wpisując następujące polecenie:
cd /d D:\caddy
UWAGA: W niniejszym protokole ścieżka D:\caddy jest lokalną ścieżką pobierania lub instalacji programu Caddy użytą w środowisku testowym. Jeśli program Caddy znajduje się w innym katalogu, należy zastąpić D:\caddy odpowiednią ścieżką lokalną. - Uruchom Caddy z określonym plikiem Caddyfile, wprowadzając następujące polecenie:
caddy.exe run --config Caddyfile - Upewnij się, że program Caddy uruchamia się bez zgłaszania błędu konfiguracji. Otwórz adres http://localhost:8090/motor w przeglądarce internetowej i zweryfikuj, czy interfejs użytkownika (Web UI) silnika został wygenerowany, zgodnie z przedstawionym w Rysunek 12.
UWAGA: Jeśli strona internetowa silnika ładuje się, ale wartości wyjściowe nie są aktualizowane, należy potwierdzić, że usługa RIP WebService jest uruchomiona, motor VI jest w trakcie wykonywania, port RIP WebService w programie LabVIEW jest zgodny z adresem odwrotnego proxy w pliku Caddyfile oraz że trasa /RIP/SSE* jest poprawnie przekierowana przez proxy.
- Zweryfikuj wyniki operacyjne eksperymentu z silnikiem.
- Upewnij się, że strona front-end automatycznie generuje Wartość zadana, Kc, Ti, Td, Zakłócenie, i Resetuj kontrola wejść sterujących.
- Zweryfikuj, czy strona front-end wyświetla Położenie, Napięcie, Czas, i Zmierzona prędkość kątowa zmienne wyjściowe
- Dostosuj Wartość zadana oraz zaobserwuj, czy położenie reaguje na zmianę położenia zadanego.
- Dostosuj Kc, Ti, i Td i zaobserwować, czy Napięcie, Pozycja, i Zmierzona prędkość kątowa zmiana
- Dostosuj zakłócenie i zaobserwowanie, czy pozycja, napięcie sterujące lub zmierzona prędkość kątowa jest pod wpływem zakłócenie Proszę podać tekst źródłowy do tłumaczenia.
- Kliknij Reset control i sprawdź, czy Położenie, Napięcie, Pomierzona prędkość kątowa, a powiązane stany wewnętrzne powracają do swoich stanów początkowych zgodnie z logiką resetowania.
Wyniki
Po zakończeniu opisanego powyżej przepływu pracy, dostęp do eksperymentu z wentylatorem oraz eksperymentu z kontrolą pozycji PID silnika DC można uzyskać za pomocą automatycznie generowanego interfejsu Web. Pomyślny wynik jest wskazywany przez trzy obserwacje. Po pierwsze, strona internetowa automatycznie generuje elementy sterujące wejściem i pola wyświetlania wyjścia zgodnie z metadanymi zmiennych zwróconymi przez serwer RIP. Po drugie, gdy użytkownik zmienia zmienną wejściową na stronie internetowej, zmodyfikowana wartość jest zapisywana w VI back-endu LabVIEW poprzez interfejs RIP. Po trzecie, zmienne wyjściowe obliczone przez VI back-endu są zwracane przez RIP i odświeżane na stronie internetowej w czasie rzeczywistym. W przypadku eksperymentu z wentylatorem, po wpisaniu adresu http://localhost:8090/fan w przeglądarce, strona automatycznie generuje sterowniki wejściowe i pola wyjściowe z metadanych RIP, jak pokazano na ryc. 7. Strona wejściowa obejmuje Enable, PWM, Load, Tau, KMaxRPM, oraz Disturbance, natomiast strona wyjściowa wyświetla SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA, oraz PowerW. Podczas normalnej pracy wartość TimeS zwiększa się stale, co wskazuje na działanie VI back-endu fengshan.vi. Gdy zwiększana jest wartość PWM , wartości SpeedRPM oraz SteadyRPM rosną odpowiednio. Przy zwiększeniu Load prędkość wentylatora spada, ponieważ load redukuje stabilną prędkość pracy. Po dostosowaniu Disturbance można zaobserwować odpowiadające temu zmiany w SpeedRPM, CurrentA, oraz PowerW. Obserwacje te potwierdzają, że dane wejściowe ze strony Web są poprawnie przesyłane do back-endu LabVIEW, a obliczone dane wyjściowe są zwracane do front-endu poprzez RIP.
W eksperymencie dotyczącym regulacji pozycji silnika DC za pomocą kontrolera PID, po wpisaniu adresu http://localhost:8090/motor w przeglądarce, strona automatycznie generuje odpowiednie elementy sterujące i pola wyjściowe na podstawie metadanych RIP, co przedstawiono na ryc. 12. Zmienne wejściowe obejmują Setpoint, Kc, Ti, Td, Disturbance oraz sterowanie Reset, a zmienne wyjściowe obejmują Position, Voltage, Time oraz Measured angular velocity. Po zmianie wartości Setpoint, parametr Position reaguje na nową wartość zadaną. Po dostrojeniu parametrów PID Kc, Ti oraz Td, odpowiednio zmieniają się odpowiedź wyjściowa, voltage sterująca oraz measured angular velocity, co wskazuje, że wartości parametrów wprowadzone na stronie WWW są prawidłowo zapisywane w modelu backendowym LabVIEW i biorą udział w obliczeniach sterowania. Po aktywacji sterowania Reset, zmienne modelu powracają do stanów początkowych zgodnie z logiką resetowania.
Stany błędów i komunikacji po stronie przeglądarki przedstawiono na Rysunku 13, Rysunku 14, Rysunku 15. Rysunek 13 przedstawia przypadek nieudanego dostępu z przeglądarki w sytuacji, gdy Caddy nie jest uruchomiony. Przeglądarka próbuje uzyskać dostęp do adresu http://localhost:8090/motor, ale wyświetla komunikat ERR_CONNECTION_REFUSED, co wskazuje, że lokalna usługa proxy jest niedostępna lub nie nasłuchuje na wybranym porcie dostępu. Rysunek 14 przedstawia błąd komunikacji RIP POST po załadowaniu strony. W tym przypadku konsola przeglądarki zgłasza błąd 502 Bad Gateway dla żądania RIP POST, co oznacza, że front-end dotarł do adresu proxy, ale żądanie nie może zostać pomyślnie przekazane do back-endu RIP WebService lub nie może zostać przez niego przetworzone. Z kolei Rysunek 15 przedstawia prawidłowy stan komunikacji po stronie przeglądarki. Narzędzia programisty przeglądarki pokazują pomyślne ładowanie strony, żądania RIP POST oraz aktywny żądanie SSE z parametrem expId=fan, co wskazuje, że front-end sieciowy komunikuje się z RIP WebService poprzez proxy Caddy i otrzymuje aktualizacje w czasie rzeczywistym za pośrednictwem kanału SSE.
Łącznie pomyślne wyniki dotyczące wentylatora i silnika oraz wyniki diagnostyki po stronie przeglądarki wykazują, że ten sam przepływ pracy automatycznego generowania interfejsu użytkownika w oparciu o metadane można zreplikować dla dwóch różnych eksperymentów w środowisku LabVIEW. Wyniki te dostarczają również obserwowalnych kryteriów pozwalających odróżnić poprawną komunikację od reprezentatywnych błędów wdrożenia, natomiast odpowiadające im procedury rozwiązywania problemów zostały omówione w sekcji Dyskusja.
Rycina 1: Ogólna struktura systemu eksperymentalnego. System składa się z VI LabVIEW (back-end), serwera RIP, proxy Caddy oraz automatycznie generowanego interfejsu Web UI. VI LabVIEW dostarcza zmienne modelu, serwer RIP odczytuje metadane VI i wartości zmiennych, Caddy ujednolica ścieżkę dostępu i rozwiązuje problem dostępu międzyoriginowego (cross-origin access), a Web UI automatycznie generuje elementy sterujące. Nazwa i logo Caddy są pokazane wyłącznie w celu zidentyfikowania komponentu serwera/proxy WWW Caddy użytego w przepływie pracy. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
Rysunek 2Panel przedni wentylatora VI. Panel przedni zawiera elementy sterujące wejściem dla Włącz, PWM, Obciążenie, Tau, KMaxRPMi Zakłócenie oraz wskaźniki wyjściowe dla PrędkośćRPM, StabilnaRPM, CzasS, PrędkośćZnormalizowana, PrądA, i PowerWZrzut ekranu ten został wykonany z panelu przedniego (Front Panel) programu fengshan.vi w środowisku LabVIEW 2026 w lokalnym środowisku eksperymentalnym autorów. Nie zawarto w nim danych użytkowników osób trzecich ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ilustracji.
Rycina 3Schemat blokowy VI wentylatora. Model wentylatora zaimplementowano przy użyciu pętli While oraz rejestrów przesuwnych, Włącz logikę, węzeł formuły (Formula Node) oraz wskaźniki wyjściowe. Zrzut ekranu ten został wykonany z diagramu blokowego pliku fengshan.vi w programie LabVIEW 2026 w lokalnym środowisku eksperymentalnym autorów. Nie zawarto w nim żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
Rycina 4: Strona konfiguracji fan.vi. Eksperyment z wentylatorem jest zarejestrowany w RIP Configuration z nazwą eksperymentu fan, rzeczywistą ścieżką do pliku VI, informacjami o słowach kluczowych, opisem oraz częstotliwością próbkowania. Zrzut ekranu został wykonany z interfejsu RIP Configuration używanego z LabVIEW 2026 i RIP WebService w lokalnym środowisku eksperymentalnym autorów. Nie zawarto danych użytkowników stron trzecich ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
Rycina 5: Ustawienia ID eksperymentu i logika generowania interfejsu użytkownika na podstawie metadanych w plikach front-endu XHTML. Zrzuty ekranu kodu XHTML zostały wykonane z plików Fan_Automatic_UI.xhtml oraz Motor_Automatic_UI.xhtml otwartych w programie Visual Studio Code. Strony wentylatora i silnika wykorzystują tę samą logikę odczytu metadanych i generowania elementów sterujących; zmieniono jedynie ID eksperymentu, aby odpowiadało odpowiedniemu polu Name w konfiguracji RIP. Zrzuty ekranu kodu XHTML zostały wykonane z plików Fan_Automatic_UI.xhtml oraz Motor_Automatic_UI.xhtml otwartych w programie Visual Studio Code w lokalnym środowisku programistycznym autorów. Pliki kodu zostały przygotowane przez autorów na potrzeby niniejszego protokołu. Nie zawarto w nich żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
Rycina 6: Konfiguracja Caddyfile. Plik Caddyfile definiuje lokalny port dostępu do proxy, ustawia główny katalog front-endu, przekierowuje trasy /fan i /motor do odpowiadających im plików XHTML oraz przesyła żądania /RIP/SSE* i /RIP* przez odwrotne proxy do portu LabVIEW/RIP WebService. Zrzut ekranu konfiguracji Caddyfile został wykonany z pliku Caddyfile otwartego w Visual Studio Code w lokalnym środowisku programistycznym autorów. Plik Caddyfile został przygotowany przez autorów w celu skonfigurowania Caddy jako lokalnego serwera WWW i odwrotnego proxy. Nie zawarto w nim danych użytkowników stron trzecich ani informacji poufnych. Kliknij tutaj, aby zobaczyć powiększoną wersję tej ryciny.
Rycina 7: Strona interfejsu WWW programu fan.vi. Zrzut ekranu tego interfejsu WWW został wykonany z lokalnie wdrożonej przez autorów strony WWW wentylatora przy użyciu przeglądarki Mozilla Firefox. Strona front-end automatycznie generuje sterowniki wejściowe i wyświetlacze wyjściowe na podstawie metadanych zmiennych zwracanych przez serwer RIP. Zrzut ekranu tego interfejsu WWW został wykonany z lokalnie wdrożonej przez autorów strony WWW wentylatora przy użyciu przeglądarki Mozilla Firefox. Wyświetlane sterowniki i pola wyjściowe zostały wygenerowane z metadanych RIP w lokalnym środowisku eksperymentalnym autorów. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
Rysunek 8: Panel przedni VI silnika. Panel przedni zawiera elementy sterujące dla Setpoint, Kc, Ti, Td, Disturbance oraz sterowanie Reset, a także wskaźniki dla Position, Voltage, Time oraz Measured angular velocity. Zrzut ekranu ten został wykonany z panelu przedniego Motor.vi w programie LabVIEW 2026 w lokalnym środowisku eksperymentalnym autorów. Nie zawarto w nim danych użytkowników osób trzecich ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.
Rysunek 9: Schemat modelu sterowania pozycją silnika DC za pomocą regulatora PID. Schemat przedstawia ścieżkę sygnału od błędu wartości zadanej, sterowania PID, ograniczania napięcia, superpozycji zakłóceń, dynamiki elektrycznej, dynamiki mechanicznej i aktualizacji pozycji aż po sprzężenie zwrotne. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.
Rycina 10: Schemat blokowy VI silnika. Model silnika został zaimplementowany przy użyciu pętli While, rejestrów przesuwnych, węzła formuły, logiki czasowej oraz wskaźników wyjściowych. Zrzut ekranu wykonano z schematu blokowego Motor.vi w programie LabVIEW 2026 w lokalnym środowisku eksperymentalnym autorów. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
Rycina 11: Strona konfiguracji Motor.vi. Eksperyment z silnikiem jest zarejestrowany w RIP Configuration pod nazwą eksperymentu Motor, wraz z rzeczywistą ścieżką do VI, informacjami o słowach kluczowych, opisem oraz częstotliwością próbkowania. Zrzut ekranu został wykonany z interfejsu RIP Configuration używanego z LabVIEW 2026 i RIP WebService w lokalnym środowisku eksperymentalnym autorów. Nie zawarto danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
Rysunek 12: Strona interfejsu WWW programu Motor.vi. Strona front-end automatycznie generuje elementy sterowania wejściowego i wyświetlacze wyjściowe dla eksperymentu sterowania pozycją silnika DC za pomocą regulatora PID. Ten zrzut ekranu interfejsu WWW został wykonany z lokalnie wdrożonej strony WWW silnika autorów przy użyciu przeglądarki Mozilla Firefox. Wyświetlane elementy sterujące i pola wyjściowe zostały wygenerowane z metadanych RIP w lokalnym środowisku eksperymentalnym autorów. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.
Rysunek 13: Nieudany dostęp z przeglądarki, gdy Caddy nie jest uruchomiony. Gdy Caddy nie został uruchomiony, proxy lokalnego adresu http://localhost:8090/motor nie można osiągnąć, a przeglądarka wyświetla komunikat ERR_CONNECTION_REFUSED. Ten objaw błędu wskazuje, że lokalna usługa proxy Caddy jest niedostępna lub nie nasłuchuje na wybranym porcie dostępu. Ten zrzut ekranu przeglądarki został wykonany przy użyciu Mozilla Firefox we własnym środowisku testowym autorów i pokazuje stan nieudanego dostępu, gdy lokalne proxy Caddy nie było uruchomione. Nie zawarto żadnych danych użytkowników stron trzecich ani poufnych informacji. Kliknij tutaj, aby wyświetlić większą wersję tego rysunku.
Rycina 14: Błąd komunikacji RIP POST po załadowaniu strony. Konsola przeglądarki wyświetla błąd 502 Bad Gateway dla żądania RIP POST. Wynik ten wskazuje, że strona internetowa dotarła do adresu proxy Caddy, ale żądanie nie może zostać pomyślnie przekazane do zaplecza RIP WebService ani przez nie przetworzone. Ten zrzut ekranu konsoli przeglądarki został wykonany za pomocą narzędzi Mozilla Firefox Developer Tools we własnym lokalnym środowisku wdrożeniowym autorów i pokazuje błąd komunikacji RIP POST 502 Bad Gateway. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić większą wersję tej ryciny.
Rycina 15: Status komunikacji po stronie przeglądarki podczas normalnej pracy. Narzędzia programisty przeglądarki pokazują pomyślne ładowanie strony, żądania RIP POST oraz aktywne żądanie SSE z expId=fan. Żądania te wskazują, że front-end WWW komunikuje się z RIP WebService poprzez proxy Caddy i otrzymuje aktualizacje w czasie rzeczywistym za pośrednictwem kanału SSE. Ten zrzut ekranu z narzędzi programisty przeglądarki został wykonany przy użyciu przeglądarki Mozilla Firefox w lokalnym środowisku wdrożeniowym autorów i pokazuje prawidłową komunikację RIP POST oraz SSE. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Aby wyświetlić większą wersję tej ryciny, kliknij tutaj.
Rysunek 16: Pojedyncza reprezentatywna obserwacja konsoli przeglądarki i zasobów na poziomie procesów dla eksperymentu z wentylatorem. Zrzut ekranu został wykonany podczas lokalnego testu eksperymentu z wentylatorem. Konsola pokazuje czas żądania/odpowiedzi metadanych, liczbę zmiennych metadanych, czas generowania interfejsu użytkownika na podstawie metadanych, czas otwarcia połączenia SSE oraz odebrane dane SSE. Widok menedżera zadań pokazuje wartości CPU i pamięci na poziomie procesów dla przeglądarki oraz procesów LabVIEW w momencie przechwycenia obrazu. Wartości te są opisowymi obserwacjami z tego pojedynczego testu i nie stanowią powielonych pomiarów wydajności ani punktu odniesienia statystycznego. Zrzut ekranu został wykonany za pomocą narzędzi programistycznych Mozilla Firefox oraz Menedżera zadań systemu Windows w lokalnym środowisku testowym autorów. Przeglądarka Mozilla Firefox została użyta do rejestracji wyjścia konsoli, a Menedżer zadań systemu Windows do obserwacji użycia CPU i pamięci przez procesy przeglądarki i LabVIEW. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić większą wersję tego rysunku.
Rycina 17: Jednoczesny dostęp do tej samej strony internetowej opartej na RIP z przeglądarki komputerowej i mobilnej. Strona eksperymentu z wentylatorem jest otwarta jednocześnie na komputerze PC i urządzeniu mobilnym, a obaj klienci wyświetlają automatycznie wygenerowane elementy sterujące i zmienne wyjściowe. Dostęp do strony internetowej na komputerze uzyskano za pomocą przeglądarki Mozilla Firefox, a dostęp do strony mobilnej za pomocą przeglądarki mobilnej w tym samym lokalnym środowisku sieciowym. Zrzuty ekranu zostały wykonane we własnym lokalnym środowisku testowym autorów. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić większą wersję tej ryciny.
| Nazwa zmiennej | Typ danych | Wejście/Wyjście | Znaczenie fizyczne | Rola w modelu | Zakres/Ustawienie | ||
| Włącz | Boole'owski | Proszę podać tekst źródłowy do przetłumaczenia. | Przełącznik pracy wentylatora | Steruje tym, czy model otrzymuje sygnał wejściowy PWM. Gdy wartość jest True, u = PWM; gdy wartość jest False, u = 0. | Prawda / Fałsz | ||
| PWM (modulacja szerokości impulsu) | DBL | Proszę podać tekst źródłowy do tłumaczenia. | Wejście napędu | Określa podstawową intensywność napędu wentylatora i stanowi główną wartość wejściową wykorzystywaną do obliczenia prędkości stanu ustalonego SteadyRPM. | 0-1, krok 0,01 | ||
| Załaduj | DBL | Proszę podać tekst źródłowy do tłumaczenia. | Współczynnik obciążenia | Opisuje wpływ obciążenia na obniżenie prędkości w stanie ustalonym. Wraz ze wzrostem obciążenia prędkość w stanie ustalonym spada. | 0-1, krok 0,01 | ||
| Tau | DBL | Proszę podać tekst źródłowy do tłumaczenia. | Stała czasowa odpowiedzi | Określa, jak szybko prędkość wentylatora osiąga prędkość stanu ustalonego z poprzedniego stanu. | 0,1-5, krok 0,1 | ||
| Maksymalna prędkość obrotowa (KMaxRPM) | DBL | Proszę podać tekst źródłowy do tłumaczenia. | Prędkość maksymalna | Ustawia maksymalną prędkość dopuszczalną przez model i jest wykorzystywana do ograniczania oraz normalizacji prędkości. | 500-6000, krok 100 | ||
| Zaburzenie | DBL | Proszę podać tekst źródłowy do przetłumaczenia. | Sygnał zakłócający | Przedstawia wpływ zewnętrznych zakłóceń lub wahań obciążenia na prędkość w stanie ustalonym, prąd oraz moc. | 0-1, krok 0.1 | ||
| PrędkośćRPM | DBL | Wynik | Prędkość rzeczywista | Reprezentuje aktualną prędkość wyjściową wentylatora i jest aktualizowana zgodnie z dynamiką inercyjną pierwszego rzędu. | Obliczone przez model | ||
| SteadyRPM | DBL | Wynik | Prędkość ustalona | Reprezentuje teoretyczną prędkość stanu ustalonego przy aktualnych warunkach wejściowych. | Obliczone przez model | ||
| TimeS | DBL | Wynik | Czas trwania procesu | Reprezentuje ciągły czas pracy modelu. | Obliczone przez model | ||
| SpeedNorm | DBL | Wynik | Prędkość znormalizowana | Reprezentuje stosunek SpeedRPM do KMaxRPM. | 0–1 lub obliczone przez model | ||
| Aktualny A | DBL | Wynik | Aktualny | Reprezentuje szacowany prąd modelu, który zmienia się w zależności od wejścia sterującego i wejścia zakłócającego. | Obliczone przez model | ||
| PowerW | DBL | Wynik | Moc | Reprezentuje szacowaną moc modelu, obliczoną na podstawie stałej napięcia i natężenia prądu. | Obliczone przez model | ||
| Wartość zadana | DBL | Proszę podać tekst do tłumaczenia. | Pożądana pozycja | Wyznacza pozycję, którą powinien osiągnąć silnik, i tworzy wartość błędu e względem aktualnej pozycji Position. | -3-3, krok 0.1 | ||
| Kc | DBL | Proszę wprowadzić tekst do tłumaczenia. | Wzmocnienie proporcjonalne | Reguluje siłę odpowiedzi kontrolera PID na błąd. | 0-10, krok 0,1 | ||
| Ti | DBL | Proszę podać tekst źródłowy do tłumaczenia. | Czas całkowania | Reguluje działanie całkujące regulatora PID i jest wykorzystywany do redukcji błędu ustalonego. | 0-10, krok 0,1 | ||
| Td | DBL | Proszę podać tekst źródłowy do tłumaczenia. | Czas pochodnej | Reguluje działanie różniczkujące regulatora PID i jest wykorzystywane do tłumienia zbyt gwałtownych zmian błędu oraz poprawy odpowiedzi dynamicznej. | 0-5, krok 0,1 | ||
| Zaburzenie | DBL | Proszę podać tekst źródłowy do tłumaczenia. | Sygnał zakłócający | Reprezentuje zakłócenie zewnętrzne nałożone na wejście silnika, działające na model silnika wraz z napięciem sterującym. | 0-10, krok 0,1 | ||
| Resetowanie kontroli | Boole'owski | Proszę podać tekst źródłowy do przetłumaczenia. | Resetowanie kontroli | Inicjuje czyszczenie stanu modelu, aby pozycja, prędkość kątowa, prąd, błąd oraz człon całkujący powróciły do swoich stanów początkowych. | Prawda / Fałsz | ||
| Położenie | DBL | Wynik | Pozycja rzeczywista | Reprezentuje aktualną pozycję kątową silnika i służy jako zmienna sprzężenia zwrotnego dla regulatora PID. | Obliczone przez model | ||
| Napięcie elektryczne | DBL | Wynik | Napięcie sterujące | Reprezentuje wyjście regulatora PID po ograniczeniu napięcia i oddziałuje na wejście silnika. | Obliczone przez model; ograniczone do zakresu od -24 do 24 V | ||
| Czas | DBL | Wynik | Czas trwania pomiaru | Reprezentuje czas ciągłego działania modelu silnika. | Obliczone przez model | ||
| Zmierzona prędkość kątowa | DBL | Wynik | Zmierzona prędkość kątowa | Reprezentuje aktualną prędkość kątową silnika i stanowi wyjściowy stan mechaniczny silnika. | Obliczone przez model | ||
Tabela 1: Zmienne wejściowe i wyjściowe użyte w przykładach z wentylatorem i silnikiem prądu stałego. Tabela zawiera nazwę każdej zmiennej, typ danych, rolę wejścia/wyjścia, znaczenie fizyczne, zalecany zakres oraz wielkość kroku.
| Parametr | Wartość | Znaczenie fizyczne | Rola w modelu | ||
| R | 1 | Rezystancja prądnicy/silnika (rezystancja uzwojenia kotwicy) | Reprezentuje człon rezystancyjny w obwodzie prądnicy silnika i określa spadek napięcia R × im w równaniu prądu. | ||
| L | 0.5 | Indukcyjność prądu kotwicy | Reprezentuje indukcyjność obwodu indukcyjnego i określa szybkość zmian prądu. Większa wartość L powoduje wolniejszą odpowiedź prądową. | ||
| J | 0.01 | Moment bezwładności | Reprezentuje opór rotora silnika przeciwko zmianom przyspieszenia kątowego i określa, jak szybko zmienia się prędkość kątowa. | ||
| b | 0.1 | Współczynnik tłumienia lepkościowego | Reprezentuje tłumienie mechaniczne i opisuje moment tłumiący, który utrudnia zwiększanie prędkości kątowej podczas obrotu. | ||
| Kt | 0.01 | Stała momentu obrotowego | Reprezentuje współczynnik proporcjonalny, który przelicza prąd stojana na moment obrotowy elektromagnetyczny. | ||
| Ke | 0.01 | Stała siły przeciwelektromotorycznej | Reprezentuje współczynnik proporcjonalności, z którym prędkość kątowa generuje przeciwemf, i opisuje efekt sprzężenia zwrotnego prędkości na prąd. | ||
| Vmax | 24 | Maksymalne napięcie sterujące | Reprezentuje limit napięcia wyjściowego kontrolera i utrzymuje napięcie w zakresie od -24 V do 24 V. | ||
| dt | 0.001 | Krok symulacji dyskretnej | Reprezentuje odstęp czasu dla każdej aktualizacji stanu w pętli i jest wykorzystywany do aktualizacji prądu, prędkości kątowej, pozycji oraz czasu pracy. | ||
Tabela 2: Parametry wewnętrzne zastosowane w modelu sterowania pozycją silnika DC za pomocą regulatora PID. Tabela zawiera parametry elektryczne i mechaniczne, symbole, wartości liczbowe, jednostki oraz role w modelu.
Uzupełniające pliki kodu: pełne pliki źródłowe i konfiguracyjne niezbędne do odtworzenia przykładów z wentylatorem i silnikiem prądu stałego. Uzupełniające pliki kodu obejmują kod węzła formuły (Formula Node) LabVIEW, konfigurację reverse-proxy Caddy, pliki front-end XHTML oraz pliki źródłowe VI LabVIEW wykorzystane w tym protokole. Plik Code in LabVIEW Formula Node.docx zawiera kod węzła formuły dla modeli regulacji pozycji PID wentylatora i silnika prądu stałego. Plik Caddyfile.txt zawiera konfigurację lokalnego serwera WWW i reverse-proxy. Pliki Fan_Automatic_UI.xhtml oraz Motor_Automatic_UI.xhtml zawierają logikę front-endu WWW opartą na metadanych. Pliki fengshan.vi oraz Motor.vi to pliki VI back-end LabVIEW dla eksperymentów z wentylatorem i silnikiem.Kliknij tutaj, aby pobrać ten plik.
Dyskusja
Kluczowym krokiem w tym protokole jest ustandaryzowana konstrukcja i rejestracja instrumentu VI (Virtual Instrument) w programie LabVIEW pełniącym rolę backendu. Elementy sterujące i wskaźniki na panelu przednim (Front Panel) muszą posiadać jasne i unikalne nazwy zmiennych, a ich typy danych muszą być zgodne ze zmiennymi oczekiwanymi przez obliczenia modelu oraz przez proces odczytu/zapisu RIP. W dwóch przykładach wykorzystanych w tym protokole zmienne numeryczne skalarne zdefiniowano jako sterowniki lub wskaźniki typu DBL, a zmienne Boolean jako sterowniki Boolean. Diagram blokowy (Block Diagram) musi również zapewniać ciągłą aktualizację stanu poprzez pętlę While (While Loop), rejestry przesuwne (Shift Registers) i węzeł formuły (Formula Node), aby zmienne takie jak prędkość wentylatora, pozycja silnika, prędkość kątowa silnika, napięcie i czas mogły być aktualizowane podczas wykonywania programu. Po skonstruowaniu VI, nazwa eksperymentu w konfiguracji RIP musi być dokładnie zgodna z identyfikatorem eksperymentu użytym w odpowiadającym mu pliku XHTML, a ścieżka VI (VI Path) musi wskazywać na rzeczywistą zapisaną lokalizację VI. Ustawienia te są istotne, ponieważ front-end internetowy nie posiada na stałe zakodowanych zmiennych dla każdego eksperymentu. Zamiast tego polega on na metadanych zwracanych przez serwer RIP w celu zidentyfikowania zmiennych zapisywalnych, zmiennych odczytywalnych, typów danych oraz właściwości numerycznych10,11.
Główne problemy wymagające rozwiązywania dotyczą spójności pomiędzy identyfikatorem eksperymentu w pliku XHTML, konfiguracją RIP, usługą RIP WebService a ustawieniami serwera proxy Caddy. Jeśli identyfikator eksperymentu w pliku XHTML nie zgadza się z nazwą eksperymentu w konfiguracji RIP, strona internetowa nie może przesłać żądania o poprawne metadane, a w konsekwencji nie może wygenerować oczekiwanych elementów sterujących i pól wyjściowych. Jeśli ścieżka VI jest nieprawidłowa lub usługa RIP WebService nie została uruchomiona, strona internetowa może się otworzyć, ale nie będzie mogła komunikować się z zapleczem LabVIEW. Jeśli program Caddy nie jest uruchomiony, przeglądarka nie może uzyskać dostępu do wybranego lokalnego adresu proxy i może wyświetlić komunikat ERR_CONNECTION_REFUSED, jak pokazano na ryc. 13. Jeśli Caddy działa, ale cel odwrotnego proxy (reverse-proxy target) nie zgadza się z portem usługi RIP WebService, strona może zostać załadowana, podczas gdy żądania RIP POST zakończą się błędem 502 Bad Gateway, jak pokazano na ryc. 14. Jeśli trasa /RIP/SSE* nie działa poprawnie, strona może się otworzyć i wyświetlić elementy sterujące, ale wartości wyjściowe nie będą aktualizowane w czasie rzeczywistym. W warunkach prawidłowego działania narzędzia deweloperskie przeglądarki powinny wykazać pomyślne ładowanie strony, żądania RIP POST oraz aktywne żądanie SSE z poprawnym identyfikatorem eksperymentu, jak pokazano na ryc. 15. W związku z tym rozwiązywanie problemów należy rozpocząć od sprawdzenia identyfikatora eksperymentu, ścieżki VI, stanu usługi RIP WebService, stanu działania programu Caddy, portów proxy oraz trasy SSE. Jeśli komunikacja nadal przebiega nieprawidłowo, pomocne w odróżnieniu problemów z konfiguracją RIP/Caddy od zachowań specyficznych dla przeglądarki może być ponowne uruchomienie zarówno usługi RIP WebService, jak i programu Caddy, wyczyszczenie pamięci podręcznej przeglądarki lub powtórzenie testu w innej przeglądarce.
Niniejszy protokół jest powtarzalny w obu przykładach, ponieważ ten sam schemat pracy (budowa-rejestracja-wdrażanie-weryfikacja) został zastosowany zarówno do modelu prędkości wentylatora, jak i do modelu sterowania pozycją silnika DC za pomocą regulatora PID. Aby zmniejszyć zależność od specjalistycznych bibliotek (toolboxes), tylne instrumenty VI zostały zrekonstruowane przy użyciu podstawowych struktur LabVIEW, w tym elementów sterujących i wskaźników Front Panel, pętli While, rejestrów przesuwnych (Shift Registers), węzłów formuł (Formula Nodes) oraz standardowych skalarnych zmiennych numerycznych i typu Boolean. Niemniej jednak, powtarzalność w zależności od wersji programu LabVIEW, instalacji systemu Windows i środowisk sieci lokalnych wciąż zależy od szczegółów konfiguracji, takich jak ścieżki do plików, uprawnienia dostępu, lokalne porty, polecenia uruchamiania usług oraz zachowanie przeglądarki. Schemat pracy można rozszerzyć na zdalne eksperymenty związane z urządzeniami sprzętowymi, jednak metody tej nie należy interpretować jako bezpośredniego rozpoznawania sprzętu po stronie sieci Web. Interfejs Web identyfikuje elementy sterujące i wskaźniki Front Panel programu LabVIEW za pomocą metadanych RIP. W związku z tym czujniki, aktuatory, instrumenty lub urządzenia sterowania procesem muszą zostać najpierw podłączone i przetworzone w tylnym instrumencie VI LabVIEW poprzez odpowiednie sterowniki sprzętowe, moduły akwizycji danych, moduły sterowania instrumentami lub inne mechanizmy adaptacji sprzętowej. Po zmapowaniu pomiarów sprzętowych i poleceń sterujących na wskaźniki i elementy sterujące Front Panel, interfejs Web oparty na RIP może rozpoznawać te zmienne w ten sam sposób, w jaki rozpoznaje zmienne symulacyjne użyte w niniejszym protokole. Poprzednie badania nad zdalnymi laboratoriami opartymi na LabVIEW wykazały, że LabVIEW może być wykorzystywane jako środowisko backendowe dla zdalnych eksperymentów z zakresu inżynierii sterowania, robotyki, stanowisk sterowania procesami, akwizycji danych z czujników oraz interakcji z urządzeniami fizycznymi9,12,17,18,19,20.
Rysunek 16 przedstawia pojedynczy reprezentatywny przykład implementacji zarejestrowany podczas eksperymentu z lokalnym wentylatorem. Kod front-endu został wyposażony w instrumentację do rejestrowania czasu żądania/odpowiedzi metadanych, liczby zmiennych metadanych, czasu generowania interfejsu użytkownika (UI) na podstawie metadanych, czasu otwierania połączenia SSE oraz odebranych danych SSE. W tym przykładzie konsola przeglądarki wykazała czas żądania/odpowiedzi metadanych wynoszący 68.00 ms, zidentyfikowała 7 zmiennych zapisywalnych i 7 zmiennych odczytywalnych z metadanych RIP, wygenerowała odpowiednie elementy UI w czasie 2.00 ms oraz otworzyła połączenie SSE w ciągu 16.00 ms. Powtarzające się wpisy danych SSE wykazały, że zmienne wyjściowe, takie jak SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA oraz PowerW, były stale odbierane z back-endu LabVIEW. Widok menedżera zadań w tym samym stanie testu lokalnego wykazał zużycie procesora na poziomie około 1.5% i 391.7 MB pamięci dla procesu Firefox, podczas gdy proces LabVIEW wykazał 0% zużycia procesora i 9.2 MB pamięci w momencie przechwycenia danych. Obserwacje te stanowią podstawowy dowód na to, że pobieranie metadanych, generowanie UI na podstawie metadanych, komunikacja RIP/SSE oraz obciążenie procesora na poziomie procesu mogą być obserwowane w lokalnym środowisku wdrożeniowym. Jednakże dane te mają służyć jako weryfikacja na poziomie implementacji, a nie jako kompleksowy benchmark wydajności. Systematyczna ocena wydajności przy użyciu różnych przeglądarek, powtórnych prób, większego obciążenia zmiennymi, sprzętu fizycznego oraz wielu jednoczesnych użytkowników pozostaje niezbędna w przyszłych pracach.
Metoda ta posiada również ograniczenia, zwłaszcza gdy jest rozszerzana o złożone struktury danych, eksperymenty sprzętowe oraz pracę wielu użytkowników. Obecny przepływ pracy jest najbardziej odpowiedni dla skalarnych zmiennych wejściowych i wyjściowych typu liczbowego oraz logicznego (Boolean). Nie zapewnia on automatycznie pełnego wsparcia dla złożonych tablic, klastrów, zagnieżdżonych struktur danych, relacji wykresów ani wizualizacji specyficznych dla danej dziedziny. Przypadki te mogą wymagać dodatkowych reguł mapowania metadanych lub ręcznie napisanych komponentów front-endowych. Automatycznie generowany interfejs użytkownika może tworzyć podstawowe elementy sterujące i wyświetlacze na podstawie metadanych zmiennych, ale nie potrafi w pełni wywnioskować fizycznych zależności między zmiennymi, wybrać najodpowiedniejszej wizualizacji ani zaprojektować interakcji bezpieczeństwa specyficznych dla danego eksperymentu. W przypadku rozszerzenia przepływu pracy na rzeczywisty sprzęt wymagane są dodatkowe rozważania, w tym sterowniki sprzętowe, kalibracja urządzeń, ograniczenia próbkowania, limity elementów wykonawczych, logika zatrzymania awaryjnego, uwierzytelnianie oraz mechanizmy kontroli zapisu dla wielu użytkowników. Obecna implementacja może być również dostępna z wielu urządzeń klienckich poprzez standardowe przeglądarki internetowe w tej samej lokalnej sieci. Jak pokazano na Rysunku 17, ta sama strona eksperymentu z wentylatorem została otwarta jednocześnie w przeglądarce komputerowej i mobilnej, a oba klienty wyświetlały automatycznie wygenerowane sterowniki i odpowiadające im zmienne wyjściowe. Obserwacja ta wskazuje na podstawowy jednoczesny dostęp wielu klientów do przeglądania i interakcji z tą samą stroną eksperymentu. Nie należy jednak interpretować tego jako kompletnego frameworka sterowania wieloużytkownikowego, ponieważ obecna implementacja nie zawiera dedykowanego uwierzytelniania użytkowników, blokad sterowania, arbitrażu współbieżnego zapisu, kolejek zapisu ani mechanizmów rozwiązywania konfliktów. Ograniczenia te są zgodne z wcześniejszymi badaniami nad laboratoriami zdalnymi, w których złożone lub kolaboracyjne laboratoria zdalne zazwyczaj wymagają projektu interfejsu specyficznego dla eksperymentu, mechanizmów synchronizacji, ograniczeń bezpieczeństwa oraz logiki zarządzania użytkownikami13,14,15,16,17.
Wartość metodologiczna niniejszego protokołu nie polega na wprowadzeniu nowej architektury RIP ani na rozszerzeniu typów danych obsługiwanych przez RIP. Zamiast tego jego wartość tkwi w zapewnieniu kompletnej i powtarzalnej ścieżki implementacji dla zastosowania ugruntowanego mechanizmu automatycznego generowania interfejsu użytkownika opartego na RIP w różnych systemach LabVIEW. W porównaniu do pisania niestandardowego interfejsu internetowego dla każdego eksperymentu, ten przepływ pracy redukuje powtarzającą się implementację podstawowego układu sterowania, wiązania zmiennych oraz logiki komunikacji odczyt/zapis w przypadkach, gdy VI backendu udostępnia kompatybilne zmienne8,9,10,11. Protokół ten jest zatem przydatny w edukacji inżynieryjnej, rozwoju laboratoriów zdalnych oraz szybkym wdrażaniu niskoryzykowych eksperymentów symulacyjnych lub dydaktycznych, które wymagają regulacji parametrów w przeglądarce i monitorowania stanu w czasie rzeczywistym. Przyszłe prace powinny rozszerzyć ten przepływ pracy o bardziej złożone struktury danych, fizyczne urządzenia eksperymentalne, formalną kontrolę dostępu dla wielu użytkowników oraz ilościową ocenę wydajności, w tym czas generowania interfejsu, opóźnienia komunikacyjne, stabilność synchronizacji, obciążenie serwera, narzut CPU oraz użyteczność front-endu.
Oświadczenia
Autorzy wykorzystali narzędzia wspomagane przez AI wyłącznie do korekty językowej. Cała treść naukowa, procedury eksperymentalne, implementacja oprogramowania, ryciny, wyniki, interpretacje oraz ostateczna redakcja tekstu zostały sprawdzone, poprawione i zatwierdzone przez autorów. Żadne narzędzie AI nie zostało użyte do generowania danych eksperymentalnych.
Podziękowania
Praca ta była wspierana przez Programy Szkoleniowe dla Studentów Studiów Pierwszego Stopnia w zakresie Innowacji Uniwersytetu w Wuhan.
Materiały
| Nazwa | Firma | Numer katalogowy | Komentarze |
|---|---|---|---|
| Serwer proxy Caddy | Caddy | N/A | Odwrócony proxy używany do obsługi interfejsu Web UI i przekazywania żądań /RIP do usługi RIP WebService |
| Caddyfile | Przygotowany przez autorów | N/A | Definiuje trasy plików statycznych oraz trasy odwróconego proxy dla komunikacji RIP |
| Fan_Automatic_UI.xhtml | Przygotowany przez autorów | N/A | Interfejs Web front end oparty na metadanych dla eksperymentu z wentylatorem |
| LabVIEW | National Instruments | 2026 | Oprogramowanie używane do konstrukcji i uruchamiania programów fengshan.vi oraz Motor.vi |
| System operacyjny Microsoft Windows | Microsoft | Win11 | System operacyjny używany do uruchamiania LabVIEW, RIP WebService, Caddy oraz przeglądarki |
| Motor_Automatic_UI.xhtml | Przygotowany przez autorów | N/A | Interfejs Web front end oparty na metadanych dla eksperymentu z silnikiem |
| Przeglądarka stacjonarna Mozilla Firefox | Mozilla | 2026 | Przeglądarka stacjonarna używana do dostępu do Web UI, narzędzi deweloperskich, obserwacji czasu i zasobów oraz wykonywania zrzutów ekranu z sieci i konsoli |
| RIP WebService | UNEDLabs | https://github.com/Nebulous-Systems/rip-server_labview | Odbiera żądania RIP POST i zapewnia warstwę komunikacyjną WebService wykorzystywaną przez front end przeglądarki |
| Menedżer zadań systemu Windows | Microsoft | Wbudowany w system Windows | Używany do rejestrowania obserwacji zużycia procesora i pamięci na poziomie procesów dla przeglądarki i procesów LabVIEW |
Bibliografia
- Gomes, L., Bogosyan, S. Current trends in remote laboratories. IEEE Trans Ind Electron. 2009;56(12):4744–4756.
- Ma, J., Nickerson, J. V. Hands-on, simulated, and remote laboratories: A comparative literature review. ACM Comput Surv. 2006;38(3):7-es.
- Heradio, R. et al. Virtual and remote labs in education: A bibliometric analysis. Comput. Educ. 2016;98:14–38.
- May, D., Jahnke, I., Moore, S. Online laboratories and virtual experimentation in higher education from a sociotechnical-pedagogical design perspective. J. Comput. High. Educ. 2023;35:203–222.
- Amador Nelke, S. et al. Enhancing lessons on the Internet of Things in science, technology, engineering, and medical education with a remote lab. Sensors.2024;24(19):6424.
- Lei, Z. et al. Interactive and visualized online experimentation system for engineering education and research. J. Vis. Exp. 2021;(177):e63342.
- Zhang, G., Lei, Z., Hu, W., Zhou, H. Online virtual reality networked control laboratory applied in control engineering education. J. Vis. Exp. 2024;(204):e66432.
- Fabregas, E., Farias, G., Dormido-Canto, S., Dormido, S., Esquembre, F. Developing a remote laboratory for engineering education. Comput. Educ. 2011;57(2):1686–1697.
- Chacón, J., Vargas, H., Farias, G., Sánchez, J., Dormido, S. EJS, JIL Server, and LabVIEW: An architecture for rapid development of remote labs. IEEE Trans. Learn. Technol.2015;8(4):393–401.
- Chacón, J., Farias, G., Vargas, H., Visioli, A., Dormido, S. Remote Interoperability Protocol: A bridge between interactive interfaces and engineering systems. IFAC-PapersOnLine.2015;48(29):247–252.
- de la Torre, L., Chacón, J., Chaos, D., Heradio, R., Chandramouli, R. Using IoT-type metadata and smart Web design to create user interfaces automatically. IEEE Trans. Ind. Inform. 2023;19(3):3109–3118.
- Chaos, D., Chacón, J., Lopez-Orozco, J. A., Dormido, S. Virtual and remote robotic laboratory using EJS, MATLAB, and LabVIEW. Sensors. 2013;13(2):2595–2612.
- Haj-Hosseini, N., Jonasson, H., Stridsman, M., Carlsson, L. Interactive remote electrical safety laboratory module in biomedical engineering education. Educ. Inf. Technol. 2024;29:20505–20521.
- Galán, D. et al. Safe experimentation in optical levitation of charged droplets using remote labs. J. Vis. Exp. 2019;(143):e58699.
- Kurtz, M., Benabbou, A., Pons, C., Broisin, J. Collaboration in virtual and remote laboratories for education: A systematic literature review. Int. J. Comput.-Support. Collab. Learn. 2025;20:549–603.
- Zamarreño, J. M., Ríos, J. C., Alonso, G. Virtual and remote laboratory as a complementary support in control education. Discov. Educ. 2025;4:477.
- Chacón, J., Sáenz, J., de la Torre, L., Díaz, J. M., Esquembre, F. Design of a low-cost air levitation system for teaching control engineering. Sensors. 2017;17(10):2321.
- Stefanovic, M., Cvijetkovic, V., Matijevic, M., Simic, V. A LabVIEW-based remote laboratory experiments for control engineering education. Comput. Appl. Eng. Educ.2011; 19(3):538–549.
- González, I., Calderón, A. J., Mejías, A., Andújar, J. M. Novel networked remote laboratory architecture for open connectivity based on PLC-OPC-LabVIEW-EJS integration. Application in remote fuzzy control and sensors data acquisition. Sensors. 2016;16(11):1822.
- Abdulwahed, M., Nagy, Z. K. Developing the TriLab, a triple access mode (hands-on, virtual, remote) laboratory, of a process control rig using LabVIEW and Joomla. Comput. Appl. Eng. Educ. 2013;21(4):614–626.
Przedruki i uprawnienia
Ten artykuł został opublikowany
Film wkrótce dostępny