Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » dll import in programming
dll import in programming [message #1807706] |
Thu, 06 June 2019 14:16 |
joy woo Messages: 198 Registered: May 2019 |
Senior Member |
|
|
As an industry distribution system, except PLCs, motion control and vision system also play an important role, now we can use ST to implement functionality to PLCs, but for motion control, most vendors provide with dll(c++,C# etc),
i think about lua +alien, the purpose is to call dll dynamic, and call api of dll dynamic. I tested alien+ffi, require("alien") is successful, but call function seems to be failure, and there is no error message. So i want to ask, if alien can be a available solution or not, or other better solution ?
|
|
| | | | |
Re: dll import in programming [message #1807724 is a reply to message #1807710] |
Thu, 06 June 2019 18:19 |
|
joy woo wrote on Thu, 06 June 2019 14:22Currently we have a researching team, are developing the web 4diac IDE, and also plan to make the whole project open source, we are now in phase II,
Wow this sounds very interesting! Is it also based on Eclipse technologies like Eclipse Theia and Eclipse Sprotty?
joy woo wrote on Thu, 06 June 2019 14:22we realized if there is not a good compiler(for ST, also can reference dll), it will
be hard for the developer to use it, and most developers are not willing to accept it. So we encounter this problem, and hope to get help from you. we will be appreciated if you can provide us with help.
To be honest, in the 12 years that 4diac is existing we here the importance if this feature for the first time. As we are currently supporting more then 7 different operating system providing such a feature generically is very hard for us. For me the question would be what is your specific use case? Can you provide as a concrete example what you would like to do.
We already wrapped some years ago the open CV into function blocks to be used in IEC 61499. But here we went the road of developing dedicated SI FBs. The problem I see is that there is no clear definition how functions in a dll should be called. Especially how variable should be passed and converted. In general the IEC 61131-3 type system is not compatible with c, for example. Also directly calling dlls can even be dangerous as it can violate the execution model of IEC 61499.
Depending on your use case you could experiment with the feature that you can add #include files in the header info of your type. Than you could just use the functions defined in this header in your ST code. But be warned as said above that the result may be not what you expect.
If you have clearer definitions what is needed I would be happy to discuss implementation options.
joy woo wrote on Thu, 06 June 2019 14:22Another question, so far, we can just program with ST, or hard coded with c++ , IL, LD, FBD in IEC 61131 will be also support or not?
As Martin said we focused on ST as we think this is the most needed language in IEC 61499. Currently we have no plans nor resources/financing to implement more languages.
To formulate it even stronger than Martin IMHO I don't even believe that the others should be implemented in an IEC 61499 environment. If you want to to have FBD I would go for IEC 61499 FB networks which are much more powerful. Also I would strongly recommend to further embrace ECCs. If ECCs are used to your advantage most of your algorithms are really really small. And ECCs are much easier to model then the according ST or LD code.
|
|
|
Re: dll import in programming [message #1807752 is a reply to message #1807724] |
Fri, 07 June 2019 11:33 |
joy woo Messages: 198 Registered: May 2019 |
Senior Member |
|
|
Alois Zoitl wrote on Thu, 06 June 2019 18:19joy woo wrote on Thu, 06 June 2019 14:22Currently we have a researching team, are developing the web 4diac IDE, and also plan to make the whole project open source, we are now in phase II,
Wow this sounds very interesting! Is it also based on Eclipse technologies like Eclipse Theia and Eclipse Sprotty?
Thanks to 4diac & Forte, it is a great product, we learn a lot from it, we are using Nodejs+vue to implement that, comparing
to 4diac IDE, ours is much more lighter and simplified.
we plan to make it totally open source and delivery it this August, but now we have several problems, if we can get help from you, that will be great!
joy woo wrote on Thu, 06 June 2019 14:22we realized if there is not a good compiler(for ST, also can reference dll), it will
be hard for the developer to use it, and most developers are not willing to accept it. So we encounter this problem, and hope to get help from you. we will be appreciated if you can provide us with help.
To be honest, in the 12 years that 4diac is existing we here the importance if this feature for the first time. As we are currently supporting more then 7 different operating system providing such a feature generically is very hard for us. For me the question would be what is your specific use case? Can you provide as a concrete example what you would like to do.
We also researched codesys, it has a strong IDE to code with ST and for debugging, actually, there are series of libraries managed on the cloud, developers can reference them and call the api, and for business users, who can even add custom dll(C++) in IDE .
Our requirement is that, for example, there is a motion control hardware(motion control card, motion control driver), and servo, I/O module,
the vendor of hardware usually provide a c++ dll (or lib) to interact with the Axis, i will reference/import the dll and call the api to implement servo on, homing, stop such as these operation. Now we can only hard code in forte, that is too complex for the developers, we hope in ECC control, we can import the dll dynamically, and call the API(with ST or Lua).
As i tested with Lua+Alien, but when calling the api, it seems to not work,
but with no error throwing , i want to know if there is a better way?
We already wrapped some years ago the open CV into function blocks to be used in IEC 61499. But here we went the road of developing dedicated SI FBs. The problem I see is that there is no clear definition how functions in a dll should be called. Especially how variable should be passed and converted. In general the IEC 61131-3 type system is not compatible with c, for example. Also directly calling dlls can even be dangerous as it can violate the execution model of IEC 61499.
We just want the developers to use existed dll(c++) easily
Depending on your use case you could experiment with the feature that you can add #include files in the header info of your type. Than you could just use the functions defined in this header in your ST code. But be warned as said above that the result may be not what you expect.
If you have clearer definitions what is needed I would be happy to discuss implementation options.
joy woo wrote on Thu, 06 June 2019 14:22Another question, so far, we can just program with ST, or hard coded with c++ , IL, LD, FBD in IEC 61131 will be also support or not?
As Martin said we focused on ST as we think this is the most needed language in IEC 61499. Currently we have no plans nor resources/financing to implement more languages.
To formulate it even stronger than Martin IMHO I don't even believe that the others should be implemented in an IEC 61499 environment. If you want to to have FBD I would go for IEC 61499 FB networks which are much more powerful. Also I would strongly recommend to further embrace ECCs. If ECCs are used to your advantage most of your algorithms are really really small. And ECCs are much easier to model then the according ST or LD code.
That is OK even only ST, but if we can debug with the ST with breakpoint,
variable watching that would be better.
-
Attachment: snap2.jpg
(Size: 31.84KB, Downloaded 97 times) -
Attachment: snap1.jpg
(Size: 50.17KB, Downloaded 92 times)
|
|
| |
Re: dll import in programming [message #1807761 is a reply to message #1807753] |
Fri, 07 June 2019 15:56 |
|
If we can we are happy to support. Please not that our resources are currently also rather limited.
Debugging and testing of FBs is something we would love to have. However I would see breakpoints and stepping through FBs for a dedicated debugging environment and not directly on the controller. I think as 4diac provides clear definitions and environment where a FB will run the same on all of the devices this is a feasible and good approach. Another reason we strongly focus on ST and basic FBs. These makes FBs independent from the target system.
Regarding your dll issue: have you tried my other suggestion from above?
|
|
|
Re: dll import in programming [message #1807814 is a reply to message #1807761] |
Mon, 10 June 2019 09:36 |
joy woo Messages: 198 Registered: May 2019 |
Senior Member |
|
|
Mr. Zoitl, thanks for you reply.
Beremiz is also a great open source product, which implements all of the six languages.
And i agree with you, if we can do it with ST, then it is good enough for us to start working.
Plz consider the dll issue to be import, because 4 diac is to solve the distribution industry automation & control,
some of the robots, motion cards, vision system etc and managed by host computer(with PCI cards),
and usually the product vendor supplies dll to interact with the hardware(motion control drivers), software usually
use c++, c#, vb, labview etc to reference/import dll, and call APIs to enable servo, jod, homing, move Axis, stop Axis.
So how to reference/import dll and coding easily in FB is a very import thing.
I checked the previous reply, you suggested, #include headerfile, in this situation, i have to export FB as C++ file, then compile it with forte, then the compile info will tell us if the gamma is correct,
and after debugging, then we know if the behavior is expected or not. That's too complex,if we can compile/debug the pieces of ST on ST editor's UI quickly,
and the debugging environment is a softmotion(not the real runtime enviroment) environment(just as codesys does), that would be better experience.
The second problem is , in older version of 4diac, it supported FBRT of hmi, but now is no longer support.
So if we want to develop HMI with HTML5, shall we have to implement all the controls(label, button, textbox, matrix, etc) with each converting to FB?,
looking forward to your advice.
|
|
|
Re: dll import in programming [message #1807927 is a reply to message #1807814] |
Wed, 12 June 2019 16:30 |
|
joy woo wrote on Mon, 10 June 2019 09:36Mr. Zoitl, thanks for you reply.
Beremiz is also a great open source product, which implements all of the six languages.
And i agree with you, if we can do it with ST, then it is good enough for us to start working.
Plz consider the dll issue to be import, because 4 diac is to solve the distribution industry automation & control,
some of the robots, motion cards, vision system etc and managed by host computer(with PCI cards),
and usually the product vendor supplies dll to interact with the hardware(motion control drivers), software usually
use c++, c#, vb, labview etc to reference/import dll, and call APIs to enable servo, jod, homing, move Axis, stop Axis.
So how to reference/import dll and coding easily in FB is a very import thing.
We'll consider it. As said in one of my post we made the the best experience when we wrapped third party libraries in FBs. By that we could better represent the intended APi for IEC 61499.
joy woo wrote on Mon, 10 June 2019 09:36
I checked the previous reply, you suggested, #include headerfile, in this situation, i have to export FB as C++ file, then compile it with forte, then the compile info will tell us if the gamma is correct,
and after debugging, then we know if the behavior is expected or not. That's too complex,if we can compile/debug the pieces of ST on ST editor's UI quickly,
and the debugging environment is a softmotion(not the real runtime enviroment) environment(just as codesys does), that would be better experience.
This is something I have in mind. The work Jan is currently doing with lua is for me an imortant step in that direction. But as always any support is warmly welcome!
joy woo wrote on Mon, 10 June 2019 09:36
The second problem is , in older version of 4diac, it supported FBRT of hmi, but now is no longer support.
So if we want to develop HMI with HTML5, shall we have to implement all the controls(label, button, textbox, matrix, etc) with each converting to FB?,
looking forward to your advice.
We did many different experiments with HMI approaches. We even had one master thesis some 12 years ago or so where we extended the FBRT hmi with face plactes windows and more complex layouting. But all in all I must say I don't think that modeling UIs with IEC 61499 is the right approach. From all the experience I see that a better approach is to define in your IEC 61499 clear interfaces to the HMI (e.g., with OPC UA or MQTT) and then have dedicated GUI environments for implementing the HMIs (e.g., HTML5).
|
|
|
Goto Forum:
Current Time: Tue Sep 24 09:29:07 GMT 2024
Powered by FUDForum. Page generated in 0.06391 seconds
|