Win-Dll in Unix-So umwandeln...

[Maik81ftl]

Moin.

Habe auf einem WIn7 Rechner, welcher NUR Dienstlich läuft eine RS485_Com.dll von Nanotec (ist teil von NanoPro V1.60). Wie schon vermuten läst, geht es hierbei um eine Comsteuerung zw. PC und Motorsteuerung (z.B. SCMI-12). Die Demo's von Nanotec helfen auch nicht wirklich, da kein ich über "KEIN" Visual Basic Verfüge und zugegeben kein plan habe, wo ich des beziehen soll.

ist jemand von euch bekannt, ob man eine WIndows-dll mit Unbekannten parameter Ohne bzw. mit mittleren Aufwand in seinen Quellcode umwandeln kann?

Habe mich auch schon hier >>>http://www.winehq.org/wwn/329#Windows/Linux<<< belesen, aber wirklich schlau bin ich nicht geworden. , und Nanotec gibt den Quellcode leider nicht raus.

Glaube zwar nicht wirklich, das jemand was hab, aber wenn doch irgendwo eine So für Unix rumgeistern sollte, würde ich mich durch eine Versehendliche Datenübertragung via DropBox freuen

[Hitman]

Du brauchst kein VB um den Source zu lesen. All zu schwierig is VB auch nicht zu verstehen, zumal du ja nur nach den Prozeduren (= "Sub" in VB) bzw. Funktionen schauen musst, um dir die Signatur herzuleiten.
Was mich etwas wundert: ist die DLL denn spezifisch für besagten Motor? Vom Namen her klingt mir das eher nach einer allgemeinen COM Port Bibliothek. Synaser könnte dir also von Pascal aus weiterhelfen. Natürlich musst du dann immernoch wissen, was du über den Port zu jagen hast um am Motor etwas zu erreichen. Aber dafür sollte Dokumentation der Motorsteuerung vorliegen.

[Maik81ftl]

@Hitman
die Handbücher habe ich alle schon durchgelesen. ich weiß nur, welche Befehler für Seriel, und Java verwendet werden. aber wie diese nun innerhalb der DLL definiert sind, verraten diese nicht. deshalb wollte ich ggf. Bsp-Projekte durchlesen und sehen, wie die dies aufrufen. somit bekomm ich ja auch die Parameter der Functionen raus.

[pluto]

Das musst du dann in Erfahrung bringen. Beispiel:
Ich habe eine IR-Fernbedienung für USB. Für Windows lag eine Software dabei. Was mache ich? Zuerst versuche ich es unter Delphi zum Laufen zu bekommen, kein Thema.
Unter Lazarus hat es etwas länger gedauert, aber auch jetzt läuft es unter Lazarus. Ich möchte zwar nur Lesend drauf zugreifen, aber fürs schreiben dürften Ähnliche Regeln Gelten oder?

Du musst also den Genauen Aufbau der Daten irgendwie in Erfahrung bringen. Durch Analyse der Datenwege. Das klingt einfacher als es wirklich ist. Vielleicht findest du im Internet Beispiele, die du verwenden könntest.

[Maik81ftl]

Würde ich mit sicherheit was finden, Aber wenn denne 100 Pro nur für Win.

wenn ich aber nun eine artverwande Unix-so oder der gleichen hätte, würde ich es gleich via Lazarus versuchen.

[af0815]

Wenn die Schrittmotorsteuerung mitl RS485 verbunden ist, so kann auch lt. den Unterlagen von NanoTec auch mitttels ASCII Kommandos die Steuerung angesteuert werden. Siehe auch dem Programmierhandbuch V2.4,pdf so ab Seite 10 sind die Kommandos beschrieben.

Probieren würde ich mal die Kommandos ab Seite 29/30 Firmware Version bzw. Status auslesen. Die sollten auch mit einem Terminal gehen. Wenn das funzt so kan man mit Synaser sicherlich weiterarbeiten.

[pluto]

Würde ich mit sicherheit was finden, Aber wenn denne 100 Pro nur für Win.

Das würde ich so nicht sagen. Du könntest Glück haben, dass der Code den du findest, auch unter Lazarus/Linux läuft. Wobei: Es geht auch eigentlich nur darum, wie die Datenaufgebaut sind. Wenn du das weißt, solltest du in der Lage sein, einen eigenen "Treiber" zu schreiben.

[Maik81ftl]

Wenn die Schrittmotorsteuerung mitl RS485 verbunden ist, so kann auch lt. den Unterlagen von NanoTec auch mitttels ASCII Kommandos die Steuerung angesteuert werden. Siehe auch dem Programmierhandbuch V2.4,pdf so ab Seite 10 sind die Kommandos beschrieben.

Probieren würde ich mal die Kommandos ab Seite 29/30 Firmware Version bzw. Status auslesen. Die sollten auch mit einem Terminal gehen. Wenn das funzt so kan man mit Synaser sicherlich weiterarbeiten.

Genau, das was ich sowieso vorhatte

Würde ich mit sicherheit was finden, Aber wenn denne 100 Pro nur für Win.

Das würde ich so nicht sagen. Du könntest Glück haben, dass der Code den du findest, auch unter Lazarus/Linux läuft. Wobei: Es geht auch eigentlich nur darum, wie die Datenaufgebaut sind. Wenn du das weißt, solltest du in der Lage sein, einen eigenen "Treiber" zu schreiben.

werd mich denne am WE mal nebenbei mir hinsetzten, bin ja sowieso. Via Nanopro und CoDeSys auf der Steuerung. Lohnt sich gleich 3fach

werd mal sehen, was ich hinbekomme.

[schnullerbacke]

Hi,

versuch mal das hier. Wenn dann Zugriffe auf die Windows-API vorkommen, kannst du das eh knicken.

http://www.chip.de/downloads/IDA-Pro-Free-4.9_29744270.html

Wenn keine API dann einfach neu unter linux Assemblieren.
Manchmal klappt derlei...

[pluto]

versuch mal das hier. Wenn dann Zugriffe auf die Windows-API vorkommen, kannst du das eh knicken.

Nicht immer. Es gibt Windows API Funktionen, die wurden nach gebildet unter Lazarus/Linux. z.b. bitblt ist so eine.

[Maik81ftl]

Hi,

versuch mal das hier. Wenn dann Zugriffe auf die Windows-API vorkommen, kannst du das eh knicken.

http://www.chip.de/downloads/IDA-Pro-Free-4.9_29744270.html

Wenn keine API dann einfach neu unter linux Assemblieren.
Manchmal klappt derlei...

Hört sich erst mal nicht verkehrt an, aber ist leider für das Falsche BS.

[schnullerbacke]

Hört sich erst mal nicht verkehrt an, aber ist leider für das Falsche BS.

Hast mich aber schon richtig verstanden, disassemblieren unter Windoofs. Dabei kommt halbwegs brauchbarer Assemblercode zustande, den dann unter LINUX neu assemblieren. Da gibt es auch einen Standard-Assembler im Netz der für LINUX geht. Kommt mehr auf den Prozessor an, für den das laufen soll. Hier wäre derlei:

http://www.heise.de/software/download/hdwl45214_d376724d70dbcedad1efb0eb98880b10_1328428518

Die BS-Aufrufe dürften sich bei der Kiste vermutlich in engen Grenzen halten, soll ja auf die USB zugreifen.

[af0815]

Ich glaube in diesem Fall ist man Zielführender weenn man die Dokumentierten Zugriffe in SW gießt, denn nur disassemblieren und dann auf der neuen Plattform assemblieren, ist sicherlich zuwenig.

[schnullerbacke]

Ich glaube in diesem Fall ist man Zielführender weenn man die Dokumentierten Zugriffe in SW gießt, denn nur disassemblieren und dann auf der neuen Plattform assemblieren, ist sicherlich zuwenig.

Na ja af,

das Problem ist gerade das er die lib braucht um auf die vorhandenen interfaces zu kommen. Ansonsten könnte man auch Java-Script nehmen, wie ich gesehen habe. Aber ideal ist sowas meist nicht, weil sehr langsam.

Wenn der faule Trick(s.o) klappt, hat man praktisch die lib zur Verfügung und kenn das in Lazarus verwenden indem man sich die Schnittstellen in einer Unit deklariert und kann dann eben unter Linüx genauso so schön arbeiten wie unter Windoofs.

Ein bisschen "tricky" ist das allerdings.

[Maik81ftl]

Hört sich erst mal nicht verkehrt an, aber ist leider für das Falsche BS.

Hast mich aber schon richtig verstanden, disassemblieren unter Windoofs. Dabei kommt halbwegs brauchbarer Assemblercode zustande, den dann unter LINUX neu assemblieren. Da gibt es auch einen Standard-Assembler im Netz der für LINUX geht. Kommt mehr auf den Prozessor an, für den das laufen soll. Hier wäre derlei:

http://www.heise.de/software/download/hdwl45214_d376724d70dbcedad1efb0eb98880b10_1328428518

Die BS-Aufrufe dürften sich bei der Kiste vermutlich in engen Grenzen halten, soll ja auf die USB zugreifen.

Jopp Schnullerbacke habe ich.

das Teil von Heise hab ich mir auch mal angeschaut, soweit es bei Ubuntu durch die verwendung von DEB geht (sind nur rpm-Downloads)

Auch wenn dein erster vorschlag eigendlich unter WIndows laufen soll, hab ich nicht gesagt, das ich es nicht unter Wine laufen lasse.

werd versuchen aus der Dll eine fpc-Unit zu bekommen. bzw genug daten, um eine zu schreiben.