Messgeraete-Steuerung ueber Excel etc?

Joerg :

Und schaumal hier weiter zurück das Posting zu VB und RS485. Wenn du bytes haben willst, musst du bytearrays verwenden. Selbst eine als byte (char) defi nierte Variable kann mehrere Bytes gross sein (Unicode o.ä. Dilemma mit dem Zeichensatz).

VBA ist also für das, was du vorhast, ne ziemliche Krücke. Delphi find ich auch ziemlich genial. Version 4 mit den 2 Updates. Die Versionen danach sind schon wieder unnütz aufgebläht. Wenn man aber Wert drauf legt, Teile der Software auch mal woanders mitzunutzen, dann sollte man C++Builder wählen. Das ist im Prinzip ein Delphi, nur das man halt in C programmieren kann.

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

Hallo zusammen,

vor ein paar Jahren gab's mal einen Artikel in der Elektronik in dem MSP40 über Excel programmiert wurden. Alles in Excel, also keine dlls oder ocx oder sonstiges. Der Vorteil -alles ist im Excelfile enthalten. Damit hab ich mir von der i2c-Steuerung bis zum Online-Debugger für die Fujitsu 16LX-Controller oder das Eval-Board von Luminary alles auf die schnelle zusammengeschustert. Ging auch für mich als Nicht-Softi sehr gut. Das File nannte sich vb_rs232.zip Hat mir immer gute Dienste geliefert. @Joerg ... you have mail.

Gerold

Hallo Matthias,

Den Thread hatte ich mitgelesen und die char-byte Geschichte gleich notiert. Da bekam ich schon den Eindruck, dass das alles etwas "krueckig" ist.

Nur hat MS eben VBA gewaehlt und damit ist auf anderen Rechnern oft nicht mehr drauf. D.h. wenn jemand einen Excel File so wie er ist mit Messgeraeteanschluss laufen lassen will, geht es wahrscheinlich kaum anders.

Instek scheint das eigene Interface mit .NET gemacht zu haben. Jedenfalls musste ich das erstmal installieren, damit es lief. Dieses Interface ist jedoch nicht frei konfigurierbar, funktioniert aber fuer Doku Zwecke ganz brauchbar. Das bedeutet zum Beispiel, dass man Scope Plots unter 10sec/div nicht direkt damit machen kann. Wie Murphy es vorhersagte, kam genau dann ein Auftrag, wo ich etliche Minuten/div als Display brauchte. Das ging nur ueber den recht langen Speicher dieses DSO, indem ich den in Excel lud und dann skalierte. Mit der anfangs ins Auge gefassten Tek2xxx Serie haette ich vermutlich ziemlich alt ausgesehen.

--
Gruesse, Joerg

http://www.analogconsultants.com

Matthias Weingart schrieb:

Ja, ja die Datentypen...

Da muss ich widersprechen. IMHO ist Delphi 5 eine der besten Versionen. Delphi 7 ist sicher gebraucht teurer, soll in mancher Hinsicht besser sein, hab ich aber nie gehabt (es enthaelt quasi AdoExpress, was bei D5 ein Zugekauft werden musste)). Ansonsten hatte ich bisher 1,2,4,5,2006. Es haelt sich hartnaeckig das Geruecht, die ungeraden Versionen seien immer die besseren gewesen.

2006 enthält in der Pro Version auch den C++Builder. Sie wirkt in der tat ein wenig aufgeblaeht, bietet aber auch eine Menge. Ich kann diese Version allerdings nicht fuer den Einstieg empfehlen, da die Hilfe echt schlecht implementiert ist. Mein Tip für den Einstieg ist daher Version 5 mit kleinen diversen Helfern (Gexperts, DelForExp[must have]...).

Peter

Hallo Gerold,

Meintest Du den MSP430?

Danke, angekommen! Konkrete Beispiele, also das Lesen von Code aus dem wirklichen Leben, sind immer besser als die ueblichen "Hello World" Lektionen.

--
Gruesse, Joerg

http://www.analogconsultants.com

Joerg :

Warum geht eine normale Exe-Datei nicht?

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

Hallo Matthias,

Geht schon, ist aber bei groesseren Betrieben nicht erlaubt. Das muesste u.U. die EDV installieren und das will man sich nicht wirklich antun.

--
Gruesse, Joerg

http://www.analogconsultants.com

Hallo Heiko,

Ich habe in Europa mehr PC-Anbindung ueber MS-Office im Labor gesehen als hier. Bei uns ist es meist LabView. OT finde ich das nicht, da wir in dieser NG so gut wie alle mit Labormessgeraeten zu tun haben.

Bisher hatte ich noch keinen Fall erlebt, wo Office nicht die offizielle EDV Oberflaeche in den Bueros der Firma war. Bis auf eine kleine SW-Schmiede bei Muenster vor 15 Jahren, wo sie Apples benutzten.

Die Einschraenkungen werden mir auch so langsam bewusst, ebenso der wahre Wust an Code, der dabei entsteht. Jedoch hatten mir Peter und Gerold per PM einiges geschickt, was sehr hilfreich ist, besonders zum Lernen. Normaler Datenaustausch mit Messgeraeten sieht danach sehr machbar aus. Jedenfalls nachdem in Sachen Control Boxes, Message Blocks und RS232 Anbindung bei mir so langsam die Groschen fallen. Etliche Messgeraete (zumindest in meinem Labor) arbeiten bis auf den Fall der Live Bilduebertragung auch ueber USB mit Pseudo-RS232. Klar, mit dem Live Bildschirm wird das nichts ueber Excel, doch das dient ja nur der Doku und wird einfach per mitgeliefertem Viewer aufs LAN geschickt.

Da wurde ich eben nicht ganz schlau draus. Zum Beispiel fehlte ordentliche Info zum RS232, die ich dank Gerold und Peter jetzt aber habe.

Mit Steuerblock meinte ich ein Eingabefeld fuer den Benutzer, das halbwegs intuitiv ist. Dies laesst sich in Excel offenbar recht ansprechend hinzaubern, sofern man mit Pfeiltasten, Scroll Bars und Textfeldern zufrieden ist. Da kann man mit leben.

Da ist was wahres dran. C ist manchmal so wie ein Rennrad ohne Vorderbremse. Es ist flott, aber genauso schnell kracht es auch.

--
Gruesse, Joerg

http://www.analogconsultants.com

Das ist auch ein Problem mit den diversen Excel-Versionen. Ich selbst schlage mich damit nicht herum, aber meine Mitarbeiter machen gelegentlich Anpassungen, bzw. Schnittstellen, um zwischen Delphi und Excel oder auch Delphi und Word Daten auszutauschen. Das funktioniert übrigens im Prinzip genauso, wie von Visual-C zu Excel. Ist also nichts Delphi spezifisches.

Kunden setzen gerne Excel oder auch Access ein, weil sie glauben, damit z.B. eigene Auswertungen relativ leicht realisieren können. Es gibt aber immer wieder Probleme mit Versionsunterschieden oder Grundeinstellungen. Anstatt richtig programmieren zu lernen, schlägt sich der User dann mit den Fehlern anderer Leute herum.

Mir sind diese "Pfuschertools" Excel und Access einfach zu unordentlich.

Wenn man so eine Anwendung sieht, weiß man nie, ob die Sachen als Makro irgendwo versteckt sind, ob es VB-Programme sind und wo überall rumgetrickst wurde um irgendwelche Funktionalitäten zu realisieren, die man mit einer ordentlichen Programmiersprache ganz einfach und verständlich formulieren kann.

Da wird dann mir irgendwelchen Grundeinstellungen herumgebastelt, solange, bis etwas läuft und man hat einfach keinen Überblick über das "Programm". Das ist einfach Chaos-Programmierung...

Wir lösen das normalerweise so: Wir schreiben ein Programm in Delphi, das als DLL compiliert wird. Das geht genauso in C, C++ oder C##. Diese DLL stellt Funktionen zur Verfügung, die in VBA aufgerufen werden können. Dazu liefern wir dem Kunden eine Exel-Tabelle mit einem Beispielprogramm in VBA, wo diese Funktionen aufgerufen werden.

Stefan

Klar, glaub ich dir. Man geht natürlich zunächst mal den Weg, den man kennt, und mit VBA kenn ich mich so gut wie gar nicht aus. Aber das was du beschreibst, klingt vernünftig.

Stimmt sicher. Aber wenn es um die Kommunikation mit Messgeräten geht, würde ich ein Delphi- oder C Programm immer einer Excel-Lösung vorziehen. Daten dann in eine Datenbank, z.B. SQL oder D-Base, oder in eine CSV-Datei schreiben, und dann kann der User das in Excel oder Access einlesen, wenn er weitere Auswertungen braucht.

Das kommt auf die Disziplin des Programmierers an. Man kann in C durchaus ordentlich sauber und lesbar programmieren.

Un wenn es kracht, findet man meistens auch die Ursache und hat eine Chance, diese zu Beseitigen.

"Stefan Brröring" schrieb im Newsbeitrag news:f9js0b$im7$ snipped-for-privacy@news1.ewetel.de...

In C we had to code our own bugs. In C++ we can inherit them.

Bezieht sich darauf, dass in C++ manchmal gar nichts mehr dasteht, wo doch auf zauberische Art Code ausgefuehrt wird (der dann ggf. falsch ist, zumindest falsch an der Stelle).

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Was muss denn da die EDV installieren? Dass du eine ausführbare Datei auf ein bestimmtes Verzeichnis kopierst? Dass du ueberhaupt eine anderes ausfuehrbares Programm als die offiziellen "katholischen" startest?

Wenn die EDV-Policy in einem Laden so ist, dann haben die Admins auch die Ausfuehrung von Office-Makros verboten/unterbunden, sofern sie einen Schuss Pulver wert sind. Und dann muessen die die Ausfuehrung deines Makros genau so freischalten wie bei jedem anderen ausfuehrbaren Programm.

Ich verstehe so wenig wie viele andere hier, warum man sich den Einstieg in die Steuerung von Messgeraeten unnoetig erschweren sollte, indem man VBA waehlt. Wenn du schon lange der VBA wizard waerest, waere das sicher eine naheliegende Idee - if all you have is a hammer, everything looks like a nail.

Richtige Programmiersprachen gibt es aber auch, und wenn man mit dem Programmieren anfaengt, sollte man IMHO nicht mit der uebelsten greifbaren Gurke anfangen. Delphi, C#, Python (mein heimlicher Favorit) sind gratis oder fuer kleines Geld zu haben, laufen auch ohne MS-Office, koennen grafische Benutzeroberflaechen bauen etc. etc.. Die Auswertung von Messdaten in Excel kannst du trotzdem haben. Dafuer (und _nur_ dafuer) wuerde ich Excel benutzen, wenn ich nicht schon lange OOo calc vorzoege :-)

Gruss Michael

ja MSP430 - sorry bei mir sind die Gedanken machmal schneller als die Finger....

..und an alle anderen SW-Profis: es ist mir schon klar, dass VBA keine richtige Programmiersprache ist, dass man alles viel besser mit "richtigen" Entwicklungswerkzeugen machen kann und und...-aber alles natürlich nur so man hat (incl. das nötige Know-How etc). Das hatte ich alles nicht und es musste unbedingt schell mal über RS232 was eingelesen/ausgegeben werden. Auch der anscheinend allseits beliebte LTC1290 Bausatz der mir vor ein paar Wochen über den Weg lief, war schnell ausgelesen und mit ein paar farbigen Zellen versehen kann man auch in Excel recht Ansprechendes zusammenklopfen. Und man kann das ganze 1:1 in VB6 reinkopieren ;-=)

-Ja alles schnell und dreckig... aber mir hat's geholfen und hilfts noch immer ;-)

Gerold

Hallo Michael,

So aehnlich, oder es wird gleich von der Firewall ausgebremst. Dann muesste man es umbenennen, was auch nicht ganz so koscher ist.

Das ist aber haeufig so, weil in Unternehmen Macros intern gebraucht werden. Was vom Web kommt, geht erstmal durch den "Schrubber". Wenn selbiger gut funktioniert, bleibt alles sicher.

:-)

Fuer richtige Programmiersprachen muss man auch richtiger Programmierer sein. Das bin ich nicht. Ausserdem ist es so einfach auch nicht. Beispiel: Ein Programmierer (ein recht guter) erstellte vor zwei Monaten so eine Steuerung fuer eines meiner Kundendesigns. Der Kunde wollte dann noch alles ein wenig graphisch a la Excel haben, worauf erstmal ein C-Graphikpaket gekauft werden musste. Er sagte, mit dem Compiler wuerden nur ganz rudimentaere Graphik-Extensions geliefert.

--
Gruesse, Joerg

http://www.analogconsultants.com

Hallo Stefan,

Wenn alles '97 kompatibel gehalten wurde, hatte ich noch keinen Aerger mitbekommen.

Es sind aber "die" Office Programme. Gibt's in so gut wie allen Firmen, oft aber nichts anderes.

Das waere natuerlich auch eine Moeglichkeit, viel eleganter. Doch dafuer muss man ein guter Programmierer sein. Zu denen zaehle ich als Analogix derzeit eher nicht.

--
Gruesse, Joerg

http://www.analogconsultants.com

Hallo Gerold,

Sehe ich auch so. In Amerika gibt es die Ausdruecke "good enough" und "keep it simple". Warum gueldene Wasserhaehne installieren, wenn man sich nur mal eben die Haende damit Waschen will?

Nochmal vielen Dank fuer Deine Files. Inzwischen habe ich auch raus, wie man diese kleinen grauen Kommandobloeckchen setzt. Doch heute sind Holzpfosten zu reparieren. Die Freuden eines Holzhausbesitzers :-(

--
Gruesse, Joerg

http://www.analogconsultants.com

Hallo Stefan,

Das gibt es heute zu den Messgeraeten als Beilage. Auch mein Scope hat ein Programm dabei, das in eine CSV Datei schreibt. Musste ich letztens fuer eine Langzeitmessung benutzen. Doch das verlangt einen Eingriff des Benutzers per Keyboard.

--
Gruesse, Joerg

http://www.analogconsultants.com

Hallo Stefan,

Manchmal akustisch. So wie ich bei meinen ersten Gehversuchen mit dem Microsoft C 7.0 Anfang der 90er. Musste natuerlich gleich eine Displaygeschichte sein (brauchte ich dringend). Ploetzlich fing der Zeilentrafo uebel an zu zischen und es spratzelte. Irgendwie muss ich an der in DOS eingestellten Sicherheitsgrenze fuer die Zeilenzahl vorbeiprogrammiert haben.

--
Gruesse, Joerg

http://www.analogconsultants.com