[Etherlab-users] Fw: Master malfunctions after a few runs of a program

[j.sikorski at utwente.nl]

Hi Richard,

This is actually a stunningly obvious and powerful suggestion that I completely overlooked. Thank you a lot.
I will do exactly that. Should post again within this thread once I get down to it. May take a week or two, as this is not the only project I'm handling atm.

And honestly, after dealing with the master for years now, I rather expect my code or the hardware (slaves or the network card) to be the source of the problem.
But I will see after I get the "hello world" running.

Best,
Jakub


________________________________
From: Richard Hacker <ha at igh.de>
Sent: 03 March 2021 00:15
To: etherlab-users at etherlab.org
Cc: Sikorski, J. (ET)
Subject: Re: [Etherlab-users] Fw: Master malfunctions after a few runs of a program

Hi Jakub,

You seem to be using an application with quite a distributed and
sophisticated functionality -- sorry if I'm treading on your feet there!

This is certainly necessary when you want to reuse code the way you are
doing, but to debug it when things don't work out becomes increasingly
more difficult. On an philosophical note: nothing is for free ;)

You say it had been working in a number of previous applications.
Unfortunately even that may go wrong. As Einstein once said:
No number of experiments can prove my theory right, but it takes only
one to prove it wrong!

What it boils down to is: you will have to reduce your code to a
straight forward, no frills and dingbats, three liner straight forward
C-type hello world:
1) get resources
2) configure
3) activate
4) run in cyclic mode
in the sense of the provided examples (ok that was four lines ;) )

I am not postulating that the master is exempt from bugs even though it
is running on thousands of applications (see above), but when you're
juggling with C-type pointers you can get silent corruption in places
that you never expected. The fact that the master hangs is certainly not
right, but you'll only find it when one side (your application) is
completely predictable.

On a side note: recently I was involved in slave development. My master
was also coughing and I thought it was due to my code on the slave. It
boiled down to my network adapter (Intel I219-V) on the master trying to
be clever by bundling frames together before passing them to the kernel
(aka master). A disaster for real time applications! But my three-liner
helped reducing the possible failure space.

Happy coding!
Richard

Mit freundlichem Gruß

Richard Hacker

--
------------------------------------------------------------------------

Richard Hacker M.Sc.
richard.hacker at igh.de
Tel.: +49 201 / 36014-16

Ingenieurgemeinschaft IgH
Gesellschaft für Ingenieurleistungen mbH
Nordsternstraße 66
D-45329 Essen

Amtsgericht Essen HRB 11500
USt-Id.-Nr.: DE 174 626 722
Geschäftsführung:
- Dr.-Ing. Siegfried Rotthäuser
- Dr. Sven Beermann, Prokurist
Tel.: +49 201 / 360-14-0
http://www.igh.de

------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20210302/55c78600/attachment.htm>