DAQCArd-700 & DAQCard-1200 comedi drivers appear broken on Ubuntu 13.04 3.8 kernel

[wally_666]

I dug out an old PCMCIA to PCI adapter  to see if the current Comedi would allow be to recycle these old cards. 

I'd already succeeded in getting an old Measurement Computing PCI-DAS-1602/16 to work, so I'm reasonably sure the Comedilib installation (from the repos) is correct.

The PCMCIA adapter was plug and play.  The instructions for manually configuring /dev/comedi0 & /dev/comedi1 were clear and worked fine after reserving two "legacy" driver slots in /etc/modprobe.d/comedi.conf and rebooting.

Problem is that neither card works using comedi_test or the simple inp.c program from the demo directory of the comedilib tarball.

The DAQCard-700 gives: "value range too large for type" on A/D reads.

The DAQCard-1200 "locks up" comedi_test and gives timeout errors reading A/D with inp.c

Are these devices in use by anyone else on a recent kernel?  Or should I just forget about it?

[Ian Abbott]

On 2013-05-07 20:50, wally_666 wrote:
> I dug out an old PCMCIA to PCI adapter to see if the current Comedi
> would allow be to recycle these old cards.
>
> I'd already succeeded in getting an old Measurement Computing
> PCI-DAS-1602/16 to work, so I'm reasonably sure the Comedilib
> installation (from the repos) is correct.
>
> The PCMCIA adapter was plug and play. The instructions for manually
> configuring /dev/comedi0 & /dev/comedi1 were clear and worked fine after
> reserving two "legacy" driver slots in /etc/modprobe.d/comedi.conf and
> rebooting.
>
> Problem is that neither card works using comedi_test or the simple inp.c
> program from the demo directory of the comedilib tarball.
>
> The DAQCard-700 gives: "value range too large for type" on A/D reads.

I don't know where that message comes from. The ni_daq_700 driver only
supports the digital input and digital output ports at the moment,
although somewhat weirdly, it treats them as a single DIO subdevice
instead of separate DI and DO subdevices.

> The DAQCard-1200 "locks up" comedi_test and gives timeout errors reading
> A/D with inp.c
>
> Are these devices in use by anyone else on a recent kernel? Or should I
> just forget about it?

I've no idea, to be honest. The PCMCIA driver interface has changed so
much over recent years that it's possible something broke.

--
-=( Ian Abbott @ MEV Ltd. E-mail: <abb...@mev.co.uk> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-

[wally_666]

I had an old laptop running Ubuntu 10.04 that had a PCMCIA slot.  Installed the comedilib from its repos (8.8.1 I believe).  Reserved one legacy driver slot and rebooted.  Did comedi_config /dev/comedi0 ni_labpc_cs, compiled my simple  timing test code and the DAQCard-1200 appears to work fine, although we only use comedi_data_read/write or instruction lists since support for commands is so far from universal or consistent that it totally breaks using comedi to "abstract" the A/D, D/A & DIO hardware.  Although I admit DIO is damn near impossible to generalize or usefully abstract without crippling features, a limited DIO abstraction works for our needs.

Looks like something has broken the DAQCard-1200 support since Ubuntu 10.04 :(


You are correct, that on 10.04 only a single DIO subdevice is reported for the DAQCard-700, but on 13.04 it reported 16 channels of 12-bit A/D but these didn't work giving the strange "value range too large for type" (I may not have remembered it exactly) error on the comedi_data_read() calls.  Perhaps someone has been hacking on the driver in the current 3.8 kernel?

Is there a "comedi_unconfig" utility?  Since this laptop only has a single PCMCIA slot, I had to reboot to configure the DAQCard-700.

When setting up an instruction list to scan the card's channels, how do I specify the settling time?  I couldn't seem to figure that out, So I've been just scanning the channels in a loop uisng comedi_data_read_delayed().

[wally_666]

Followup, I retried the DAQCard-1200 on 13.04 and using my timing test program and it seems to work OK, but running the comedi_test program in the comedilib/testing directory locks up when doing:  testing cmd_read_fast_1chan.  Also the "cmd" example in the demo directory locks up after printing the start time.

I don't have the 8.1 comedilib source handy to try on the 10.04 system, but I'll try to get to it eventually in case anyone cares.

The DAQCard-700s will head to the boneyard, the DAQCard-1200s might still have some utility since I don't use comedi commands in my code.

[Gilles Detillieux]

Ian, recall that these were the drivers that were giving me grief while
building on RHEL 6 a couple weeks ago. The calls to
pcmcia_request_window() and pcmcia_map_mem_page() were inconsistent in
two sections of the code in each file, with the first section triggering
warnings and errors, and the second not. The first
pcmcia_map_mem_page() call had one more argument than the 2nd, which
caused the error. The first pcmcia_request_window() merely caused a
warning. I have no idea which version of the comedi driver is built
into the 10.04 Ubuntu kernel source, and which section of code it would
end up using, but if the builder ignored some warnings, it's possible
that there's a pointer that's not getting passed properly. It might be
informative to either try rebuilding their kernel source package, or
rebuilding the latest comedi source, on 10.04 to see if any warnings
occur. If the latest source builds cleanly, maybe trying that set of
modules instead of the ones that came with the Ubuntu distro's kernel
modules will work better.

My Ubuntu experience is really quite limited, so I can't really suggest
anything more specific.

--
Gilles R. Detillieux E-mail: <grd...@scrc.umanitoba.ca>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 0J9 (Canada)

[Ian Abbott]

On 08/05/2013 18:13, Gilles Detillieux wrote:
> On 08/05/2013 5:17 AM, Ian Abbott wrote:
>> On 2013-05-07 20:50, wally_666 wrote:
>>> I dug out an old PCMCIA to PCI adapter to see if the current Comedi
>>> would allow be to recycle these old cards.
>>>
>>> I'd already succeeded in getting an old Measurement Computing
>>> PCI-DAS-1602/16 to work, so I'm reasonably sure the Comedilib
>>> installation (from the repos) is correct.
>>>
>>> The PCMCIA adapter was plug and play. The instructions for manually

>>> configuring /dev/comedi0& /dev/comedi1 were clear and worked fine after

>>> reserving two "legacy" driver slots in /etc/modprobe.d/comedi.conf and
>>> rebooting.
>>>
>>> Problem is that neither card works using comedi_test or the simple inp.c
>>> program from the demo directory of the comedilib tarball.
>>>
>>> The DAQCard-700 gives: "value range too large for type" on A/D reads.
>>
>> I don't know where that message comes from. The ni_daq_700 driver
>> only supports the digital input and digital output ports at the
>> moment, although somewhat weirdly, it treats them as a single DIO
>> subdevice instead of separate DI and DO subdevices.

Oh, it appears new kernels do have the AI subdevice for ni_daq_700. In
fact, I submitted changes to add the AI subdevice by adapting the work
of Fred Brooks who implemented it for an older kernel version.

>>> The DAQCard-1200 "locks up" comedi_test and gives timeout errors reading
>>> A/D with inp.c
>>>
>>> Are these devices in use by anyone else on a recent kernel? Or should I
>>> just forget about it?
>>
>> I've no idea, to be honest. The PCMCIA driver interface has changed
>> so much over recent years that it's possible something broke.
>
> Ian, recall that these were the drivers that were giving me grief while
> building on RHEL 6 a couple weeks ago. The calls to
> pcmcia_request_window() and pcmcia_map_mem_page() were inconsistent in
> two sections of the code in each file, with the first section triggering
> warnings and errors, and the second not. The first
> pcmcia_map_mem_page() call had one more argument than the 2nd, which
> caused the error. The first pcmcia_request_window() merely caused a
> warning. I have no idea which version of the comedi driver is built
> into the 10.04 Ubuntu kernel source, and which section of code it would
> end up using, but if the builder ignored some warnings, it's possible
> that there's a pointer that's not getting passed properly. It might be
> informative to either try rebuilding their kernel source package, or
> rebuilding the latest comedi source, on 10.04 to see if any warnings
> occur. If the latest source builds cleanly, maybe trying that set of
> modules instead of the ones that came with the Ubuntu distro's kernel
> modules will work better.

Yes, but you were building the standalone comedi drivers, whereas Wally
was using the "staging" comedi drivers shipped with the kernel.

[wally_666]

Just to bring some closure, the DAQCard-1200 appears to work with comdedi_data_read/write() on 13.04 but actually doesn't.  I managed to find the cable and a break out terminal strip and loopback wired the D/A to the A/D and some DO to DI.  Nothing reasonable is happening on the I/O pins running on Ubuntu 13.04.

Moving the card to the 10.04 laptop and everything actually works as verified by the loopback readings and a voltmeter.

Note that both systems report "Comedi Version Code"  0x00074c as returned by comedi_get_version_code()

Also note that building, but not installing) the comedilib-0.10.1 on Ubuntu 10.04 results in a demo/cmd program that seems to work and a testing/comedi_test that also appears to run correctly.

I'd be willing to test any fixes that might appear for Ubuntu 13.04

I guess one extra complication is my 12.04 & 13.04 systems are 64-bit, the 10.04 laptop is 32-bit.

--wally.

[wally_666]

I don't think the 13.04 problems have anything to do with PCMCIA support or my adapter card.  I manged to find an NI DAQCard-6036E PCMCIA card and its cabling.  It runs the testing/comedi_test and demo/cmd apparently correctly using the PCMCIA to PCI adapter card that didn't work with the DAQCard-1200.  It also works with my timing test code and voltmeter verification.


To answer my own Comedi usage question,   sudo rmmod comedi_config_module_name   is the comedi unconfig command to avoid a reboot when manual configuration is required.  :)

And yes I'm using the staging drivers.  I'm updating my code and training my replacement for my fast approaching retirement and don't want to leave behind code that requires kernel module building voodoo to work.

--wally.

[Ian Abbott]

On 2013/05/08 08:08 PM, wally_666 wrote:
> Just to bring some closure, the DAQCard-1200 appears to work with
> comdedi_data_read/write() on 13.04 but actually doesn't. I managed to
> find the cable and a break out terminal strip and loopback wired the D/A
> to the A/D and some DO to DI. Nothing reasonable is happening on the
> I/O pins running on Ubuntu 13.04.
>
> Moving the card to the 10.04 laptop and everything actually works as
> verified by the loopback readings and a voltmeter.

Looks like something may have broken in the last 4 years.

There have been various changes to the way the PCMCIA device is
configured. For example this patch:

<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/comedi/drivers/ni_labpc_cs.c?id=55a19b39acb8888af8e9cfe5b762d03c52fdb48c>

shows that some extra magic was used in the setting of
'p_dev->io.Attributes1' so that it depends on 'io->flags', whereas the
earlier 'link->io.Attributes1' was previously fixed to the value
'IO_DATA_PATH_WIDTH_8'.

Something small like that could easily be the cause of the problem.
It's all changed again more than once since that patch, but still
determines the data width automatically instead of fixing it to width 8.

The above might not be the problem. I don't know much about PCMCIA
cards, but would it be possible for you to post the output from
`pccardctl info` to see if it provides any clues?

> Note that both systems report "Comedi Version Code" 0x00074c as
> returned by comedi_get_version_code()

Yes, that was the version from the last official, out-of-tree comedi
release and it's never been changed.

> Also note that building, but not installing) the comedilib-0.10.1 on
> Ubuntu 10.04 results in a demo/cmd program that seems to work and a
> testing/comedi_test that also appears to run correctly.
>
> I'd be willing to test any fixes that might appear for Ubuntu 13.04
>
> I guess one extra complication is my 12.04 & 13.04 systems are 64-bit,
> the 10.04 laptop is 32-bit.

64-bit shouldn't be a problem, but you never know!

>
> --wally.
>
>
> On Wednesday, May 8, 2013 10:41:56 AM UTC-5, wally_666 wrote:
>
> Followup, I retried the DAQCard-1200 on 13.04 and using my timing
> test program and it seems to work OK, but running the comedi_test
> program in the comedilib/testing directory locks up when doing:
> testing cmd_read_fast_1chan. Also the "cmd" example in the demo
> directory locks up after printing the start time.
>
> I don't have the 8.1 comedilib source handy to try on the 10.04
> system, but I'll try to get to it eventually in case anyone cares.
>
> The DAQCard-700s will head to the boneyard, the DAQCard-1200s might
> still have some utility since I don't use comedi commands in my code.

If you like, you could lend them to me and I can try and get them
working. I don't know how practical that would be for you though.

[Ian Abbott]

On 2013/05/08 11:51 PM, wally_666 wrote:
> To answer my own Comedi usage question, sudo rmmod
> comedi_config_module_name is the comedi unconfig command to avoid a
> reboot when manual configuration is required. :)

You can also do `comedi_config -r /dev/comedi0` to unconfigure the
manually configured device.

[wally_666]

On Thursday, May 9, 2013 5:46:36 AM UTC-5, Ian Abbott wrote:

 I don't know much about PCMCIA
cards, but would it be possible for you to post the output from
`pccardctl info` to see if it provides any clues?

 

Here is the output of pccardctl info on 13.04, doubt it has anything useful in it:
For DAQCard 6036E on 13.04 (working)

~$ pccardctl info
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=0000,0000
FUNCID=255
PRODID_1="National Instruments
"
PRODID_2="DAQCard-6036E
"
PRODID_3=""
PRODID_4=""
MANFID=010b,0245
FUNCID=255


For DAQCard-1200 on 13.04 (not working)
~$ pccardctl info
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=0000,0000
FUNCID=255
PRODID_1="National Instruments
"
PRODID_2="DAQCard-1200
"
PRODID_3="E
"
PRODID_4="0
"
MANFID=010b,0103
FUNCID=255
 

And for reference on 10.04 where the DAQCard-1200 works:
~$ pccardctl info
PRODID_1="National Instruments"
PRODID_2="DAQCard-1200"
PRODID_3="E"
PRODID_4="0"
MANFID=010b,0103
FUNCID=255

If you like, you could lend them to me and I can try and get them
working.  I don't know how practical that would be for you though.

I'd be happy to send the cards to you if they were mine, but the paperwork to do would be mind numbing,  OTOH the path to the boneyard is slick and easy, where the stuff sits in a warehouse until every last drop of value beyond its recycled material content has evaporated, and then its auctioned off.   :(

Without the breakout connections it would look like the DAQCard-1200 was working in that Comedi throws no errors.

--wally.

[Ian Abbott]

Yes, your right! It doesn't really contain anything useful. :(

It's a shame `pccardctl config` isn't implemented yet (according to the
man page) as that sounds like it would be more useful.

>> If you like, you could lend them to me and I can try and get them
>> working. I don't know how practical that would be for you though.
>
> I'd be happy to send the cards to you if they were mine, but the
> paperwork to do would be mind numbing, OTOH the path to the boneyard is
> slick and easy, where the stuff sits in a warehouse until every last
> drop of value beyond its recycled material content has evaporated, and
> then its auctioned off. :(
>
> Without the breakout connections it would look like the DAQCard-1200 was
> working in that Comedi throws no errors.

Oh well, it was worth a try!

[spam]

On 05/08/2013 12:08 PM, wally_666 wrote:
>
>
> The DAQCard-700s will head to the boneyard, the DAQCard-1200s
> might still have some utility since I don't use comedi commands in
> my code.
>
>
>

I still use the DAQCard-700 on some 32 bit Debian systems for simple
solar energy monitoring so it should still be OK. My simple test program
works with the stock module from the 3.8 kernels.

https://github.com/nsaspook/nidaq700/tree/master/bmc/bmc_x86

[fred brooks]

I just posted a patch that should fix this problem.

[Greg McGee]

I used the one in 3.18.5 or such, has all the latest fixes, and it works fine with Fred Brooks' test program.
It also auto-creates the /dev entry now, saves some manual configuration//headscratching.

Sadly it won't work with apps like xoscope, qtscope etc due to not having the comedi_cmd interface.

This means it will work if you write a program for it, the example Mr Brooks provides is likely a good starting point.

Curious:
Is there a possibility of adding the comedi_cmd structures to the daqcard-700 driver, to allow using it with the various existing virtual instruments out there, or is it just missing to many features in hardware?

I took a pass at it awhile back and it just reminded me I'm thankfully far better working on metal in meatspace than I am at C, or I would have starved long ago.

[Greg McGee]

The driver in the kernel/staging is the most current. Even the latets comedi git repos are ages old by comparison.

[Ian Abbott]

On 16/02/15 06:39, Greg McGee wrote:
> I used the one in 3.18.5 or such, has all the latest fixes, and it works
> fine with Fred Brooks' test program.
> It also auto-creates the /dev entry now, saves some manual
> configuration//headscratching.
>
> Sadly it won't work with apps like xoscope, qtscope etc due to not
> having the comedi_cmd interface.
>
> This means it will work if you write a program for it, the example Mr
> Brooks provides is likely a good starting point.
>
> Curious:
> Is there a possibility of adding the comedi_cmd structures to the
> daqcard-700 driver, to allow using it with the various existing virtual
> instruments out there, or is it just missing to many features in hardware?
>
> I took a pass at it awhile back and it just reminded me I'm thankfully
> far better working on metal in meatspace than I am at C, or I would have
> starved long ago.

It's technically possible. It has the hardware facilities to support
it. There's even a register-level programming manual for it:
http://www.ni.com/pdf/manuals/340698.pdf

The main problem is finding someone with the hardware, skills, and
motivation to implement and test the changes.

--
-=( Ian Abbott @ MEV Ltd. E-mail: <abb...@mev.co.uk> )=-

-=( Web: http://www.mev.co.uk/ )=-

[Greg McGee]

Finally found my daqcard700 and related DAQ cables and stuff after moving 6 years ago.

Had a minor epiphany and realized the 700 is essentially an earlier 1200, same except with fewer voltage ranges, even have same quirk for channel order

Slapped the ids for the 700 into the 1200 driver source and limited the ranges, looks OK.

Now I just need to remember how to ifdef the code so they can coexist in the driver, haven't touched any code other that fixing typos etc in 30 years, wasn't any good at it then, i'm a hardware guy.

It works fine in the expresscard adapter I have in my X201T.