Hi Ian,
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!
Richard
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
Ian R.K. Norton
System Support Engineer
Aircraft Engineering
Cranfield Aerospace Ltd
Cranfield
Bedford MK43 0AL
UK
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:[email protected]]
Sent: 04 February 2013 14:44
To: Ian Norton
Cc: [email protected]
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
Ian R.K. Norton
System Support Engineer
Aircraft Engineering
Cranfield Aerospace Ltd
Cranfield
Bedford MK43 0AL
UK
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:[email protected]]
Sent: 04 February 2013 13:12
To: Ian Norton
Cc: [email protected]
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 :(
Regards
Richard
Am 02/04/2013 12:06 PM, schrieb Ian Norton:
Hi,
I have a very strange problem.
I'm running V1.5 in user mode. My app clocks the bus at 1KHz with
ecrt_domain_queue/ecrt_master_send
/ecrt_master_receive/ecrt_domain_process and get my data back with
EC_READ's.
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
none.
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?
regards
Ian R.K. Norton
System Support Engineer
Aircraft Engineering
Cranfield Aerospace Ltd
Cranfield
Bedford MK43 0AL
UK
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'
************************************************************
DISCLAIMER:
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
[email protected]
http://lists.etherlab.org/mailman/listinfo/etherlab-users
Mit freundlichem Gruß
Richard Hacker
Mit freundlichem Gruß
Richard Hacker
Mit freundlichem Gruß
Richard Hacker
--
------------------------------------------------------------------------
Richard Hacker M.Sc.
[email protected]
Tel.: +49 201 / 36014-16
Ingenieurgemeinschaft IgH
Gesellschaft für Ingenieurleistungen mbH
Heinz-Bäcker-Str. 34
D-45356 Essen
Amtsgericht Essen HRB 11500
USt-Id.-Nr.: DE 174 626 722
Geschäftsführung:
- Dr.-Ing. T. Finke,
- Dr.-Ing. W. Hagemeister
Tel.: +49 201 / 360-14-0
http://www.igh-essen.com
------------------------------------------------------------------------
_______________________________________________
etherlab-users mailing list
[email protected]
http://lists.etherlab.org/mailman/listinfo/etherlab-users
