uogólnienie rozwiązania

[MK_Zuk]

Witam.
Proszę o pomoc w sprawie uogólnienia rozwiązania jeżeli da się w ten sposób.
Generalnie zależy mi, żeby zrobić to na typedef.
1. klaster z referencjami zamieniany jest na wektor,
2. wszystkie zadania są uruchamiane,
3. chcę złożyć wszystkie referencje z powrotem do klastra.

Problem jest z punktem 3.
- Wersja z index array i bundle nie jest skalowalna,
- wersja z array to cluster "gubi" strukturę klastra i w dalszej części unbundle by name nie będzie miało sensu...
W jednym miejscu potrzebuję 3 lub 4 zadania uruchomić a w innym 2 zadania.
W wersji nieskalowalnej potrzebowałbym 2 praktycznie identyczne vi.

Pozdrawiam
Zuk

[semper fidelis]

A czy skoro pusczasz to wszystko na petle for z indeksowaniem to i tak kazda z tych referencji nie zostanie zmieniona? Nie 4 lub 2 tylko tyle ile jest w Twoim type def?

[pawhan11]

W openG masz dużo gotowców do zabawy z typami danych.
Jeżeli chcesz dynamicznie wyciągnąc wszystkie el klastra coś na nich zrobić i spakować spowrotem to można np tj w zalaczniku
Tylko na logike jak to jest referencja to nie ma potrzeby jej spowrotem wpinac do tego klastra.

[Zyga]

Jeśli nie masz OpenG,

type cast.png (11.1 KiB) Przejrzano 11159 razy

to polecam zainstalować

[PiDi]

Witam.

W jednym miejscu potrzebuję 3 lub 4 zadania uruchomić a w innym 2 zadania.
W wersji nieskalowalnej potrzebowałbym 2 praktycznie identyczne vi.

Pytanie: to dlaczego to musi być typedef klastra, a nie tablica tasków?

[MK_Zuk]

Pytanie: to dlaczego to musi być typedef klastra, a nie tablica tasków?

Bo w klastrze nie będę musiał pamiętać, który task dotyczy którego zadania
odpowiednie zadania będę wyciągał unbundle by name
a przy tablicy będę musiał pamiętać kolejność - z klastrem bardziej czytelne i trudniej pomylić się.

Dziękuję wszystkim za odpowiedzi.
najprostsze rozwiązanie - rzutowanie typów - nie pomyślałem o tym.
Niestety dla tasków nie działa...

Pozdrawiam
Zuk

[TMa]

Również operowałbym na tablicy elementów. W elastyczny sposób pozwoli to na zarządzanie zadaniami. Jako element sugerowałbym w najprostszej wersji klaster składający się z referenji i nazwy (Np. EncoderX, EncoderY, PowerSwitch etc). Jeśli działasz na wszystkich to wtedy używasz iteracji po każdym elemencie w tablicy (run all, stop all). Jeśli działasz na konkretnych, to zwracasz się do nich po nazwie (patrz załącznik).

W wersji dla bystrzaków proponuje OOP. Wtedy elementy tablicy będą mogły mieć różne typy danych co dodatkowo uelestyczni rozwiązanie. Klasa bazowa/abstrakcyjna ustalająca interfejs i klasy dziedziczone w zależności od typu taska.

[MK_Zuk]

Wersja "dla bystrzaków" na razie nie dla mnie w tym projekcie.
Nie bawiłem się jeszcze w OOP,
a w niektórych projektach lepiej nie eksperymentować z nowymi rozwiązaniami...

Dzięki za pomoc
Pozdrawiam
Zuk

[PiDi]

Pytanie: to dlaczego to musi być typedef klastra, a nie tablica tasków?

Bo w klastrze nie będę musiał pamiętać, który task dotyczy którego zadania
odpowiednie zadania będę wyciągał unbundle by name
a przy tablicy będę musiał pamiętać kolejność - z klastrem bardziej czytelne i trudniej pomylić się.

To w jaki sposób decydujesz o tym, które zadania uruchamiać? Czyli jak robisz to, o czym pisałeś w pierwszym poście:

W jednym miejscu potrzebuję 3 lub 4 zadania uruchomić a w innym 2 zadania.

[MK_Zuk]

Rozwiązanie Zygi jednak nie działa dla Task Refnum.
Dla innych typów danych w klastrze jest OK.

To w jaki sposób decydujesz o tym, które zadania uruchamiać?

Generalnie są dwie niezależne pętle.
W jednej są 4 zadania a w drugiej 2 zadania.
Chciałem to trochę uogólnić, żeby nie robić dwóch identycznych subVI.
Ale chyba tak jednak nie da się.
Trochę mało czasu na dalsze eksperymentowanie...

Dziękuję wszystkim za pomoc.

Pozdrawiam
Zuk