MSeries examples dont' run correctly in QNX?

[bueth]

I am developing an analouge input driver for QNX Neutrino 6.4.1, for the PCI6220.  As an initial test, I compiled the aiex1 example, and tried to run it with the card connected to a connected Force Torq sensor interface.  The program seems to loop infinitely in the test function arround line 131, while checking the FIFO empty state.  The program generates no output.  Aiex2 generated promising looking output once when running immediately after aiex1 (~16 samples before assumedly entering an infinite loop), thereafter generating only (what happened to be) the first of the origonal promising looking ~16 samples (the number is 10.57563, which is the same even after a hard system restart, and whether or not the sensor is attached).  Aiex3 outputs the same value as Aiex2, over and over, no matter what I set numchannels to.

The bus and device numbers seem to be correct based on lsdaq.  Am I doing something wrong, or is this some kind of bug?  If it's a bug, what might it be, or where might it be?  Any ideas at all on how to make this work?  Any questions I could answer that would help narrow it down?

[JoeFriedchicken]

Hi bueth,

The first two things I would check are

1. the 622x-specific calls you need to make/change in the examples;
2. error messages from the QNX kernel.

622x-specific calls
These changes are outlined in the comments for the examples. For aiex1.cpp:

• Line 42: 622x boards needs to be personalized with tMSeries::tAI_Output_Control::kAI_CONVERT_Output_SelectActive_High
• Line 46: 622x boards do not need to have their ADC reset

Error messages
If the examples make correct calls for the 6220, then I would look for errors in memory mapping the board. Look at acquireBoard() from osiUserCode.cpp, and you'll see how we detect and attach to the device. Once we have a handle on the device, we attempt to map its registers to memory. If that fails, you'll see errors printed in the logs and writes/reads to the board will be undefined.

But, given that lsdaq works and the examples don't tell you that they couldn't access the PCI device, it's highly unlikely that acquireBoard() is failing and more likely that the board hasn't been initialized correctly.

[bueth]

Thanks Joe,

You are correct.  It seems that the board wasn't correctly initialized.  After correcting the two mentioned lines, the example seems to be running fine.  I guess I had assumed these sort of board specific diffrences had been abstracted away with device ID checks, because they had been in the last library I worked with - I should read more carefully.  Thanks for humoring me, and solving a problem I'm sure you've already solved 100 times.

Cheers,

Bueth

[JoeFriedchicken]

Excellent 🙂 I'm glad to hear that things are unstuck again.

[wan_anne]

Hi everyone,

I want to use the NI M-series DAQ to acquire analog inputs from a force sensor in QNX OS environment. As I know there is no driver for QNX. Do I need to develop my own driver to make it work in QNX? Is there any guideline, tutorial or example that I can follow in order to make it work in QNX? Hope somebody can help me. Thank you.

[JoeFriedchicken]

Hi wan_anne,

Yes, in order to control an M Series device in QNX, you will need to write your own driver. The MHDDK shows how to program the hardware via a collection of example applications, and it also provides a simple OS extension to get access to the hardware from an application. Keep in mind that the DDK is meant to show how the hardware works and is not a fully-featured driver [1].

To get started, download the M Series DDK as well as the QNX OS Interface component from the MHDDK Downloads page:

Register Level Programming for OEM Customers
http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument

[1] Re: Any updates to the DDK for USB-600x/QNX since 2007?

http://forums.ni.com/t5/Driver-Development-Kit-DDK/Any-updates-to-the-DDK-for-USB-600x-QNX-since-200...

[bueth]

I relatively recently completed code for an application that does (among other things) exactly what you describe - acquire data for a force torque sensor in qnx on the m-series card.  With what I believe was an over-understanding of register level programming, I was able to complete this part of the application using code very similar to the example code, and then cannibalizing the sensor-specific code provided by the sensor vendor to get the correct transformation matrix.  

If you can provide me with an email address, I may be able to provide you with working code.  I work in an academic environment, but I don't know our policy.

[wan_anne]

Hi Bueth,

Thank you for your reply. I'm glad somebody have done similar thing. 

Can you send me the working code? This is my e-mail address w.n.wan-zakaria@ncl.ac.uk.