* Simple Components 4.12 with MQTT implementation released @ 2016-04-12 18:48 Dmitry A. Kazakov 2016-04-14 8:54 ` slos 0 siblings, 1 reply; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-12 18:48 UTC (permalink / raw) The library provides implementations of smart pointers, directed graphs, sets, maps, B-trees, stacks, tables, string editing, unbounded arrays, expression analyzers, lock-free data structures, synchronization primitives (events, race condition free pulse events, arrays of events, reentrant mutexes, deadlock-free arrays of mutexes), pseudo-random non-repeating numbers, symmetric encoding and decoding, IEEE 754 representations support, multiple connections server/client designing tools. http://www.dmitry-kazakov.de/ada/components.htm This new version provides a full implementation of MQTT protocol. The implementation includes a raw MQTT stack for custom clients/servers and a full implementation of a broker with persistent sessions support, retained topics and bulk messages publishing. The broker implementation also provides some enhancements with regard of topic publishing in order to alleviate the MQTT protocol drawbacks. Stream interfaces to the message content are supported as well. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-12 18:48 Simple Components 4.12 with MQTT implementation released Dmitry A. Kazakov @ 2016-04-14 8:54 ` slos 2016-04-14 10:07 ` Dmitry A. Kazakov 0 siblings, 1 reply; 37+ messages in thread From: slos @ 2016-04-14 8:54 UTC (permalink / raw) Le mardi 12 avril 2016 20:48:17 UTC+2, Dmitry A. Kazakov a écrit : > The library provides implementations of smart pointers, directed graphs, > sets, maps, B-trees, stacks, tables, string editing, unbounded arrays, > expression analyzers, lock-free data structures, synchronization > primitives (events, race condition free pulse events, arrays of events, > reentrant mutexes, deadlock-free arrays of mutexes), pseudo-random > non-repeating numbers, symmetric encoding and decoding, IEEE 754 > representations support, multiple connections server/client designing tools. > > http://www.dmitry-kazakov.de/ada/components.htm > > This new version provides a full implementation of MQTT protocol. The > implementation includes a raw MQTT stack for custom clients/servers and > a full implementation of a broker with persistent sessions support, > retained topics and bulk messages publishing. The broker implementation > also provides some enhancements with regard of topic publishing in order > to alleviate the MQTT protocol drawbacks. Stream interfaces to the > message content are supported as well. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de Hello Dmitry, I'm really impressed by and grateful for the hard work. I think the provided MQTT features are likely to be very useful for IoT applications and so a must have for the future of Ada. It's a great addition to your already bold contribution. Thank you very much. Best Regards, Stéphane http://slo-ist.fr/ada4autom ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 8:54 ` slos @ 2016-04-14 10:07 ` Dmitry A. Kazakov 2016-04-14 13:01 ` slos 0 siblings, 1 reply; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-14 10:07 UTC (permalink / raw) On 14/04/2016 10:54, slos wrote: > I'm really impressed by and grateful for the hard work. Thanks, though MQTT protocol is not not that hard. The broker, possibly, mainly because I tried to reduce inefficiencies and faults of the MQTT protocol design as much as possible. I was astonished that MQTT looks quite popular among large, serious SW houses. Though not surprisingly, considering its faults, there is no any devices supporting MQTT. Without devices, what all these people are doing with MQTT is a mystery to me... (:-)) > I think the provided MQTT features are likely to be very useful for > IoT applications and so a must have for the future of Ada. I built it in MAX! home automation application (it controls ELV radiator thermostats), let's see. Bug reports and features requests are welcome. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 10:07 ` Dmitry A. Kazakov @ 2016-04-14 13:01 ` slos 2016-04-14 16:19 ` Björn Lundin 2016-04-14 16:47 ` Dmitry A. Kazakov 0 siblings, 2 replies; 37+ messages in thread From: slos @ 2016-04-14 13:01 UTC (permalink / raw) Le jeudi 14 avril 2016 12:08:23 UTC+2, Dmitry A. Kazakov a écrit : > On 14/04/2016 10:54, slos wrote: > > > I'm really impressed by and grateful for the hard work. > > Thanks, though MQTT protocol is not not that hard. The broker, possibly, > mainly because I tried to reduce inefficiencies and faults of the MQTT > protocol design as much as possible. > > I was astonished that MQTT looks quite popular among large, serious SW > houses. Though not surprisingly, considering its faults, there is no any > devices supporting MQTT. Without devices, what all these people are > doing with MQTT is a mystery to me... (:-)) > > > I think the provided MQTT features are likely to be very useful for > > IoT applications and so a must have for the future of Ada. > > I built it in MAX! home automation application (it controls ELV radiator > thermostats), let's see. > > Bug reports and features requests are welcome. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de I thank you not only for the MQTT implementation but for Simple Components, used among others by Gnoga which I like much too, and also for AIWCL which I would like to see available on Gnoga too. When looking for MQTT capable devices you could find those at Hilscher for example: http://www.hilscher.com/en/applications/industrial-internet/ http://www.hilscher.com/products/product-groups/industrial-internet-industry-40/ With those announced gateways to the IIOT, many things can be MQTT enabled. Anyway, every thing is getting "smarter" and MQTT is not the only protocol in the arena. Anyone for OPC ? ;-) http://open62541.org/ I think Ada could have a bright future in cloud based applications, from the embedded world to the cloud. Well, it has been designed exactly for this. And I regard your contribution and the one of David Botton as "qui tombe à pic" or "à point nommé", which come in handy or timely. Sometimes it seems that things just happen like a self arranging puzzle. It's in the air. Best Regards, Stéphane http://slo-ist.fr/ada4autom ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 13:01 ` slos @ 2016-04-14 16:19 ` Björn Lundin 2016-04-14 16:49 ` Dmitry A. Kazakov 2016-04-14 21:20 ` slos 2016-04-14 16:47 ` Dmitry A. Kazakov 1 sibling, 2 replies; 37+ messages in thread From: Björn Lundin @ 2016-04-14 16:19 UTC (permalink / raw) On 2016-04-14 15:01, slos wrote: > Anyone for OPC ? ;-) > http://open62541.org/ Via David's gnatcom, you have most of it. Use it on opcda.dll, and it will create lots of files. if the prefix id opcda, you'll get .... opcda-opcitems_interface.adb opcda-opcitems_interface.ads opcda-opcitems_object.adb opcda-opcitems_object.ads opcda-opcitem_interface.adb opcda-opcitem_interface.ads opcda-opcitem_object.adb opcda-opcitem_object.ads opcda.ads ... you then need an application to use the files. com is no fun to use, but it looks like this first - connect - definitions - subscribe - write - read - catch events. there are more events, but group is the most important one * connect to a server : Server : aliased IOPCAutoServer_Type; Create (This => Server, From => OPCDA.CLSID_OPCServer); Connect(This => Server, ProgID => Gnatcom.Bstr. To_Bstr("some registered name for a server")); You then need a group collection Group_Collection : IOPCGroups_Type; P_Group_Collection : Pointer_To_IOPCGroups; --group collection P_Group_Collection := Get_OPCGroups(This => Server); Attach(This => Group_Collection, Pointer => P_Group_Collection); Put_DefaultGroupIsActive(This => Group_Collection, DefaultGroupIsActive => GNATCOM.Types.VARIANT_BOOL_TRUE); Put_DefaultGroupDeadband(This => Group_Collection, DefaultGroupDeadband => 0.0); then you need a group: Group : IOPCGroup_Type; P_Group : Pointer_To_IOPCGroup; P_Group := Add(This => Group_Collection, Name => Gnatcom.Variant. To_Variant("A predefined group")); Attach(This => Group, Pointer => P_Group); Put_IsSubscribed(This => Group, IsSubscribed => GNATCOM.Types.VARIANT_BOOL_TRUE); Put_UpdateRate(This => Group, UpdateRate => 0); Put_DeadBand(This => Group, DeadBand => 0.0); and the group has an item collection Item_Collection : OPCItems_Type; P_Item_Collection : Pointer_To_OPCItems; P_Item_Collection := Get_OPCItems(This => Group); Attach(This => Item_Collection, Pointer => P_Item_Collection); Put_DefaultIsActive(This => Item_Collection, DefaultIsActive => GNATCOM.Types.VARIANT_BOOL_TRUE); You also need to setup a handler for incoming updates in a group event Group_Event_Object : aliased Opc.Events.Group.Group_Event_Type; Group_Event : GNATCOM.Create.COM_Interface. Pointer_To_COM_Interface_Type ; Group_Events_Connection_Point : GNATCOM.Events.IConnectionPoint_Type; Group_Event := OPCDA.DIOPCGroupEvent_Events.Create(Group_Event_Object'Unchecked_Access); OPCDA.DIOPCGroupEvent_Events. Set_Events(This => Group_Events_Connection_Point, For_Object => Group, Event_Interface => Group_Event); Put_ClientName(This => Server, ClientName => GNATCOM.BSTR.To_BSTR("A client name"))); Now, you need to subscribe to som signals: P_Item := AddItem(This => Item_Collection, ItemId => Gnatcom.Bstr.To_Bstr("a signal name"), ClientHandle => C.Long(C_H)); Attach(This => Item, Pointer => P_Item); Put_RequestedDataType(This => Item, RequestedDataType => The_Type); where the type is one of allowed type, eg VT_BOOL,VT_UI2,VT_I4. for arrys add VT_ARRAY like VT_UI2 + VT_ARRAY take care of the C_H, the client handle. Update eventes will refer to this value To write a value: declare Local_Item : OPCItem_Type; begin Local_P_Item := GetOPCItem(This => Item_Collection, ServerHandle => Server_Handle); -- Returns an OPCItem specified by server handle Attach(This => An_Item, Pointer => Local_P_Item); Write(This => Local_Item, Value => Value); Free(Local_Item); end; to explicitly read a value: procedure Read(Server_Handle : Interfaces.C.Long) is use GNATCOM.Types; Quality : aliased GNATCOM.Types.Variant; Value : aliased GNATCOM.Types.Variant; TimeStamp : aliased GNATCOM.Types.Variant; begin Gnatcom.Variant.Initialize(Value); Gnatcom.Variant.Initialize(Quality); Gnatcom.Variant.Initialize(TimeStamp); declare Local_Item : OPCItem_Type; begin Local_Item := GetOPCItem(This => Item_Collection, ServerHandle => Server_Handle); Read(This => Local_Item, Source => OPCDA.OPCDevice, Value => Value'Unchecked_Access, Quality => Quality'Unchecked_Access, TimeStamp => Timestamp'Unchecked_Access); Free(Local_Item); end; Gnatcom.Variant.Clear(Quality); Gnatcom.Variant.Clear(TimeStamp); Gnatcom.Variant.Clear(Value); Disconnect: RemoveAll(This => Group_Collection); Disconnect(This => Server); Finalize(This => Server); P_Item := null; P_Item_Collection := null; P_Group := null; P_Group_Collection := null; for events, you inherit like this with OPCDA.DIOPCGroupEvent_Events; with GNATCOM.Types; package Opc.Events.Group is type Group_Event_Type is new OPCDA.DIOPCGroupEvent_Events.DIOPCGroupEvent_Event with null record; procedure DataChange(This : Group_Event_Type; TransactionID : GNATCOM.Types.VARIANT; NumItems : GNATCOM.Types.VARIANT; ClientHandles : GNATCOM.Types.VARIANT; ItemValues : GNATCOM.Types.VARIANT; Qualities : GNATCOM.Types.VARIANT; TimeStamps : GNATCOM.Types.VARIANT); end Opc.Events.Group; and the body procedure DataChange(This : Group_Event_Type; TransactionID : GNATCOM.Types.VARIANT; NumItems : GNATCOM.Types.VARIANT; ClientHandles : GNATCOM.Types.VARIANT; ItemValues : GNATCOM.Types.VARIANT; Qualities : GNATCOM.Types.VARIANT; TimeStamps : GNATCOM.Types.VARIANT) is use GNATCOM.Types; function Get_Variant is new Gnatcom.Safearray.Get_Element(VARIANT); function Get_Integer is new Gnatcom.Safearray.Get_Element(Integer); Client_Handle,Quality : Integer := Integer'First; Value : VARIANT; I_Num_Items : Integer := To_Ada(From => NumItems); Handles : GNATCOM.Types.Pointer_To_SAFEARRAY := To_Pointer_To_SAFEARRAY(ClientHandles); Values : GNATCOM.Types.Pointer_To_SAFEARRAY := To_Pointer_To_SAFEARRAY(ItemValues); The_Qualities : GNATCOM.Types.Pointer_To_SAFEARRAY := To_Pointer_To_SAFEARRAY(Qualities); ----------------------------------------------------------------------------------- begin --It's important that the words in what is sent back are separated by -- one (1) space (' ') and one ONLY! OPC_IO will misinterpret otherwise! -- 'HANDLE server_handle VALUE some_value TYPE some_type' Initialize(Value); for i in 1 .. I_Num_Items loop Quality := Get_Integer(Of_Array => The_Qualities, Index => i); Client_Handle := Get_Integer(Of_Array => Handles, Index => i); Value := Get_Variant(Of_Array => Values, Index => i); -- do something with value here case Value.vt is when VT_I2 => --Integer_2 when VT_I4 => --Integer_4 when VT_BSTR => --Strings when VT_ARRAY + VT_I2 | -- Array of I2 VT_ARRAY + VT_UI2 | -- Array of UI2 VT_ARRAY + VT_I4 => -- Array of I4 when others => end case end loop; Clear(Value); end DataChange; -- -- Björn ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 16:19 ` Björn Lundin @ 2016-04-14 16:49 ` Dmitry A. Kazakov 2016-04-14 20:57 ` Björn Lundin 2016-04-14 21:29 ` slos 2016-04-14 21:20 ` slos 1 sibling, 2 replies; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-14 16:49 UTC (permalink / raw) On 2016-04-14 18:19, Björn Lundin wrote: > On 2016-04-14 15:01, slos wrote: >> Anyone for OPC ? ;-) >> http://open62541.org/ > > Via David's gnatcom, you have most of it. > Use it on opcda.dll, and it will create lots of files. > if the prefix id opcda, you'll get That looks OPC DA. It seems that requested was OPC UA. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 16:49 ` Dmitry A. Kazakov @ 2016-04-14 20:57 ` Björn Lundin 2016-04-14 21:29 ` slos 1 sibling, 0 replies; 37+ messages in thread From: Björn Lundin @ 2016-04-14 20:57 UTC (permalink / raw) On 2016-04-14 18:49, Dmitry A. Kazakov wrote: > On 2016-04-14 18:19, Björn Lundin wrote: >> On 2016-04-14 15:01, slos wrote: >>> Anyone for OPC ? ;-) >>> http://open62541.org/ >> >> Via David's gnatcom, you have most of it. >> Use it on opcda.dll, and it will create lots of files. >> if the prefix id opcda, you'll get > > That looks OPC DA. It seems that requested was OPC UA. Yes it is. I did not notice the UA bit -- -- Björn ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 16:49 ` Dmitry A. Kazakov 2016-04-14 20:57 ` Björn Lundin @ 2016-04-14 21:29 ` slos 1 sibling, 0 replies; 37+ messages in thread From: slos @ 2016-04-14 21:29 UTC (permalink / raw) Le jeudi 14 avril 2016 18:50:08 UTC+2, Dmitry A. Kazakov a écrit : > On 2016-04-14 18:19, Björn Lundin wrote: > > On 2016-04-14 15:01, slos wrote: > >> Anyone for OPC ? ;-) > >> http://open62541.org/ > > > > Via David's gnatcom, you have most of it. > > Use it on opcda.dll, and it will create lots of files. > > if the prefix id opcda, you'll get > > That looks OPC DA. It seems that requested was OPC UA. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de Yes indeed. OPC DA is the old stuff. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 16:19 ` Björn Lundin 2016-04-14 16:49 ` Dmitry A. Kazakov @ 2016-04-14 21:20 ` slos 2016-04-15 11:29 ` Björn Lundin 1 sibling, 1 reply; 37+ messages in thread From: slos @ 2016-04-14 21:20 UTC (permalink / raw) Le jeudi 14 avril 2016 18:19:54 UTC+2, björn lundin a écrit : > On 2016-04-14 15:01, slos wrote: > > Anyone for OPC ? ;-) > > http://open62541.org/ > > Via David's gnatcom, you have most of it. > Use it on opcda.dll, and it will create lots of files. > if the prefix id opcda, you'll get > .... > opcda-opcitems_interface.adb > opcda-opcitems_interface.ads > opcda-opcitems_object.adb > opcda-opcitems_object.ads > opcda-opcitem_interface.adb > opcda-opcitem_interface.ads > opcda-opcitem_object.adb > opcda-opcitem_object.ads > opcda.ads > ... > > > you then need an application to use the files. > com is no fun to use, but it looks like this > first > - connect > - definitions > - subscribe > - write > - read > - catch events. > there are more events, but group is the most important one > > > > > * connect to a server : > Server : aliased IOPCAutoServer_Type; > Create (This => Server, From => OPCDA.CLSID_OPCServer); > Connect(This => Server, > ProgID => Gnatcom.Bstr. > To_Bstr("some registered name for a server")); > > You then need a group collection > Group_Collection : IOPCGroups_Type; > P_Group_Collection : Pointer_To_IOPCGroups; > > > --group collection > P_Group_Collection := Get_OPCGroups(This => Server); > Attach(This => Group_Collection, Pointer => P_Group_Collection); > Put_DefaultGroupIsActive(This => Group_Collection, > DefaultGroupIsActive => > GNATCOM.Types.VARIANT_BOOL_TRUE); > > Put_DefaultGroupDeadband(This => Group_Collection, > DefaultGroupDeadband => 0.0); > > then you need a group: > Group : IOPCGroup_Type; > P_Group : Pointer_To_IOPCGroup; > > > P_Group := Add(This => Group_Collection, > Name => Gnatcom.Variant. > To_Variant("A predefined group")); > Attach(This => Group, Pointer => P_Group); > Put_IsSubscribed(This => Group, > IsSubscribed => > GNATCOM.Types.VARIANT_BOOL_TRUE); > Put_UpdateRate(This => Group, > UpdateRate => 0); > Put_DeadBand(This => Group, > DeadBand => 0.0); > > > and the group has an item collection > > Item_Collection : OPCItems_Type; > P_Item_Collection : Pointer_To_OPCItems; > > > P_Item_Collection := Get_OPCItems(This => Group); > Attach(This => Item_Collection, Pointer => P_Item_Collection); > Put_DefaultIsActive(This => Item_Collection, > DefaultIsActive => > GNATCOM.Types.VARIANT_BOOL_TRUE); > > > You also need to setup a handler for incoming updates > in a group event > > Group_Event_Object : aliased Opc.Events.Group.Group_Event_Type; > Group_Event : GNATCOM.Create.COM_Interface. > Pointer_To_COM_Interface_Type ; > Group_Events_Connection_Point : GNATCOM.Events.IConnectionPoint_Type; > > > Group_Event := > OPCDA.DIOPCGroupEvent_Events.Create(Group_Event_Object'Unchecked_Access); > > OPCDA.DIOPCGroupEvent_Events. > Set_Events(This => > Group_Events_Connection_Point, > For_Object => Group, > Event_Interface => Group_Event); > Put_ClientName(This => Server, > ClientName => > GNATCOM.BSTR.To_BSTR("A client name"))); > > > Now, you need to subscribe to som signals: > > > P_Item := AddItem(This => Item_Collection, > ItemId => > Gnatcom.Bstr.To_Bstr("a signal name"), > ClientHandle => C.Long(C_H)); > Attach(This => Item, Pointer => P_Item); > Put_RequestedDataType(This => Item, > RequestedDataType => The_Type); > > > > where the type is one of allowed type, eg > VT_BOOL,VT_UI2,VT_I4. for arrys add VT_ARRAY like > VT_UI2 + VT_ARRAY > > take care of the C_H, the client handle. > Update eventes will refer to this value > > > > To write a value: > > > declare > Local_Item : OPCItem_Type; > begin > Local_P_Item := GetOPCItem(This => Item_Collection, > ServerHandle => Server_Handle); > -- Returns an OPCItem specified by server handle > Attach(This => An_Item, Pointer => Local_P_Item); > Write(This => Local_Item, Value => Value); > Free(Local_Item); > end; > > > > to explicitly read a value: > > > procedure Read(Server_Handle : Interfaces.C.Long) is > use GNATCOM.Types; > Quality : aliased GNATCOM.Types.Variant; > Value : aliased GNATCOM.Types.Variant; > TimeStamp : aliased GNATCOM.Types.Variant; > > begin > Gnatcom.Variant.Initialize(Value); > Gnatcom.Variant.Initialize(Quality); > Gnatcom.Variant.Initialize(TimeStamp); > > declare > Local_Item : OPCItem_Type; > begin > Local_Item := GetOPCItem(This => Item_Collection, > ServerHandle => Server_Handle); > Read(This => Local_Item, > Source => OPCDA.OPCDevice, > Value => Value'Unchecked_Access, > Quality => Quality'Unchecked_Access, > TimeStamp => Timestamp'Unchecked_Access); > Free(Local_Item); > end; > > Gnatcom.Variant.Clear(Quality); > Gnatcom.Variant.Clear(TimeStamp); > Gnatcom.Variant.Clear(Value); > > > > Disconnect: > RemoveAll(This => Group_Collection); > Disconnect(This => Server); > Finalize(This => Server); > P_Item := null; > P_Item_Collection := null; > P_Group := null; > P_Group_Collection := null; > > > > for events, you inherit like this > > > with OPCDA.DIOPCGroupEvent_Events; > with GNATCOM.Types; > > package Opc.Events.Group is > > type Group_Event_Type is > new OPCDA.DIOPCGroupEvent_Events.DIOPCGroupEvent_Event > with null record; > > procedure DataChange(This : Group_Event_Type; > TransactionID : GNATCOM.Types.VARIANT; > NumItems : GNATCOM.Types.VARIANT; > ClientHandles : GNATCOM.Types.VARIANT; > ItemValues : GNATCOM.Types.VARIANT; > Qualities : GNATCOM.Types.VARIANT; > TimeStamps : GNATCOM.Types.VARIANT); > > end Opc.Events.Group; > > > and the body > > procedure DataChange(This : Group_Event_Type; > TransactionID : GNATCOM.Types.VARIANT; > NumItems : GNATCOM.Types.VARIANT; > ClientHandles : GNATCOM.Types.VARIANT; > ItemValues : GNATCOM.Types.VARIANT; > Qualities : GNATCOM.Types.VARIANT; > TimeStamps : GNATCOM.Types.VARIANT) is > > use GNATCOM.Types; > function Get_Variant is new > Gnatcom.Safearray.Get_Element(VARIANT); > function Get_Integer is new > Gnatcom.Safearray.Get_Element(Integer); > > Client_Handle,Quality : Integer := Integer'First; > Value : VARIANT; > I_Num_Items : Integer := To_Ada(From => NumItems); > Handles : GNATCOM.Types.Pointer_To_SAFEARRAY := > To_Pointer_To_SAFEARRAY(ClientHandles); > Values : GNATCOM.Types.Pointer_To_SAFEARRAY := > To_Pointer_To_SAFEARRAY(ItemValues); > The_Qualities : GNATCOM.Types.Pointer_To_SAFEARRAY := > To_Pointer_To_SAFEARRAY(Qualities); > > > ----------------------------------------------------------------------------------- > > > begin > --It's important that the words in what is sent back are separated by > -- one (1) space (' ') and one ONLY! OPC_IO will misinterpret > otherwise! > -- 'HANDLE server_handle VALUE some_value TYPE some_type' > Initialize(Value); > for i in 1 .. I_Num_Items loop > Quality := Get_Integer(Of_Array => The_Qualities, Index => i); > Client_Handle := Get_Integer(Of_Array => Handles, Index => i); > Value := Get_Variant(Of_Array => Values, Index => i); > > -- do something with value here > case Value.vt is > when VT_I2 => --Integer_2 > when VT_I4 => --Integer_4 > when VT_BSTR => --Strings > when VT_ARRAY + VT_I2 | -- Array of I2 > VT_ARRAY + VT_UI2 | -- Array of UI2 > VT_ARRAY + VT_I4 => -- Array of I4 > when others => > > end case > > > > end loop; > Clear(Value); > end DataChange; > > > > > -- > -- > Björn Hello Björn, Thank you very much for the code example. This could be a solution but only for the MS world. BR; Stéphane ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 21:20 ` slos @ 2016-04-15 11:29 ` Björn Lundin 2016-04-15 12:13 ` slos 0 siblings, 1 reply; 37+ messages in thread From: Björn Lundin @ 2016-04-15 11:29 UTC (permalink / raw) On 2016-04-14 23:20, slos wrote: > Hello Björn, > Thank you very much for the code example. > This could be a solution but only for the MS world. Yes. So that was a major annoyance, when I wrote it. So that code is wrapped in Ted Dennisons Windows service package that he wrote for running the SETI-client. So a windows pc is running the OPC-server, and my service (in 6 instances, they handle ca 1600 signals). The WMS/WCS system using this is on AIX, and it sends commands for subsriptions to the service, which sends back the events over socket (another protocol) |----- winpc --------------| |---- AIX --------| PLC <-> | opc-server <-> opc-services | <-> | client programs | |-----------------------------| |-----------------| Around 2 minutes into the film, when the STV (monorail) delivers a pallet to the conveyor, and then when the crane retrieves the pallet from the conveyor, the above is in use. https://www.youtube.com/watch?v=oE5yqCXbHJE -- -- Björn ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 11:29 ` Björn Lundin @ 2016-04-15 12:13 ` slos 0 siblings, 0 replies; 37+ messages in thread From: slos @ 2016-04-15 12:13 UTC (permalink / raw) Le vendredi 15 avril 2016 13:47:48 UTC+2, björn lundin a écrit : > On 2016-04-14 23:20, slos wrote: > > > Hello Björn, > > Thank you very much for the code example. > > This could be a solution but only for the MS world. > > Yes. So that was a major annoyance, when I wrote it. > So that code is wrapped in Ted Dennisons Windows service package > that he wrote for running the SETI-client. > > So a windows pc is running the OPC-server, and my service (in 6 > instances, they handle ca 1600 signals). > The WMS/WCS system using this is on AIX, and it sends > commands for subsriptions to the service, which sends back > the events over socket (another protocol) > > |----- winpc --------------| |---- AIX --------| > PLC <-> | opc-server <-> opc-services | <-> | client programs | > |-----------------------------| |-----------------| > > > Around 2 minutes into the film, when the STV (monorail) delivers a > pallet to the conveyor, and then when the crane retrieves the pallet > from the conveyor, the above is in use. > > https://www.youtube.com/watch?v=oE5yqCXbHJE > > > > -- > -- > Björn Thank you Björn. So just put in operation "Ada for Automation" in Linux PREEMPT_RT targets instead of your PLC + Windows PC + OPC stuff and employ the protocol of your choice to communicate with your management system ! Easy isn't it? ;-) I would love to participate in such interesting project. Count on me if you decide to go this way ! BR, Stéphane http://slo-ist.fr/ada4autom ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 13:01 ` slos 2016-04-14 16:19 ` Björn Lundin @ 2016-04-14 16:47 ` Dmitry A. Kazakov 2016-04-14 21:03 ` Björn Lundin 1 sibling, 1 reply; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-14 16:47 UTC (permalink / raw) On 2016-04-14 15:01, slos wrote: > Anyone for OPC ? ;-) Well, which of? OPC DA is, truth to tell, garbage. OPC UA is under permanent development. It is impossible to say when it will reach even a semi-standard stage. Regarding architecture, OPC is barely usable in automation because of its heavy client/server architecture. Part of our business is to replace OPC with better middleware architectures. Replacement works smoothly because in most cases you can throw out the OPC server and communicate with the hardware directly. E.g. most SPS' support either ITOT or ModBus, each far superior to OPC. > http://open62541.org/ Cannot comment on it. I am familiar with Softing OPC DA stack and with Unified Automation OPC UA stack. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 16:47 ` Dmitry A. Kazakov @ 2016-04-14 21:03 ` Björn Lundin 2016-04-14 21:30 ` slos 0 siblings, 1 reply; 37+ messages in thread From: Björn Lundin @ 2016-04-14 21:03 UTC (permalink / raw) On 2016-04-14 18:47, Dmitry A. Kazakov wrote: > On 2016-04-14 15:01, slos wrote: > >> Anyone for OPC ? ;-) > > Well, which of? > > OPC DA is, truth to tell, garbage. Yes. > OPC UA is under permanent development. It is impossible to say when it > will reach even a semi-standard stage. Iteresting. Never heard of it. But we left the OPC-world 10 years ago, when we realized it is much better with direct socket with some protocol we PLC-guys and we could agree upon. > > Regarding architecture, OPC is barely usable in automation because of > its heavy client/server architecture. Part of our business is to replace > OPC with better middleware architectures. Replacement works smoothly > because in most cases you can throw out the OPC server and communicate > with the hardware directly. E.g. most SPS' support either ITOT or > ModBus, each far superior to OPC. > The only real advantage I can see is the OPC-scout - a way of browsing raw data in the plc. But that is for manual use, and troubleshooting, so for 'office' use I can see OPC as something not too bad - hence why I wrote down the opcda code in another answer. For automation - other protocols are better -- -- Björn ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 21:03 ` Björn Lundin @ 2016-04-14 21:30 ` slos 2016-04-15 8:01 ` Dmitry A. Kazakov 0 siblings, 1 reply; 37+ messages in thread From: slos @ 2016-04-14 21:30 UTC (permalink / raw) Le jeudi 14 avril 2016 23:03:47 UTC+2, björn lundin a écrit : > On 2016-04-14 18:47, Dmitry A. Kazakov wrote: > > On 2016-04-14 15:01, slos wrote: > > > >> Anyone for OPC ? ;-) > > > > Well, which of? > > > > OPC DA is, truth to tell, garbage. > > Yes. > > > > OPC UA is under permanent development. It is impossible to say when it > > will reach even a semi-standard stage. > > Iteresting. Never heard of it. > But we left the OPC-world 10 years ago, > when we realized it is much better with direct socket > with some protocol we PLC-guys and we could agree upon. > > > > > Regarding architecture, OPC is barely usable in automation because of > > its heavy client/server architecture. Part of our business is to replace > > OPC with better middleware architectures. Replacement works smoothly > > because in most cases you can throw out the OPC server and communicate > > with the hardware directly. E.g. most SPS' support either ITOT or > > ModBus, each far superior to OPC. > > > > The only real advantage I can see is the OPC-scout - a way of > browsing raw data in the plc. > But that is for manual use, and troubleshooting, > so for 'office' use I can see OPC as something not too bad - > hence why I wrote down the opcda code in another answer. > For automation - other protocols are better > > > -- > -- > Björn Be prepared to ear about it soon. Just google for "industry 4.0 opc ua" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-14 21:30 ` slos @ 2016-04-15 8:01 ` Dmitry A. Kazakov 2016-04-15 10:06 ` slos 0 siblings, 1 reply; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-15 8:01 UTC (permalink / raw) On 14/04/2016 23:30, slos wrote: > Be prepared to ear about it soon. > Just google for "industry 4.0 opc ua" Well, actually I am involved in an Industry 4.0 project: http://www.secureplugandwork.de/servlet/is/10291/ We indeed use OPC UA in this project. But OPC UA is unsuitable for field automation, basically, for any work associated with data acquisition and control. Therefore the architecture is that the OPC UA is only a gateway to the applications. All actual the work is done by the middleware developed by cbb software GmbH running on the system nodes (ARM boards). The middleware feeds an UPC UA server which the gateway's OPC UA client accesses. BTW, the middleware is 100% Ada and 0% OPC. Note that without OPC UA everything could work far better and require far less resources. E.g. having all process data the OPC cannot access because it is too slow to pace with the middleware capable to deliver data at less than 1ms rate and does not properly support push-subscriptions, does not support distributed time stamping, physical units, error states etc. That was the reason why it was decided that the OPC UA gateway would not deal with process data at all. It is used only for configuration and possibly for history process data. In short, there are serious multiple reasons why OPC UA cannot be used in the field, regardless how strong the push for it is. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 8:01 ` Dmitry A. Kazakov @ 2016-04-15 10:06 ` slos 2016-04-15 11:12 ` Björn Lundin 2016-04-15 15:05 ` Dmitry A. Kazakov 0 siblings, 2 replies; 37+ messages in thread From: slos @ 2016-04-15 10:06 UTC (permalink / raw) Le vendredi 15 avril 2016 10:01:31 UTC+2, Dmitry A. Kazakov a écrit : > On 14/04/2016 23:30, slos wrote: > > > Be prepared to ear about it soon. > > Just google for "industry 4.0 opc ua" > > Well, actually I am involved in an Industry 4.0 project: > > http://www.secureplugandwork.de/servlet/is/10291/ > Good to know ! Thank you for the link. > We indeed use OPC UA in this project. But OPC UA is unsuitable for field > automation, basically, for any work associated with data acquisition and > control. Of course but like nobody, I don't intend to use it in this case. There are already plenty of industrial protocols fitting here. "Ada for Automation" is using libmodbus for Modbus RTU and TCP communications and Hilscher boards for all major field buses. > Therefore the architecture is that the OPC UA is only a gateway > to the applications. All actual the work is done by the middleware > developed by cbb software GmbH running on the system nodes (ARM boards). > The middleware feeds an UPC UA server which the gateway's OPC UA client > accesses. BTW, the middleware is 100% Ada and 0% OPC. We share some of the vision. "Ada for Automation" is a framework with which one can build his own control application using Ada. I would not call it a middleware. And MQTT or OPC UA would just connect it to some SCADA or cloud based application like one using IBM BlueMix. > Note that without OPC UA everything could work far better and require > far less resources. E.g. having all process data the OPC cannot access > because it is too slow to pace with the middleware capable to deliver > data at less than 1ms rate and does not properly support > push-subscriptions, does not support distributed time stamping, physical > units, error states etc. > I agree that OPC UA does not fit where EtherCAT, Sercos III or PROFINET IRT would. OPC was created for office and SCADA / GUI applications access to PLC data, not for IO processing. > That was the reason why it was decided that the OPC UA gateway would not > deal with process data at all. It is used only for configuration and > possibly for history process data. > > In short, there are serious multiple reasons why OPC UA cannot be used > in the field, regardless how strong the push for it is. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de Stéphane ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 10:06 ` slos @ 2016-04-15 11:12 ` Björn Lundin 2016-04-15 15:05 ` Dmitry A. Kazakov 1 sibling, 0 replies; 37+ messages in thread From: Björn Lundin @ 2016-04-15 11:12 UTC (permalink / raw) On 2016-04-15 12:06, slos wrote: > I agree that OPC UA does not fit where EtherCAT, Sercos III or PROFINET IRT would. > OPC was created for office and SCADA / GUI applications access to PLC data, not for IO processing. For pulling data to office use from a PLC is ok. But protocols have a tendency to be used in other ways than originally designed for. I've stopped several integration projects the last couple of years, where the PLC-programmers wanted OPC (DA). they went live with proprietary socket protocols instead, with great success. PLC-programmers usually like OPC because they do not need to do very much in order to make it work on their side. Then it does not matter that it is a clunky protocol. -- Björn ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 10:06 ` slos 2016-04-15 11:12 ` Björn Lundin @ 2016-04-15 15:05 ` Dmitry A. Kazakov 2016-04-15 15:17 ` slos 2016-04-15 15:47 ` slos 1 sibling, 2 replies; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-15 15:05 UTC (permalink / raw) On 2016-04-15 12:06, slos wrote: > We share some of the vision. > "Ada for Automation" is a framework with which one can build his own > control application using Ada. I would not call it a middleware. Why not? > And MQTT or OPC UA would just connect it to some SCADA or cloud based > application like one using IBM BlueMix. Neither is good for SCADA, especially regarding safety requirements and performance. >> Note that without OPC UA everything could work far better and require >> far less resources. E.g. having all process data the OPC cannot access >> because it is too slow to pace with the middleware capable to deliver >> data at less than 1ms rate and does not properly support >> push-subscriptions, does not support distributed time stamping, physical >> units, error states etc. >> > I agree that OPC UA does not fit where EtherCAT, Sercos III or PROFINET IRT would. > OPC was created for office and SCADA / GUI applications access to > PLC data, not for IO processing. Why SCADA or DB server should ever use some other middleware protocols? The point is that one middleware can stretch from the ERP levels down to the field. But when the middleware is OPC or MQTT you cannot not put it into a device and expect that working. This is the reason we must live with EtherCAT, ProfiNET down there, which are nightmare to any system integrator. That defeats the very idea of a middleware. The real advantage of Ada is that it is scalable from heavy duty to hard real-time embedded. The ugly protocols like XML, HTTP, OPC etc only hinder developing of safe and efficient systems. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 15:05 ` Dmitry A. Kazakov @ 2016-04-15 15:17 ` slos 2016-04-15 15:34 ` Dmitry A. Kazakov 2016-04-15 15:47 ` slos 1 sibling, 1 reply; 37+ messages in thread From: slos @ 2016-04-15 15:17 UTC (permalink / raw) Le vendredi 15 avril 2016 17:05:56 UTC+2, Dmitry A. Kazakov a écrit : > On 2016-04-15 12:06, slos wrote: > > > We share some of the vision. > > "Ada for Automation" is a framework with which one can build his own > > control application using Ada. I would not call it a middleware. > > Why not? > > > And MQTT or OPC UA would just connect it to some SCADA or cloud based > > application like one using IBM BlueMix. > > Neither is good for SCADA, especially regarding safety requirements and > performance. > > >> Note that without OPC UA everything could work far better and require > >> far less resources. E.g. having all process data the OPC cannot access > >> because it is too slow to pace with the middleware capable to deliver > >> data at less than 1ms rate and does not properly support > >> push-subscriptions, does not support distributed time stamping, physical > >> units, error states etc. > >> > > I agree that OPC UA does not fit where EtherCAT, Sercos III or PROFINET IRT would. > > OPC was created for office and SCADA / GUI applications access to > > PLC data, not for IO processing. > > Why SCADA or DB server should ever use some other middleware protocols? > The point is that one middleware can stretch from the ERP levels down to > the field. But when the middleware is OPC or MQTT you cannot not put it > into a device and expect that working. This is the reason we must live > with EtherCAT, ProfiNET down there, which are nightmare to any system > integrator. That defeats the very idea of a middleware. > > The real advantage of Ada is that it is scalable from heavy duty to hard > real-time embedded. The ugly protocols like XML, HTTP, OPC etc only > hinder developing of safe and efficient systems. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de Standards are created for interoperability. If you don't need interoperability, you don't need standards. Hence you need standards since you leave in an interconnected world now. BR, Stéphane ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 15:17 ` slos @ 2016-04-15 15:34 ` Dmitry A. Kazakov 2016-04-15 16:00 ` slos 0 siblings, 1 reply; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-15 15:34 UTC (permalink / raw) On 2016-04-15 17:17, slos wrote: > Standards are created for interoperability. > If you don't need interoperability, you don't need standards. > Hence you need standards since you leave in an interconnected world now. It is an idealized picture. In reality it starts with an insular solution, not infrequently developed rather to prevent interoperability. When the solution gains some market breath it is elevated to a "standard" if there is enough commercial muscles behind it. So the future is totally unpredictable as the choice is almost never motivated by technical merit. You can sit and wait for something reasonable to come, or you can start using things you consider right. I prefer the latter. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 15:34 ` Dmitry A. Kazakov @ 2016-04-15 16:00 ` slos 2016-04-15 16:39 ` Dmitry A. Kazakov 0 siblings, 1 reply; 37+ messages in thread From: slos @ 2016-04-15 16:00 UTC (permalink / raw) Le vendredi 15 avril 2016 17:34:36 UTC+2, Dmitry A. Kazakov a écrit : > On 2016-04-15 17:17, slos wrote: > > > Standards are created for interoperability. > > If you don't need interoperability, you don't need standards. > > Hence you need standards since you leave in an interconnected world now. > > It is an idealized picture. In reality it starts with an insular > solution, not infrequently developed rather to prevent interoperability. Ada is a standard too isn't it ? > When the solution gains some market breath it is elevated to a > "standard" if there is enough commercial muscles behind it. Yes, someone has an idea which he feels net to be developed. Then the market and the marketing and the muscles that go with make it grow or collapse. The more you talk to others the more it grows. > So the future is totally unpredictable as the choice is almost never > motivated by technical merit. As always. Marketing is motivating people to buy your stuff. I guess Siemens, Rockwell, Schneider Electric and the other folks have the muscles it takes. > You can sit and wait for something reasonable to come, or you can start > using things you consider right. I prefer the latter. And reinvent the wheel ? If you want drives, encoders, IO modules, etc... you have them all using those standard field buses. Would you create your own ? > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de BR, Stéphane ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 16:00 ` slos @ 2016-04-15 16:39 ` Dmitry A. Kazakov 2016-04-15 22:39 ` slos 0 siblings, 1 reply; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-15 16:39 UTC (permalink / raw) On 2016-04-15 18:00, slos wrote: > Le vendredi 15 avril 2016 17:34:36 UTC+2, Dmitry A. Kazakov a écrit : >> You can sit and wait for something reasonable to come, or you can start >> using things you consider right. I prefer the latter. > And reinvent the wheel ? > > If you want drives, encoders, IO modules, etc... you have them all > using those standard field buses. Would you create your own ? No, I would dock them to the middleware using whatever protocol they run. That is one of the key advantages of a proper middleware over OPC, i.e. an abstraction of the hardware. With OPC/MQTT approach you must wait until the vendor of the encoder will write an OPC/MQTT server for you. He might do it or decide in favor of something else ModBus, ProfiNET, CAN etc. Vendors have limited resources and even more limited software development competence to expect them to offer the exactly "standard" you consider standard. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 16:39 ` Dmitry A. Kazakov @ 2016-04-15 22:39 ` slos 0 siblings, 0 replies; 37+ messages in thread From: slos @ 2016-04-15 22:39 UTC (permalink / raw) Le vendredi 15 avril 2016 18:39:42 UTC+2, Dmitry A. Kazakov a écrit : > On 2016-04-15 18:00, slos wrote: > > Le vendredi 15 avril 2016 17:34:36 UTC+2, Dmitry A. Kazakov a écrit : > > >> You can sit and wait for something reasonable to come, or you can start > >> using things you consider right. I prefer the latter. > > And reinvent the wheel ? > > > > If you want drives, encoders, IO modules, etc... you have them all > > using those standard field buses. Would you create your own ? > > No, I would dock them to the middleware using whatever protocol they > run. That is one of the key advantages of a proper middleware over OPC, > i.e. an abstraction of the hardware. You seem to consider me as a supporter of the OPC or MQTT technologies. I won't discuss their merits since I am just a user of those. Those are technologies already available and supported by major organizations. And at some point you need to use them/ > > With OPC/MQTT approach you must wait until the vendor of the encoder > will write an OPC/MQTT server for you. He might do it or decide in favor > of something else ModBus, ProfiNET, CAN etc. Vendors have limited > resources and even more limited software development competence to > expect them to offer the exactly "standard" you consider standard. Oh Lord, please don't let me be misunderstood... Dmitry, I like you for providing interesting Ada components and sometimes help and good advice. But we end up discussing the up and downs of the protocols versus your middleware and this seems to lead nowhere. "Ada for Automation" targets manufacturing control applications, no rockets or weapons. There the protocols we have discussed are established since years and there is a huge ecosystem that allow one to pick the components of his choice and build the solution he can, although being a not so competent engineer. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de Have a nice week end. BR, Stéphane ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 15:05 ` Dmitry A. Kazakov 2016-04-15 15:17 ` slos @ 2016-04-15 15:47 ` slos 2016-04-15 16:30 ` Dmitry A. Kazakov 1 sibling, 1 reply; 37+ messages in thread From: slos @ 2016-04-15 15:47 UTC (permalink / raw) Le vendredi 15 avril 2016 17:05:56 UTC+2, Dmitry A. Kazakov a écrit : > On 2016-04-15 12:06, slos wrote: > > > We share some of the vision. > > "Ada for Automation" is a framework with which one can build his own > > control application using Ada. I would not call it a middleware. > > Why not? > > > And MQTT or OPC UA would just connect it to some SCADA or cloud based > > application like one using IBM BlueMix. > > Neither is good for SCADA, especially regarding safety requirements and > performance. > > >> Note that without OPC UA everything could work far better and require > >> far less resources. E.g. having all process data the OPC cannot access > >> because it is too slow to pace with the middleware capable to deliver > >> data at less than 1ms rate and does not properly support > >> push-subscriptions, does not support distributed time stamping, physical > >> units, error states etc. > >> > > I agree that OPC UA does not fit where EtherCAT, Sercos III or PROFINET IRT would. > > OPC was created for office and SCADA / GUI applications access to > > PLC data, not for IO processing. > > Why SCADA or DB server should ever use some other middleware protocols? > The point is that one middleware can stretch from the ERP levels down to > the field. Well, in this case this is no more a middleware. It's an everyware... > But when the middleware is OPC or MQTT you cannot not put it > into a device and expect that working. Yes you can : http://www.hilscher.com/fileadmin/cms_upload/en-US/Resources/pdf/netIC-IOT_Datasheet_10-2015_EN.pdf > This is the reason we must live > with EtherCAT, ProfiNET down there, which are nightmare to any system > integrator. That is not the case. Those standard protocols are designed with lots of goals, among them performance and interoperability. They allow multiple vendors to propose products fitting well together and it works pretty well since years. > That defeats the very idea of a middleware. I don't see why. The middle of what ? Architecture is made with layers and middleware can sit between any two of them. > The real advantage of Ada is that it is scalable from heavy duty to hard > real-time embedded. Yes, hence my choice for "Ada for Automation". > The ugly protocols like XML, HTTP, OPC etc only > hinder developing of safe and efficient systems. Yes but they allow interoperability, and the web and talking to each other whatever browser or platform we use. I think one of the problems of Ada community is a kind of sectarianism or elitism. I agree that Ada has great qualities and could be used with huge benefits in most applications but there is an ocean of already available stuff that is not written in Ada and work anyway. That's what I am trying to do with "Ada for Automation" : gather software components, integrate them in something consistent for a control engineer and create sample applications to start from. If I find components written in Ada, that's great. If they are in C, that's fine too for me. Anyway my day job is C programming and I've been programming PLCs for decades too. Ada is my night language... which I am still learning. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de BR, Stéphane ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 15:47 ` slos @ 2016-04-15 16:30 ` Dmitry A. Kazakov 2016-04-15 22:18 ` slos 2016-04-19 11:51 ` hanslad 0 siblings, 2 replies; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-15 16:30 UTC (permalink / raw) On 2016-04-15 17:47, slos wrote: >> But when the middleware is OPC or MQTT you cannot not put it >> into a device and expect that working. > Yes you can : > http://www.hilscher.com/fileadmin/cms_upload/en-US/Resources/pdf/netIC-IOT_Datasheet_10-2015_EN.pdf It is not a device, it a SBC with an OPC stack in it. We have that too, an ARM board with OPC UA server, no problem whatsoever. Anybody can have it. Now try to sample 8 10kHz channels and subscribe to them through OPC, get the data to a PC and log them with time stamps and no losses. >> This is the reason we must live >> with EtherCAT, ProfiNET down there, which are nightmare to any system >> integrator. > That is not the case. Those standard protocols are designed with > lots of goals, among them performance and interoperability. How does EtherCAT operate with other protocols? > They allow multiple vendors to propose products fitting well > together and it works pretty well since years. Clearly, any protocol is interoperable with itself. This is not interoperability, when multiple vendors can implement it, IMO it is openness. >> That defeats the very idea of a middleware. > I don't see why. The middle of what ? A middle between an application logic and the devices/actuator/sensor/data source logic. The idea of middleware is to be able to develop applications independently on the actual hardware and its configuration directly in the terms of the problem space's variables. > Architecture is made with layers and middleware can sit between any two of them. Yes, that is the application on the one side and data acquisition/control hardware on another. The latter naturally includes networking and other distribution means. A middleware that is not a distributed one is useless for automation. >> The ugly protocols like XML, HTTP, OPC etc only >> hinder developing of safe and efficient systems. > Yes but they allow interoperability, and the web and talking to each > other whatever browser or platform we use. This, again, is not interoperability. Nor it is portability, you probably meant. Web application are *NOT* portable. They require a specific platform called browser. If web "standard" were true standard we would already have hardware browsers instead of software emulators like Firefox. But the "standard" is so bad that it requires permanent patching of the "platform", which prevents developing to make it real hardware. An Ada program is portable in the sense that you can translate it into the machine language of the target platform. Even if the platform is web and machine is browser! See gnoga > I think one of the problems of Ada community is a kind of > sectarianism or elitism. Ada community consists of competent engineers, that shapes it this way. Is it a problem? Maybe it is, but I prefer this problem to others. > I agree that Ada has great qualities and could be used with huge > benefits in most applications but there is an ocean of already available > stuff that is not written in Ada and work anyway. Yes, but that does not make it better than it is. If we only used available stuff, why would we have to program anything? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 16:30 ` Dmitry A. Kazakov @ 2016-04-15 22:18 ` slos 2016-04-16 8:12 ` Dmitry A. Kazakov 2016-04-19 11:51 ` hanslad 1 sibling, 1 reply; 37+ messages in thread From: slos @ 2016-04-15 22:18 UTC (permalink / raw) Le vendredi 15 avril 2016 18:31:00 UTC+2, Dmitry A. Kazakov a écrit : > On 2016-04-15 17:47, slos wrote: > > >> But when the middleware is OPC or MQTT you cannot not put it > >> into a device and expect that working. > > Yes you can : > > http://www.hilscher.com/fileadmin/cms_upload/en-US/Resources/pdf/netIC-IOT_Datasheet_10-2015_EN.pdf > > It is not a device, it a SBC with an OPC stack in it. We have that too, > an ARM board with OPC UA server, no problem whatsoever. Anybody can have it. You have read the data sheet too fast. May be you should consider to read it again. Not only you have OPC UA or MQTT but also on the same medium EtherCAT, Ethernet/IP or PROFINET. So real time data is exchanged via real time protocols and relevant data for cloud application is exchanged with OPC UA or MQTT. > Now try to sample 8 10kHz channels and subscribe to them through OPC, > get the data to a PC and log them with time stamps and no losses. OPC was never designed with this kind of needs in mind. > > >> This is the reason we must live > >> with EtherCAT, ProfiNET down there, which are nightmare to any system > >> integrator. > > > That is not the case. Those standard protocols are designed with > > lots of goals, among them performance and interoperability. > > How does EtherCAT operate with other protocols? You could use Ethernet over EtherCAT. > > They allow multiple vendors to propose products fitting well > > together and it works pretty well since years. > > Clearly, any protocol is interoperable with itself. This is not > interoperability, when multiple vendors can implement it, IMO it is > openness. Please could you give your definition of interoperability? > > >> That defeats the very idea of a middleware. > > I don't see why. The middle of what ? > > A middle between an application logic and the > devices/actuator/sensor/data source logic. So Ada from hardware to application. All or nothing ? You'll have to endure frustration. > > The idea of middleware is to be able to develop applications > independently on the actual hardware and its configuration directly in > the terms of the problem space's variables. > > > Architecture is made with layers and middleware can sit between any two of them. > > Yes, that is the application on the one side and data > acquisition/control hardware on another. The latter naturally includes > networking and other distribution means. A middleware that is not a > distributed one is useless for automation. > > >> The ugly protocols like XML, HTTP, OPC etc only > >> hinder developing of safe and efficient systems. > > Yes but they allow interoperability, and the web and talking to each > > other whatever browser or platform we use. > > This, again, is not interoperability. Nor it is portability, you > probably meant. > > Web application are *NOT* portable. They require a specific platform > called browser. > > If web "standard" were true standard we would already have hardware > browsers instead of software emulators like Firefox. > > But the "standard" is so bad that it requires permanent patching of the > "platform", which prevents developing to make it real hardware. Standards may evolve and particularly when the technology is quite young. We are not talking of the tables of law. The good thing with software is that it can evolve with the knowledge on the problem at hand. > An Ada program is portable in the sense that you can translate it into > the machine language of the target platform. Even if the platform is web > and machine is browser! See gnoga This is over simplified. Actually Gnoga is in use in "Ada for Automation" and I have already thanked you several times for providing Simple Components. Gnoga allows an Ada application to talk to the browser and provide a GUI to the application. That does not make the Ada application an application running in the browser. > > > I think one of the problems of Ada community is a kind of > > sectarianism or elitism. > > Ada community consists of competent engineers, that shapes it this way. > Is it a problem? Maybe it is, but I prefer this problem to others. Other communities have also competent engineers. They don't write their code in the Ada language but that alone does not make their creation a crap. > > > I agree that Ada has great qualities and could be used with huge > > benefits in most applications but there is an ocean of already available > > stuff that is not written in Ada and work anyway. > > Yes, but that does not make it better than it is. If we only used > available stuff, why would we have to program anything? This is called integration. And the Ada language favors it greatly but may be suffers from a too competent engineers community. I don't consider myself a competent engineer for having used too much technologies and languages to be an expert in any. I am just a support guy interested in development. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de BR, Stéphane ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 22:18 ` slos @ 2016-04-16 8:12 ` Dmitry A. Kazakov 2016-04-16 17:48 ` slos 0 siblings, 1 reply; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-16 8:12 UTC (permalink / raw) On 2016-04-16 00:18, slos wrote: > Le vendredi 15 avril 2016 18:31:00 UTC+2, Dmitry A. Kazakov a écrit : >> On 2016-04-15 17:47, slos wrote: >> >>>> But when the middleware is OPC or MQTT you cannot not put it >>>> into a device and expect that working. >>> Yes you can : >>> http://www.hilscher.com/fileadmin/cms_upload/en-US/Resources/pdf/netIC-IOT_Datasheet_10-2015_EN.pdf >> >> It is not a device, it a SBC with an OPC stack in it. We have that too, >> an ARM board with OPC UA server, no problem whatsoever. Anybody can have it. > You have read the data sheet too fast. May be you should consider to read it again. > Not only you have OPC UA or MQTT but also on the same medium EtherCAT, Ethernet/IP or PROFINET. Of course I read it. It is exactly what all other vendors do, including the firm where I work. Neither the concept nor the hardware is any new. For example, how is it different from an antique SPS equipped by an OPC server and PROFINET? The idea of middleware, predating by decades the "newly discovered" idea of IoT is different. It is getting rid of the gateways like yours: Application <--OPC--> Hilscher <--PROFINET--> ADC terminal to be replaced with: Application <--DDL--> ADC terminal The ADC terminal is a device or "thing" in the IoT Newspeak. The idea is to talk right to the thing. No gateways, just interconnected things. Now, the point I am making is that neither OPC nor MQTT is suitable to serve as the DDL (data-distribution layer) for a middleware stretching from application to the automation devices. Both were originated under impression of desktop office applications rather than real-life process control. > So real time data is exchanged via real time protocols and relevant > data for cloud application is exchanged with OPC UA or MQTT. q.e.d. >> Now try to sample 8 10kHz channels and subscribe to them through OPC, >> get the data to a PC and log them with time stamps and no losses. > OPC was never designed with this kind of needs in mind. Ergo, unsuitable for automation and control. >> How does EtherCAT operate with other protocols? > You could use Ethernet over EtherCAT. Tunneling is not "operating with". You need a gateway, like Hilscher box, to bridge OPC and EtherCAT. Hence, OPC and EtherCAT are not interoperable. >>> They allow multiple vendors to propose products fitting well >>> together and it works pretty well since years. >> >> Clearly, any protocol is interoperable with itself. This is not >> interoperability, when multiple vendors can implement it, IMO it is >> openness. > Please could you give your definition of interoperability? Wikipedia: "Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation" >>> The middle of what ? >> >> A middle between an application logic and the >> devices/actuator/sensor/data source logic. > So Ada from hardware to application. Are you talking about the language of API? The middleware will have API in all languages used in the application area. Most of middlewares do. The language of the implementation is only of the vendor's interest. For us it will be Ada. > Gnoga allows an Ada application to talk to the browser and provide a GUI to the application. > That does not make the Ada application an application running in the browser. Parts of it are certainly running in the browser. >>> I think one of the problems of Ada community is a kind of >>> sectarianism or elitism. >> >> Ada community consists of competent engineers, that shapes it this way. >> Is it a problem? Maybe it is, but I prefer this problem to others. > Other communities have also competent engineers. They don't write > their code in the Ada language but that alone does not make their > creation a crap. Now you are switching the topic towards quality of the software designed in different communities. I am not ready to pass judgment without knowing who are "they" you are talking about. Some "they" produce excellent quality software, other "they" produce exclusively garbage. When "they" = all software developers in the world, then the picture is quite grim, as expected. > I am just a support guy interested in development. I see, less protocols would mean less support work. Worrying about your business? (:-)) Do not. It is a very long way to go, alas... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-16 8:12 ` Dmitry A. Kazakov @ 2016-04-16 17:48 ` slos 2016-04-18 16:33 ` Dmitry A. Kazakov 0 siblings, 1 reply; 37+ messages in thread From: slos @ 2016-04-16 17:48 UTC (permalink / raw) Le samedi 16 avril 2016 10:12:47 UTC+2, Dmitry A. Kazakov a écrit : > On 2016-04-16 00:18, slos wrote: > > Le vendredi 15 avril 2016 18:31:00 UTC+2, Dmitry A. Kazakov a écrit : > >> On 2016-04-15 17:47, slos wrote: > >> > >>>> But when the middleware is OPC or MQTT you cannot not put it > >>>> into a device and expect that working. > >>> Yes you can : > >>> http://www.hilscher.com/fileadmin/cms_upload/en-US/Resources/pdf/netIC-IOT_Datasheet_10-2015_EN.pdf > >> > >> It is not a device, it a SBC with an OPC stack in it. We have that too, > >> an ARM board with OPC UA server, no problem whatsoever. Anybody can have it. > > You have read the data sheet too fast. May be you should consider to read it again. > > Not only you have OPC UA or MQTT but also on the same medium EtherCAT, Ethernet/IP or PROFINET. > > Of course I read it. It is exactly what all other vendors do, including > the firm where I work. Neither the concept nor the hardware is any new. > For example, how is it different from an antique SPS equipped by an OPC > server and PROFINET? > > The idea of middleware, predating by decades the "newly discovered" idea > of IoT is different. It is getting rid of the gateways like yours: > > Application <--OPC--> Hilscher <--PROFINET--> ADC terminal Well, this is not correct. The netIoT is a gateway that gives OEM connectivity : Analog | |PROFINET-------|SPS Control Digital |--netIoT--|Ethernet/IP----|OPC----|Cloud Computed | |EtherCAT-------|MQTT---|Applications Com | Our customer WANTS this kind of connectivity because they SELL their hardware to SPS users who want to get the supposed benefits of Industry 4.0 or IIoT. They may exchange their SPS for your middleware if you go visit them. > > to be replaced with: > > Application <--DDL--> ADC terminal > > The ADC terminal is a device or "thing" in the IoT Newspeak. The idea is > to talk right to the thing. No gateways, just interconnected things. If no gateway is used the ADC has to implement the protocol, whatever it is. > > Now, the point I am making is that neither OPC nor MQTT is suitable to > serve as the DDL (data-distribution layer) for a middleware stretching > from application to the automation devices. Both were originated under > impression of desktop office applications rather than real-life process > control. I agree. That's why they are used on the upper levels. For process control, real time protocols are used. And when you only need to collect data like temperature from large networks protocols like MQTT have some advantages. > > > So real time data is exchanged via real time protocols and relevant > > data for cloud application is exchanged with OPC UA or MQTT. > > q.e.d. > > >> Now try to sample 8 10kHz channels and subscribe to them through OPC, > >> get the data to a PC and log them with time stamps and no losses. > > OPC was never designed with this kind of needs in mind. > > Ergo, unsuitable for automation and control. Again, I have already agreed on that and by the way never said the contrary. > > >> How does EtherCAT operate with other protocols? > > You could use Ethernet over EtherCAT. > > Tunneling is not "operating with". You need a gateway, like Hilscher > box, to bridge OPC and EtherCAT. Hence, OPC and EtherCAT are not > interoperable. > > >>> They allow multiple vendors to propose products fitting well > >>> together and it works pretty well since years. > >> > >> Clearly, any protocol is interoperable with itself. This is not > >> interoperability, when multiple vendors can implement it, IMO it is > >> openness. > > Please could you give your definition of interoperability? > > Wikipedia: "Interoperability is a property of a product or system, whose > interfaces are completely understood, to work with other products or > systems, present or future, without any restricted access or implementation" This is exactly what open protocols standards are created for. > > >>> The middle of what ? > >> > >> A middle between an application logic and the > >> devices/actuator/sensor/data source logic. > > So Ada from hardware to application. > > Are you talking about the language of API? The middleware will have API > in all languages used in the application area. Most of middlewares do. > > The language of the implementation is only of the vendor's interest. For > us it will be Ada. > > > Gnoga allows an Ada application to talk to the browser and provide a GUI to the application. > > That does not make the Ada application an application running in the browser. > > Parts of it are certainly running in the browser. No. No Ada code is compiled to be executed in the browser. Gnoga is not an Ada to JavaScript compiler. > > >>> I think one of the problems of Ada community is a kind of > >>> sectarianism or elitism. > >> > >> Ada community consists of competent engineers, that shapes it this way. > >> Is it a problem? Maybe it is, but I prefer this problem to others. > > > Other communities have also competent engineers. They don't write > > their code in the Ada language but that alone does not make their > > creation a crap. > > Now you are switching the topic towards quality of the software designed > in different communities. > > I am not ready to pass judgment without knowing who are "they" you are > talking about. Some "they" produce excellent quality software, other > "they" produce exclusively garbage. > > When "they" = all software developers in the world, then the picture is > quite grim, as expected. > > > I am just a support guy interested in development. > > I see, less protocols would mean less support work. Worrying about your > business? (:-)) Do not. It is a very long way to go, alas... I don't worry about my business. If I could convince you to connect your middleware to our cifX driver you would be able to talk to most devices of the automation field. Your middleware could interest more people since being more capable. And Hilscher would sell more boards. Not me. ;-) When you need some training or support I will be glad to provide it to you. Let's be friends, no enemy. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de BR, Stéphane ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-16 17:48 ` slos @ 2016-04-18 16:33 ` Dmitry A. Kazakov 0 siblings, 0 replies; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-18 16:33 UTC (permalink / raw) On 2016-04-16 19:48, slos wrote: > If no gateway is used the ADC has to implement the protocol, whatever it is.. The IoT protocol obviously, that is the idea of. >> Now, the point I am making is that neither OPC nor MQTT is suitable to >> serve as the DDL (data-distribution layer) for a middleware stretching >> from application to the automation devices. Both were originated under >> impression of desktop office applications rather than real-life process >> control. > I agree. That's why they are used on the upper levels. > For process control, real time protocols are used. And that defeats the idea of IoT which presumes a flat network of things. One cannot have both, a layered infrastructure of application protocols (dependency on the area, not to be confused with OSI layers) and an internet of things. I don't argue for or against either, I only make an observation that OPC and MQTT do not fit into the latter architecture. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-15 16:30 ` Dmitry A. Kazakov 2016-04-15 22:18 ` slos @ 2016-04-19 11:51 ` hanslad 2016-04-19 12:43 ` Dmitry A. Kazakov 1 sibling, 1 reply; 37+ messages in thread From: hanslad @ 2016-04-19 11:51 UTC (permalink / raw) I think the OPC UA discussion is interesting. Possibly not the right forum but anyway: > > It is not a device, it a SBC with an OPC stack in it. We have that too, > an ARM board with OPC UA server, no problem whatsoever. Anybody can have it. > > Now try to sample 8 10kHz channels and subscribe to them through OPC, > get the data to a PC and log them with time stamps and no losses. I can't see what in the OPC UA standard from OPC Foundation that doesn't make this possible? Having in mind that OPC UA is just a protocol standard and given that you have hardware to cope with the problem, there should be no problem to create a subscription with monitoring items on the items that holds the value of the channels(In my lack of understanding what a channel is, I have regarded this as something with a value, represented as a double, changing 10000 times a second). Setting up a subscription with the requested sample rate and, say, a publishing interval of 1 sec gives a close to 16 MBit/s binary encoded stream. That's not to difficult to handle for any system? Also, there is pub-sub is added to OPC UA in the upcoming 1.04 version of the standard. I cant' see why OPC UA shouldn't bee fit for device to device communication, both real-time-, information model-(for interoperability) and security-wise? Regards Hans Petter ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-19 11:51 ` hanslad @ 2016-04-19 12:43 ` Dmitry A. Kazakov 2016-04-19 12:59 ` high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released) G.B. 2016-04-19 13:43 ` Simple Components 4.12 with MQTT implementation released hanslad 0 siblings, 2 replies; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-19 12:43 UTC (permalink / raw) On 19/04/2016 13:51, hanslad@gmail.com wrote: > I think the OPC UA discussion is interesting. Possibly not the right forum but anyway: > >> >> It is not a device, it a SBC with an OPC stack in it. We have that too, >> an ARM board with OPC UA server, no problem whatsoever. Anybody can have it. >> >> Now try to sample 8 10kHz channels and subscribe to them through OPC, >> get the data to a PC and log them with time stamps and no losses. > > I can't see what in the OPC UA standard from OPC Foundation that > doesn't make this possible? So far it cannot. > Having in mind that OPC UA is just a protocol standard and given > that you have hardware to cope with the problem, there should be no problem > to create a subscription with monitoring items on the items that holds > the value of the channels(In my lack of understanding what a channel is, > I have regarded this as something with a value, represented as a double, > changing 10000 times a second). Sort of. It is a value and a time stamp, because data are oversampled. There is no way a conventional OS could respond to each change at this rate. > Setting up a subscription with the > requested sample rate and, say, a publishing interval of 1 sec gives a > close to 16 MBit/s binary encoded stream. I don't understand what you mean. In the systems we deploy there is no publishing interval. Updates are sent to the subscribers when become available. Due to oversampling it is usually several updates per channel at once (if the QoS of subscription requires this). The DDL protocol ensures ordering and time stamping, so that the subscriber can sort out the data, e.g. for logging or other processing. > That's not to difficult to handle for any system? That depends on the method of handling. You cannot handle it if you react to each change synchronously. One of the differences of the middleware we use to OPC servers is that producers are never blocked and practically nothing is serviced synchronously. All variables are "history" data in OPC terms (if they make it working some day). > Also, there is pub-sub is added to OPC UA in the upcoming 1.04 > version of the standard. I cant' see why OPC UA shouldn't bee fit for > device todevice communication, both real-time-, information model-(for > interoperability) and security-wise? OPC is about 20 years old and still does not do basic stuff. There is a lot of details how publishing-subscribing service has to be implemented to deal with the use cases of automation and control problems. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released) 2016-04-19 12:43 ` Dmitry A. Kazakov @ 2016-04-19 12:59 ` G.B. 2016-04-19 13:35 ` Dmitry A. Kazakov 2016-04-19 13:43 ` Simple Components 4.12 with MQTT implementation released hanslad 1 sibling, 1 reply; 37+ messages in thread From: G.B. @ 2016-04-19 12:59 UTC (permalink / raw) On 19.04.16 14:43, Dmitry A. Kazakov wrote: > It is a value and a time stamp, because data are oversampled. There is > no way a conventional OS could respond to each change at this rate. Is it possible to have a volatile variable T representing some point in time and a CAS discipline so that 1. there is one task that updates T at regular intervals and 2. another task that reads T for stamping items more frequently than the first would write updates? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released) 2016-04-19 12:59 ` high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released) G.B. @ 2016-04-19 13:35 ` Dmitry A. Kazakov 2016-04-20 7:55 ` Georg Bauhaus 0 siblings, 1 reply; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-19 13:35 UTC (permalink / raw) On 19/04/2016 14:59, G.B. wrote: > On 19.04.16 14:43, Dmitry A. Kazakov wrote: >> It is a value and a time stamp, because data are oversampled. There is >> no way a conventional OS could respond to each change at this rate. > > Is it possible to have a volatile variable T representing > some point in time and a CAS discipline so that > > 1. there is one task that updates T at regular intervals and > > 2. another task that reads T for stamping items more frequently > than the first would write updates? It is an interesting question. Do you mean CAS = content-addressable storage? I don't think it were possible to do. We use a blackboard storage with a notification event signaling that the local consumer tasks may inspect the latest contents without blocking the producers. The oversampling hardware deploys a buffer that can be read out. It basically is a soft of blackboard too. Clearly ADCs run asynchronously most of the time and there is no way you would wait for an ADC, it would take to much time. So pull methods do not work in most cases. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released) 2016-04-19 13:35 ` Dmitry A. Kazakov @ 2016-04-20 7:55 ` Georg Bauhaus 2016-04-20 8:48 ` Dmitry A. Kazakov 0 siblings, 1 reply; 37+ messages in thread From: Georg Bauhaus @ 2016-04-20 7:55 UTC (permalink / raw) On 19.04.16 15:35, Dmitry A. Kazakov wrote: > On 19/04/2016 14:59, G.B. wrote: >> On 19.04.16 14:43, Dmitry A. Kazakov wrote: >>> It is a value and a time stamp, because data are oversampled. There is >>> no way a conventional OS could respond to each change at this rate. >> >> Is it possible to have a volatile variable T representing >> some point in time and a CAS discipline so that >> >> 1. there is one task that updates T at regular intervals and >> >> 2. another task that reads T for stamping items more frequently >> than the first would write updates? > > It is an interesting question. Do you mean CAS = content-addressable storage? Coincidence! While I'd expect the time storing variable to be located in some kind of privileged location, I had meant CAS to refer to some thread-safe update mechanism. I now notice that maybe mutex via volatile storage might already be in place. All of this would be based on the assumption that reading the time via system is much more costly than just reading a volatile variable, while perhaps adding a sequence number for ordering the stamped items within one time frame. Also separates problems and solutions, as you indicated. Nothing new, I guess. (For a case at hand, the measuring devices will be collecting only about 10-200 signals/second, yet mustn't have their batteries emptied.) ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released) 2016-04-20 7:55 ` Georg Bauhaus @ 2016-04-20 8:48 ` Dmitry A. Kazakov 0 siblings, 0 replies; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-20 8:48 UTC (permalink / raw) On 20/04/2016 09:55, Georg Bauhaus wrote: > On 19.04.16 15:35, Dmitry A. Kazakov wrote: >> On 19/04/2016 14:59, G.B. wrote: >>> On 19.04.16 14:43, Dmitry A. Kazakov wrote: >>>> It is a value and a time stamp, because data are oversampled. There is >>>> no way a conventional OS could respond to each change at this rate. >>> >>> Is it possible to have a volatile variable T representing >>> some point in time and a CAS discipline so that >>> >>> 1. there is one task that updates T at regular intervals and >>> >>> 2. another task that reads T for stamping items more frequently >>> than the first would write updates? >> >> It is an interesting question. Do you mean CAS = content-addressable >> storage? > > Coincidence! While I'd expect the time storing variable to be located > in some kind of privileged location, I had meant CAS to refer to some > thread-safe update mechanism. I now notice that maybe mutex via volatile > storage might already be in place. The method I am using is of a lock-free blackboard. There is single producer that writes onto it without locking. Consumers scan the blackboard without locking starting from the last read position = sequence number. They detect losses through the sequence number going out of the bounds. > All of this would be based on the assumption that reading the time via > system is much more costly than just reading a volatile variable, > while perhaps adding a sequence number for ordering the stamped items > within one time frame. Also separates problems and solutions, as you > indicated. Nothing new, I guess. When a bunch of oversampled values are read, their time stamps are reconstructed, if the hardware is unable to stamp the values. Then the values and stamps are written into the blackboard. So the consumers never need not to care of the way the data came there in first place. > (For a case at hand, the measuring devices will be collecting only > about 10-200 signals/second, yet mustn't have their batteries emptied.) Another user case is when the mobile network traffic must paid for. The producer usually filters out updates which are within the tolerance band in order to reduce the traffic. Everything is running in the push mode, of course. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-19 12:43 ` Dmitry A. Kazakov 2016-04-19 12:59 ` high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released) G.B. @ 2016-04-19 13:43 ` hanslad 2016-04-19 16:39 ` Dmitry A. Kazakov 1 sibling, 1 reply; 37+ messages in thread From: hanslad @ 2016-04-19 13:43 UTC (permalink / raw) > >> It is not a device, it a SBC with an OPC stack in it. We have that too, > >> an ARM board with OPC UA server, no problem whatsoever. Anybody can have it. > >> > >> Now try to sample 8 10kHz channels and subscribe to them through OPC, > >> get the data to a PC and log them with time stamps and no losses. > > > > I can't see what in the OPC UA standard from OPC Foundation that > > doesn't make this possible? > > So far it cannot. The case was reading data from 8 10KHz channels into a log . Nothing in the OPC UA protocol that hinder this. > > > Having in mind that OPC UA is just a protocol standard and given > > that you have hardware to cope with the problem, there should be no problem > > to create a subscription with monitoring items on the items that holds > > the value of the channels(In my lack of understanding what a channel is, > > I have regarded this as something with a value, represented as a double, > > changing 10000 times a second). > > Sort of. It is a value and a time stamp, because data are oversampled. > There is no way a conventional OS could respond to each change at this rate. OPC UA is not tied to any OS platform. Our stack works fine on VxWorks, for instance. > > > Setting up a subscription with the > > requested sample rate and, say, a publishing interval of 1 sec gives a > > close to 16 MBit/s binary encoded stream. > > I don't understand what you mean. In the systems we deploy there is no > publishing interval. Updates are sent to the subscribers when become > available. Due to oversampling it is usually several updates per channel > at once (if the QoS of subscription requires this). The DDL protocol > ensures ordering and time stamping, so that the subscriber can sort out > the data, e.g. for logging or other processing. Well that is exactly how OPC UA works, you request data with a required sample rate, published at a required rate. > > > That's not to difficult to handle for any system? > > That depends on the method of handling. You cannot handle it if you > react to each change synchronously. One of the differences of the > middleware we use to OPC servers is that producers are never blocked and > practically nothing is serviced synchronously. All variables are > "history" data in OPC terms (if they make it working some day). For the logging purpose, why should you react synchronously? As long as the system that generates the data has buffers to handle data storage between each OPC UA publish request response, this will work fine. > > > Also, there is pub-sub is added to OPC UA in the upcoming 1.04 > > version of the standard. I cant' see why OPC UA shouldn't bee fit for > > device todevice communication, both real-time-, information model-(for > > interoperability) and security-wise? > > OPC is about 20 years old and still does not do basic stuff. There is a > lot of details how publishing-subscribing service has to be implemented > to deal with the use cases of automation and control problems. You are mixing classic OPC and OPC UA, I think. Regards Hans Petter ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Simple Components 4.12 with MQTT implementation released 2016-04-19 13:43 ` Simple Components 4.12 with MQTT implementation released hanslad @ 2016-04-19 16:39 ` Dmitry A. Kazakov 0 siblings, 0 replies; 37+ messages in thread From: Dmitry A. Kazakov @ 2016-04-19 16:39 UTC (permalink / raw) On 19/04/2016 15:43, hanslad@gmail.com wrote: >>>> It is not a device, it a SBC with an OPC stack in it. We have that too, >>>> an ARM board with OPC UA server, no problem whatsoever. Anybody can have it. >>>> >>>> Now try to sample 8 10kHz channels and subscribe to them through OPC, >>>> get the data to a PC and log them with time stamps and no losses. >>> >>> I can't see what in the OPC UA standard from OPC Foundation that >>> doesn't make this possible? >> >> So far it cannot. > > The case was reading data from 8 10KHz channels into a log . Nothing > in the OPC UA protocol that hinder this. No, the data are read into the local system and handled there. They also are distributed among the remote systems (remote subscribers). Some remote systems log data, without loss. >>> Having in mind that OPC UA is just a protocol standard and given >>> that you have hardware to cope with the problem, there should be no problem >>> to create a subscription with monitoring items on the items that holds >>> the value of the channels(In my lack of understanding what a channel is, >>> I have regarded this as something with a value, represented as a double, >>> changing 10000 times a second). >> >> Sort of. It is a value and a time stamp, because data are oversampled. >> There is no way a conventional OS could respond to each change at this rate. > > OPC UA is not tied to any OS platform. Our stack works fine on VxWorks, for instance. That does not change much, of course we have VxWorks as one target. But VxWorks could not handle that either. It is not so drastically better than say Linux in terms of latencies. Oversampling is a very special case but it illustrates the services a middleware must provide. > Well that is exactly how OPC UA works, you request data with a > required sample rate, published at a required rate. Who requests data? An OPC client? The problem with actual OPC UA is that it is in the pull mode. There is no chance to get almost anything working in automation and control through pull without hard time synchronization, with is of course, impossible in a loosely coupled networking system. >>> That's not to difficult to handle for any system? >> >> That depends on the method of handling. You cannot handle it if you >> react to each change synchronously. One of the differences of the >> middleware we use to OPC servers is that producers are never blocked and >> practically nothing is serviced synchronously. All variables are >> "history" data in OPC terms (if they make it working some day). > > For the logging purpose, why should you react synchronously? As long > as the system that generates the data has buffers to handle data storage > between each OPC UA publish request response, this will work fine. It is the DDL which has to buffer published state changes for the subscribers, not the application. The application must get all changes if it requested that level of QoS. >>> Also, there is pub-sub is added to OPC UA in the upcoming 1.04 >>> version of the standard. I cant' see why OPC UA shouldn't bee fit for >>> device todevice communication, both real-time-, information model-(for >>> interoperability) and security-wise? >> >> OPC is about 20 years old and still does not do basic stuff. There is a >> lot of details how publishing-subscribing service has to be implemented >> to deal with the use cases of automation and control problems. > > You are mixing classic OPC and OPC UA, I think. They failed each other attempt, why should they succeed now? OPC UA started with a wrong architecture and wrong assumptions right away. I don't believe it can be fixed, because there is too much power behind OPC. OPC is sold and accepted as an overall solution even if it is not and never was. Nobody cares, why should anybody improve anything if the thing is already sold? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2016-04-20 8:48 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-12 18:48 Simple Components 4.12 with MQTT implementation released Dmitry A. Kazakov 2016-04-14 8:54 ` slos 2016-04-14 10:07 ` Dmitry A. Kazakov 2016-04-14 13:01 ` slos 2016-04-14 16:19 ` Björn Lundin 2016-04-14 16:49 ` Dmitry A. Kazakov 2016-04-14 20:57 ` Björn Lundin 2016-04-14 21:29 ` slos 2016-04-14 21:20 ` slos 2016-04-15 11:29 ` Björn Lundin 2016-04-15 12:13 ` slos 2016-04-14 16:47 ` Dmitry A. Kazakov 2016-04-14 21:03 ` Björn Lundin 2016-04-14 21:30 ` slos 2016-04-15 8:01 ` Dmitry A. Kazakov 2016-04-15 10:06 ` slos 2016-04-15 11:12 ` Björn Lundin 2016-04-15 15:05 ` Dmitry A. Kazakov 2016-04-15 15:17 ` slos 2016-04-15 15:34 ` Dmitry A. Kazakov 2016-04-15 16:00 ` slos 2016-04-15 16:39 ` Dmitry A. Kazakov 2016-04-15 22:39 ` slos 2016-04-15 15:47 ` slos 2016-04-15 16:30 ` Dmitry A. Kazakov 2016-04-15 22:18 ` slos 2016-04-16 8:12 ` Dmitry A. Kazakov 2016-04-16 17:48 ` slos 2016-04-18 16:33 ` Dmitry A. Kazakov 2016-04-19 11:51 ` hanslad 2016-04-19 12:43 ` Dmitry A. Kazakov 2016-04-19 12:59 ` high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released) G.B. 2016-04-19 13:35 ` Dmitry A. Kazakov 2016-04-20 7:55 ` Georg Bauhaus 2016-04-20 8:48 ` Dmitry A. Kazakov 2016-04-19 13:43 ` Simple Components 4.12 with MQTT implementation released hanslad 2016-04-19 16:39 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox