[etherlab-dev] ethercat-1.5: Various issues

[Frank Heckenbach]

Florian Pose wrote:

> Hello Gavin and others,
> 
> I really appreciate your work from the past months and I feel a little
> uncomfortable because I did not find the time to include your patches in
> the repository. Let me express, that I'm really willing to change that.
> 
> Then I would start to merge the numerous patches from the list. Since
> some of you are deeply involved and made experiences with testing the
> patches already, may I suggest that you post a short summary, which
> patches exactly you personally would like to be merged and the results
> of the tests.

In case you're including me with "others", my answer is simple: I
need all of the patches I posted. I didn't make them for fun, but to
solve actual problems.

As I said, I will revisit our EtherCAT project. I don't know yet
when, but probably in a couple of weeks to months. If by then there
is a newer versions with my patches (or equivalent) included, I
might test it (and if successful use it) with our project. What I
won't do is start with a half-way applied version and try to merge
the rest of my patches again, simply because my client won't pay me
to do that (they have a working version, so why pay for an upgrade
that doesn't seem to improve anything).

Of course, I'd prefer if you didn't just blindly merge my patches
(or accept Gavin's merges), but read my comments about them, in
particular
http://lists.etherlab.org/pipermail/etherlab-users/2011/001271.html
http://lists.etherlab.org/pipermail/etherlab-users/2011/001272.html
http://lists.etherlab.org/pipermail/etherlab-dev/2014/000378.html
and reply to some questions I raised, especially about the locking
(io_sem, see #19), callbacks (#20) and RTAI (#21, #22). As I wrote,
in some cases I don't really understand your intentions (and you
might not understand mine), so a satisfactory solution will require
some discussion I suppose.

> I just want to make sure, that I'm not committing older
> versions, or things that will break functionality for others.

Of course they wil break some things, e.g. there are API changes for
the callbacks (#20), dictionary fetched (#28) and possibly locking
mechanisms, but IMHO that's necessary to fix things, as I described.

If those changes (or equivalent) are no option to you, I'm afraid
we'll have to agree to disagree, i.e. I keep using my fork and won't
really care what you do in your version, sorry. (This might have
been prevented if there was communication in 2011, but as you know,
there wasn't.)

Regards,
Frank

-- 
Dipl.-Math. Frank Heckenbach <f.heckenbach at fh-soft.de>
Stubenlohstr. 6, 91052 Erlangen, Germany, +49-9131-21359
Systems Programming, Software Development, IT Consulting