6224

[lorenze]

I've coded an RTX driver following the flow in example aiex1.cpp.  Setup for 7 channels.  Implemented all except I did not implement the aiGetScalingCoefficients.  Is it required?  What is it?
 
What changes are needed to setup for single ended common ground, instead of differential?  Is it necessary to have a voltage present on the 6224 during integration testing?
 
After initialization the JOINT_STATUS_2 returns 0x90 indicating that AI_Scan_In_Progress_St, and AI_EOC_St, and never clears.
 
Can't read from the FIFO unless the AI_Scan_In_Progress_St clears. 

Since NI doesn't provide a manual I have no idea what this means, except that these flags never clear. 

So where is the FIFO data?  Why are we using a FIFO.   Is there a mapped memory option instead?  I am not using DMA.

What exactly is flush call used in example code?  Are delays required between register commands?  Single stepping through the code gives the same JOINT_STATUS_2 status.

The example code calls write/read methods.  Does every write put zeros in non specific register bits?

Do you have a direct register accessing sequence with HEX inputs which shortcuts the labored methods used in the examples?  All I want is to read 7 analogs on demand at 100Hz.

Hope someone has answers.  Thanks.

[Tom_W_[DE]]

Hi Lorenze-

Let me see if I can help with your questions:

1.  aiGetScalingCoefficients() is used to interpret the raw EEPROM scaling coefficient values and determine the polynomial scaling parameters to be used as shown in aiPolynomialScaler() .  It is absolutely necessary to implement this function in order to achieve the accuracy specified for the device.  Without applying the scaling coefficients, the readings returned will not be calibrated.

2.  In order to use RSE, NRSE, or any other reference configuration you only need to change the settings you program in aiConfigureChannel(), specifically the 'channelType' parameter.  Valid values for this parameter are shown in tMSeries.h:

typedef

enum {
kAI_Config_Channel_TypeCalibration = 0,
kAI_Config_Channel_TypeDifferential = 1,
kAI_Config_Channel_TypeNRSE = 2,
kAI_Config_Channel_TypeRSE = 3,
kAI_Config_Channel_TypeAux = 5,
kAI_Config_Channel_TypeGhost = 7,
} tAI_Config_Channel_Type;

3.  It's a good idea to have a voltage present during your testing so that you can verify that the readings returned are correct and accurate.

4.  AI_Scan_In_Progress_St may remain set if your AI_STOP signal has not occurred or has not been correctly recognized.  Did you implement aiSampleStop()?  Which settings did you use for the bitfields contained therein?

5.  We always use a FIFO with AI to provide some buffer because of the scanning nature of the device.  For programmed I/O (aka software-timed) operation, you should use the method shown in aiStartOnDemand() to initiate a single scan, then use this method (from aiex1.cpp) to read the data channel-by-channel out of the FIFO:

m = 0;

while ( m < numberOfChannels )
{
   if(!board->AI_Status_1.readAI_FIFO_Empty_St())
   {
      value = board->AI_FIFO_Data.readRegister ();
      aiPolynomialScaler (&value, &scaled, &scale);
      printf ("%e,\n", scaled);
      m++;
   }
}

6.  The flush() methods in the example code are used whenever multiple bitfields of the same register are to be updated at once.  The ChipObject files provide this interface; they give the write() methods to perform immediate updates on individual bitfields or registers and set()/flush() methods for batch operations.  There are few software delays required between operations, but status bits are polled in the examples whenever necessary.  For example:

while

( board->Joint_Status_2.readAI_Scan_In_Progress_St())
{
// waiting for scan to complete
}

7.  The write()/read() methods for bitfield access are designed to only read from or update the specific bitfields indicated by the method.  For write() operations, the other bits in the register are not modified.  For read() operations, the data returned that corresponds to other bits in the register is invalid.

The examples provided in the MHDDK are currently our only and best source of help for programming M Series devices.  Does the "stock" aiex1.cpp work for you under RTX?  Can you please elaborate on any problems you have running that example out of the box?

Hopefully this helps-

 

[lorenze]

I implemented the stock aiex1.cpp and aiex2.cpp under RTX.

Both run OK except the resulting reads (aiex1) always return 00007fff  (1.062319e+001). I've applied 5 to 10 volts on a few different pins on the SCB-68 breakout box, e.g., 10V to pin 68, Rtn to Pin 67.  Also tried changing the Config_Channel_TypeRSE, otherwise stock aiex1, except adcReset is commented out, and using 0 for gain in aiConfigureChannel.  None of these changes had any apparent effect.

Added a counter in the readAI_Scan_In_Progress_St loop.  It takes up to 500 cycles for the Scan to complete (all 32 channels).  That is a lot for a real time application.  How can I speed that up?

Any ideas?

[Tom_W_[DE]]

Hi lorenze-

You may also want to check the setting for AI Convert Polarity in aiPersonalize().  From ai.h, the allowable settings vary by device as follow:

// aiPersonalize AI output control parameter
//
// NI 622x --
// tMSeries::tAI_Output_Control::kAI_CONVERT_Output_SelectActive_High
//
// NI 623x --
// tMSeries::tAI_Output_Control::kAI_CONVERT_Output_SelectActive_High
//
// NI 625x --
// tMSeries::tAI_Output_Control::kAI_CONVERT_Output_SelectActive_Low
//
// NI 628x --
// tMSeries::tAI_Output_Control::kAI_CONVERT_Output_SelectActive_Low
//

One reason your scan may be taking a long time to complete is that your ai/ConvertClock may be running slowly.  The default setting in the examples is for an ai/ConvertClock divisor of 280.  This results in an ai/ConvertClock rate of 20M / (280) ~= 71428 Hz.  You can increase this rate, up to a divisor of 80 (as listed in ai.h).  This would result in an ai/ConverClock rate of 250kHz and should speed up your loop rate accordingly.

[lorenze]

The settings of 80 and 3 in aiConvert brought the wait loops down to around 60, good enough.

The select active High in aiPersonalize gives me readings.  Going across 67 and 68 on connnetor 0 should be AI channel 0.  The card always reads 4.8 for that channel no matter what voltage is input.  The other 15 channels are all over the map (reading from 1 to 5).  Something else is apparently wrong. 

[lorenze]

Tom W.

I have enough to implement what I need.

The M series manual has some useful information about how the card works. The example code didn't work out of the box because of the 6224 personality.  The RTX code seems solid.  My only gripe is that no RLP manual is available.

Thanks for your help. 

L Goering

[Tom_W_[DE]]

Hi lorenze-

Apologies for not getting back to you sooner, but I'm glad to hear that you were able to get up and running.  For the benefit of anyone else who might run into this, can you please post the changes you made to the personalization code in order to get the device to return good data?

To address your other comment, you are definitely not the first to request an RLP manual and we certainly feel your pain.  We hope to provide an M Series RLP manual at some point in the future once resources to complete that effort are available, but in the meantime please feel free to post here and I'll be glad to help with any other issues you run into.

Thanks again-