AuronX

Zumindest zeigt mir mein Visual Studio keine anderen als die genannten Warnungen zum Thema CLS, ich denke also, dass das alles sein sollte. Spontan würde ich übrigens denken, dass die korrekte Schreibweise [CLSCompliant(false)] sein müsste, also ohne Attribute. Möglicherweise geht aber auch beides. Verstehe ich es richtig, dass ihr nur bei den Methoden wo der Wertebereich es notwendig macht zwei Überladungen anbieten wollt? Oder soll es für jede Methode eine zweit-Überladung geben? (beispielsweise wäre sie ja bei SetVoltage im AnalogOut nicht nötig, weil der maximal 5000mV kann) Viele Grüße Jan

@Nic: Wie gesagt, es gibt Bindings für VB.Net! Denn die C#-Bindings sollten das Problemlos unterstützen. Was fehlt ist lediglich die entsprechende Doku. Allerdings gebe ich dir gerne recht, dass es nie eine schlechte Idee sein kann sich C# anzuschauen edit: ich nehme alles zurück und behaupte das gegenteil! Folgendes Problem: Das Benutzen von C#-DLLs in VB.Net funktioniert nur, wenn die DLL auch CLS-compliant ist (das ist der gemeinsame Sprachstandard von z.B. C# und VB.Net). Allerdings sind unsigned integers (uint) nicht Teil der CLS. Wenn jetzt also eine C#-Bibliothek Funktionen anbietet die ein uint erwarten, dann kann man diese aus VB.Net gar nicht nutzen, weil VB.Net kein uint kennt. Wenn ich das gerade richtig überblicke nutzt die aktuelle Bibliothek an 267 Stellen uint oder ushort als Parameter oder Rückgabewert. Damit ist die Bibliothek so nicht in VB.Net nutzbar. Ich kann im Moment nicht einschätzen, ob und wie gut es möglich ist diese Vorkommen durch andere Datentypen zu ersetzen. Dazu würde ich dann aber demnächst zumindest meine Meinung äußern können Viele Grüße Jan ergänzende Kurzanalyse: Es gibt auf jeden Fall Methoden wo ushort nicht notwendig ist. Beispiel: BrickletAnalogOut.SetVoltage(ushort voltage). Laut Spezifikation sind für voltage Werte von 0-5000 erlaubt. Das bedeutet zweierlei Dinge: 1. Sowohl der Wertebereich von short also auch der von ushort umfassen den vollen Bereich der Spezifikation 2. ushort bietet den (scheinbaren) Vorteil, dass man keine ungültigen negativen Spannungen angeben kann. Allerdings ist es noch immer möglich höhere als die spezifizierten Spannungen anzugeben. Insofern wäre m.E. ein Range-check sowieso von Vorteil, wenn man den macht, dann kann man auch direkt für beide Grenzen (0 und 5000) testen und ggf. eine Exception werfen.

Falls du Angst hast nicht genügend Strom zu bekommen gibt es ja auch noch eine Alternative: ein Stack pro Lichtquelle Du könntest eine Step-Down-Supply + Master pro Lichtquelle betreiben, dann hätte jede Quelle die volle Stromversorgung und müsste sie sich nicht mit den anderen teilen. Du brauchst dann aber auch noch eine Master-Extension (Kabellos oder mit Kabel) um die einzelnen Stacks zu verbinden. Ist aber zugegeben auch etwas teuer... [edit: ich stelle gerade fest, dass du möglicherweise sogar schon so gerechnet hast...] externer Dimmer? Ich frage mich ob es möglich ist einen externen PWM-Dimmer mit Potenziometer zu nutzen. Die Idee wäre, dass man die Poti-Ansteuerung durch eine TF-Ansteuerung (Analog-Out???) ersetzt und TF dadurch nur die Regelung übernimmt, die Versorgungsspannung der LED aber nicht durch die TF-Teile bereitgestellt wird. Wenn das ginge wäre auch gleich das PWM-Problem erschlagen, allerdings fehlt mir hier das elektrotechnische Wissen... Wegen dem PWM frage ich mich außerdem gerade, ob man dafür nicht auch das DC-Brick verwenden kann. Das können dir die TF-Leute bestimmt besser sagen, aber ich hätte gedacht, dass das DC-Brick nix anderes tut als ein Gleichstromgerät per PWM zu kontrollieren. LG Jan

Sobald ich meine eigenen Bricklets habe werd ich mir mal ne kleine VB-Umgebung aufsetzen und versuchen die C#-Beispiele nach VB.Net zu übersetzen (im Wiki denke ich, oder?). Musst du aber ein wenig warten, weil ohne jemals mit den kleinen Teilen gearbeitet zu haben will ich dann doch lieber nicht dokumentieren

Dass es in Java geht habe ich ja nicht bestritten, dennoch finde ich die andere Lösung schöner. Im übrigen wäre mE eine eigene Datei mit public Device sinnvoller als das Device in der IPConnection. Das Device in der IPConn ist ja eher ein Hack, weil Java die Klassen<->Datei-Beziehung enforced. P.S.: Im übrigen hab ich mich sogar zunächst gewundert, wo denn das Device steckt, da es keine Device.java gab

Vermutlich würde niemand Echtzeit-verarbeitung mithilfe von Webservices machen und natürlich hat Soap overhead. Auf der Haben-Seite steht allerdings eine Plattformunabhängige Zugriffsmöglichkeit, insofern keine dumme Idee, da oft keine Echtzeit nötig ist (Wetterstationen, Lichtautomatik, etc.). Es ist ja btw. schon strittig ob es ne gute Idee ist, Echtzeitverarbeitung unter Betriebssystemen wie Windows 7 oder Linux zu machen, beide bieten keine "hard realtime". Für sowas nutzt man dann eher Windows CE oder RT-Linux.

Ist ja spannend... habe mir auf deinen Post hin die Java-API das erste mal angeschaut. Device ist ja selbst nicht public, wird aber in der public Methode einer public Klasse als Parameter verwendet (IPConnection.addDevice()), ist also am Ende schon irgendwie "sichtbar". In der DotNet-Welt (also z.B. C#) würde das zu einem Compile-Fehler führen, weil da nichts nach außen sichtbar sein darf, was nicht selbst auch als public deklariert ist. Das macht auch Sinn ^^ Insofern würde ich dir rechtgeben, das Device gehört public.

Are your C#-Bindings CLR-compliant? If so they should work for Visual Basic .NET out of the box (as for any other CLR-compliant language). Or what do you mean by "Visual Basic"? BR Jan

Weil ich gerade den "you will never get here" Kommentar gelesen habe: try: # die ursprüngliche while-schleife except KeyboardInterrupt: print('Received request to stop the program (Ctrl+C)') # You will now get here ipcon.destroy() Viele Grüße Jan P.S.: Hoffe keine Syntaxfehler gemacht zu haben, aber denke das Grundprinzip erschließt sich auch so