Bernd Porr | 3 May 15:46 2012

Bug#570069: [gudjon <at> gudjon.org: Re: [comedi] libcomedi0 removed from debian testing]

Do you remember why we separated them in the first place? Were there 
some dependency problems? We could def get comedi_calibrate back in with 
the option to enable/disable it. Would make life much easier.
/Bernd

On 03/05/12 14:08, Ian Abbott wrote:
> Oh right, so the problem is due to the debian comedilib source package
> merging the comedi_calibrate sources back in to the comedilib sources.
> If comedi_calibrate had its own debian source package this extra
> configure option wouldn't be needed.
>
> Might be better off avoiding needless extra comedi_calibrate configure
> options and either splitting the debian source package or retro-patching
> the comedi_calibrate stuff back in at the autoconf/automake level,
> basically undoing these two patches:
>
> <http://comedi.org/git?p=comedi/comedilib.git;a=blobdiff;f=configure.ac;h=bcc1ae532bd97c5cdf5444e8923e1c33763d6f90;hp=4740a18a1ac4bba20ec80e04c98823342b8e921b;hb=c632d4e636aa89acd4543aea4d04aa32ac05da94;hpb=d4fd5f7b087d96676f53d3d74fde681baa26270c>
>
> <http://comedi.org/git?p=comedi/comedilib.git;a=blobdiff;f=Makefile.am;h=6abfe2227c32553f416bb13382bba451fb01e10e;hp=8a75b7b587bf413d17477bd9f4cc1c8563cded85;hb=64d90d7f374c64cdce46aff0e397ba35f33563e6;hpb=c632d4e636aa89acd4543aea4d04aa32ac05da94>
>
> On 2012/05/03 01:50 PM, Bernd Porr wrote:
>> I've got this now compiling. As I suspected: first both configure
>> scripts run and then the two makes are run later. To get this to compile
>> also the comedilib header check needs to be disabled. Basically because:
>>
>> comedilib/configure
>> comedilib/comedi-calibrate/configure
>>
>> comedilib/make
>> comedilib/comedi-calibrate/make
(Continue reading)

Yaroslav Halchenko | 5 Apr 15:31 2012
Picon

Bug#570069: [gudjon <at> gudjon.org: Re: [comedi] libcomedi0 removed from debian testing]

Thank you Christoph for the note -- original announcement I guess
have slipped through my mailbox without notice ;)

Gudjon,   I would be glad (whenever time allows) to sponsor the
upload to Debian.  I will look into current package you have -- only 1
major issue I see:   

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570069

if it is usable on kfreebsd then udev depends should be said
[!kfreebsd-amd64] or smth like that OR may be moved into Recommends
altogether, OR just do not build for kfreebsd if it is of no use there
-- I am just ignorant on this subject.  Any input is welcome to help
resolving this.

GIT version --  would be neat (whenever current one gets back into
testing)!

On Thu, 05 Apr 2012, Christoph Schmidt-Hieber wrote:

> Hi Yaro,

> maybe NeuroDebian can come to the rescue here? Comedi is an incredibly
> important package, and it would be a shame to see it vanish from the
> debian repositories.

> Cheers,
> Christoph

> ----- Forwarded message from "Gudjon I. Gudjonsson" <gudjon <at> gudjon.org> -----
(Continue reading)

W. Trevor King | 28 Jan 00:52 2011
Picon

[PATCH] Staging: comedi: Add MODULE_AUTHOR and similar to ni_pcimio.c.

Without this metadata, I got (while running 2.6.36)
  # modprobe ni_pcimio
  FATAL: Error inserting ni_pcimio (/.../ni_pcimio.ko):
    Unknown symbol in module, or unknown parameter (see dmesg)
  # dmesg | tail -n30
  ...
  [ 2970.180691] ni_pcimio: Unknown symbol ni_tio_handle_interrupt (err 0)
  [ 2970.181170] ni_pcimio: Unknown symbol ni_tio_set_mite_channel (err 0)
  [ 2970.183127] ni_pcimio: Unknown symbol ni_tio_init_counter (err 0)
  [ 2970.183562] ni_pcimio: Unknown symbol ni_tio_winsn (err 0)
  (similar missing symbols)
  ...
Even though other Comedi modules were providing the symbols:
  # grep ni_tio_handle_interrupt /proc/kallsyms
  d82a45b1 t ni_tio_handle_interrupt      [ni_tiocmd]

With the metadata macros, ni_pcimio loads successfully.

Signed-off-by: W. Trevor King <wking <at> drexel.edu>
---
 drivers/staging/comedi/drivers/ni_pcimio.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_pcimio.c b/drivers/staging/comedi/drivers/ni_pcimio.c
index 23a3812..dc0548c 100644
--- a/drivers/staging/comedi/drivers/ni_pcimio.c
+++ b/drivers/staging/comedi/drivers/ni_pcimio.c
 <at>  <at>  -1277,6 +1277,11  <at>  <at>  static void __exit driver_pcimio_cleanup_module(void)
 module_init(driver_pcimio_init_module);
 module_exit(driver_pcimio_cleanup_module);
(Continue reading)

Daniele Nicolodi | 17 Jun 11:07 2010
Picon

Re: [comedi] NI 6251 "wrong" samples

Hello. Sorry for the long delay, I had some real work to get done with
the acquisition system and I had to implement a work-around for this
problem...

I have been investigating the issue further, but its random nature makes
this quite difficult.

> The observation that the "wrong" sample occurs on the last sample of the
> scan sounds useful.  Does it occur randomly or on every scan?

I must retire this statement. The "wrong" samples can occur on any
channel. Some are just more probable than other. The "wrong" samples do
NOT occur at each scan, and they look to be completely random in their
occurrence, I'm trying to find a pattern but without luck up to now.

> Also, are you using the TRIG_WAKE_EOS command flag (or equivalently,
> setting stop_arg to TRIG_COUNT and stop_count to 1)?  If so, does the
> wrong sample still occur when the TRIG_WAKE_EOS flag is not set?  (You
> might need to look harder for the wrong samples when TRIG_WAKE_EOS is
> not set, as they might occur much less frequently and they might occur
> at any position in the scan.

No. I'm running a continuous memory mapped acquisition. The only maybe
uncommon thing I'm doing is that I'm reading the mmapped buffer in fixed
chunks, rather than reading all the samples available each time. The
number of samples I read each time is larger than the 4095 samples after
which the hardware sends the FIFO half full trigger event.

Suggestions?

(Continue reading)

Daniele Nicolodi | 4 Jun 19:49 2010
Picon

NI 6251 "wrong" samples

Hello.

I'm working with a NI PCI 6251 ADC board. I configured it to sample
channels 6 and 7, configured as differential analog inputs, at 50 kHz
with a conversion time of 2000 ns. I'm using a Xenomai kernel and the
Analogy drivers, a port of comedi drivers over the Xenomai real time
device driver abstraction layer.

The systems works well (I do not fully understand the properties fo the
noise spectrum of the sample data, see my other email to the mailing
list, but this is quite mynor) except that now and then I receive a
clearly "wrong" sample from the board.

I think I receive a wrong sample because I'm testing the system
acquiring a simple sine wave generated from a function generator, and
sometimes I obtain a sample that is clearly not where expected and I I
hardly believe that the discrepancy is due to physical noise.

I'm unable to identify a pattern of when those "wrong" samples appear in
my output, so I do not believe the issue is due to wrong FIFO
synchronization.

Has someone ever observed a similar behavior? Does someone has a
suggestion on how I can try to investigate it?

Thanks. Cheers,
--

-- 
Daniele
mark@noakes.com | 18 Jan 21:05 2010

ATI force/torque sensor on RTAI/comedi

Is there anyone out there that has done an ATI force/torque sensor 
implementation under RTAI and comedi? I could use some integration 
assistance; please ping me off list.

Thanks,

Mark N
_______________________________________________
Rtai mailing list
Rtai <at> rtai.org
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai

carlos_jimenez | 10 Nov 10:45 2009

RTAI + comedi freezes on flash-disk

Hello,

Sorry for the crossposting, but I don't know where send this problem.

We want to program a National device (NI-PCI6229). We want it to work  
stand alone, so the device has to acquire by itself and alert us each  
time it completes an acquisition.

First of all, we create a task in real time where we program National  
device (comedi_command), and using triggers, it alerts us when it  
finishes an acquisition (rt_comedi_register_callback,  
rt_comedi_command_data_wread). At this point we create another real  
time task that remains suspended (rt_task_suspend) until the first  
task alerts it (rt_task_resume). We collect the data and send it by  
ethernet to another computer.

We have configured the device for a trigger period of 10kHz, acquiring  
4 channels, with an overscan of 4, so we acquire 4 times these 4  
channels reaching 40kHz sample period.

This strategy works correctly with a computer of these characteristics:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping        : 9
cpu MHz         : 2800.300
cache size      : 512 KB
(Continue reading)

∂єєραк >>; | 25 Jun 14:25 2009
Picon

RTAI working well with comedi.....but cannot check overrun of kernel

Hi Guys,

I am really glad to inform you all that my first RTAI/Linux is working fine with comedi after long hard work. I am new in this field but I am learning it well. I would like to thank you all especially who supported me at every problem.

There is one thing I would like to know about while my model executable is running, Can I check my overrun of my kernel because when I tried it says that
insmod:error inserting '/usr/realtime/modules/rtai_sched.ko': -1 Invalid module format
Error: cannot load /usr/realtime/modules/rtai_sched.ko

And it hanged my RTAI/linux completly. I was unable to do anything except restarting my machine.

Kind Regards
DP

_______________________________________________
Rtai mailing list
Rtai <at> rtai.org
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
Guillaume Millet | 13 May 00:32 2009
Picon

[Fwd: [comedi] scicos + rtai + comedi: how to read more encoders?]

Hello,

it's a bug in RTAI-Lab. The Comedi-encoder block was written for NI 
cards whose counters are mapped on subdevices. The comedi driver for the 
s626 board seems to map counters on the channels of a subdevice, I don't 
know whether it's a lack of standardization in comedi drivers or it's 
inherent to the card.

I am surprised it worked on your card for counter 1.
You are lucky that the main configuration function (INSN_CONFIG) is 
similar for your card, that is why it worked.
I changed the code to allow the use of channels instead of subdevices, I 
send it to you (in another mail).

Guillaume

-------- Message original --------

hello everybody,

I'm trying to develop a program aimed at controlling 3 motors in
realtime by using a Sensoray s626 board, driven by comedi drivers,
into scilab/scicos software platform. I used this tutorial -
https://www.rtai.org/RTAILAB/RTAI-Lab-tutorial.pdf - to start working
and everything has gone well up to now.

If I use the counter 0, the program works. When I try to read from the
counter 1, the program automatically shouts down and "the target is
closed". The output follows.
Does anybody know why?

Any help will be appreciate.
thanks

            vito

Target settings
===============
  Real-time : HARD
  Timing    : internal / periodic
  Priority  : 0
  Finaltime : RUN FOREVER
  CPU map   : f

TARGET STARTS.
COMEDI /dev/comedi0 (s626) opened.

Comedi find_subdevice failed (No digital Input)
AO Channel 1 - Range : -10.00 [V] - 10.00 [V]
AO Channel 1 - Range : -10.00 [V] - 10.00 [V]
AO Channel 1 - Range : -10.00 [V] - 10.00 [V]
Find subdevice failed (No Counter 1)
Counter 1 - MaxData : 16777215 - Initial value : 0 - Index enable : 1
Mode UP/DOWN - Channel A on PFI3 - Channel B on PFI11

Model : SuperBlock .
Executes on CPU map : f.
Sampling time : 1.000000e-01 (s).
Target is running.

COMEDI Counter /dev/comedi0 closed.

Meter METER2 closed
Target has been stopped.
TARGET ENDS.

--

-- 
Guillaume Millet

Institut des Systèmes Intelligents et de Robotique
Université Pierre et Marie Curie - Paris 6
Tel : +33 1 44 27 63 79

_______________________________________________
Rtai mailing list
Rtai <at> rtai.org
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai

Riccardo FABBRIS | 24 Apr 12:32 2009
Picon

Problem with Comedi configuration

Hi all,
I installed Comedi 0.7.76 following "RTAI-Lab tutorial: Scilab, Comedi, and real-time control" without
any error and I tried to configure my DAQ card but:

root <at> costa-desktop:/usr/local/src/comedi-0.7.76# modprobe adv_pci1710
root <at> costa-desktop:/usr/local/src/comedi-0.7.76# comedi_config -v /dev/comedi0 adv_pci1710
configuring driver=adv_pci1710 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
Configure failed!: Input/output error
Check kernel log for more information
Possible reasons for failure:
  Driver not found

I had already load Rtai modules and the ones of Comedi:

insmod /usr/rtbucher/modules/rtai_hal.ko
insmod /usr/rtbucher/modules/rtai_up.ko
insmod /usr/rtbucher/modules/rtai_fifos.ko
insmod /usr/rtbucher/modules/rtai_sem.ko
insmod /usr/rtbucher/modules/rtai_mbx.ko
insmod /usr/rtbucher/modules/rtai_msg.ko
insmod /usr/rtbucher/modules/rtai_netrpc.ko ThisNode="127.0.0.1"
insmod /usr/rtbucher/modules/rtai_shm.ko
insmod /usr/rtbucher/modules/rtai_signal.ko
insmod /usr/rtbucher/modules/rtai_tasklets.ko
modprobe comedi
modprobe kcomedilib
modprobe comedi_fc

The card is working (I tried it before installing) and it's a Advantech PCI-1711, I'm working with RTAI
3.6.2 on a vanilla Linux 2.6.24.7.

Do I have to load other modules? Do I have to do other things?
Any suggestion will be appreciated,
Thanks,
Riccardo
_______________________________________________
Rtai mailing list
Rtai <at> rtai.org
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
Alessio Igor Bogani | 24 Apr 11:28 2009
Picon

RFC about Comedi on a patch that remove a lot fo code

Dear Comedi developers,

Sorry for my bad english.

I would be happy to receive your considerations about that patch:

http://marc.info/?l=linux-next&m=123792129500760&w=2

I know that some users use Comedi on dual kernel approach systems.
Obviously I don't have any against this but i think that Linux git
tree isn't the right place to support those software (RTAI, Xenomai,
RTLinux and others). Those projects already released patches against
Linux source code so it very easy for them add also patch for Comedi
drivers in the same tarball.

At the already listed 8 reasons  in that email I want added a ninth one:
9) Give more chance for interested developers to fix it against RT_PREEMPT
http://marc.info/?l=linux-rt-users&m=124049407712792&w=2

Thanks!

Ciao,
Alessio

Gmane