writeDigPort example didn't work

[WM_John_Weeks]

I am working with NI-DAQmx Base for OS X, 1.4.0f2. I tried running the example program writeDigPort using a PCI-6014. The result was the following output:

[Rumble:NI-DAQmx Base/examples/dio] johnweek% ./writeDigPort
Data to write: 0x55
openDevice(PXI6::3::0): Error opening nirlpdrvk.
openDevice(PXI6::3::0): Error opening nirlpdrvk.
DAQmxBase Error: 15

I don't see anywhere in the example code where the two lines starting "openDevice" are output, so this must be coming from NI-DAQmx Base itself. It would seem that output from the library like this would be a bug.

The error code isn't one of the -2xxxxx numbers, so it must also be an internal code that has escaped from the library.

Should this example run on a PCI-6014?

[PatFord]

What does lsmod return ( there should be a line that looks like
nirlpdrvk 4724 0 (used)

Pat

Message Edited by PatFord on 04-08-2005 01:52 PM

[WM_John_Weeks]

I'm working on Mac OS X. It doesn't appear to have an lsmod; that appears to be a Linux thing.

[AlanArmstead]

Have you run lsdaq, to ensure proper installation of your device? Do any other examples work? Analog in or out or digital in? Are you using a dynamic or static version of Write Dig Port? To use a static example, you will need to have a DAQmx Base digital output task created in the DAQmx Base Task Configuration Utility. You will then input the name of that pre-created task. To use a dynamic example, you will use physical channel names like "Dev1/port0".
-Alan A.

[WM_John_Weeks]

---

@Alan A. wrote:
Have you run lsdaq, to ensure proper installation of your device? Do any other examples work? Analog in or out or digital in? Are you using a dynamic or static version of Write Dig Port? To use a static example, you will need to have a DAQmx Base digital output task created in the DAQmx Base Task Configuration Utility. You will then input the name of that pre-created task. To use a dynamic example, you will use physical channel names like "Dev1/port0".
-Alan A.

---

I have run lsdaq, and my board appears in the list. I have done quite a few other things with the board, including my own DIO port reads/writes, using the static read/write function DAQmxBaseXOP_ReadDigScalarU32() or DAQmxBaseXOP_WriteDigScalarU32(). The example cited in my initial post does not use the Scalar version; it uses a 1-sample buffer instead.

I know that buffered digital I/O on my board (PCI-6014) is not supported using DAQmx Base, and it looks like I can't use the buffered functions with a 1-sample buffer, either.

My post was really about the fact that running the example results in output that should have been caught before I saw it, and turned into one of the official error messages. I was also interested to know if a 1-sample write should work on the PCI-6014, where buffered digital I/O is not supported.

[AlanArmstead]

John,
I have been able to run the Write Dig Port.vi shipping example, without receiving any error message using a PCI-6014 on a Mac OS X machine. I ran both the static and dynamic examples successfully. Did you run the example without modifying it? You are correct that your board only supports software-timed port input and output (no buffered digital i/o). I'm not sure what you did to receive the error, but it certainly should not have occurred. Perhaps you need re-install DAQmx Base.
-Alan A.

[WM_John_Weeks]

Well, wouldn't you know it, I just re-ran the writeDigPort.c example program and it worked. Maybe the problems I wrote about way up there at the top were caused by some sort of device contention problem (I am working on my own code at the same time).

So now at least I have some indication that 1-sample writes are OK.

The fact remains, though, that NI-DAQBase on my machine got into some sort of state where it was exposing something that I am certain I wasn't supposed to see. Sort of like seeing the driver's underwear...

Thanks for your efforts!

[WM_John_Weeks]

OK- I've just tried another example and got the original (obscure) message. It seems that is the response if I try to access DAQmxBase from two different programs.

I see that the Read Me file says that it is not multi-thread safe. It doesn't say anything about two different processes trying to access the driver. I guess you just can't do that, eh?

I still think it's a bug to report the problem with that sort of message.

[AlanArmstead]

So it is sort of implied that two separate programs will be executing in separate threads. You are correct that you can't have those separate programs making DAQmx Base API calls simultaneously. As to the error, it looks like you got some junk, but eventually got Error 15, which is a known error listed in the readme.
-Alan A.

[WM_John_Weeks]

---

@Alan A. wrote:
So it is sort of implied that two separate programs will be executing in separate threads. You are correct that you can't have those separate programs making DAQmx Base API calls simultaneously. As to the error, it looks like you got some junk, but eventually got Error 15, which is a known error listed in the readme.
-Alan A.

---

It sure enough is in the Read Me. The description is a bit obscure, though:

MHDDK ERROR & WARNING CODES
15
Resource Not Found - The application cannot get access to the hardware. Occurs if the DAQ
device is not installed on the PDA or the reference to the hardware is invalid. For an
invalid reference, restart LabVIEW.

Ahhhh..... MHDDK must refer to the Hardware register DDK... That's why it's no in the usual numeric range.

But Resource Not Found, well, really the resource was unavailable because it's in use...

Thanks, Alan!