[etherlab-users] X Windows Manager & Network Connection?

[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: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 :(

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
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>

Mit freundlichem Gruß

Richard Hacker

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

Richard Hacker M.Sc.
richard.hacker at igh-essen.com
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

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