"Olaf Kaluza" schrieb im Newsbeitrag news: snipped-for-privacy@criseis.ruhr.de...
Mail die an, die im Internet freie Software geschrieben haben, die deine Ansprueche erfuellt. Die haben BEWIESEN das sie was kooennen und das sie Engagement haben.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
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.
Wie weit ist eigentlich Delphi in der Industrie verbreitet? Interessiert mich nur, weil ich eigentlich ein Delphi-Fan bin. Nur habe ich überall gehört "C++ für die Industrie, sonst gibts nix". Egal, ich habe C/C++ gelernt, Delphi gefällt mir immer noch besser. Gruß Andy
"MaWin" wrote in news: snipped-for-privacy@individual.net:
Frag mal in den Delphicorners im Internet z.B.
formatting link
oder guck nach den Autoren bei
formatting link
oder
formatting link
Meisten sind das natuerlich erstmal "nur" Delphiprogrammierer, das hardwarenahe muss man ihnen erstmal "beibiegen" :-). Am ehesten findet man gute Hardwareleute auch unter den Teilnehmern bei Elektronik-Design Wettbewerben (z.B. circuitcellar.com oder elektor hatte sowas auch mal gemacht), manche haben auch Delphi benutzt um Ihr Projekt an den PC zu koppeln.
Delphi benutze ich auch gern. Es ist ungeschlagen schnell, wenn man schnell mal was "zusammenhacken" will (in jeder Hinsicht). Und mehr als Delphi 4 braucht man eigentlich auch nicht. Wenn gemeinsamer C-Code benutzt werden muss, kann man auch auf BCB (C++ Builder) zurückgreifen. Das ist aber ziemlich "haesslich" ;-).
Delphi ist nicht besonders gut geeignet für hardwarenahe Programme. Es fehlen Mechanismen, die gute Hardwareanbindung erleichtern. Besonders in den letzten Jahren hat sich Borland bemüht, mehr in die Richtung Datenbankanwendungen, Internetkommunikation, usw. zu gehen.
Für Steuerungen, Meßdatenauswertung, usw. sind andere Werkzeuge und Sprachen besser geeignet, C++ ganz bestimmt, besonders mit solchen Entwicklungsumgebungen, wie LabWindows, für solche Leute, die sich nicht in Tiefen der maschinennahen Sprache begeben wollen natürlich auch LabView. Die zuletzt genannte Sprache scheint sich daher immer mehr zu verbreiten.
Ich glaube, daß Delphi immer seltener für hardwarenahe Programmierung genutzt wird, sogar Visual Basic scheint aus dieser Hinsicht besser verbreitet zu sein (komischerweise besonders in Italien).
Aufgrund unserer Erfahrung würde ich C++ mit LabWindows empfehlen. Seit
1986, als ich solche Sachen mache habe ich etliches ausprobiert, viel hat sich geändert, aber nur wenige Sachen sind wirklich für industrielle Anwendungen geeignet, besonders bei zeitkritischen Aufgaben.
Für Ansteuerung der Meßgeräte sind in einigen Fällen die Programme der Gerätehersteller besser - zum beispiel von HP.
Windows muß natürlich nicht immer sein, es gibt aber auch sehr gute Alternativen (billige und teure) - und da funktionert normaleweise auch kein Delphi.
Programmierer, die wirklich gute hardwarenahe Programme machen können sind nicht so leicht zu finden, da sie normaleweise sehr begehrt sind. Nur wenige Menschen können das wirklich gut, da sie sowohl die Software-, wie auch die Elektronikkenntnisse benötigen. Zusätzlich müssen sie auch die Funktion der Hardware verstehen und oft sogar noch viel mehr.
Am Fri, 04 Feb 2005 21:56:14 +0100 schrieb Wieslaw Bicz :
Messgeräte hab ich auch programmiert, zwar im universitären Umfeld und hauptsächlich mit LABView, aber wir hatten auch Delphi im Einsatz ;)
Ich bin zwar Informatikstudent, aber meine Libs hab ich mir (wo es ging, da dokumentiert) selber gebaut - ich hoffe, dass ich das nicht nach dem Diplom verlernt habe ;)
c't-Anzeige,
formatting link
oder wie MaWin riet: Google bemühen, schauen, ob schon einer was Ähnliches macht und wie geschickt er sich dabei anstellt. (Aber Vorsicht: Gerade im Bereich Programmierung von Meßgeräten lassen sich viele Leute nicht gerne in die Karten gucken...)
Das kann ich so nicht unwidersprochen stehen lassen.
Man kann mit Delphi DLLs nutzen, die ihrerseits Standard-Interfaces bieten - und eigentlich reicht das schon. Ich hab meine DLLs meistens in C und Assembler geschrieben und dann über LABView oder Delphi die Oberfläche und das Management der anfallenden Daten gemacht.
Man kann auch mit Delphi selber DLLs oder Treiber schreiben, aber da man mit ein paar Borland-eigenen Verzierungen eh dasselbe schreibt wie in C, kann man es auch gleich in C machen :-)
Abgesehen davon bietet Delphi mit Object Pascal mal eine schön lesbare Programmiersprache, ich ärgere mich seit langem, dass ich nicht mehr damit zu tun hatte in meinem letzten Job.
Wie es der Markt halt wünscht...
Mit LABView kann man eben schnell testen, ob etwas so geht, wie man sich das vorstellt. Dabei baut man Oberfläche und Programm weitestgehend simultan und kann dem Laien, pardon Anwender, sehr schnell eine hübsche Bedienoberfläche präsentieren ;) Allerdings ist es preislich in Regionen angesiedelt, bei denen mittelständische Firmen nur verzweifelt die Hände heben können...
Mit Visual Basic wird ein sehr guter Oberflächeneditor mitgeliefert, und es gibt unzählige Komponenten. Die gibt es zwar für Delphi auch, aber VB ist von Microsoft, und die meisten Leute denken, alles, was von Microsoft kommt, ist toll (siehe aktuellen .NET Hype).
Allerdings ist VB genau richtig für die Leute, die gerade mal fertige Libs einbinden können und kapitulieren, wenn es für irgendwas keine fertige Komponente gibt. Ansonsten gibts natürlich auch ein Interface für C-DLLs, aber dann kann ich ja auch wieder Delphi nehmen für die Oberfläche...
Stichwort Echtzeitsysteme, aber das ist eine andere Baustelle.
Hmm...aber auch nur, weil sie ihre Schnittstellen schlecht, falsch oder gar nicht dokumentieren. Und diese speziellen Programme können dann noch nicht mal elementare Exportfunktionen. Wir hatten mal eine Oszilloskopsoftware, der man nur per Screenshot die in den PC geladenen Oszillogramme entreißen konnte - und die kein anderes Programm neben sich duldete.
Deshalb haben wir bisher immer die Hardware-Routinen in separaten Programmteilen gehabt, Maxime: möglichst klein, möglichst überschaubar, und die Oberfläche lieferte irgendein anderes System. Delphi-Alternativen unter Linux gibts aber auch: Kylix z.B. oder (wenns nur um die Oberfläche geht) kdevelop (nur die bekanntesten Beispiele).
nicht so leicht zu finden, da sie normaleweise sehr begehrt sind. Nur wenige Menschen können das wirklich gut, da sie sowohl die Software-, wie auch die Elektronikkenntnisse benötigen. Zusätzlich müssen sie auch die Funktion der Hardware verstehen und oft sogar noch viel mehr.
Bißchen Hintergrundwissen über die Anwendung schadet nicht :) Es ist schon hilfreich, wenn man z.B. bei der Programmierung medizinischer Diagnosegeräte und der Auwertung der von ihnen erzeugten Daten auch ein paar Medizinkenntnisse hat :)
Man beschränkt sich halt auf Linux/x86 und zudem hat Kylix meiner Meinung nach eine ungewisse Zukunft, da es sich nicht richtig etablieren konnte.
Nutze ich hingegen Qt mit C++ habe ich neben Linux/x86 bei Bedarf Linux mit allen Hardwareplattformen, kommerzielle Unixe und auch MacOS X. Neben Windows (aber das hat man bei Kylix/Delphi auch).
Vielleicht eine bloede Frage, aber ich suche fuer meine Firma einen faehigen Windows-Delphiprogrammierer der _hardwarenah_ programmieren kann. Also Steuerungstechnik, Messgeraete und soetwas die dann auch zuverlaessig funktionieren. Keinen Informatiker der wochenlang ueber den richtigen Algorythmus gruebelt und nur programmieren kann wenn er fertige Libaries einbinden kann. Weiss jemand wo man so jemanden am besten finden kann?
Also Delphi-Programmierer gibt es sicher ne ganze Menge (noch) aber damit hardwarenah programmieren?
Hardwarenahe Programmierung heist Kernel-Treiber schreiben und das macht man nur in C/C++. Messgeräte werden über COM-Port oder IEEE angesprochen und dafür gibts fertige Libs - entweder z.B. von MS oder vom Hersteller. Falls nicht hackt man sich die Sachen z.B. mit Jungo
formatting link
zusammen. Ich kenne nur sehr wenige Leute die sowas noch mit dem DDK machen.
Alles andere ist doch application. Man holt sich halt z.B.
formatting link
und für hübsche Reportausdrucke mit netten Diagrammen Excel per ActiveX dazu und das wars dann aber auch schon.
Die meisten Firmen wollen halt Geld verdienen und da fängt man nicht gerne immer wieder beim Urknall an, sondern sieht zu, dass Teile die man kaufen kann auch gekauft werden (soviel zu den Libs einbinden).
Steuerungstechnik kann man mit Windos nicht machen, es sei denn alles was dran hängt ist eigensicher, kann Latencen von min. 3s aushalten (puffern) und hat einen eingebauten Watchdog, der nach spätestens 5s zuschlägt :-). (Unter Linux gibt's da aber bessere Ansätze.) Man kann aber schon eine hübsche GUI schreiben, die Parameter annimmt und ausgibt und mit den Messgeräten/Einsteckkarten usw. kommuniziert.
Keine Ahnung. Ich wuerd es jedenfalls niemals freiwillig einsetzen weil man damit zu fest an einem Betriebssystem klebt. Aber was soll man machen wenn schon bergeweise darin programmiert wurde?
Industrie heisst ja nicht nur Windowsmuehlen sondern auch sehr viele Microcontroller oder andere Steuerrechner und da wird ueberwiegend in C programmiert.
Wir haben schon unterschiedliche Projekte mit VB realisiert
Delphi währ sicher auch kein Problem aber mit VB würde es schneller gehen weil wir schon in der Programmierung der unterschiedlichsten Schnittstellen Erfahrung haben. Z.B. Rs232, Par oder auch Steuerung über Ethernet, OPC. Direkte Programmierung von Hardware I/O Karten wird sicher auch gehen, z.B. von Meilhaus aber preistechnisch würde ich eher externe E/A verwenden. z.B. Profibus Slaves direkt als Master aus einem VB Programm ansprechen.
Bei Interresse einfach mal anrufen und beraten lassen, bin nur ein Mitarbeiter also leider schon vergeben ;)
Hier :-) Deine Meinung über Informatiker ist sicher neueren Datums, denn ich hab ein Hamburg 1970 in Informatik noch selbst Displays, Lightpens und Druckertreiber geschrieben. Danach habe ich als Informatiker 2 Betriebssysteme inklusive aller Treiber schreiben können, weil es ja noch keine PCs und kein Linux gab. Wenn Du mit einem freien Mitarbeiter leben kannst, melde dich.
Gruß, Kurt
--
Kurt Harders
PiN -Präsenz im Netz GITmbH
mailto:news@kurt-harders.de
http://www.pin-gmbh.com
a) es gäbe noch deutsche de.comp.lang.delphi... newsgroups. b) man sollte andeuten ob man Freiberufler/Festanstellung will. In ersterem Fall wäre noch de.etc.beruf.selbststaendig für vorsichtige Frage geeignet. c) soweit man Zweifel an der langfristigen Verfügbarkeit von Delphi hat sollte man auch andeuten wohin dann portiert werden soll. d) "einen faehigen ..." Sollte man sich keiner Illusionen hingeben: den suchen viele. Da die Industrie aber munter schrumpft werden die Leute mit relevanter aktueller praktischer Erfahrung eher weniger.
Wenn einer wirklich *fähig* ist, dann hat er schnell erkannt, dass er sich mit dieser Konstellation nicht rumschlagen will ... Weder angestellt noch freiberuflich und erst recht nicht selbstständig ;-/
Ciao Oliver
P.s.: Turbo-Pascal war für mich in dem Moment tot, als ich einmal die Berechnung eines trivialen konstanten Ausdrucks im ausgegebenen Objektcode gesehen hatte. Und dieses Aha-Erlebnis ist bestimmt >20 Jahre her, das muss irgendwann zu Schulzeiten gewesen sein ;-) Und irgendwie konnte ich meine Meinung zu Borland bei nachfolgenden Berührpunkten nie wirklich revidieren, obwohl ich mich bemüht habe.
On Sat, 5 Feb 2005 08:00:46 -0500, Olaf Kaluza wrote: [ Linux-based ]
Hör mir bitte mit Informatik und dem Deutschen_Ingenieur auf, wir kennen das Drama aus dem EDA Bereich nur zu gut.
Vorallem wenn die Herrschaften dann anfangen, vermeintliche "Pflichtenhefte" für *Produkte von Dritten* zu schreiben, statt das Handbuch zu lesen, etwa so: "Ich 'abe immer mit meinem $ALTSYSTEM *so* gearbeitet. Wie: Halt *so*, nicht *anders*. Der Lichtschalter war immer rechts oben und ein Schiebeschalter. Nun ist $ALTSYSTEM vom Markt. Kann ich garned verstehen, böse und gemein ist das ... Nun soll ich mit $NEUER_SOFTWARE arbeiten. Die kann das aber alles nicht. Die sagen zwar, ich soll das anders machen, dann könne die das schon, abe' ich abe' nun doch 10 Jahre das immer *so* gemacht. Der Lichtschalter ist nun links unten und ein Drehschalter. Den finde ich nicht und muss deshalb ohne Licht fahren. Damit kann ich nachts meinen Job nicht mehr ausüben und bekomme keine Nachtzuschläge mehr. Das ist einfach *un*zu*mut*bar*, jawoll. Geeeeeeewerkschaft! Ich kann damit *so* nicht arbeiten. Völlig unmöglich ist das. Ihr seid schuld daran! Ich schreibe jetzt nur noch Pflichtenhefte, bäh, das habt ihr davon ... "
Insofern muss ich hier mal ganz klar eine Lanze für die Informatiker brechen:
Rafael Deliano wrote in news: snipped-for-privacy@t-online.de:
Mhh, Delphi ist so lange verfügbar, wie Windows die WIN32-Api unterstützt. Auch heute kann man noch Programme für Windows 3.1 schreiben (oder für Dos). Die Software verfällt ja nicht. (zumindest _noch nicht_, wenn man danach geht, was Billy plant wird das aber sicher bald der Fall sein :-(. Muss man denn immer updaten?
Naja, die Software verfällt nicht, wohl aber die Hardware.
Und irgendwann wird es für neue Hardware keine Treiber mehr für Uraltsoftware geben. Weil alte Software, z.B. unter DOS, in vielen Fällen noch direkt die Hardware ansteuern mußte. Und weil neue Hardware auch im Zeitalter der API's ab- und zu mal eine Ergänzung in denselbigen benötigt.
Wir merken das wenn z.B. irgendwelche Firmen hier mit seit *10 Jahren* nicht geupdateter EDA Software ankommen und gerne einen Treiber für die DOS Uraltversion für eine neue Grafikkarte wollen. Offenbar wurde die Software bis dato fleißig genutzt, irgendwann ist aber auch die beste Hardware mal am Ende.
Es ist dann immer lustig zu sehen, welche Blüten der Oberknickergeiz treibt, wenn man denen dann dezent erklärt, dass es einen neuen "Treiber" für die Win32 API nur mit neuer Software gibt, die sogar (was wirklich nicht selbstverständlich ist!) die alten Binärdaten übernehmen kann, aber, ach wie schrecklich, ach wie grausam, nach
10 Jahren Nutzung ohne weitere Aufwendungen jetzt tatsächlich einen Griff in das Sparschatulle erfordert ;-/ Und das, wo seit 10 Jahren keiner mehr weiß, wo der Schlüssel zu der Kasse eigentlich geblieben ist ...
Man muss nicht *immer* updaten, man sollte es aber ab und zu mal in Erwägung ziehen, so wie man einem Auto auch manchmal einen Ölwechsel, neue Reifen oder gar eine Inspektion gönnt.
Die Erwartungshaltung mancher Software-Nutzer ist wirklich die, dass sie jahrzehntelang nach einer Investition keinerlei Erhaltungsaufwendung mehr tätigen brauchen und am Ende wundern sie sich und jammern rum, wenn sie dann auf die Nase fallen. Weil nicht überall gibt es Aufwärtskompatibilität über große Zeiträume, manchmal sind dann auch die Arbeitsdaten schlicht unlesbar verloren, besonders wenn man selber der letzte Mohikaner ist ...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.