Simple Components 4.12 with MQTT implementation released

Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[Björn Lundin]

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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[Björn Lundin]

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

Re: Simple Components 4.12 with MQTT implementation released

[Björn Lundin]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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.

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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"

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[Björn Lundin]

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

Re: Simple Components 4.12 with MQTT implementation released

[Björn Lundin]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[slos]

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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[hanslad]

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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released)

[G.B.]

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?

Re: high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released)

[Dmitry A. Kazakov]

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

Re: Simple Components 4.12 with MQTT implementation released

[hanslad]

> >> 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

Re: Simple Components 4.12 with MQTT implementation released

[Dmitry A. Kazakov]

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

Re: high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released)

[Georg Bauhaus]

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.)

Re: high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released)

[Dmitry A. Kazakov]

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