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 <h...@igh.de> Sent: 03 March 2021 00:15 To: etherlab-users@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.hac...@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 ------------------------------------------------------------------------
-- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
