Opcja na prostą modernizację starszych środowisk LabVIEW + TestStand
: 17 cze 2026 02:19
Hej, od paru tygodni po godzinach pracuję nad wrapperem Python dla TestStand COM API o nazwie py-teststand 
.
Tworzony z naciskiem na automatyzację środowisk opartych na stosie: LabVIEW (front-end - interfejs użytkownika i back-end - adaptery oraz wrappowanie .NET Framework / Core) + TestStand (executive), poprzez ułatwienie tworzenia nowoczesnych narzędzi R&D (osobiście też cenię sobie możliwość tworzenia dystrybuowalnych kopii oprogramowania poprzez "mrożenie" projektów przy użyciu cx_Freeze).
Wspierane wersje Python to 3.8.20 do 3.14.x, żeby zachować oficjalną kompatybilność dla Windows 7 (przy wyborze starszej wersji interpretera), a przy tym móc zarządzać sprawnie projektem przez stos Astral.sh.
W przykładach jest pokaz jak używać do manipulacji kroków opartych na adapterze LabVIEW (z podreśleniem tych wywoływanych z poziomu projektu - LVPROJ oraz PPL aka LVLIBP).
Testowane na kombinacjach: LabVIEW 2017 SP1 32-bit + TestStand 2016 SP1 32-bit oraz LabVIEW 2026 Q1 64-bit TestStand 2026 Q1 32/64-bit
Podejrzewam, że realnie też wspiera starsze wersje silnika (np. 14.0), gdyż większość (jak nie wszystkie) owrapowanych typów COM tam istnieje.
Technologicznie redukuje także potrzebę przełączania wersji środowisk
, tak jak jest to potrzebne przy używaniu modułów z palety wsparcia LabVIEW do deploymentu LLB do vi.lib, lub remapowania bibliotek interop dla API .NET w Visual Studio.
.Tworzony z naciskiem na automatyzację środowisk opartych na stosie: LabVIEW (front-end - interfejs użytkownika i back-end - adaptery oraz wrappowanie .NET Framework / Core) + TestStand (executive), poprzez ułatwienie tworzenia nowoczesnych narzędzi R&D (osobiście też cenię sobie możliwość tworzenia dystrybuowalnych kopii oprogramowania poprzez "mrożenie" projektów przy użyciu cx_Freeze).
Wspierane wersje Python to 3.8.20 do 3.14.x, żeby zachować oficjalną kompatybilność dla Windows 7 (przy wyborze starszej wersji interpretera), a przy tym móc zarządzać sprawnie projektem przez stos Astral.sh.
W przykładach jest pokaz jak używać do manipulacji kroków opartych na adapterze LabVIEW (z podreśleniem tych wywoływanych z poziomu projektu - LVPROJ oraz PPL aka LVLIBP).
Testowane na kombinacjach: LabVIEW 2017 SP1 32-bit + TestStand 2016 SP1 32-bit oraz LabVIEW 2026 Q1 64-bit TestStand 2026 Q1 32/64-bit
Podejrzewam, że realnie też wspiera starsze wersje silnika (np. 14.0), gdyż większość (jak nie wszystkie) owrapowanych typów COM tam istnieje.
Technologicznie redukuje także potrzebę przełączania wersji środowisk
, tak jak jest to potrzebne przy używaniu modułów z palety wsparcia LabVIEW do deploymentu LLB do vi.lib, lub remapowania bibliotek interop dla API .NET w Visual Studio.