Polskie Centrum LabVIEW

Witam,

jak powinien wygladac projekt oprogramowania w LV. Chodzi mi konkretnie jakie informacje powinien zawierac, jaka powinna być struktura projektu, generalnie co powinno sie w nim znajdować ? Czy sa jakies konkretne wytyczne do tworzenia projektru w LV. Moze ma ktos jakis przyklad ?

pozdro

Myślę, że Twój temat jest bardzo dobrym pomysłem i mam nadzieję, że stanie się miejscem do wymiany doświadczeń. Ze swojej strony dodam, iż warto by projekt został w swojej strukturze został podzielony na foldery, w których znajdą się przykładowo: Kontrolki (w formie typedef), Moduły (zawierające subVI), program główny oraz folder z plikami dodatkowymi np. jakaś dokumentacja, pliki readme. Myślę również, że warto trzymać się konsekwentnie konwencji nazewnictwa (folderów, plików, zmiennych) by móc natychmiastowo zorientować się co jest czym.

Witam,
wiem, że w większości firm kładzie się duży nacisk na ochronę danych ale może znajdzie się ktoś aby pokazać przykładowe realizacje...

Pozdrawiam

Fajny temat.
Można zacząć od analizy dziś udostępnionych materiałów z ostatniej konferencji NI: Dzień Programisty LabVIEW

Projekt programu w LV powinien się zacząć od dokumentu opisującego jego funkcjonalność i sposób działania.

bogdani

Dokładnie, dokumentacja jest bardzo istotna gdy wraca się do projektu po dłuższym okresie czasu, co zresztą Veritech udowodnił;)

Myślę, że wszystko zależy od zwyczajów w danej firmie, ale przede wszystkim istotne jest trzymanie się jednej ustalonej i jasnej konwencji tworzenia projektu. Dobrze jest korzystać z auto-populating folders. Dodatkowo każdy subVI/VI powinien mieć logiczną nazwę, pełen opis w polu description oraz ikonkę. Najlepiej by było, gdyby ikonki były tworzone zgodnie z jedną konwencją (mieszanie w stylu: jedna ikonka to sam tekst, druga ikonka to obrazek, trzecia ikonka domyślna, czwarta z ramką, etc. powoduje chaos w projektach:) ).

Może dla jednych to oczywiste, a dla innych mniej więc dodam coś od siebie.
Ważne, aby zwracać uwagę na polskie znaki. Najlepiej aby ich w ogóle nie było w projekcie.
Swego czasu chciałem ładnie ponazywać poszczególne porty w modułach cRIO po polsku i okazało się, że sygnał z portu jest niemożliwy do odczytania. Komunikatu o błędzie nie było, ale i sygnału też.
Innym faktem jest to, że gdy wysłałem projekt do pomocy technicznej (już ze zmienionymi nazwami tam gdzie trzeba, ale nie wszędzie), to był problem z jego otwarciem właśnie z powodu polskich znaków.

Jak juz o tym mowa, Moze dalo by sie namowic naszych tu obecnych GURU, na zrobienie "szablonu".
Widzialem kilka fajnych (bardzo zawansowanych) tzn. Katalog zawierajacy podkatalogi na rozne okazje. Juz wyjasniam.
osobny na SUB VI'ie, na Sterowniki, Controls (*.ctl), fpga, statemachines (z i bez queue), grafiki, schematy itd,ect.
Widzialem takie i wiem ze sa firmy ktore sie tylko w tym specjalizuja...
Ale powiem szczeze niewiem jak takiego gotowca ustawic w LV jako domyslny i zeby automatycznie zapisywal do stworzonych lokacji. tzn jak stworzysz nowy control t aby zachowal go w wybranym katalogu (domyslnie).

Pewnie stawiam durze wymagania, ale kazdemu takie cos by ulatwilo bardzo prace i nauczylo dobrych nawykow.

@Jamal: otwórz sobie plik lvproj z jakiegoś takiego rozbudowanego projektu w notatniku. Zauważysz, że ma on zwykłą strukturę xml, więc można napisać program, który taką strukturę będzie sam tworzyć w zależności od wymagań i zaznaczonych checkboxów. Nie wiem czy widziałeś prezentację Veritechu z ostatniego NI Developers Day - oni stworzyli tego typu narzędzie na własne potrzeby, gdyż np wykorzystywane w programach klasy się powtarzają. Możliwe, że program zostanie kiedyś udostępniony, ale można sobie napisać coś takiego, tylko mniej zaawansowanego i niekoniecznie wykorzystującego pokaźny zbiór zrobionych w przeszłości VI.

Właściwie to może się pobawię, żeby zrobić taki program w LV. W końcu wszystko właściwie jest dostępne: tworzenie folderów, plików, edycja XML, etc. etc, tylko kwestia jakiegoś zgrabnego połączenia elementów i przemyślenia jaka struktura folderów jest najbardziej uniwersalna i najłatwiej rozszerzalna.

To może jako Veritechowiec pomogę i zasugeruję, w końcu przez edukację również zdobywa się klientów ;)

Pomijając strukturę katalogów wynikającą z SVN, to u nas projekt wzorcowy składa się z następujących katalogów:
Docs - katalog zawierający różnego rozdzaju dokumentację, może zawierać:
Docs/Notes - notatki - przydaje się robienie notatek podsumowujących spotkania i wysyłanie ich wszystkim do zgłoszenia uwag/zatwierdzenia - to jest świetna praktyka i się sprawdza, gdy ktoś czegoś zapomni przy odbiorze
Docs/OfferSpecifications - specyfikacja ofertowa - dokument tworzony na początku i zawiera wymagania do oferty, jak również z oferty, to są wytyczne z wymogami wobec projektu (o wymogach trochę mówiłem w czasie prezentacji)
Docs/ProjectSpecification - specyfikacja projektowa - przepis na realizację projektu - dokument omawiany w czasie prezentacji
Docs/UserManuals - instrukcje użytkownika - dobrze gdy end user dostaje jakiś podręcznik - może się zdarzyć, że go przeczyta zanim zadzwoni na serwis
Docs/Others - dużo różnych dokumentów - często te otrzymane od klienta (instrukcje, opisy, schematy)
Docs/ProjectManagment - dokumentacja związana z zarządzaniem projektem - listy kontaktów (przydatne w pracy grupowej) dokumenty związane z inicjacją projektu, itd.

To było tytułem dokumentacji - wszystko oczywiście należy robić z głową, żeby nie było że program jest do zrobienia w tydzień, a wy robicie dokumentację przez miesiąc

Wracając do głównego katalogu to lecimy dalej:
Builds - wersja skompilowane programów
Installer - wersje instalacyjne - tu uwaga - niektóre instalatory zajmują spokojnie ponad 1 GB
Data - katalog na dane pomiarowe, testowe, itd.

Temp - bez tego nie ma projektu - wszystkie próby i testy lecą tu

Potem to już katalogi zawierające struktury plików związane z konkretną platformą:
FieldPoint
RIO
PXI
Windows
Shared - biblioteki wspólne dla różnych platform
Trzeba pamiętać jeszcze o FPGA - może być zarówno w RIO, PXI jak i Windows

To by było tyle, na tą chwilę. Mam nadzieję, że nie przynudziłem
Jak ktoś ma jakieś uwagi, propozycję to zapraszam do dyskusji. My też się ciągle uczymy i usprawniamy nasze działania.

bogdani

@Gareth: no wlasnie moge sobie cos tam pokabinowac.

Ale zawsze wychodze z zalozenia, ze brak czasu na wymyslenie kola od nowa.
Tak jak bogdani pisze, latwiej znalezc ludzi z talentem, jak mysla i wykorzystuja te same schematy i standarty.
Ja to widzialem tak:
VI w ktorym mamy szereg Checkboxow, adres gdzie chcemy zapisac nowy szablon i pod jaka nazwa.
Plik *.ini (textowy) z adresami katalogow, plikow, ktore wyskocza pod postacia Checkboxow.

Zrobilem takie cos na szybko.

Tabela z wyborem pozycji.
Adresiki do zapisu projektu.
Pola tekstowe
adresiki do zapisu tekstow. (a moze i print screeny, snagity)
Sam niewiem czy to wogole ma znaczenie ale ja lubie miec katrole i mozliwosc "updatowania" postepow.

Tak aby kazdy kolejny update tekstow zapisywal w tym samym pliku, w kolejnej linijce z aktualna data i czasem...