Fórum Root.cz

Hlavní témata => Software => Téma založeno: Kryštof 26. 03. 2018, 18:07:36

Název: .Net knihovna pod Linuxem
Přispěvatel: Kryštof 26. 03. 2018, 18:07:36
Dobrý den,

mám prosbu a dotaz. Pro stahování dat z PLC používáme MX Components a z nich knihovnu .dll pro přímé spojení s konkrétním PLC. Dosud jsme data stahovali pomocí vyřazeného PC s WinXP. Rád bych jej vyhodil a přesunul aplikaci pro stahování na Linuxový server. Jedná se o konzolovou aplikaci,která se v pravidelných intervalech připojuje k PLC a stažená data ukládá na SQL server.

Myslel jsem, že bych napsal v Mono aplikaci, která by tuto knihovnu využila. Začal jsem samotnou kostrou

Kód: [Vybrat]
using System;
using ACTETHERLib;

namespace Melsec
{
class Program
{       
static void Main(string[] args)
{
ActFXENETTCP plc = new ActFXENETTCP();
Console.WriteLine("Start ...");

}
}
}

Po přeložení
Kód: [Vybrat]
mcs melsec.cs /reference:Interop.ACTETHERLib.dll

mi aplikace chodila chybu
Kód: [Vybrat]
Unhandled Exception:
System.DllNotFoundException: ole32.dll
  at (wrapper managed-to-native) System.__ComObject.CoCreateInstance(System.Guid,intptr,uint,System.Guid,intptr&)
  at System.__ComObject.CreateIUnknown (System.Type t) [0x00051] in <62351af909f64c3d9f8698380a6f7518>:0
  at Mono.Interop.ComInteropProxy.CreateProxy (System.Type t) [0x00000] in <62351af909f64c3d9f8698380a6f7518>:0
  at System.Runtime.Remoting.RemotingServices.CreateClientProxyForComInterop (System.Type type) [0x00000] in <62351af909f64c3d9f8698380a6f7518>:0
  at System.Runtime.Remoting.Activation.ActivationServices.CreateProxyForType (System.Type type) [0x0003b] in <62351af909f64c3d9f8698380a6f7518>:0
  at (wrapper managed-to-native) System.Object.__icall_wrapper_ves_icall_object_new_specific(intptr)
  at Melsec.Program.Main (System.String[] args) [0x00000] in <b06b9891e8c04e19803d3da7277465a3>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.DllNotFoundException: ole32.dll
  at (wrapper managed-to-native) System.__ComObject.CoCreateInstance(System.Guid,intptr,uint,System.Guid,intptr&)
  at System.__ComObject.CreateIUnknown (System.Type t) [0x00051] in <62351af909f64c3d9f8698380a6f7518>:0
  at Mono.Interop.ComInteropProxy.CreateProxy (System.Type t) [0x00000] in <62351af909f64c3d9f8698380a6f7518>:0
  at System.Runtime.Remoting.RemotingServices.CreateClientProxyForComInterop (System.Type type) [0x00000] in <62351af909f64c3d9f8698380a6f7518>:0
  at System.Runtime.Remoting.Activation.ActivationServices.CreateProxyForType (System.Type type) [0x0003b] in <62351af909f64c3d9f8698380a6f7518>:0
  at (wrapper managed-to-native) System.Object.__icall_wrapper_ves_icall_object_new_specific(intptr)
  at Melsec.Program.Main (System.String[] args) [0x00000] in <b06b9891e8c04e19803d3da7277465a3>:0
Můžete mě prosím pěkně nakopnout, zda je vůbec moje úvaha správná? Můžu pod Mono nějak jednoduše používat knihovny z Windows? Případně zda byste jinou cestou.
Teprve se učím a tak prosím o shovívavost a jen konstruktivní odpovědi. Jsem jen údržbář :) Něco jsem zkoušel googlit, ale moc moudrý z toho nejsem.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: jm 26. 03. 2018, 18:21:44
Jestli to chápu správně, tak si mono (.NET) stěžuje, že nemůže najít COM knihovnu, která je slinkovaná s ActFXENETTCP wrapperem. Tzn že řešíš problém, jak zaregistrovat a rozjet COM knihovnu "ACTETHERLib.dll" pod Linuxem.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Kryštof 26. 03. 2018, 18:29:51
Aplikace mi jde přeložit, hodí jen varování, že objekt plc je deklarován, ale není použit. Když ji zkusím spustit, tak to hodí tu chybu.
Nevím bohužel o jiném způsobu, jak se k PLC připojit jinak než přes tu knihovnu.
Chápu tu tak, že si ta knihovna volá další knihovnu, ale tu už se mi nedaří "přilinkovat".

Zkoušel jsem okolo toho hledat na netu a našel jsem tohle
http://linux.lsdev.sil.org/wiki/index.php/COM_in_Linux
ale na pochopení toho už moje znalosti nestačí.  :-[
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: jm 26. 03. 2018, 18:40:33
Je to tak jak píšeš. Ten Interop.ACTETHERLib.dll je vygenerované .NET rozhraní pro COM knihovnu, která je uložená někde na HDD počítače. COM knihovna se na Windows zaregistruje skrze
cmd -> regsvr32 <cesta ke COM.dll>
a poté přes COM rozhraní můžeš přistoupit z libovolné aplikace, aniž by to danou knihovnu musela s sebou tahat, protože ta je zaregistrována na COM serveru.

Nicméně jak přesně nastavit Linux, aby fungoval s COM knihovnami, to opravdu netuším a nejspíše ti nebudu schopný pomoci. Dle toho co jsi poslal v tom linku jde o rozjetí COM serveru na Linuxu podobným způsobem jako běží Windows.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Kryštof 26. 03. 2018, 18:45:59
Díky moc za nakopnutí, zkusím pátrat a hledat nějaký příklad.

Název: Re:.Net knihovna pod Linuxem
Přispěvatel: . 26. 03. 2018, 19:02:26
DLL pro Windows je pro Windows. Možná uspěješ s Wine.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Daniel Kozak 26. 03. 2018, 19:46:47
Díky moc za nakopnutí, zkusím pátrat a hledat nějaký příklad.

Tak pokud nemaji verzi pro Linux nebo dostupne zdrojaky, tak bych se na to vykaslal a sel cestou wine. Usetris si stim dost prace
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Jester 26. 03. 2018, 20:28:03
Aplikace mi jde přeložit, hodí jen varování, že objekt plc je deklarován, ale není použit. Když ji zkusím spustit, tak to hodí tu chybu.
Nevím bohužel o jiném způsobu, jak se k PLC připojit jinak než přes tu knihovnu.
Chápu tu tak, že si ta knihovna volá další knihovnu, ale tu už se mi nedaří "přilinkovat".

Zkoušel jsem okolo toho hledat na netu a našel jsem tohle
http://linux.lsdev.sil.org/wiki/index.php/COM_in_Linux
ale na pochopení toho už moje znalosti nestačí.  :-[
Jakmile kód v .NET volá nativní kód, ať už přes COM nebo IJW nebo jinak, tak má Mono problém, protože příslušné "vázací" knihovny v Mono nejsou a ty z Windows většinou na Linuxu nefungují, kromě pár výjimek. Nejjednodušší asi je mít ten počítač s Windows, pokud příslušný software není k dispozici i pro Unix/Linux.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Kryštof 26. 03. 2018, 20:51:09
Děkuju za odpovědi všem a za snahu. Asi to tak dopadne a nechám nějaký vyřazený stroj s Win7 bežet v serverovně. Vůbec se mi to nelíbí, ale nic lepšího mě nenapadá.
Wine mi teď doma v terminálu padá, zkusím zítra v práci.
Původně mi ten SQL server běžel na Windows Serveru 2008, ale kvůli nutnosti dokupovat CALy jsem se rozhodl celou síť migrovat na Linux. Jenže mi z toho teď vznikne takový kočkopes.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: hooodini 26. 03. 2018, 21:03:01
IMHO bez sance rozjet tohle na Linuxu.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Bugs 27. 03. 2018, 06:15:26
V současné době lze pro Linux udělat CLI aplikaci přes .NET Core 2. Jenže ta PLC knihovna by musela být přeložená/přeložitelná v API .NET Core nebo .NET Standard.

Další možností by bylo dekompilovat starou knihovnu pomocí https://www.jetbrains.com/decompiler/ a naportovat si ji ručně na ten .NET Core nebo .NET Standard.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: JmJ 27. 03. 2018, 07:28:11
K plc strojum se vetsinou da pripojit pres modbus (snad si ten nazev nepletu).  Knihovna na modbus napsana v .net se da urcite sehnat, jednu pouzivam.  Pokud by tve plc umelo ta data, ktera od nej potrebujes, sdilet modbusem, pak bys mohl mit cistou .net aplikaci, ktera by v linuxu jela.

Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Kryštof 27. 03. 2018, 08:07:55
K plc strojum se vetsinou da pripojit pres modbus (snad si ten nazev nepletu).  Knihovna na modbus napsana v .net se da urcite sehnat, jednu pouzivam.  Pokud by tve plc umelo ta data, ktera od nej potrebujes, sdilet modbusem, pak bys mohl mit cistou .net aplikaci, ktera by v linuxu jela.
Jedná se o PLC Mitsubishi řad Fx, A a Q. Pro připojení k těm Q modulům používáme karty QJ71E71-100. Výrobce dělá utilitu MX Components a z ní jsem použil knihovnu ActEther.dll Ve Win to šlapalo uspokojivě, tak jsem neměl moc důvodů a i času to nějak řešit ( není to moje hlavní náplň práce, spíš si s tím hraju ve volném čase).

V každém případě moc děkuji za nápady
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Kryštof 27. 03. 2018, 08:12:11
V současné době lze pro Linux udělat CLI aplikaci přes .NET Core 2. Jenže ta PLC knihovna by musela být přeložená/přeložitelná v API .NET Core nebo .NET Standard.

Další možností by bylo dekompilovat starou knihovnu pomocí https://www.jetbrains.com/decompiler/ a naportovat si ji ručně na ten .NET Core nebo .NET Standard.

To netuším, jsem C# embryo :). Původní knihovna je tady https://uloz.to/!hQf7J2IbVLn3/actether-dll a po přidání do VisualStudia z ní VS 2017 udělá toto https://uloz.to/!0sNkSrNl9KWr/interop-actetherlib-dll

Děkuju za rady a případné nakopnutí.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: VojtaF 27. 03. 2018, 09:19:40
Je nekolik moznosti jak pouzit puvodni dll bez rekompilace:

https://github.com/taviso/loadlibrary
http://ndiswrapper.sourceforge.net/wiki/index.php/Main_Page
https://wiki.winehq.org/Winelib_User%27s_Guide

nejmene starosti ale bude asi to Wine
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: ehmmm 27. 03. 2018, 09:39:19
Jedná se o PLC Mitsubishi řad Fx, A a Q. Pro připojení k těm Q modulům používáme karty QJ71E71-100. Výrobce dělá utilitu MX Components a z ní jsem použil knihovnu ActEther.dll Ve Win to šlapalo uspokojivě, tak jsem neměl moc důvodů a i času to nějak řešit ( není to moje hlavní náplň práce, spíš si s tím hraju ve volném čase).

V každém případě moc děkuji za nápady

Mitsubishi Q ctu a zapisuju po ethernetu MC protokolem bez problemu, aspon tedy ty zakladni typy registru, ale neni problem dle dokumentace cokoliv pridat. Onehdy jsem zkoumal i komunikaci s FX a prislo mi to taky trivialni. Myslim, ze jsem zkousel i MELSEC protokol, ale potom to tusim s necim kolidovalo. Pokud ti jde pouze o cteni, tak si myslim, ze za den to musis rozchodit bez jakychkoliv knihoven (no dobre, potrebujes sockety). Schvalne si k tem PLC vygoogli nejake PDF s popisem protokolu a uvidis. Prislo mi to jednodussi nez Omron FINS a mozna i nez Fatek.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Kryštof 27. 03. 2018, 11:09:52
Jedná se o PLC Mitsubishi řad Fx, A a Q. Pro připojení k těm Q modulům používáme karty QJ71E71-100. Výrobce dělá utilitu MX Components a z ní jsem použil knihovnu ActEther.dll Ve Win to šlapalo uspokojivě, tak jsem neměl moc důvodů a i času to nějak řešit ( není to moje hlavní náplň práce, spíš si s tím hraju ve volném čase).

V každém případě moc děkuji za nápady

Mitsubishi Q ctu a zapisuju po ethernetu MC protokolem bez problemu, aspon tedy ty zakladni typy registru, ale neni problem dle dokumentace cokoliv pridat. Onehdy jsem zkoumal i komunikaci s FX a prislo mi to taky trivialni. Myslim, ze jsem zkousel i MELSEC protokol, ale potom to tusim s necim kolidovalo. Pokud ti jde pouze o cteni, tak si myslim, ze za den to musis rozchodit bez jakychkoliv knihoven (no dobre, potrebujes sockety). Schvalne si k tem PLC vygoogli nejake PDF s popisem protokolu a uvidis. Prislo mi to jednodussi nez Omron FINS a mozna i nez Fatek.
Děkuju, už to čtu - http://dl.mitsubishielectric.com/dl/fa/document/manual/plc/sh080008/sh080008x.pdf
V téhle aplikaci mi jde jen o čtení hodnot z výroby a jejich další zpracování. V budoucnu možná budeme chtít i zapisovat, ale to počká :) Díky moc
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: ehmmm 27. 03. 2018, 15:02:39
Děkuju, už to čtu - http://dl.mitsubishielectric.com/dl/fa/document/manual/plc/sh080008/sh080008x.pdf
V téhle aplikaci mi jde jen o čtení hodnot z výroby a jejich další zpracování. V budoucnu možná budeme chtít i zapisovat, ale to počká :) Díky moc

Jo, takhle nejak to vypadalo. Je jenom potreba si vyzkouset, nebo nastudovat, co ktere PLC umi. Ne kazde PLC umi vsechny typy ramcu (to je takove to 1C/2C/3E) a vsecny prikazy (0401 vs. 0403 vs. 0406). Pomohlo by odposlechnout si tu knihovnu, co ti funguje na WinXP, dohledat si v dokumentaci, o co jde a pak to ohnout pro svoji potrebu.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Kryštof 27. 03. 2018, 18:44:32
Děkuju, už to čtu - http://dl.mitsubishielectric.com/dl/fa/document/manual/plc/sh080008/sh080008x.pdf
V téhle aplikaci mi jde jen o čtení hodnot z výroby a jejich další zpracování. V budoucnu možná budeme chtít i zapisovat, ale to počká :) Díky moc

Jo, takhle nejak to vypadalo. Je jenom potreba si vyzkouset, nebo nastudovat, co ktere PLC umi. Ne kazde PLC umi vsechny typy ramcu (to je takove to 1C/2C/3E) a vsecny prikazy (0401 vs. 0403 vs. 0406). Pomohlo by odposlechnout si tu knihovnu, co ti funguje na WinXP, dohledat si v dokumentaci, o co jde a pak to ohnout pro svoji potrebu.
Díky moc. Prokousávám se tím. Zjistil jsem, že kromě toho MC protokolu, který umí jen karty typu Q (podle dokumentace) ještě existuje komunikace fixed buffer a random access. Ta s tím pevně daným bufferem by měla být kompatibilní pro nejvíce typů PLC.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: ehmmm 27. 03. 2018, 21:31:42
Díky moc. Prokousávám se tím. Zjistil jsem, že kromě toho MC protokolu, který umí jen karty typu Q (podle dokumentace) ještě existuje komunikace fixed buffer a random access. Ta s tím pevně daným bufferem by měla být kompatibilní pro nejvíce typů PLC.

Popravde, s tim fixed buffer a random access nevim presne, o cem mluvis. Ale verim, ze si poradis, ta dokumentace je fakt nazorna. A jestli si navic muzes odposlechnout neco, co funguje, tak jses vysmatej.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Kryštof 27. 03. 2018, 22:44:00
Díky moc. Prokousávám se tím. Zjistil jsem, že kromě toho MC protokolu, který umí jen karty typu Q (podle dokumentace) ještě existuje komunikace fixed buffer a random access. Ta s tím pevně daným bufferem by měla být kompatibilní pro nejvíce typů PLC.

Popravde, s tim fixed buffer a random access nevim presne, o cem mluvis. Ale verim, ze si poradis, ta dokumentace je fakt nazorna. A jestli si navic muzes odposlechnout neco, co funguje, tak jses vysmatej.

Vyčetl jsem to odsud
http://dl.mitsubishielectric.com/dl/fa/document/manual/school_text/sh080618eng/sh080618enga.pdf
je to obsáhlejší, ale z kapitoly 2.2.4. to tak chápu. Chtěl jsem sem dát výstřižek, ale nejde mi to.

Díky za podporu a za důvěru :) :)

Název: Re:.Net knihovna pod Linuxem
Přispěvatel: ehmmm 28. 03. 2018, 10:05:29
Popravde, s tim fixed buffer a random access nevim presne, o cem mluvis. Ale verim, ze si poradis, ta dokumentace je fakt nazorna. A jestli si navic muzes odposlechnout neco, co funguje, tak jses vysmatej.

Vyčetl jsem to odsud
http://dl.mitsubishielectric.com/dl/fa/document/manual/school_text/sh080618eng/sh080618enga.pdf
je to obsáhlejší, ale z kapitoly 2.2.4. to tak chápu. Chtěl jsem sem dát výstřižek, ale nejde mi to.

Díky za podporu a za důvěru :) :)

Tak tohle vidim poprve. Neco jako fixed buffer jsem videl jednou u FX. Nekolik registru se mapovalo 1:1 mezi dvema PLC. Random access vypada taky jako nejaky mechanismus, jak prenaset data mezi dvema PLC. Jestli muzu doporucit, tak se drz MC protokolu, alespon u rady Q (radu A neznam, ale co jsem kdy cetl, tak to bude podobne). Jenom me trochu mate dolni obrazek na strane 2-14. Co jsem kdy videl, tak tam PLCckari nastavovali prave UDP, MC protokol a cislo UDP portu, na kterem PLC nasloucha. Nic vic nebylo potreba (plus jeste o dialog driv prepinac binary/ascii). Ale asi to neni uplne to same nastavovatko, protoze v tom, co jsem videl, byl jeste v rohu prepinac zobrazeni cisla portu HEX/DEC.
Název: Re:.Net knihovna pod Linuxem
Přispěvatel: Kryštof 28. 03. 2018, 14:30:32

Tak tohle vidim poprve. Neco jako fixed buffer jsem videl jednou u FX. Nekolik registru se mapovalo 1:1 mezi dvema PLC. Random access vypada taky jako nejaky mechanismus, jak prenaset data mezi dvema PLC. Jestli muzu doporucit, tak se drz MC protokolu, alespon u rady Q (radu A neznam, ale co jsem kdy cetl, tak to bude podobne). Jenom me trochu mate dolni obrazek na strane 2-14. Co jsem kdy videl, tak tam PLCckari nastavovali prave UDP, MC protokol a cislo UDP portu, na kterem PLC nasloucha. Nic vic nebylo potreba (plus jeste o dialog driv prepinac binary/ascii). Ale asi to neni uplne to same nastavovatko, protoze v tom, co jsem videl, byl jeste v rohu prepinac zobrazeni cisla portu HEX/DEC.

Pochopil jsem to tak, že MC protokol se používá na komunikaci PC <-> PLC. Ostatní dva hlavně na komunikaci mezi samotnými PLC, když si potřebují posílat nějaké D či M.