[etherlab-users] X Windows Manager & Network Connection?
ha at igh-essen.com
Tue Feb 5 09:17:35 CET 2013
If you want real time, you are not allowed to do anything that will
cause page faults in the entire process. Page faults could be caused by
anthing where data is transferred: network, disk, pipes (although I have
heard of setups where pipes work, but I am not convinced of its
guarantee to work).
In a real time application you:
1) Initialize everything
2) Get all your memory
3) perform mlockall()
4) Go into cyclic mode and don't cause page faults
If you want your application to talk to the world, you will need to
create a setup of two processes talking via shared memory. On the one
side your real time application and on the other the "offline", page
faultable process. Yes, there are 2 processes! Threads don't work.
(Beware that the offline process does not have all memory locked with
mlockall(), otherwise it will explode sometime too)
I cannot explain why your previous setup worked, but that is the problem
about guarantees: if you do not fulfill the prerequisites, you _may_
loose, usually when it's most unexpected ;)
We have developed a range of libraries that will help you in your
endeavor. On the server (real time) side, you use pdserv and for the
client (gui) you use pdcom. Take a look at our website: www.etherlab.org.
The two libraries talk to each other via network sockets (so you get
remote access via internet for free). It will take you some programming,
but I looks as if that is not a problem for you!
Am 02/04/2013 04:50 PM, schrieb Ian Norton:
> Hi Richard,
> I guess that's a true statement.
> Are you saying the process that drives the master cannot do anything else in another thread?
> By the way I'm using Centos 6.3.
> I've never had any issues at all before. In fact, on all other systems I can run some heavy real time graphics in the GUI (same process) on a system with 4 motors and 32 ADC/DAC channels. It's totally reliable and continues to operate smoothly. I dont see why changing the AMP should change the system's operation.
> Florian has worked on my app. He never hinted about the X-Server point.
> In my tests at the moment, the GUI is really quiet. i.e. no i/o going on.
> Ian R.K. Norton
> System Support Engineer
> Aircraft Engineering
> Cranfield Aerospace Ltd
> Bedford MK43 0AL
> Tel - +44 (0) 1234 754926
> Fax - +44 (0) 1234 752375
> 'All technology information within this Email has been Exported from the United Kingdom under Open General Export Licence (Technology for Military Goods) - BIS Reference: GBOGE2008/00462'
> -----Original Message-----
> From: Richard Hacker [mailto:ha at igh-essen.com]
> Sent: 04 February 2013 14:44
> To: Ian Norton
> Cc: etherlab-users at etherlab.org
> Subject: Re: [etherlab-users] X Windows Manager & Network Connection?
> Hello Ian
> But it does look like you are talking to the X-Server from within the
> same process (Note: process, which includes its threads!) that is also
> handling EtherCAT. Am I correct?
> Am 02/04/2013 03:02 PM, schrieb Ian Norton:
>> Hi Richard
>> No, no, no.
>> I'm not in real time, it's not important. I just have a thread that ticks away at 1Khz and calls the relevant master routines. In the the millisecond between ticks I calculate a few things and control the motor. The X windowy bit is just for the programs GUI, and doesn't do much. There's no graphics in the data acq thread.
>> Data calulated in the 1 khz thread is passed to other threads which display a few numbers etc on the GUI.
>> It all been working fine for 3 years. Only since using the AKD has the issue arisen.
>> I just happened to notice that doing something with the window managed seemed to release data into my program.
>> It's as though something is blocked in the bus master?
>> How can the master give me the same data for seconds at a time? It's as though a network packet has not been sent and I just get the last data that came through.
>> Ian R.K. Norton
>> System Support Engineer
>> Aircraft Engineering
>> Cranfield Aerospace Ltd
>> Bedford MK43 0AL
>> Tel - +44 (0) 1234 754926
>> Fax - +44 (0) 1234 752375
>> 'All technology information within this Email has been Exported from the United Kingdom under Open General Export Licence (Technology for Military Goods) - BIS Reference: GBOGE2008/00462'
>> -----Original Message-----
>> From: Richard Hacker [mailto:ha at igh-essen.com]
>> Sent: 04 February 2013 13:12
>> To: Ian Norton
>> Cc: etherlab-users at etherlab.org
>> Subject: Re: [etherlab-users] X Windows Manager & Network Connection?
>> Hello Ian
>> Are you trying to get an application running in real time to talk to
>> your X-screen? If that is true, you're in for trouble IMHO :(
>> Am 02/04/2013 12:06 PM, schrieb Ian Norton:
>>> I have a very strange problem.
>>> I'm running V1.5 in user mode. My app clocks the bus at 1KHz with
>>> /ecrt_master_receive/ecrt_domain_process and get my data back with
>>> Devices on the bus vary, but include Kollmorgen S300, Festo pressure
>>> regulators, Beckhof ADC/DAC. I have 7 systems working fine in the field.
>>> So now we've upgraded the Kollmorgen S300's to AKD drives. Fairly
>>> straightforward move you might think.
>>> Not so! After an internal initial homing process, the angular positional
>>> data returned from the drive would not show any change, even though the
>>> attached motor was turning. After a time (variable, and anything from .5
>>> secs to 10 secs), a new value would be returned which is massively
>>> different from the previous "static" value, now reflecting the true
>>> position of the motor.
>>> My app is an X windows program, and by chance I noticed that if I
>>> perfomed a Window manager function, i.e. move a terminal window on top
>>> of my app, it kick started new data to be retrieved from the bus!?
>>> The code driving the bus has a heartbeat, which never misses a beat,
>>> even when returned data is not changing, so I'm happy the ecrt routines
>>> are being called continuously.
>>> I use ecrt_master_state and ecrt_domain_state to look for errors but get
>>> So I'm wondering how the master can return the same data to me when it
>>> is clearly changing at the device. After all, with no errors, it must
>>> think data has been exchanged.
>>> And, why does an X window manager kick a transfer off? How can it be
>>> linked to the network?
>>> Anyone had similar issues?
>>> Ian R.K. Norton
>>> System Support Engineer
>>> Aircraft Engineering
>>> Cranfield Aerospace Ltd
>>> Bedford MK43 0AL
>>> Tel - +44 (0) 1234 754926
>>> Fax - +44 (0) 1234 752375
>>> 'All technology information within this Email has been Exported from the
>>> United Kingdom under Open General Export Licence (Technology for
>>> Military Goods) - BIS Reference: GBOGE2008/00462'
>>> This email and any attachments are confidential to the intended
>>> recipient and may also be privileged. For those other than the recipient
>>> any disclosure, copying, distribution, or any action taken or omitted to
>>> be taken in reliance on such information is prohibited and may be
>>> unlawful. If you are not the intended recipient please delete it from
>>> your system and notify the sender immediately by telephoning +44(0) 1234
>>> 754978 or by immediate reply via e-mail to the Sender.
>>> Should the content of this Email, including any attachments, require an
>>> Export Licence, this shall have been registered in compliance with
>>> export controls laid down by the UK Export Control Organisation, which
>>> forms part of the UK Department for Business, Innovation and Skills (BIS).
>>> Emails and other electronic communication with Cranfield Aerospace may
>>> be monitored.
>>> Thank you.
>>> Cranfield Aerospace Limited Registered in England No. 2415720 Registered
>>> Office: Cranfield University, Cranfield, Beds, MK43 0AL
>>> Updated 14-July-2010
>>> Disclaimer added by *CodeTwo Exchange Rules*
>>> www.codetwo.com <http://www.codetwo.com>
>>> etherlab-users mailing list
>>> etherlab-users at etherlab.org
>> Mit freundlichem Gruß
>> Richard Hacker
> Mit freundlichem Gruß
> Richard Hacker
Mit freundlichem Gruß
Richard Hacker M.Sc.
richard.hacker at igh-essen.com
Tel.: +49 201 / 36014-16
Gesellschaft für Ingenieurleistungen mbH
Amtsgericht Essen HRB 11500
USt-Id.-Nr.: DE 174 626 722
- Dr.-Ing. T. Finke,
- Dr.-Ing. W. Hagemeister
Tel.: +49 201 / 360-14-0
More information about the Etherlab-users