Ada for Automation

Ada for Automation

[slos]

Hello,

"Ada for Automation" (A4A in short) is a framework, for designing industrial automation applications using the Ada language. It uses the libmodbus library to allow building a Modbus TCP client or server, or a Modbus RTU master. It can also use Hilscher communication boards allowing to communicate on field buses like AS-Interface, CANopen, CC-Link, DeviceNet, PROFIBUS, EtherCAT, Ethernet/IP, Modbus TCP, PROFINET, Sercos III, POWERLINK, or VARAN.

The code is in English but the documentation is in French, for the moment...
I'd like to augment it before translation. To much work on the table for now.
But there is plenty of images and code, and I guess you know how to auto-magically translate the parts you would feel interest for.

Thanks to Ada, it is working on Microsoft Windows, Linux and Linux with PREMPT_RT patches, down to the millisecond cycle time.

Thanks to GtkAda it can be built with a GUI.
It can be built without of course.

For more information :
http://slo-ist.fr/ada4autom

I have already posted some questions on this list and most have been answered, making the project get where it is now, so I have to thank you again.

It works rather nicely but it would be fantastic if some experienced person would review the code and give me some feedback on the design, the bindings, the code quality... I'm a lonely Ada programmer, and I miss feedback.

Of course, I am interested in any collaboration around this matter.
So, do not hesitate to get in touch when you have some real case.

There is a forum where users are expected to meet:
http://forum.slo-ist.fr/index.php

Thanks in advance.

Best Regards,
Stéphane
http://slo-ist.fr

Re: Ada for Automation

[Dmitry A. Kazakov]

On Thu, 6 Nov 2014 03:14:43 -0800 (PST), slos wrote:

First of all, congratulate and thank for the efforts.

Don't mind a little bit critique which follows.

> "Ada for Automation" (A4A in short) is a framework, for designing
> industrial automation applications using the Ada language. It uses the
> libmodbus library to allow building a Modbus TCP client or server, or a
> Modbus RTU master.

> It can also use Hilscher communication boards allowing
> to communicate on field buses like AS-Interface, CANopen, CC-Link,
> DeviceNet, PROFIBUS, EtherCAT, Ethernet/IP, Modbus TCP, PROFINET, Sercos
> III, POWERLINK, or VARAN.

In other words it does not implement the corresponding stacks? E.g.
EtherCAT master.

Regarding communication boards, they are not very useful. I can guarantee
you that the same EtherCAT would be impossible to talk to using such a
board. The protocol requires a very complicated initialization to talk even
with relatively simple slaves. You might be able to connect a simple
analogue I/O terminal, but nothing beyond that. Even TwinCAT, which is
vendor's tool does not support everything. Our EtherCAT master does, almost
(:-)).

So, my advice would be to implement these stacks natively. Yes, it is a
huge amount of work and you will need community support.

Even CANOpen master is many thousands times more complex than ModBus +
support of various CAN controllers under various OSes.

EtherCAT master is thousands times more complex than CANOpen + raw Ethernet
drivers needed for Windows.

This is not one-man job.

> Thanks to GtkAda it can be built with a GUI.
> It can be built without of course.

Do you mix data acquisition and distribution middleware with the GUI? That
is not a good idea, generally. It is better to keep them separate. Which is
a serious architectural problem how to communicate between the middleware
dealing with the hardware, providing publisher-subscriber services and
various clients. GUI is only one of them. Inter-process communication, DLLs
are all system-dependent. No solution is scalable and portable, meets
real-time requirements. It is a very difficult problem to resolve.
 
> It works rather nicely but it would be fantastic if some experienced
> person would review the code and give me some feedback on the design, the
> bindings, the code quality... I'm a lonely Ada programmer, and I miss
> feedback.
> 
> Of course, I am interested in any collaboration around this matter.
> So, do not hesitate to get in touch when you have some real case.

We do the same stuff, but it is a commercial product. So I cannot do that
on ethical and contractual grounds, sorry.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for Automation

[slos]

Le jeudi 6 novembre 2014 14:31:15 UTC+1, Dmitry A. Kazakov a écrit :
> On Thu, 6 Nov 2014 03:14:43 -0800 (PST), slos wrote:
> 
> First of all, congratulate and thank for the efforts.
Thanks Dmitry. You have been inspirational.

> 
> Don't mind a little bit critique which follows.
I am fine with critique, I can stand it and even appreciate it.

> 
> > "Ada for Automation" (A4A in short) is a framework, for designing
> > industrial automation applications using the Ada language. It uses the
> > libmodbus library to allow building a Modbus TCP client or server, or a
> > Modbus RTU master.
> 
> > It can also use Hilscher communication boards allowing
> > to communicate on field buses like AS-Interface, CANopen, CC-Link,
> > DeviceNet, PROFIBUS, EtherCAT, Ethernet/IP, Modbus TCP, PROFINET, Sercos
> > III, POWERLINK, or VARAN.
> 
> In other words it does not implement the corresponding stacks? E.g.
> EtherCAT master.
No, as you say later on, "Ada for Automation" being for the moment a one-person project, I cannot even think about not using what is available or reinventing the wheel.
So it uses libmodbus and Hilscher communication boards.
I can even imagine writing a binding for OpenPOWERLINK but it won't be soon I am afraid.
And of course, if someone cares about other solutions, it's an open source project and I will be glad to include any contribution.

> 
> Regarding communication boards, they are not very useful.
Of course, since I am the support guy in France for the Hilscher company, I cannot let you say such a thing without reaction.

Hilscher is on this market since 1986, let's say since the birth of field buses, and has been very successful doing that.

Hilscher products are used by major players in the automation field and their products are found everywhere from encoders to drives, PLCs to HMIs.

> I can guarantee you that the same EtherCAT would be impossible to talk to
> using such a board.
Well, it happens everyday though.

> The protocol requires a very complicated initialization to talk even
> with relatively simple slaves. You might be able to connect a simple
> analogue I/O terminal, but nothing beyond that. Even TwinCAT, which is
> vendor's tool does not support everything. Our EtherCAT master does, almost
> (:-)).
> 
Yes, that's true. Industrial protocols tend to be more and more complex because the world is getting more and more complex.

> So, my advice would be to implement these stacks natively.
That is surprising after reading what you have said just above.

> Yes, it is a huge amount of work and you will need community support.
Or an Hilscher board.

> 
> Even CANOpen master is many thousands times more complex than ModBus +
> support of various CAN controllers under various OSes.
I know.

> 
> EtherCAT master is thousands times more complex than CANOpen + raw Ethernet
> drivers needed for Windows.
Yes I know.
There was once an open source stack but it is not available because one need buying a licence from ETG.
When buying an Hilscher board, the stack is running on the board, under Hilscher's RT OS rcX, and we provide drivers for several OSes and a C Toolkit as source code for your not supported OS.
And of course Hilscher provides the Configuration Tool SYCON.net.

> 
> This is not one-man job.
More than two hundred people are working at Hilscher, creating the communication solutions that "Ada for Automation" users would need.
Right now, you can start on a PC with any format and down to the embedded market using modules with same API.

> 
> > Thanks to GtkAda it can be built with a GUI.
> > It can be built without of course.
> 
> Do you mix data acquisition and distribution middleware with the GUI?
No, this is not mixed.
Tasks are employed dealing with acquisition, processing, and GUI but they are interfaced using protected types.

> That
> is not a good idea, generally. It is better to keep them separate. Which is
> a serious architectural problem how to communicate between the middleware
> dealing with the hardware, providing publisher-subscriber services and
> various clients. GUI is only one of them. Inter-process communication, DLLs
> are all system-dependent. No solution is scalable and portable, meets
> real-time requirements. It is a very difficult problem to resolve.
>  
> > It works rather nicely but it would be fantastic if some experienced
> > person would review the code and give me some feedback on the design, the
> > bindings, the code quality... I'm a lonely Ada programmer, and I miss
> > feedback.
> > 
> > Of course, I am interested in any collaboration around this matter.
> > So, do not hesitate to get in touch when you have some real case.
> 
> We do the same stuff, but it is a commercial product. So I cannot do that
> on ethical and contractual grounds, sorry.
There are plenty of commercial solutions already available like WinAC, CoDeSys, PROCONOS, ISaGRAF... to create automation solutions, none in Ada.

I think there is some room left between automation and industrial computing where the languages used in automation (IEC 61131-3) make it hard to create evolved applications and where the C/C++ languages are not easy to master for automation engineers. And we know what happens when one does not master the tool he uses.

Ada seems to fit perfectly here to me.

>  
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de


Best Regards,
Stéphane
http://slo-ist.fr

Re: Ada for Automation

[Dmitry A. Kazakov]

On Thu, 6 Nov 2014 06:43:03 -0800 (PST), slos wrote:

> Le jeudi 6 novembre 2014 14:31:15 UTC+1, Dmitry A. Kazakov a écrit :
>> On Thu, 6 Nov 2014 03:14:43 -0800 (PST), slos wrote:
>> 
>> Regarding communication boards, they are not very useful.
> Of course, since I am the support guy in France for the Hilscher company,
> I cannot let you say such a thing without reaction.
> 
> Hilscher is on this market since 1986, let's say since the birth of field
> buses, and has been very successful doing that.
> 
> Hilscher products are used by major players in the automation field and
> their products are found everywhere from encoders to drives, PLCs to HMIs.

I know Hilscher. It is not specific to their product. In my view such
boards is a wrong solution, designed mainly for vendor lock reasons not for
technical reasons.

Don't you find it strange that you'd need a special hardware to communicate
devices designed to be Ethernet-compatible? Why don't you need a board to
communicate ModBus? Telnet? HTTP?

>> The protocol requires a very complicated initialization to talk even
>> with relatively simple slaves. You might be able to connect a simple
>> analogue I/O terminal, but nothing beyond that. Even TwinCAT, which is
>> vendor's tool does not support everything. Our EtherCAT master does, almost
>> (:-)).
>> 
> Yes, that's true. Industrial protocols tend to be more and more complex
> because the world is getting more and more complex.

Not really. All of them except very few are quite poorly designed. There is
nothing in the world that can justify the enormous complexity of EtherCAT.
It is simply wrong design all way up from the lowest transport level, which
itself is nice and elegant. It looks like EtherCAT was designed by
different people. The rest of EtherCAT layers is garbage with anything done
wrong, what could be done wrong. It complicates everything, slaves,
masters. It does not support auto-configuration as proclaimed. It has a
huge and absolutely unnecessary initialization delay. Distributed clock is
broken. There is no diagnostics whatsoever and so on.

>> So, my advice would be to implement these stacks natively.
> That is surprising after reading what you have said just above.

There is no other way putting it into a small board, e.g. an ARM-based
board. And, IMO, you will not attract much community support if special,
expensive, proprietary hardware will be required. People expect it working
on a $100 board with no extra costs.

We can safely project that next generations of sensors and actuators will
be much smaller than Beckhoff terminals and fully Ethernet-capable which
will bring death to GPIO. In this context pure Ada solutions have bright
future, IMO.

>> Yes, it is a huge amount of work and you will need community support.
> Or an Hilscher board.

... or National Instruments, or Siemens, or Vector AG, or ETAS etc. I don't
believe you could gather much interest in that. Hobbyists won't go into a
vendor lock. Professionals will stick to paid services and complete
solutions.

> There was once an open source stack but it is not available because one
> need buying a licence from ETG.

These stacks are unusable as they implement less than 5% of what is
actually needed to handle complex EtherCAT slaves like oversampling
analogue inputs or incremental encoders.

The purpose of such stacks is to use them as a starting point for a
customized single-purpose system.

That is not the case for a "universal" automation system. You need to go
all way up to the application level leaving it configurable for each
combination of slaves, for each operation mode etc. You must support
interaction between hardware of different origin, e.g. signaling EtherCAT
frames by CAN telegrams etc. It is a different world.

>> This is not one-man job.
> More than two hundred people are working at Hilscher, creating the
> communication solutions that "Ada for Automation" users would need.
> Right now, you can start on a PC with any format and down to the embedded
> market using modules with same API.

Same here. Less people, though.

>>> Thanks to GtkAda it can be built with a GUI.
>>> It can be built without of course.
>> 
>> Do you mix data acquisition and distribution middleware with the GUI?
> No, this is not mixed.
> Tasks are employed dealing with acquisition, processing, and GUI but they
> are interfaced using protected types.

Monolithic design. It is all OK for an embedded system, but barely
acceptable for a medium-scale automation subsystem running on a PC with
components being independent processes. Protected objects cannot cross
process borders. You don't want to have it in single process for many
reasons.

>> That
>> is not a good idea, generally. It is better to keep them separate. Which is
>> a serious architectural problem how to communicate between the middleware
>> dealing with the hardware, providing publisher-subscriber services and
>> various clients. GUI is only one of them. Inter-process communication, DLLs
>> are all system-dependent. No solution is scalable and portable, meets
>> real-time requirements. It is a very difficult problem to resolve.
>>  
>>> It works rather nicely but it would be fantastic if some experienced
>>> person would review the code and give me some feedback on the design, the
>>> bindings, the code quality... I'm a lonely Ada programmer, and I miss
>>> feedback.
>>> 
>>> Of course, I am interested in any collaboration around this matter.
>>> So, do not hesitate to get in touch when you have some real case.
>> 
>> We do the same stuff, but it is a commercial product. So I cannot do that
>> on ethical and contractual grounds, sorry.
> There are plenty of commercial solutions already available like WinAC,
> CoDeSys, PROCONOS, ISaGRAF... to create automation solutions, none in Ada.

Ours (its embeddable variant) is all in Ada. (:-))

> I think there is some room left between automation and industrial
> computing where the languages used in automation (IEC 61131-3) make it
> hard to create evolved applications and where the C/C++ languages are not
> easy to master for automation engineers. And we know what happens when
> one does not master the tool he uses.
> 
> Ada seems to fit perfectly here to me.

Yes, but not perfect. Issues of distribution and modularity are addressed
in a way that is not very suitable for automation systems. Not that there
exists any language that does it better, but still.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for Automation

[slos]

Le jeudi 6 novembre 2014 18:22:19 UTC+1, Dmitry A. Kazakov a écrit :
> On Thu, 6 Nov 2014 06:43:03 -0800 (PST), slos wrote:
> 
> > Le jeudi 6 novembre 2014 14:31:15 UTC+1, Dmitry A. Kazakov a écrit :
> >> On Thu, 6 Nov 2014 03:14:43 -0800 (PST), slos wrote:
> >> 
> >> Regarding communication boards, they are not very useful.
> > Of course, since I am the support guy in France for the Hilscher company,
> > I cannot let you say such a thing without reaction.
> > 
> > Hilscher is on this market since 1986, let's say since the birth of field
> > buses, and has been very successful doing that.
> > 
> > Hilscher products are used by major players in the automation field and
> > their products are found everywhere from encoders to drives, PLCs to HMIs.
> 
> I know Hilscher. It is not specific to their product. In my view such
> boards is a wrong solution, designed mainly for vendor lock reasons not for
> technical reasons.
I can't agree here either. Each protocol has pros and cons.
Choice is in customer's hands and is about strategy, economics, market, technique comes at last since often any protocol is ok.
Hilscher offers a wide choice, embedded to PC, most protocols, master or slave, a single API, several drivers and the toolkit.
May be you Dmitry can design a protocol to rule them all but then you'll have to market it and, if it becomes successful, we will implement it.

> 
> Don't you find it strange that you'd need a special hardware to communicate
> devices designed to be Ethernet-compatible? Why don't you need a board to
> communicate ModBus? Telnet? HTTP?
Determinism ? High data throughput ? Synchronization ? What else ?
"Ada for Automation" is Modbus capable thanks to libmodbus. So you need special hardware only when you need other protocols to communicate with devices you have selected.

And what about standardized profiles that allow a customer to pick among different manufacturers the one who provide the right functionality at the right price ? Of course you have to stick to the profile to benefit from that.

There are no such profiles in the Modbus world. Anyone is free to lay down it's own data in the way he likes.

> 
> >> The protocol requires a very complicated initialization to talk even
> >> with relatively simple slaves. You might be able to connect a simple
> >> analogue I/O terminal, but nothing beyond that. Even TwinCAT, which is
> >> vendor's tool does not support everything. Our EtherCAT master does, almost
> >> (:-)).
> >> 
> > Yes, that's true. Industrial protocols tend to be more and more complex
> > because the world is getting more and more complex.
> 
> Not really. All of them except very few are quite poorly designed. There is
> nothing in the world that can justify the enormous complexity of EtherCAT.
> It is simply wrong design all way up from the lowest transport level, which
> itself is nice and elegant. It looks like EtherCAT was designed by
> different people. The rest of EtherCAT layers is garbage with anything done
> wrong, what could be done wrong. It complicates everything, slaves,
> masters. It does not support auto-configuration as proclaimed. It has a
> huge and absolutely unnecessary initialization delay. Distributed clock is
> broken. There is no diagnostics whatsoever and so on.
> 
That's strange. It seems to me that you are putting down the technology you have implemented in your solution.

No technology is perfect but EtherCAT is working quite fine for a number of manufacturers who have chosen it. As already said, they might have chosen it for other reasons than purely technical ones but who knows.

So, over EtherCAT, the application layer is mainly CANopen like for POWERLINK.
CANopen allows to select in the object dictionary of each devices the data that has to be cyclically exchanged. This you cannot do with, let's say, Modbus.

I won't argue on the merits of each protocol, one can find "facts" from any technology vendor. And who am I to tell if such design is broken ? I am not an expert but a support and development guy wanting to learn Ada.

> >> So, my advice would be to implement these stacks natively.
> > That is surprising after reading what you have said just above.
> 
> There is no other way putting it into a small board, e.g. an ARM-based
> board. And, IMO, you will not attract much community support if special,
> expensive, proprietary hardware will be required. People expect it working
> on a $100 board with no extra costs.
Excellent, this is what Hilscher communication solutions are : small boards with a home designed system on chip netX with ARM CPU and special communication units of our own. And since no one is willing to develop for free on those boards all those poorly designed protocols, drivers, and configuration tools, we have work for a while.
 
> 
> We can safely project that next generations of sensors and actuators will
> be much smaller than Beckhoff terminals and fully Ethernet-capable which
> will bring death to GPIO. In this context pure Ada solutions have bright
> future, IMO.
Those terminals are that big because someone has to tighten the screws or the clamps need to bite the cable.

> 
> >> Yes, it is a huge amount of work and you will need community support.
> > Or an Hilscher board.
> 
> ... or National Instruments, or Siemens, or Vector AG, or ETAS etc. I don't
> believe you could gather much interest in that. Hobbyists won't go into a
> vendor lock. Professionals will stick to paid services and complete
> solutions.
Well, if someone is willing to spend some time in binding their API, everyone could then use those boards as well.
Hobbyists can still use Modbus TCP or RTU, that's available for nothing.
Professionals are using IEC 61131-3 PLCs or C/C++. I am just trying to offer an Ada possibility. The choice is theirs again.

> 
> > There was once an open source stack but it is not available because one
> > need buying a licence from ETG.
> 
> These stacks are unusable as they implement less than 5% of what is
> actually needed to handle complex EtherCAT slaves like oversampling
> analogue inputs or incremental encoders.
> 
> The purpose of such stacks is to use them as a starting point for a
> customized single-purpose system.
> 
> That is not the case for a "universal" automation system. You need to go
> all way up to the application level leaving it configurable for each
> combination of slaves, for each operation mode etc. You must support
> interaction between hardware of different origin, e.g. signaling EtherCAT
> frames by CAN telegrams etc. It is a different world.
You know I know, and that's why Hilscher products are useful for a number of customers. If it was that easy, we would do something else.

> 
> >> This is not one-man job.
> > More than two hundred people are working at Hilscher, creating the
> > communication solutions that "Ada for Automation" users would need.
> > Right now, you can start on a PC with any format and down to the embedded
> > market using modules with same API.
> 
> Same here. Less people, though.
> 
> >>> Thanks to GtkAda it can be built with a GUI.
> >>> It can be built without of course.
> >> 
> >> Do you mix data acquisition and distribution middleware with the GUI?
> > No, this is not mixed.
> > Tasks are employed dealing with acquisition, processing, and GUI but they
> > are interfaced using protected types.
> 
> Monolithic design. It is all OK for an embedded system, but barely
> acceptable for a medium-scale automation subsystem running on a PC with
> components being independent processes. Protected objects cannot cross
> process borders. You don't want to have it in single process for many
> reasons.
It works fine this way. I don't want to put in too much complexity, no more than needed. May be your applications need that.
I have learned about PolyORB and DSA and thought that I could have one partition managing the GUI while another managing the process for example but for the moment I want to keep it quite simple.

> 
> >> That
> >> is not a good idea, generally. It is better to keep them separate. Which is
> >> a serious architectural problem how to communicate between the middleware
> >> dealing with the hardware, providing publisher-subscriber services and
> >> various clients. GUI is only one of them. Inter-process communication, DLLs
> >> are all system-dependent. No solution is scalable and portable, meets
> >> real-time requirements. It is a very difficult problem to resolve.
> >>  
> >>> It works rather nicely but it would be fantastic if some experienced
> >>> person would review the code and give me some feedback on the design, the
> >>> bindings, the code quality... I'm a lonely Ada programmer, and I miss
> >>> feedback.
> >>> 
> >>> Of course, I am interested in any collaboration around this matter.
> >>> So, do not hesitate to get in touch when you have some real case.
> >> 
> >> We do the same stuff, but it is a commercial product. So I cannot do that
> >> on ethical and contractual grounds, sorry.
> > There are plenty of commercial solutions already available like WinAC,
> > CoDeSys, PROCONOS, ISaGRAF... to create automation solutions, none in Ada.
> 
> Ours (its embeddable variant) is all in Ada. (:-))
Who is developing the application ? Automation engineers or your team ?

> 
> > I think there is some room left between automation and industrial
> > computing where the languages used in automation (IEC 61131-3) make it
> > hard to create evolved applications and where the C/C++ languages are not
> > easy to master for automation engineers. And we know what happens when
> > one does not master the tool he uses.
> > 
> > Ada seems to fit perfectly here to me.
> 
> Yes, but not perfect. Issues of distribution and modularity are addressed
> in a way that is not very suitable for automation systems. Not that there
> exists any language that does it better, but still.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Best Regards,
Stéphane
http://slo-ist.fr/

Re: Ada for Automation

[Dmitry A. Kazakov]

On Thu, 6 Nov 2014 13:58:11 -0800 (PST), slos wrote:

> Le jeudi 6 novembre 2014 18:22:19 UTC+1, Dmitry A. Kazakov a écrit :
>> On Thu, 6 Nov 2014 06:43:03 -0800 (PST), slos wrote:
>> 
>> Don't you find it strange that you'd need a special hardware to communicate
>> devices designed to be Ethernet-compatible? Why don't you need a board to
>> communicate ModBus? Telnet? HTTP?
> Determinism ? High data throughput ? Synchronization ? What else ?

I don't see why any of this requires a board, which is nothing but another
computer. If it can do this, why the target system cannot?

>>> Yes, that's true. Industrial protocols tend to be more and more complex
>>> because the world is getting more and more complex.
>> 
>> Not really. All of them except very few are quite poorly designed. There is
>> nothing in the world that can justify the enormous complexity of EtherCAT.
>> It is simply wrong design all way up from the lowest transport level, which
>> itself is nice and elegant. It looks like EtherCAT was designed by
>> different people. The rest of EtherCAT layers is garbage with anything done
>> wrong, what could be done wrong. It complicates everything, slaves,
>> masters. It does not support auto-configuration as proclaimed. It has a
>> huge and absolutely unnecessary initialization delay. Distributed clock is
>> broken. There is no diagnostics whatsoever and so on.
>> 
> That's strange. It seems to me that you are putting down the technology
> you have implemented in your solution.

Why? Our solution is all about hardware integration. Its philosophy is that
we don't dictate customer hardware choices. He decides what hardware to
buy. We integrate that hardware into the automation system.

There is a lot of EtherCAT hardware around. This does not make EtherCAT
design good. Furthermore, EtherCAT is only inexpensive solution that
manages cycles under 1ms. Customers love short cycles and gigabytes of
useless data blowing up hard drives, therefore we support it.

Given a choice between Beckhoff EtherCAT and ModBus terminals, same vendor,
ModBus is clear favorite. Building a system that uses ModBus terminals is
in order magnitude simpler and far more maintainable than a system based on
EtherCAT. The advantage of EtherCAT is much shorter cycles (50us vs. 5ms)
and slightly lower price. All else is disadvantages.

> So, over EtherCAT, the application layer is mainly CANopen like for POWERLINK.

Yes.

> CANopen allows to select in the object dictionary of each devices the data
> that has to be cyclically exchanged.

Most of EtherCAT terminals cannot this (e.g. selection of PDOs, free
configuration of sync buffers). Many of them don't even have object
dictionary, others have it incomplete or broken. Much of work our master
does is gathering information scattered across different sources on the
terminal (EEPROM, object dictionary, address space), fixing
inconsistencies, filling missing parts.

> This you cannot do with, let's say, Modbus.

Of course you can. There is no problem to query only data you needed over
ModBus. We do this all the time.

All this CANOpen stuff borrowed by EtherCAT is nonsense, because like
ModBus the EtherCAT's transport is pure *client-server*, while CANOpen is
running on CAN which is *bus*. So the upper EtherCAT layers simply do not
fit to the transport and are useless at best.

>> ... or National Instruments, or Siemens, or Vector AG, or ETAS etc. I don't
>> believe you could gather much interest in that. Hobbyists won't go into a
>> vendor lock. Professionals will stick to paid services and complete
>> solutions.
> Well, if someone is willing to spend some time in binding their API,
> everyone could then use those boards as well.

Which would be more work than supporting stacks natively, and far more work
in the future spent on maintenance. Protocols are more or less standardised
and stable. Vendor API's are a volatile havoc. Furthermore the high
abstraction level will prevent seamless board integration anyway. It is
classic abstraction inversion, you add a full-blown system in order to
sample few low-level data channels.

>> Monolithic design. It is all OK for an embedded system, but barely
>> acceptable for a medium-scale automation subsystem running on a PC with
>> components being independent processes. Protected objects cannot cross
>> process borders. You don't want to have it in single process for many
>> reasons.
> It works fine this way. I don't want to put in too much complexity, no
> more than needed. May be your applications need that.
> I have learned about PolyORB and DSA and thought that I could have one
> partition managing the GUI while another managing the process for example
> but for the moment I want to keep it quite simple.

It will be difficult to add distribution services later. They must be a
part of the middleware, too much coupling needed.

>>>> That
>>>> is not a good idea, generally. It is better to keep them separate. Which is
>>>> a serious architectural problem how to communicate between the middleware
>>>> dealing with the hardware, providing publisher-subscriber services and
>>>> various clients. GUI is only one of them. Inter-process communication, DLLs
>>>> are all system-dependent. No solution is scalable and portable, meets
>>>> real-time requirements. It is a very difficult problem to resolve.
>>>>  
>>>>> It works rather nicely but it would be fantastic if some experienced
>>>>> person would review the code and give me some feedback on the design, the
>>>>> bindings, the code quality... I'm a lonely Ada programmer, and I miss
>>>>> feedback.
>>>>> 
>>>>> Of course, I am interested in any collaboration around this matter.
>>>>> So, do not hesitate to get in touch when you have some real case.
>>>> 
>>>> We do the same stuff, but it is a commercial product. So I cannot do that
>>>> on ethical and contractual grounds, sorry.
>>> There are plenty of commercial solutions already available like WinAC,
>>> CoDeSys, PROCONOS, ISaGRAF... to create automation solutions, none in Ada.
>> 
>> Ours (its embeddable variant) is all in Ada. (:-))
> Who is developing the application ? Automation engineers or your team ?

Usually engineers and usually not in Ada. Since the middleware is natively
distributed, applications can be written in other languages, the ones
people prefer, something as horrific as C# or MATLAB.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for Automation

[slos]

Le vendredi 7 novembre 2014 09:29:38 UTC+1, Dmitry A. Kazakov a écrit :
> On Thu, 6 Nov 2014 13:58:11 -0800 (PST), slos wrote:
> 
> > Le jeudi 6 novembre 2014 18:22:19 UTC+1, Dmitry A. Kazakov a écrit :
> >> On Thu, 6 Nov 2014 06:43:03 -0800 (PST), slos wrote:
> >> 
> >> Don't you find it strange that you'd need a special hardware to communicate
> >> devices designed to be Ethernet-compatible? Why don't you need a board to
> >> communicate ModBus? Telnet? HTTP?
> > Determinism ? High data throughput ? Synchronization ? What else ?
> 
> I don't see why any of this requires a board, which is nothing but another
> computer. If it can do this, why the target system cannot?
Because for some specialized features like synchronisation with jitter in the nanosecond range require ad hoc hardware ?
Because an ad hoc OS gives better performance than a general one ?

> 
> >>> Yes, that's true. Industrial protocols tend to be more and more complex
> >>> because the world is getting more and more complex.
> >> 
> >> Not really. All of them except very few are quite poorly designed. There is
> >> nothing in the world that can justify the enormous complexity of EtherCAT.
> >> It is simply wrong design all way up from the lowest transport level, which
> >> itself is nice and elegant. It looks like EtherCAT was designed by
> >> different people. The rest of EtherCAT layers is garbage with anything done
> >> wrong, what could be done wrong. It complicates everything, slaves,
> >> masters. It does not support auto-configuration as proclaimed. It has a
> >> huge and absolutely unnecessary initialization delay. Distributed clock is
> >> broken. There is no diagnostics whatsoever and so on.
> >> 
> > That's strange. It seems to me that you are putting down the technology
> > you have implemented in your solution.
> 
> Why? Our solution is all about hardware integration. Its philosophy is that
> we don't dictate customer hardware choices. He decides what hardware to
> buy. We integrate that hardware into the automation system.
Yes, it's all about choice. Hilscher and others offer that choice.

> 
> There is a lot of EtherCAT hardware around. This does not make EtherCAT
> design good. Furthermore, EtherCAT is only inexpensive solution that
> manages cycles under 1ms. Customers love short cycles and gigabytes of
> useless data blowing up hard drives, therefore we support it.
It may be useless or not. I am not the customer and I don't know why he needs so much data but if he needs it he gets it.

I have some examples where it makes sense like this one :
Our customer is building robots arms and need to know if they are moving as expected.

So he is moving the arm and records position and couple at 1 ms rate.

Then, analysing the data he can detect whether there is a mechanical problem that has to be adjusted.

Anyway, in motion control, such features are mandatory these days, not for recording them but for very accurate motion of many axes.

> 
> Given a choice between Beckhoff EtherCAT and ModBus terminals, same vendor,
> ModBus is clear favorite. Building a system that uses ModBus terminals is
> in order magnitude simpler and far more maintainable than a system based on
> EtherCAT. The advantage of EtherCAT is much shorter cycles (50us vs. 5ms)
> and slightly lower price. All else is disadvantages.
On a field bus you will find some other devices like encoders or drives for example where Modbus will not suffice. Having also terminals with digital / analog I/Os just make sense because you don't want to have several networks.
And of course, when you need high rate data acquisition like for test benches it's just mandatory.

> 
> > So, over EtherCAT, the application layer is mainly CANopen like for POWERLINK.
> 
> Yes.
> 
> > CANopen allows to select in the object dictionary of each devices the data
> > that has to be cyclically exchanged.
> 
> Most of EtherCAT terminals cannot this (e.g. selection of PDOs, free
> configuration of sync buffers). Many of them don't even have object
> dictionary, others have it incomplete or broken. Much of work our master
> does is gathering information scattered across different sources on the
> terminal (EEPROM, object dictionary, address space), fixing
> inconsistencies, filling missing parts.
Again terminals are not the only things you will find on a network.
No technology is perfect and developers are humans and there are bugs like every where else.

And yes, integration is creating working applications with components which have some bugs and you have to get them updated / corrected or find some workaround. And that's where open source shines.

> 
> > This you cannot do with, let's say, Modbus.
> 
> Of course you can. There is no problem to query only data you needed over
> ModBus. We do this all the time.
> 
> All this CANOpen stuff borrowed by EtherCAT is nonsense, because like
> ModBus the EtherCAT's transport is pure *client-server*, while CANOpen is
> running on CAN which is *bus*. So the upper EtherCAT layers simply do not
> fit to the transport and are useless at best.
Woah ! are you sure ? I cannot tell. But I can see it working everyday.

> 
> >> ... or National Instruments, or Siemens, or Vector AG, or ETAS etc. I don't
> >> believe you could gather much interest in that. Hobbyists won't go into a
> >> vendor lock. Professionals will stick to paid services and complete
> >> solutions.
> > Well, if someone is willing to spend some time in binding their API,
> > everyone could then use those boards as well.
> 
> Which would be more work than supporting stacks natively, and far more work
> in the future spent on maintenance. Protocols are more or less standardised
> and stable. Vendor API's are a volatile havoc. Furthermore the high
> abstraction level will prevent seamless board integration anyway. It is
> classic abstraction inversion, you add a full-blown system in order to
> sample few low-level data channels.
Well, since protocols are standardized, what would prevent to create some hardware abstraction layer over boards drivers bindings ?
Let's say there is a CANopen interface that allows the application to send an SDO read / write request. Then depending on some configuration step, this layer would call the corresponding function in the selected board interface.
Seems rather simple in fact.

> 
> >> Monolithic design. It is all OK for an embedded system, but barely
> >> acceptable for a medium-scale automation subsystem running on a PC with
> >> components being independent processes. Protected objects cannot cross
> >> process borders. You don't want to have it in single process for many
> >> reasons.
> > It works fine this way. I don't want to put in too much complexity, no
> > more than needed. May be your applications need that.
> > I have learned about PolyORB and DSA and thought that I could have one
> > partition managing the GUI while another managing the process for example
> > but for the moment I want to keep it quite simple.
> 
> It will be difficult to add distribution services later. They must be a
> part of the middleware, too much coupling needed.
Well, let's see if "Ada for Automation" can do the work for not so simple applications and how it is perceived.

> 
> >>>> That
> >>>> is not a good idea, generally. It is better to keep them separate. Which is
> >>>> a serious architectural problem how to communicate between the middleware
> >>>> dealing with the hardware, providing publisher-subscriber services and
> >>>> various clients. GUI is only one of them. Inter-process communication, DLLs
> >>>> are all system-dependent. No solution is scalable and portable, meets
> >>>> real-time requirements. It is a very difficult problem to resolve.
> >>>>  
> >>>>> It works rather nicely but it would be fantastic if some experienced
> >>>>> person would review the code and give me some feedback on the design, the
> >>>>> bindings, the code quality... I'm a lonely Ada programmer, and I miss
> >>>>> feedback.
> >>>>> 
> >>>>> Of course, I am interested in any collaboration around this matter.
> >>>>> So, do not hesitate to get in touch when you have some real case.
> >>>> 
> >>>> We do the same stuff, but it is a commercial product. So I cannot do that
> >>>> on ethical and contractual grounds, sorry.
> >>> There are plenty of commercial solutions already available like WinAC,
> >>> CoDeSys, PROCONOS, ISaGRAF... to create automation solutions, none in Ada.
> >> 
> >> Ours (its embeddable variant) is all in Ada. (:-))
> > Who is developing the application ? Automation engineers or your team ?
> 
> Usually engineers and usually not in Ada. Since the middleware is natively
> distributed, applications can be written in other languages, the ones
> people prefer, something as horrific as C# or MATLAB.
People use what they know or are directed to use.
"Ada for Automation" wants them to learn Ada and use it for their applications.

We could continue this discussion about field buses but I am here to let the Ada community know about this project and get some feedback on my beginner's job.

I am quite sure your Ada skills are far more developed than mines and that I could learn a lot from you and others on this list.

> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Best Regards,
Stéphane
http://slo-ist.fr/

Re: Ada for Automation

[slos]

Le vendredi 7 novembre 2014 09:29:38 UTC+1, Dmitry A. Kazakov a écrit :
> On Thu, 6 Nov 2014 13:58:11 -0800 (PST), slos wrote:
> 
> > Le jeudi 6 novembre 2014 18:22:19 UTC+1, Dmitry A. Kazakov a écrit :
> >> On Thu, 6 Nov 2014 06:43:03 -0800 (PST), slos wrote:
> >> 
> >> Don't you find it strange that you'd need a special hardware to communicate
> >> devices designed to be Ethernet-compatible? Why don't you need a board to
> >> communicate ModBus? Telnet? HTTP?
> > Determinism ? High data throughput ? Synchronization ? What else ?
> 
> I don't see why any of this requires a board, which is nothing but another
> computer. If it can do this, why the target system cannot?
> 
> >>> Yes, that's true. Industrial protocols tend to be more and more complex
> >>> because the world is getting more and more complex.
> >> 
> >> Not really. All of them except very few are quite poorly designed. There is
> >> nothing in the world that can justify the enormous complexity of EtherCAT.
> >> It is simply wrong design all way up from the lowest transport level, which
> >> itself is nice and elegant. It looks like EtherCAT was designed by
> >> different people. The rest of EtherCAT layers is garbage with anything done
> >> wrong, what could be done wrong. It complicates everything, slaves,
> >> masters. It does not support auto-configuration as proclaimed. It has a
> >> huge and absolutely unnecessary initialization delay. Distributed clock is
> >> broken. There is no diagnostics whatsoever and so on.
> >> 
> > That's strange. It seems to me that you are putting down the technology
> > you have implemented in your solution.
> 
> Why? Our solution is all about hardware integration. Its philosophy is that
> we don't dictate customer hardware choices. He decides what hardware to
> buy. We integrate that hardware into the automation system.
> 
> There is a lot of EtherCAT hardware around. This does not make EtherCAT
> design good. Furthermore, EtherCAT is only inexpensive solution that
> manages cycles under 1ms. Customers love short cycles and gigabytes of
> useless data blowing up hard drives, therefore we support it.
> 
> Given a choice between Beckhoff EtherCAT and ModBus terminals, same vendor,
> ModBus is clear favorite. Building a system that uses ModBus terminals is
> in order magnitude simpler and far more maintainable than a system based on
> EtherCAT. The advantage of EtherCAT is much shorter cycles (50us vs. 5ms)
> and slightly lower price. All else is disadvantages.
> 
> > So, over EtherCAT, the application layer is mainly CANopen like for POWERLINK.
> 
> Yes.
> 
> > CANopen allows to select in the object dictionary of each devices the data
> > that has to be cyclically exchanged.
> 
> Most of EtherCAT terminals cannot this (e.g. selection of PDOs, free
> configuration of sync buffers). Many of them don't even have object
> dictionary, others have it incomplete or broken. Much of work our master
> does is gathering information scattered across different sources on the
> terminal (EEPROM, object dictionary, address space), fixing
> inconsistencies, filling missing parts.
> 
> > This you cannot do with, let's say, Modbus.
> 
> Of course you can. There is no problem to query only data you needed over
> ModBus. We do this all the time.
No, that's not the same thing.
With today field buses you are able to select what will be exchanged cyclically in a PDO (CANopen / EtherCAT / POWERLINK) or Assembly (Ethernet/IP). The device will prepare its answer accordingly.
With Modbus, you can access of course the whole data set but you end up reading more data and filter out the one you don't need or make several requests to pick up only the data needed.
Of course, performance wise, the former is better.

> 
> All this CANOpen stuff borrowed by EtherCAT is nonsense, because like
> ModBus the EtherCAT's transport is pure *client-server*, while CANOpen is
> running on CAN which is *bus*. So the upper EtherCAT layers simply do not
> fit to the transport and are useless at best.
> 
> >> ... or National Instruments, or Siemens, or Vector AG, or ETAS etc. I don't
> >> believe you could gather much interest in that. Hobbyists won't go into a
> >> vendor lock. Professionals will stick to paid services and complete
> >> solutions.
> > Well, if someone is willing to spend some time in binding their API,
> > everyone could then use those boards as well.
> 
> Which would be more work than supporting stacks natively, and far more work
> in the future spent on maintenance. Protocols are more or less standardised
> and stable. Vendor API's are a volatile havoc. Furthermore the high
> abstraction level will prevent seamless board integration anyway. It is
> classic abstraction inversion, you add a full-blown system in order to
> sample few low-level data channels.
> 
> >> Monolithic design. It is all OK for an embedded system, but barely
> >> acceptable for a medium-scale automation subsystem running on a PC with
> >> components being independent processes. Protected objects cannot cross
> >> process borders. You don't want to have it in single process for many
> >> reasons.
> > It works fine this way. I don't want to put in too much complexity, no
> > more than needed. May be your applications need that.
> > I have learned about PolyORB and DSA and thought that I could have one
> > partition managing the GUI while another managing the process for example
> > but for the moment I want to keep it quite simple.
> 
> It will be difficult to add distribution services later. They must be a
> part of the middleware, too much coupling needed.
> 
> >>>> That
> >>>> is not a good idea, generally. It is better to keep them separate. Which is
> >>>> a serious architectural problem how to communicate between the middleware
> >>>> dealing with the hardware, providing publisher-subscriber services and
> >>>> various clients. GUI is only one of them. Inter-process communication, DLLs
> >>>> are all system-dependent. No solution is scalable and portable, meets
> >>>> real-time requirements. It is a very difficult problem to resolve.
> >>>>  
> >>>>> It works rather nicely but it would be fantastic if some experienced
> >>>>> person would review the code and give me some feedback on the design, the
> >>>>> bindings, the code quality... I'm a lonely Ada programmer, and I miss
> >>>>> feedback.
> >>>>> 
> >>>>> Of course, I am interested in any collaboration around this matter.
> >>>>> So, do not hesitate to get in touch when you have some real case.
> >>>> 
> >>>> We do the same stuff, but it is a commercial product. So I cannot do that
> >>>> on ethical and contractual grounds, sorry.
> >>> There are plenty of commercial solutions already available like WinAC,
> >>> CoDeSys, PROCONOS, ISaGRAF... to create automation solutions, none in Ada.
> >> 
> >> Ours (its embeddable variant) is all in Ada. (:-))
> > Who is developing the application ? Automation engineers or your team ?
> 
> Usually engineers and usually not in Ada. Since the middleware is natively
> distributed, applications can be written in other languages, the ones
> people prefer, something as horrific as C# or MATLAB.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Re: Ada for Automation

[Dmitry A. Kazakov]

On Fri, 7 Nov 2014 01:51:19 -0800 (PST), slos wrote:

> Le vendredi 7 novembre 2014 09:29:38 UTC+1, Dmitry A. Kazakov a écrit :
>> On Thu, 6 Nov 2014 13:58:11 -0800 (PST), slos wrote:
>> 
>>> Le jeudi 6 novembre 2014 18:22:19 UTC+1, Dmitry A. Kazakov a écrit :
>>>> On Thu, 6 Nov 2014 06:43:03 -0800 (PST), slos wrote:
>>>> 
>>>> Don't you find it strange that you'd need a special hardware to communicate
>>>> devices designed to be Ethernet-compatible? Why don't you need a board to
>>>> communicate ModBus? Telnet? HTTP?
>>> Determinism ? High data throughput ? Synchronization ? What else ?
>> 
>> I don't see why any of this requires a board, which is nothing but another
>> computer. If it can do this, why the target system cannot?
> Because for some specialized features like synchronisation with jitter in
> the nanosecond range require ad hoc hardware ?

You cannot do that on an ARM board anyway. And if you could, what for? If
the data are to be processed on the PC via network which has jitter nowhere
close to ns?

If these data are not automation process data, then what are we talking
about?

Such high speed data are processed in the terminals which provide integral
measures which in turn don't require meaningless ns jitter. As an example
take frequency measurements. They require ns clocking and pulse counting,
which is done by the hardware, not by the board. Here the computed result
is frequency, a pretty normal data with pretty no extraordinary jitter
requirements.

> Because an ad hoc OS gives better performance than a general one ?

I doubt it much. The board must support some network protocol where all
performance ends. Either it will run in several threads which would make it
not better than general OS, or it will use some multiple buffering
techniques with have *worse* performance being time-triggered.

> I have some examples where it makes sense like this one :
> Our customer is building robots arms and need to know if they are moving
> as expected.
> 
> So he is moving the arm and records position and couple at 1 ms rate.

Our customers require multiple channel 100µs.

>Then, analysing the data he can detect whether there is a mechanical
> problem that has to be adjusted.

Yes, this is a typical line of the argument. The problem is that it is too
much data to analyse later or ever.

Alas, it is impossible to convince customers to invest into on-line
diagnostics. Because that would cost time and money. 

With the data simply stored away, they believe they would be able to
analyse them later, for nothing, using Excel to read 4Gb files... (:-))

>> Given a choice between Beckhoff EtherCAT and ModBus terminals, same vendor,
>> ModBus is clear favorite. Building a system that uses ModBus terminals is
>> in order magnitude simpler and far more maintainable than a system based on
>> EtherCAT. The advantage of EtherCAT is much shorter cycles (50us vs. 5ms)
>> and slightly lower price. All else is disadvantages.
> On a field bus you will find some other devices like encoders or drives
> for example where Modbus will not suffice.

I doubt it. E.g. WAGO ModBus incremental encoders are no worse or better
than EtherCAT ones. Actually ModBus encoders are simpler to use because the
vendor does not try to pack all possible modes into single terminal
requiring the automation system to configure dozens of parameters nobody
needs. Less flexibility safer and simpler usage.

>>> CANopen allows to select in the object dictionary of each devices the data
>>> that has to be cyclically exchanged.
>> 
>> Most of EtherCAT terminals cannot this (e.g. selection of PDOs, free
>> configuration of sync buffers). Many of them don't even have object
>> dictionary, others have it incomplete or broken. Much of work our master
>> does is gathering information scattered across different sources on the
>> terminal (EEPROM, object dictionary, address space), fixing
>> inconsistencies, filling missing parts.
> Again terminals are not the only things you will find on a network.

You don't seriously suggest PCs to communicate over EtherCAT? There is
nothing but terminals which is needed. For anything else there is data
distribution protocols which has nothing to do with EtherCAT or any other
field protocol. And in our designs we always physically separate filed and
automation networks.

>>>> ... or National Instruments, or Siemens, or Vector AG, or ETAS etc. I don't
>>>> believe you could gather much interest in that. Hobbyists won't go into a
>>>> vendor lock. Professionals will stick to paid services and complete
>>>> solutions.
>>> Well, if someone is willing to spend some time in binding their API,
>>> everyone could then use those boards as well.
>> 
>> Which would be more work than supporting stacks natively, and far more work
>> in the future spent on maintenance. Protocols are more or less standardised
>> and stable. Vendor API's are a volatile havoc. Furthermore the high
>> abstraction level will prevent seamless board integration anyway. It is
>> classic abstraction inversion, you add a full-blown system in order to
>> sample few low-level data channels.
> Well, since protocols are standardized, what would prevent to create some
> hardware abstraction layer over boards drivers bindings ?

Because vendors want to keep customers locked.

> Let's say there is a CANopen interface that allows the application to send
> an SDO read / write request. Then depending on some configuration step,
> this layer would call the corresponding function in the selected board
> interface.

This what middleware distribution protocol is for.

> Seems rather simple in fact.

Right. And if the board can talk this protocol, why terminal cannot? See?
You don't need dedicated boards in the end.

> "Ada for Automation" wants them to learn Ada and use it for their
> applications.

Yes, ideally.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for Automation

[Dmitry A. Kazakov]

On Fri, 7 Nov 2014 03:44:38 -0800 (PST), slos wrote:

>>> This you cannot do with, let's say, Modbus.
>> 
>> Of course you can. There is no problem to query only data you needed over
>> ModBus. We do this all the time.
> No, that's not the same thing.
> With today field buses you are able to select what will be exchanged
> cyclically in a PDO (CANopen / EtherCAT / POWERLINK) or Assembly
> (Ethernet/IP).

EtherCAT does not do anything cyclically. The master must explicitly
initiate every single cycle. It is strictly client-server. All immense
configuration overhead and slave complexity could be spared if the master
simply queried slave's registers using slave ID and the data point ID.

> The device will prepare its answer accordingly.

Which is unnecessary overhead only complicating EtherCAT masters and
slaves. BTW, our master does not use FMMU and other useless stuff. Which is
why it is capable to run as many independent cycles as needed, all
simultaneously. It does not make sense querying temperatures and digital
inputs at 200µs, right?

> With Modbus, you can access of course the whole data set but you end up
> reading more data and filter out the one you don't need or make several
> requests to pick up only the data needed.

No. This is maybe an artefact of the libmodbus you are using, I don't know
it. But in ModBus (class 2) you can read/write any single register or any
sequence of adjacent registers.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for Automation

[slos]

Le vendredi 7 novembre 2014 14:44:13 UTC+1, Dmitry A. Kazakov a écrit :
> On Fri, 7 Nov 2014 01:51:19 -0800 (PST), slos wrote:
> 
> > Le vendredi 7 novembre 2014 09:29:38 UTC+1, Dmitry A. Kazakov a écrit :
> >> On Thu, 6 Nov 2014 13:58:11 -0800 (PST), slos wrote:
> >> 
> >>> Le jeudi 6 novembre 2014 18:22:19 UTC+1, Dmitry A. Kazakov a écrit :
> >>>> On Thu, 6 Nov 2014 06:43:03 -0800 (PST), slos wrote:
> >>>> 
> >>>> Don't you find it strange that you'd need a special hardware to communicate
> >>>> devices designed to be Ethernet-compatible? Why don't you need a board to
> >>>> communicate ModBus? Telnet? HTTP?
> >>> Determinism ? High data throughput ? Synchronization ? What else ?
> >> 
> >> I don't see why any of this requires a board, which is nothing but another
> >> computer. If it can do this, why the target system cannot?
> > Because for some specialized features like synchronisation with jitter in
> > the nanosecond range require ad hoc hardware ?
> 
> You cannot do that on an ARM board anyway. And if you could, what for? If
> the data are to be processed on the PC via network which has jitter nowhere
> close to ns?
Of course we can ! Not an ARM board but a netX powered one with what's needed to achieve that.
The jitter relates to the synchronisation signal. Data is delivered by the communication but it is applied on power stage only when the synchronisation happens.

Our customers may use FPGA / DSP / Micro-controllers... and PCs sometimes.

> 
> If these data are not automation process data, then what are we talking
> about?
> 
> Such high speed data are processed in the terminals which provide integral
> measures which in turn don't require meaningless ns jitter. As an example
> take frequency measurements. They require ns clocking and pulse counting,
> which is done by the hardware, not by the board. Here the computed result
> is frequency, a pretty normal data with pretty no extraordinary jitter
> requirements.
I agree totally for this kind of data and you could say the same for let's say a drive with an encoder connected to ; the loop is closed in the drive and that would be the easiest architecture. But some customers want to have the loop closed in the controller so that they can write the control algorithm they need.

> 
> > Because an ad hoc OS gives better performance than a general one ?
> 
> I doubt it much. The board must support some network protocol where all
> performance ends. Either it will run in several threads which would make it
> not better than general OS, or it will use some multiple buffering
> techniques with have *worse* performance being time-triggered.
Don't doubt. Experiment with it.

> 
> > I have some examples where it makes sense like this one :
> > Our customer is building robots arms and need to know if they are moving
> > as expected.
> > 
> > So he is moving the arm and records position and couple at 1 ms rate.
> 
> Our customers require multiple channel 100µs.
That's not what is needed even by motion control applications.
"Ada for Automation" target applications are those in the millisecond range, that is most of automation ones.

> 
> >Then, analysing the data he can detect whether there is a mechanical
> > problem that has to be adjusted.
> 
> Yes, this is a typical line of the argument. The problem is that it is too
> much data to analyse later or ever.
This customer has to provide some evidence of the quality of its arm.
Curves show if there is some outstanding values.
No problem for him, he can analyse the data he captures.

> 
> Alas, it is impossible to convince customers to invest into on-line
> diagnostics. Because that would cost time and money. 
> 
> With the data simply stored away, they believe they would be able to
> analyse them later, for nothing, using Excel to read 4Gb files... (:-))
One can filter out normal data to get only interesting one.

> 
> >> Given a choice between Beckhoff EtherCAT and ModBus terminals, same vendor,
> >> ModBus is clear favorite. Building a system that uses ModBus terminals is
> >> in order magnitude simpler and far more maintainable than a system based on
> >> EtherCAT. The advantage of EtherCAT is much shorter cycles (50us vs. 5ms)
> >> and slightly lower price. All else is disadvantages.
> > On a field bus you will find some other devices like encoders or drives
> > for example where Modbus will not suffice.
> 
> I doubt it. E.g. WAGO ModBus incremental encoders are no worse or better
> than EtherCAT ones. Actually ModBus encoders are simpler to use because the
> vendor does not try to pack all possible modes into single terminal
> requiring the automation system to configure dozens of parameters nobody
> needs. Less flexibility safer and simpler usage.
In drives applications, you have much more data to choose from, depending on the working mode.

> 
> >>> CANopen allows to select in the object dictionary of each devices the data
> >>> that has to be cyclically exchanged.
> >> 
> >> Most of EtherCAT terminals cannot this (e.g. selection of PDOs, free
> >> configuration of sync buffers). Many of them don't even have object
> >> dictionary, others have it incomplete or broken. Much of work our master
> >> does is gathering information scattered across different sources on the
> >> terminal (EEPROM, object dictionary, address space), fixing
> >> inconsistencies, filling missing parts.
> > Again terminals are not the only things you will find on a network.
> 
> You don't seriously suggest PCs to communicate over EtherCAT?
They can since Ethernet over EtherCAT allows this but I am mostly talking about motion control and drives since those technologies have been specifically developed for that particular need, remember CANopen and Sercos.

> There is
> nothing but terminals which is needed. For anything else there is data
> distribution protocols which has nothing to do with EtherCAT or any other
> field protocol. And in our designs we always physically separate filed and
> automation networks.
Since Ethernet based real time protocols were designed to provide both kind of communications a single path, you have missed the point.
Of course, if your customer can afford two networks...

> 
> >>>> ... or National Instruments, or Siemens, or Vector AG, or ETAS etc. I don't
> >>>> believe you could gather much interest in that. Hobbyists won't go into a
> >>>> vendor lock. Professionals will stick to paid services and complete
> >>>> solutions.
> >>> Well, if someone is willing to spend some time in binding their API,
> >>> everyone could then use those boards as well.
> >> 
> >> Which would be more work than supporting stacks natively, and far more work
> >> in the future spent on maintenance. Protocols are more or less standardised
> >> and stable. Vendor API's are a volatile havoc. Furthermore the high
> >> abstraction level will prevent seamless board integration anyway. It is
> >> classic abstraction inversion, you add a full-blown system in order to
> >> sample few low-level data channels.
> > Well, since protocols are standardized, what would prevent to create some
> > hardware abstraction layer over boards drivers bindings ?
> 
> Because vendors want to keep customers locked.
This is the general case.
But if there is a kind of HAL, you will be able to chose the best alternative.

> 
> > Let's say there is a CANopen interface that allows the application to send
> > an SDO read / write request. Then depending on some configuration step,
> > this layer would call the corresponding function in the selected board
> > interface.
> 
> This what middleware distribution protocol is for.
> 
> > Seems rather simple in fact.
> 
> Right. And if the board can talk this protocol, why terminal cannot? See?
> You don't need dedicated boards in the end.
Please design a drive, an encoder, an IO module, what ever you want, and then try to address the market.
Then you have to implement each protocol on your design. Good luck.

Or, you design your own super cool protocol and your own controller and all those devices that automation need. Welcome to the jungle.

> 
> > "Ada for Automation" wants them to learn Ada and use it for their
> > applications.
> 
> Yes, ideally.
>  
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

BR,
Stéphane

Re: Ada for Automation

[Dmitry A. Kazakov]

On Fri, 7 Nov 2014 07:23:20 -0800 (PST), slos wrote:

> Le vendredi 7 novembre 2014 14:44:13 UTC+1, Dmitry A. Kazakov a écrit :

>> You cannot do that on an ARM board anyway. And if you could, what for? If
>> the data are to be processed on the PC via network which has jitter nowhere
>> close to ns?
> Of course we can ! Not an ARM board but a netX powered one with what's
> needed to achieve that.

Just what I said. This is a one or two generation outdated architecture,
before standardized terminals came. Pack the stuff into plastic box add
Beckhoff's piggy back chip, here you are, a new EtherCAT slave. No boards
ever needed.

>> If these data are not automation process data, then what are we talking
>> about?
>> 
>> Such high speed data are processed in the terminals which provide integral
>> measures which in turn don't require meaningless ns jitter. As an example
>> take frequency measurements. They require ns clocking and pulse counting,
>> which is done by the hardware, not by the board. Here the computed result
>> is frequency, a pretty normal data with pretty no extraordinary jitter
>> requirements.
> I agree totally for this kind of data and you could say the same for let's
> say a drive with an encoder connected to ; the loop is closed in the drive
> and that would be the easiest architecture. But some customers want to
> have the loop closed in the controller so that they can write the control
> algorithm they need.

Yes, that is an outdated architecture with a closed-source PLC programmed
in some garbage language like STEP 7. This is what we want to get rid of,
replace it with open source portable controllers programmed in Ada. For
this native stacks are needed. And because Ada is so scalable and portable
I see no reason why automation and controller software cannot share the
same middleware core!

>>> Because an ad hoc OS gives better performance than a general one ?
>> 
>> I doubt it much. The board must support some network protocol where all
>> performance ends. Either it will run in several threads which would make it
>> not better than general OS, or it will use some multiple buffering
>> techniques with have *worse* performance being time-triggered.
>
> Don't doubt. Experiment with it.

Actually we do much performance measurements for various stacks.  

>>> I have some examples where it makes sense like this one :
>>> Our customer is building robots arms and need to know if they are moving
>>> as expected.
>>> 
>>> So he is moving the arm and records position and couple at 1 ms rate.
>> 
>> Our customers require multiple channel 100µs.
> That's not what is needed even by motion control applications.

It is required in combustion motor R&D and drilling engines. At least the
customers say so. I am not a physicist to argue with them.

> Curves show if there is some outstanding values.

How are you supposed to watch hundreds of curves sampled at 10ms rate for
many months, in some cases? It does not work, but nobody admits that.

> No problem for him, he can analyse the data he captures.
> 
>> Alas, it is impossible to convince customers to invest into on-line
>> diagnostics. Because that would cost time and money. 
>> 
>> With the data simply stored away, they believe they would be able to
>> analyse them later, for nothing, using Excel to read 4Gb files... (:-))
> One can filter out normal data to get only interesting one.

Better do that before storing them...

>>>> Given a choice between Beckhoff EtherCAT and ModBus terminals, same vendor,
>>>> ModBus is clear favorite. Building a system that uses ModBus terminals is
>>>> in order magnitude simpler and far more maintainable than a system based on
>>>> EtherCAT. The advantage of EtherCAT is much shorter cycles (50us vs. 5ms)
>>>> and slightly lower price. All else is disadvantages.
>>> On a field bus you will find some other devices like encoders or drives
>>> for example where Modbus will not suffice.
>> 
>> I doubt it. E.g. WAGO ModBus incremental encoders are no worse or better
>> than EtherCAT ones. Actually ModBus encoders are simpler to use because the
>> vendor does not try to pack all possible modes into single terminal
>> requiring the automation system to configure dozens of parameters nobody
>> needs. Less flexibility safer and simpler usage.
> In drives applications, you have much more data to choose from, depending
> on the working mode.

And where is any problem? We are communicating to multiple SPS controlling
a whole drilling platform machine, a lot of data in each, all goes over
ModBus. ModBus performance is only limited by the other side. E.g. WAGO
ModBus is limited to 5ms because the internal bus cycle is 3ms and because
the coupler is 100Base.

>>>>> CANopen allows to select in the object dictionary of each devices the data
>>>>> that has to be cyclically exchanged.
>>>> 
>>>> Most of EtherCAT terminals cannot this (e.g. selection of PDOs, free
>>>> configuration of sync buffers). Many of them don't even have object
>>>> dictionary, others have it incomplete or broken. Much of work our master
>>>> does is gathering information scattered across different sources on the
>>>> terminal (EEPROM, object dictionary, address space), fixing
>>>> inconsistencies, filling missing parts.
>>> Again terminals are not the only things you will find on a network.
>> 
>> You don't seriously suggest PCs to communicate over EtherCAT?
> They can since Ethernet over EtherCAT allows this but I am mostly talking
> about motion control and drives since those technologies have been
> specifically developed for that particular need

All EtherCAT interfaced drivers we dealt with were quite normal EtherCAT
terminals, nothing special.

>> There is
>> nothing but terminals which is needed. For anything else there is data
>> distribution protocols which has nothing to do with EtherCAT or any other
>> field protocol. And in our designs we always physically separate filed and
>> automation networks.
> Since Ethernet based real time protocols were designed to provide both
> kind of communications a single path, you have missed the point.
> Of course, if your customer can afford two networks...

Anybody can, dual Ethernet ports cost nothing.

All our customers want it separate for safety and bureaucratic reasons.
They often have different cabling requirements (the field network is
usually in the machine hall, dusty, dirty, a lot of EM, LEMO jacks needed
etc). HMI network is clean, but alas, hijacked by internal IT guys (we
never let them into the field with their Windows-updates mess and
firewalls).

>>> Seems rather simple in fact.
>> 
>> Right. And if the board can talk this protocol, why terminal cannot? See?
>> You don't need dedicated boards in the end.
> Please design a drive, an encoder, an IO module, what ever you want, and
> then try to address the market.
> Then you have to implement each protocol on your design. Good luck.

This is exactly what Beckhoff does in the case of EtherCAT slaves:

http://www.beckhoff.de/english/ethercat/fb1111_fb1122_fb1130.htm

or others do for ProfiNet, e.g.

http://am.renesas.com/products/soc/assp/fa_lsi/ethernet/tps1/index.jsp

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for Automation

[slos]

Le vendredi 7 novembre 2014 18:16:34 UTC+1, Dmitry A. Kazakov a écrit :
> On Fri, 7 Nov 2014 07:23:20 -0800 (PST), slos wrote:
> 
> > Le vendredi 7 novembre 2014 14:44:13 UTC+1, Dmitry A. Kazakov a écrit :
> 
> >> You cannot do that on an ARM board anyway. And if you could, what for? If
> >> the data are to be processed on the PC via network which has jitter nowhere
> >> close to ns?
> > Of course we can ! Not an ARM board but a netX powered one with what's
> > needed to achieve that.
> 
> Just what I said. This is a one or two generation outdated architecture,
> before standardized terminals came. Pack the stuff into plastic box add
> Beckhoff's piggy back chip, here you are, a new EtherCAT slave. No boards
> ever needed.
> 
> >> If these data are not automation process data, then what are we talking
> >> about?
> >> 
> >> Such high speed data are processed in the terminals which provide integral
> >> measures which in turn don't require meaningless ns jitter. As an example
> >> take frequency measurements. They require ns clocking and pulse counting,
> >> which is done by the hardware, not by the board. Here the computed result
> >> is frequency, a pretty normal data with pretty no extraordinary jitter
> >> requirements.
> > I agree totally for this kind of data and you could say the same for let's
> > say a drive with an encoder connected to ; the loop is closed in the drive
> > and that would be the easiest architecture. But some customers want to
> > have the loop closed in the controller so that they can write the control
> > algorithm they need.
> 
> Yes, that is an outdated architecture with a closed-source PLC programmed
> in some garbage language like STEP 7. This is what we want to get rid of,
> replace it with open source portable controllers programmed in Ada. For
> this native stacks are needed. And because Ada is so scalable and portable
> I see no reason why automation and controller software cannot share the
> same middleware core!
> 
> >>> Because an ad hoc OS gives better performance than a general one ?
> >> 
> >> I doubt it much. The board must support some network protocol where all
> >> performance ends. Either it will run in several threads which would make it
> >> not better than general OS, or it will use some multiple buffering
> >> techniques with have *worse* performance being time-triggered.
> >
> > Don't doubt. Experiment with it.
> 
> Actually we do much performance measurements for various stacks.  
> 
> >>> I have some examples where it makes sense like this one :
> >>> Our customer is building robots arms and need to know if they are moving
> >>> as expected.
> >>> 
> >>> So he is moving the arm and records position and couple at 1 ms rate.
> >> 
> >> Our customers require multiple channel 100ľs.
> > That's not what is needed even by motion control applications.
> 
> It is required in combustion motor R&D and drilling engines. At least the
> customers say so. I am not a physicist to argue with them.
> 
> > Curves show if there is some outstanding values.
> 
> How are you supposed to watch hundreds of curves sampled at 10ms rate for
> many months, in some cases? It does not work, but nobody admits that.
> 
> > No problem for him, he can analyse the data he captures.
> > 
> >> Alas, it is impossible to convince customers to invest into on-line
> >> diagnostics. Because that would cost time and money. 
> >> 
> >> With the data simply stored away, they believe they would be able to
> >> analyse them later, for nothing, using Excel to read 4Gb files... (:-))
> > One can filter out normal data to get only interesting one.
> 
> Better do that before storing them...
> 
> >>>> Given a choice between Beckhoff EtherCAT and ModBus terminals, same vendor,
> >>>> ModBus is clear favorite. Building a system that uses ModBus terminals is
> >>>> in order magnitude simpler and far more maintainable than a system based on
> >>>> EtherCAT. The advantage of EtherCAT is much shorter cycles (50us vs. 5ms)
> >>>> and slightly lower price. All else is disadvantages.
> >>> On a field bus you will find some other devices like encoders or drives
> >>> for example where Modbus will not suffice.
> >> 
> >> I doubt it. E.g. WAGO ModBus incremental encoders are no worse or better
> >> than EtherCAT ones. Actually ModBus encoders are simpler to use because the
> >> vendor does not try to pack all possible modes into single terminal
> >> requiring the automation system to configure dozens of parameters nobody
> >> needs. Less flexibility safer and simpler usage.
> > In drives applications, you have much more data to choose from, depending
> > on the working mode.
> 
> And where is any problem? We are communicating to multiple SPS controlling
> a whole drilling platform machine, a lot of data in each, all goes over
> ModBus. ModBus performance is only limited by the other side. E.g. WAGO
> ModBus is limited to 5ms because the internal bus cycle is 3ms and because
> the coupler is 100Base.
> 
> >>>>> CANopen allows to select in the object dictionary of each devices the data
> >>>>> that has to be cyclically exchanged.
> >>>> 
> >>>> Most of EtherCAT terminals cannot this (e.g. selection of PDOs, free
> >>>> configuration of sync buffers). Many of them don't even have object
> >>>> dictionary, others have it incomplete or broken. Much of work our master
> >>>> does is gathering information scattered across different sources on the
> >>>> terminal (EEPROM, object dictionary, address space), fixing
> >>>> inconsistencies, filling missing parts.
> >>> Again terminals are not the only things you will find on a network.
> >> 
> >> You don't seriously suggest PCs to communicate over EtherCAT?
> > They can since Ethernet over EtherCAT allows this but I am mostly talking
> > about motion control and drives since those technologies have been
> > specifically developed for that particular need
> 
> All EtherCAT interfaced drivers we dealt with were quite normal EtherCAT
> terminals, nothing special.
> 
> >> There is
> >> nothing but terminals which is needed. For anything else there is data
> >> distribution protocols which has nothing to do with EtherCAT or any other
> >> field protocol. And in our designs we always physically separate filed and
> >> automation networks.
> > Since Ethernet based real time protocols were designed to provide both
> > kind of communications a single path, you have missed the point.
> > Of course, if your customer can afford two networks...
> 
> Anybody can, dual Ethernet ports cost nothing.
> 
> All our customers want it separate for safety and bureaucratic reasons.
> They often have different cabling requirements (the field network is
> usually in the machine hall, dusty, dirty, a lot of EM, LEMO jacks needed
> etc). HMI network is clean, but alas, hijacked by internal IT guys (we
> never let them into the field with their Windows-updates mess and
> firewalls).
> 
> >>> Seems rather simple in fact.
> >> 
> >> Right. And if the board can talk this protocol, why terminal cannot? See?
> >> You don't need dedicated boards in the end.
> > Please design a drive, an encoder, an IO module, what ever you want, and
> > then try to address the market.
> > Then you have to implement each protocol on your design. Good luck.
> 
> This is exactly what Beckhoff does in the case of EtherCAT slaves:
> 
> http://www.beckhoff.de/english/ethercat/fb1111_fb1122_fb1130.htm
> 
> or others do for ProfiNet, e.g.
> 
> http://am.renesas.com/products/soc/assp/fa_lsi/ethernet/tps1/index.jsp
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

And what about Ada and the project itself ?

BR,
Stéphane

Re: Ada for Automation

[Dmitry A. Kazakov]

On Fri, 7 Nov 2014 12:37:55 -0800 (PST), slos wrote:

> And what about Ada and the project itself ?

Sorry, I lost you here. Ada and the project in which context?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for Automation

[slos]

Le vendredi 7 novembre 2014 22:15:51 UTC+1, Dmitry A. Kazakov a écrit :
> On Fri, 7 Nov 2014 12:37:55 -0800 (PST), slos wrote:
> 
> > And what about Ada and the project itself ?
> 
> Sorry, I lost you here. Ada and the project in which context?
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Dmitry, I am interested in getting feedback on the project since I am a lonely Ada programmer. I have learned through books and the web without much interaction with other fellows. I don't want to discuss further on the pros and cons of field buses protocols and implementation solutions. We have different opinions and I am fine with that, I will not be trying to convince you anymore.

BR,
Stéphane

Re: Ada for Automation

[Björn Lundin]

On 2014-11-06 12:14, slos wrote:
> Hello,
> 
> "Ada for Automation" (A4A in short) is a framework, for designing
> industrial automation applications using the Ada language.
> It uses the libmodbus library to allow building a Modbus TCP client or
server,
> or a Modbus RTU master. It can also use Hilscher communication boards
allowing to
>communicate on field buses like AS-Interface, CANopen, CC-Link,
DeviceNet, PROFIBUS,
> EtherCAT, Ethernet/IP, Modbus TCP, PROFINET, Sercos III, POWERLINK, or
VARAN.
> 

This seems good for writing PLC logic with, for conveyor systems,
stacker cranes, etc for warehouse automation, which is my field of work.

I see others has criticized the project for high latency, eg ns needed
in measuring processes within combustion engines, but in my kind of
automation ms is good enough.

Unfortuantly, the PLC level is nowadays programmed by the vendors of the
machinery. In the 80's and 90's the ancestor of my present day company
did not only WMS/WCS (Warehouse Management Systems/Warehouse Control
Systems) control but also on-board steering software of stacker cranes
and AGVs.

However those days are long gone, since the hardware vendors learned to
do that themselves, leaving us with WMS/WCS. And we _usually_ speak some
serial protocol, or now more commonly some TCP/IP protocol.

Very few sites use OPC, which was believed to be THE way of
communicating in the early 2000s

Talking modbus directly would be nice, but in my field, I don't see
any of the vendors preferring that to TCP/IP.

But If I was given the opportunity to do conveyor system logic
in say a raspberry pi, I'd definitely would look closer to you project.

Much closer.
I see it as an asset.
Good luck

--
Björn

Re: Ada for Automation

[Dmitry A. Kazakov]

On Tue, 18 Nov 2014 09:52:13 +0100, Björn Lundin wrote:

> Very few sites use OPC, which was believed to be THE way of
> communicating in the early 2000s

Huh.
 
> Talking modbus directly would be nice, but in my field, I don't see
> any of the vendors preferring that to TCP/IP.

ModBus TCP is actually far more wide spread than ModBus RTU.

The design of middleware should support easy developing on new interfaces.
That is the idea of middleware, to decouple the application from the
hardware.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for Automation

[Björn Lundin]

On 2014-11-18 10:28, Dmitry A. Kazakov wrote:
> On Tue, 18 Nov 2014 09:52:13 +0100, Björn Lundin wrote:
> 
>> Very few sites use OPC, which was believed to be THE way of
>> communicating in the early 2000s
> 
> Huh.

Sorry. I'm talking about communication between a host system (WCS) and
a PLC with the purpose of moving pallets on a conveyor.
OPC was something most vendor talked about, but
not to many implemented it. As a transportation layer.
The actual data being passed is different between most if not all vnedors.

>  
>> Talking modbus directly would be nice, but in my field, I don't see
>> any of the vendors preferring that to TCP/IP.
> 
> ModBus TCP is actually far more wide spread than ModBus RTU.
> 
> The design of middleware should support easy developing on new interfaces.
> That is the idea of middleware, to decouple the application from the
> hardware.

Yes, that is why I think Ada for Automation is interesting.
But in practice, i still see the dominating way of this kind of
communication to be TCP/IP with vendor-specific data content.

The standard question, with each new vendor we meet, is
'Can you do this'? and then they hand over a protocol specification -
TCP/IP and a propriatary data content, with a small variation of
* who is server?
* one or two sockets?
* protocol level acks
* re-transmissions (if no nak, timeout and re-send)
*
*
*





--
Björn

Re: Ada for Automation

[Dmitry A. Kazakov]

On Tue, 18 Nov 2014 11:43:12 +0100, Björn Lundin wrote:

> On 2014-11-18 10:28, Dmitry A. Kazakov wrote:
>> On Tue, 18 Nov 2014 09:52:13 +0100, Björn Lundin wrote:
>> 
>>> Very few sites use OPC, which was believed to be THE way of
>>> communicating in the early 2000s
>> 
>> Huh.
> 
> Sorry. I'm talking about communication between a host system (WCS) and
> a PLC with the purpose of moving pallets on a conveyor.
> OPC was something most vendor talked about, but
> not to many implemented it. As a transportation layer.
> The actual data being passed is different between most if not all vnedors.

Because OPC was totally unsuitable for the purpose. It was extremely slow,
hugely difficult to configure and had to run on the same host. Some of the
problems were lifted by the OPC UA, but it is still a monstrosity.

>>> Talking modbus directly would be nice, but in my field, I don't see
>>> any of the vendors preferring that to TCP/IP.
>> 
>> ModBus TCP is actually far more wide spread than ModBus RTU.
>> 
>> The design of middleware should support easy developing on new interfaces.
>> That is the idea of middleware, to decouple the application from the
>> hardware.
> 
> Yes, that is why I think Ada for Automation is interesting.
> But in practice, i still see the dominating way of this kind of
> communication to be TCP/IP with vendor-specific data content.
> 
> The standard question, with each new vendor we meet, is
> 'Can you do this'? and then they hand over a protocol specification -
> TCP/IP and a propriatary data content, with a small variation of
> * who is server?
> * one or two sockets?
> * protocol level acks
> * re-transmissions (if no nak, timeout and re-send)

Not very frequently, but it happens time to time. Unfortunately, fewer than
before, because hardware vendors tend to use "standard" industrial
protocols like EtherCAT, PROFIBUS etc, which are horrific mess and
extremely difficult to implement and no less difficult to configure and
maintain. Implementing a custom TCP/IP based protocol is usually hugely
simpler.

I don't understand "but". In our middleware (which is in Ada) there is a
well defined interface to design new device interfaces. In fact there is a
ready-to use base device type for a custom TCP/IP connection based client.
You would simply override Read and Write abstract operations. All automatic
connection and reconnection stuff is handled by the base type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for Automation

[Björn Lundin]

On 2014-11-18 12:03, Dmitry A. Kazakov wrote:
> Because OPC was totally unsuitable for the purpose. It was extremely slow,
> hugely difficult to configure and had to run on the same host. Some of the
> problems were lifted by the OPC UA, but it is still a monstrosity.

Indeed.

>> Yes, that is why I think Ada for Automation is interesting.
>> But in practice, i still see the dominating way of this kind of
>> communication to be TCP/IP with vendor-specific data content.


> I don't understand "but". In our middleware (which is in Ada) there is a
> well defined interface to design new device interfaces. In fact there is a
> ready-to use base device type for a custom TCP/IP connection based client.
> You would simply override Read and Write abstract operations. All automatic
> connection and reconnection stuff is handled by the base type.
> 

You are right, there should be not but in that sentence.
PLC-to-host communication is simple, stable and robust via TCP/IP and
custom protocols.

However, what I meant was that the OP's library would be very
interesting if I

>>> .... was given the opportunity to do conveyor system logic
>>>in say a raspberry pi, I'd definitely would look closer to you
>>>project.

That is if I was to control motors and read inputs myself.
But there seem to be no market for that, unless you supply the
hardware - as in conveyors/cranes/AGV ets - yourself.



--
Björn

Re: Ada for Automation

[Dmitry A. Kazakov]

On Tue, 18 Nov 2014 13:27:49 +0100, Björn Lundin wrote:

> However, what I meant was that the OP's library would be very
> interesting if I
> 
>>>> .... was given the opportunity to do conveyor system logic
>>>>in say a raspberry pi, I'd definitely would look closer to you
>>>>project.
> 
> That is if I was to control motors and read inputs myself.
> But there seem to be no market for that, unless you supply the
> hardware - as in conveyors/cranes/AGV ets - yourself.

Actually market exists, but it demands a tool chain based rather on models
like SIMULINK than on programming in a decent language.

I know that AdaCore has a product that allows Ada code generation from
SIMULINK models. Together with a middleware to access the hardware and
providing a protocol to communicate the outer world that would get you a
product wich many would buy, since existing alternatives are very expensive
and oriented on hardware vendor lock.

The drawback of such approaches is that they target series products, while
major customers come from R&D. For R&D guys code generation is a very
heavy-weight thing. It requires compiler-linker-uploader tool chain on the
host side and it is too slow for rapid tests and prototyping. Performance
on the controller side is not so critical as portability and speed. If the
controller is portable everything could be done first on a fat i7 and only
then transferred to the board. Thus a far better solution would be some
binary code target uploaded directly into the controller over the network
protocol. Not Java binary code, of course, but something much simpler.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de