Re: [milo-dev] Configurable OPC-UA server based on Milo

[Stefano Lissa <satollo@xxxxxxxxx>]

Surely I'll take a look to that project. OEE computation is one of the
basic things to get from data collection in a factory. A bit of
background for my questions: here factories do no have data collection
and analysis tools but, by law, they can have some fiscal benefits
implementing such new industry 4.0 concepts. Hence I'm seeking tools
which can easily adapted to the heterogeneous set of (old) machines
using standards (like OPC-UA) limiting the effort only to the machine
to OPC-UA server interface (while they now usually develop and
interface for each machine directly in the ERP!). The OT is far away
to have in place standard tools as we are used in the IT departments.

Coming back to JNI, I've successfully used JNA (which is more
manageable) to load the native Fanuc win32 DLL and transfer the g-code
part program to some lathes. Since the g-code is just a string it
would be easy to think of it as a OPC-UA string value for that
device... ok we're going off-topic now :-).

--
ing. Stefano Lissa
LinkedIn

--
ing. Stefano Lissa
LinkedIn


Il giorno lun 11 feb 2019 alle ore 16:11 Kent Randall
<point85.llc@xxxxxxxxx> ha scritto:
>
> Hello Stefano,
> The idea of looking at open62541 was to see if you can find a C device driver.  If so, you can always use the Java Native Interface (JNI) to communicate with it.  By the way, if you are interested in how I am using a Milo client, please take a look at my Overall Equipment Effectiveness (OEE) project at https://github.com/point85/OEE-Designer.
>
> Virus-free. www.avast.com
>
> On Mon, Feb 11, 2019 at 6:58 AM Kevin Herron <kevinherron@xxxxxxxxx> wrote:
>>
>> > Is it correct to attach an attribute delegate to that node so the adapter is notified of writing operations and then send back that value to the machine?
>>
>> That's one way to achieve this, but AttributeDelegates are not really meant to be used when the attribute read or write might block, and if you're talking to a machine that's definitely the case.
>>
>> What works best is to handle this in the write() method of your Namespace. In a real world implementation you can split the incoming writes into writes that can be done quickly (in memory, directly against a Node possibly via its AttributeDelegate), and those that need to be handed off to other system to complete. All the methods on Namespace are non-blocking/async so your implementation has a chance to do something smart like use non-blocking IO to communicate with external devices, if possible.
>>
>> On Mon, Feb 11, 2019 at 6:31 AM Stefano Lissa <satollo@xxxxxxxxx> wrote:
>>>
>>> Thank you Kent, I'll look at that C++ project even if I'm a long time
>>> (and a bit old) Java coder so I feel myself more comfortable with
>>> Java.
>>>
>>> Just a question (and please let me know if those kind of discussions
>>> should be moved on another forum/mailing list): I'm playing with Milo
>>> and I wrote an adapter which is able (actually not, but...) to
>>> communicate to a with a custom machine and that adapter setup a node
>>> to expose a specific machine value. Is it correct to attach an
>>> attribute delegate to that node so the adapter is notified of writing
>>> operations and then send back that value to the machine?
>>>
>>> Thank you, Stefano.
>>>
>>> --
>>> ing. Stefano Lissa
>>> LinkedIn
>>> _______________________________________________
>>> milo-dev mailing list
>>> milo-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/milo-dev
>>
>> _______________________________________________
>> milo-dev mailing list
>> milo-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/milo-dev
>
> _______________________________________________
> milo-dev mailing list
> milo-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/milo-dev