Hm... ist ziemlich genau das, was ich die letzte Zeit gemacht habe.
Je nachdem wo die Randbedingungen liegen und euer KnowHow, ist die Frage
zu klären, ob ihr euch die PC-Seitige Testumgebung selbst macht, oder
ein Baukastenprinzip kauft.
Also selbst bauen dann z.B. mit C#/.NET oder C++/Qt. Die Anbindung lässt
sich z.B. über eine USB<>UART Brücke machen. Dann kann man Frames
definieren, die in den Slaves was auslösen, bzw. solche mit denen die
Slaves antworten.
Und Vorsicht, da normale Desktop Bestriebsysteme nicht Echtzeit sind,
muss man sich was einfallen lassen, wenn man es bei seinen DUT´s mit
Zeitkonstanten zu tun bekommt.
Auch mit Arduino sollte man vorsichtig sein. Im Prinzip geht das, aber
wenn irgendwas zeitkritisch wird oder sonst ein spezieller Parameter ins
Spiel kommt, muss man schon genau wissen, was in dem Ardu-Framework los
ist. U.U. ist man mit einem nacktem µC besser bedient. Ich habe bei
meinen Testadaptern Arduino benutzt. Die kriegen nur ein Frame, wo
drinsteht, welchen Kanal sie messen sollen und dann wird postwendend
geantwortet, Meine Teitkonstanten sind so groß, dass das bisschen Jitter
vernachlässigbar ist.
Mit
>Endtest incl. Programmierung
meinst du wahrscheinlich, dass das DUT von der Testumgebung auch
geflasht wird? Das ist natürlich schon eine Portion Individualismus. In
Qt habe ich das schon gesehen, dass Compiler, Encypter und Flashtools
aus der Umgebung heraus gestartet wurden. Ich würde einfach mal tippen,
das C# das auch kann.
Ich kenne mich ehrlicher Weise weder in Lab View noch Profilab (gar
nicht) gut aus. Aus dem Bauch heraus würde ich raten, dass ihr erstmal
in harten Zahlen (z.B. Abtastrate / Auflösung) und Fakten (könnt ihr
alles was ihr simmulieren und mesen wollt WIKRLICH in Beton gießen?)
beschreibt, ob ihr 100% wisst, was ihr machen wollt. Sonst sucht ihr
euch am Ende ein Baukastenprinzip, dann ändert sich was im Projekt und
eurem Kasten fehlt eine Fähigkeit, oder sie kostet vll. Aufpreis.
