Witam. Mam następujące pytanie. Posiadam sterownik PLC, z którym możliwa jest komunikacja za pomocą bibliotek DLL z aplikacjami napisanymi w C# (.NET). Jednak dodatkowo moja aplikacja (C#), która działa z PLC musi komunikować się (dynamicznie) z aplikacją napisaną w Delphi (brak bibliotek do komunikacji z PLC). Z założenia miała to być odrębna biblioteka DLL, która przesyłałaby dane z C# do Delphi i odwrotnie. Jednak nie jest to takie proste. Jaki byłby najlepszy sposób rozwiązania tego problemu? Jakieś pomysły? Pozdrawiam.
Delphi 
C# 
- Rejestracja:ponad 21 lat
- Ostatnio:32 minuty
0
Po dwukrotnym przeczytaniu posta (więcej nie będzie) nie do końca rozumiem co ma być aplikacją a co biblioteką.
Napisz jeszcze raz, powoli, co musi być a co chcesz, wyraźnie rozróżniając co jest odgórnym założeniem a co twoim pomysłem na rozwiązanie.
edytowany 1x, ostatnio: Azarien
- Rejestracja:ponad 13 lat
- Ostatnio:około 2 godziny
- Lokalizacja:Tuchów
- Postów:12166
0
@Azarien - jemu chodzi o warstwę pośrednią:
PLC -> C# -> Delphi
Delphi -> C# -> PLC
Chodzi o to jak wysyłać dane z programu napisanego w Delphi do tego napisanego w C# (który komunikuje się ze sterownikiem) i na odwrót - sterownik wysyła do programu napisanego w C#, a ten do aplikacji napisanej w Delphi; Program napisany w C# pośredniczy komunikacji; Przynajmniej ja to tak rozumiem.
0
Witam ponownie. Dokładnie tak jak przedstawił kolega.
PLC <--> C# <-->Delphi
Aplikacja na Delphi istnieje, jest to rodzaj cad-cama maszynowego.
Aplikacja na C# to moja aplikacja - touch panel do sterowania maszyną.
Jako, że Delphi nie może się skomunikować z PLC, a moja aplikacja może (gotowe biblioteki DLL producenta), muszę jakoś przekazywać niektóre parametry poprzez swoja aplikację do tego Cad-cama.
Pozdrawiam.
- Rejestracja:ponad 12 lat
- Ostatnio:7 miesięcy
- Postów:6610
0
no dobrze ale skoro app w delphi nie jest Twoja to ma ona jakąkolwiek możliwość odbierania (albo pytania o) tych "niektórych parametrów"? Bo jeśli autor nie przewidział to jak chcesz to zrealizować?
- Rejestracja:ponad 21 lat
- Ostatnio:32 minuty
0
Jako, że Delphi nie może się skomunikować z PLC
Błędne założenie.
a moja aplikacja może (gotowe biblioteki DLL producenta), muszę jakoś przekazywać niektóre parametry poprzez swoja aplikację do tego Cad-cama.
Non sequitur.
Kombinujesz. Dlaczego nie zapytasz "jak pod Delphi użyć biblioteki DLL która jest napisana dla C#"?
A skoro Nie ty jesteś autorem aplikacji pod Delphi, to dlaczego jej autor zwala problem na ciebie? ;-)
Należałoby napisać DLL-kę w C++/CLI która będzie pomostem między programem w Delphi a C#-ową DLL-ką producenta PLC.
Twój program w C# nie musi być w to zaangażowany.
0
Jako, że Delphi nie może się skomunikować z PLC
Błędne założenie.
Siemens - producent sterownika, w swojej obszernej dokumentacji zaznacza, że dołączone biblioteki DLL działają poprawnie tylko z aplikacjami C#/VB/.NET lub C++. Nie wnikałem więc jak zrobić, żeby skomunikować w Delphi, ponieważ kompletnie nie znam Delphi.
a moja aplikacja może (gotowe biblioteki DLL producenta), muszę jakoś przekazywać niektóre parametry poprzez swoja aplikację do tego Cad-cama.
Non sequitur.
Nie ważny jest sposób przekazywania. Ważna jest logika działania. Nie chciałem rozpisywać się do szczegółów, dlaczego Delphi, dlaczego C#. Moje pytanie jaki sposób byłby najprostszy i najszybszy. Bo za pomocą DLL też dałoby radę, ale nie byłoby to ani prosto ani szybko.
Kombinujesz. Dlaczego nie zapytasz "jak pod Delphi użyć biblioteki DLL która jest napisana dla C#"?
Zważając, iż jest to Siemens, ciężko jest użyć tych DLLek dedykowanych dla C#, nawet w C#. Żeby to działało, tak jak ma działać.
A skoro Nie ty jesteś autorem aplikacji pod Delphi, to dlaczego jej autor zwala problem na ciebie? ;-)
W sumie to on robi mi przysługę, że dopasuje coś do mojej aplikacji :) Muszę mu dać najprostsze rozwiązanie.
Należałoby napisać DLL-kę w C++/CLI która będzie pomostem między programem w Delphi a C#-ową DLL-ką producenta PLC.
Twój program w C# nie musi być w to zaangażowany.
Czy to rozwiązanie będzie najprostsze? Ta DLLka to nic skomplikowanego. Potrzebuje po prostu 10, może 15 zmiennych różnych typów(int, double, string), do których będę przelewał wartości (parametry maszyny). Np. ustawiam na CNC punkt zerowy, punkt ten będzie zapisany w 5 zmiennych PLC (5 osi maszyny), mój panel odczyta sobie te zmienne i pokaże wszystkie parametry, ale dodatkowo w tym programie camowskim tenże zerowy punkt musi się narysować (zaznaczyć), więc muszę jakoś te parametry "podać".
poprawienie skopanych komentarzy - fp
edytowany 1x, ostatnio: flowCRANE
- Rejestracja:ponad 21 lat
- Ostatnio:32 minuty
1
DLL-ka w C++/CLI jest rozwiązaniem zdecydowanie prostszym, niż komunikacja między dwoma osobnymi programami.
C++/CLI służy właśnie do łączenia kodu zarządzanego (.NET) z natywnym (w tym przypadku Delphi). Z jednej strony masz normalny dostęp do bibliotek .NET-owych (do samego .NET Frameworka jak i do DLL-ek napisanych w C#), a z drugiej strony możesz wyeksportować funkcje która będą normalnie widzialne pod Delphi.
Chyba, że ta DLL-ka jest zgodna z COM. Wtedy wystarczy ją zaimportować do Delphi.
dokładnie, zależy jak mocno skomplikowana była by ta dllka, ale pamietam ze w ten sposob działało szyfrowanie u nas, musiało być zgodne z DLPHI C# i PHP - Biblioteka .net używana przez Com w delphi rozwiązała temat :)
- Rejestracja:prawie 17 lat
- Ostatnio:około 3 lata
- Lokalizacja:Szczecin
- Postów:4191
0
Taaa, zprzęgnijmy armate do ubicia muchy i zaśmiećmy userowi rejestr. Jeżeli nie możesz wykorzystać Pipes, to najprościej chyba na logikę gdy chcesz przekazać jakieś dane między dwona aplikacjami, to ja bym to oparł o ukryte okna (ewentualne puste - niewidoczne dialogi) i wysyłał komunikaty. Nie słyszałeś nigdy o SendMessageA/W i choćby o WM_COPYDATA, ewentualne własne komunikaty typu WM_USER + XXX?. Ewentualnie HWND_BROADCAST. Jeśli nie to pogoogluj.
Mogę się mylić. Ale podejrzewam, że skoro robiąc rzutowanie na przykład WParam na cokolwiek - jakiś obiekt, można to wysłać i odebrać (jeśli nie z wykorzystaniem dedykowanemu do tego celu WM_COPYDATA) pod Delphi. To i można pewnie w większości normalnych języków programowania własnym komunikatem, zarowno ogarniając odebranie i wysłanie. Ewentualnie są mechanizmy DDE do tego celu stworzone. Ale najprościej kombinował bym z komunikatami. Imo banał.
edytowany 4x, ostatnio: olesio
- Rejestracja:około 11 lat
- Ostatnio:około miesiąc
- Lokalizacja:lubuskie
- Postów:201
0
Witam. Tylko nie wiem czy takie rozwiązanie dałoby radę z wydajnością, ponieważ maszyna idzie z dokładnością do 3 miejsc po przecinku (mm), więc jeśli wrzeciono przesunie się o jeden metr, to mamy do "wyeksportowania" 1 milion współrzędnych w sekundę. I to na jednej osi. Jeśli 3 osie na raz, to parametrów będzie 3 miliony.
- Rejestracja:ponad 11 lat
- Ostatnio:ponad 9 lat
- Postów:68
0
Miałem styczność z łączeniem dwóch zewnętrznych aplikacji. Na początku łączone były poprzez właśnie wysyłanie komunikatów windowsa, potem z pewnych względów zostało to przerobione an sockety, i powiem, że przynajmniej w tej implementacji komunikacja poprzez kolejkę komunikatów jest o wile szybsza niż przez sockety.
- Rejestracja:ponad 18 lat
- Ostatnio:około 8 lat
- Lokalizacja:Poznań
- Postów:295
0
jesli masz mozliwosc zmiany kodu dll z C# polecam sprawdzenie czegos takiego
https://sites.google.com/site/robertgiesecke/
Mozesz w c# wygenerowac dll natywnie ladowane w delphi przez LoadLibrary i pozniej GetProcAddress.
Komunikacja na poziomie interface i wymiana danych poprzez OleVariant(Delphi) = object (C#)
edytowany 1x, ostatnio: crowa
Delphi <=> PLC.