01-08-2008 04:30 PM
01-08-2008 05:11 PM
01-11-2008 03:02 PM
Hi Rob
Thanks for your response, I have decided to try and dissect the example code in aiex1.cpp in the DDK and had a few questions.
In this Thread someone responded
>> -The offsets for the various registers always refer to BAR1 as the base address.
>> -M Series do not use windowed mode. It was determined that direct mode addressing was better for several reasons, so that was implemented for M Series.
I have inherited code that works on 65xx cards which I am pretty sure uses windowed mode that I am using in this 6221 driver. I have found that I can set the PLL registers to act as DIO and I can read the Discrete inputs just fine. Makes me curious, if Windowed mode is not used doesn't that mean the addresses are relative to the BAR1 address? Why then am I able to read the DIO?
Also starting with Clock_and_FOUT according to the example I set it for Slow_Internal_Timebase. But when I read back that Address it is always zero. According to the register map it is a "write". Does that mean I can't read it's contents? Or do I seem to have a problem because I am trying to use windowed mode with this card.
Appreciate any light anyone can shed, I hope I know enough to ask the right questions.
Floyd
01-28-2008 02:55 PM
Hi Floyd-
Let me address your questions individually:
A multi-channel scanlist can be created as shown in the method aiConfigureChannel() from ai.cpp in the M Series MHDDK \Examples folder. Note that the other operations leading up that point (notably, aiClearConfigurationMemory() must be performed in the order shown in the various AI examples. aiex3.cpp is the most useful starting point for investigation, in my opinion.
aiex3.cpp shows how to setup the device and its DMA controller (aka the "MITE") for DMA operation. In order to configure for continuous operation you set the "continous" flag in that example to kTrue. The effect of that setting is to program the STC-II to generate either a finite or continuous AI sample clock. This programming is performed in the function aiNumberOfSamples() from ai.cpp and has the effect of setting the appropriate bitfield for continuous operation in the AI_Mode_1 register.
Earlier in your post you asked if the STC Technical Reference Manual ( http://digital.ni.com/manuals.nsf/websearch/E929838D7D0EE50986256728007FEADF ) would be a good reference. In fact, it's a great reference from the perspective of understanding the bitfield/register names and understanding the basics of how the timing hardware works (for example BC, UC and other sample counters are all functionally equivalent in the STC and STC-II). From the perspective of actual register writes and reads, the functionality is different between E Series and M Series. The biggest difference, as another forum user alluded, is that we map and write directly to the registers on M Series so Windowed_Mode reads and writes are no longer necessary.
Another difference between STC and STC-II is that the STC-II uses NI TIO-style counter/timers. For that reason, the NI 660x RLP manual ( http://digital.ni.com/manuals.nsf/websearch/4CE1C778F442B01386256C870060F9F3 ) would be a good reference for M Series counter/timer operations.
Assuming you don't need an external start trigger, you only need to write to the strobe bit AI_Command_2->AI_START1_Pulse. This will create a single start trigger pulse internally. The differences between AI_START1 and AI_START are described in the STC Technical Reference Manual.
A finite acquisition would be stopped automatically by the AI timing engine based on the number of samples you program via the method shown in aiNumberOfSamples(). Continuous AI would be stopped by first stopping the DMA operation and then calling aiReset().
Yes, this would work but I would strongly suggest using DMA as shown in aiex3.cpp. If you want to use "programmed I/O" to read the FIFO data directly, that method is shown in aiex2.cpp
In many cases it would be very helpful. See my comments, above.
I'm not sure why this would work- it's possible that some legacy functionality is still working due to the way you access the hardware in your code. For full functionality with M Series you must use mapped memory I/O to write and read from the device's registers.
Yes, the "write" registers are write-only and the "read" registers are read-only. The effect of data read from or written to "write" or "read" registers, respectively, is undefined.
02-12-2008 03:12 PM
02-12-2008 03:45 PM - edited 02-12-2008 03:45 PM
Hi Floyd-
I would recommend building from the command line rather than trying to replicate the build environment in Visual Studio. We have already developed the Makefile(s) necessary for just this purpose.
The good news is that you can still use the C++ compiler provided by Visual Studio, and the Visual Studio installation actually provides a neat little utility that can help with the process. I use the Visual Studio Command Prompt (on my machine it's linked from the start menu, under Visual Studio>>Visual Studio tools).
In order to invoke 'make' from the command line you'll need some kind of Windows port of that utility. I use UnxUtils. You just need to download that util package and unzip it so that the the included utilities are available in your path.
You'll need to unzip all of the MHDDK source so that they appear at the same level (i.e. ./nimseries/... ./dma/... ./osinterface/... etc) and then invoke 'make' from within the Visual Studio Command Prompt in the ./nimseries directory. The Makefile there should take care of the rest.
Hopefully this helps-
02-12-2008 05:15 PM
>>You'll need to unzip all of the MHDDK source so that they appear at the same level (i.e. ./nimseries/... ./dma/... >>./osinterface/... etc) and then invoke 'make' from within the Visual Studio Command Prompt in the ./nimseries directory. >>The Makefile there should take care of the rest.
My directory structure is
c:\nimseries\
.....................ChipObjects
|....................................nimdbg
.....................Examples
there is no DMA directory or osinterface directory
no osiBus
In my makefile these statements point to paths I don't have (I don't think)
OSINTERFACE_DIR := ../nimhddk_visa
OSINTERFACE_MAKEFILE := win-visa.mak
include $(OSINTERFACE_DIR)/$(OSINTERFACE_MAKEFILE)
Have I the correct files? Or am I missing some parts I need to have
If I remove the DMA support from the Makefile when I run "make" it responds that there are no targets but no other errors
when I include them in the Makefile I get the following messages
../dma/dma.mak: No such file or directory
../nimhddk_visa/win-Visa.mak: No such file or directory
No Rule to make Target
Again thanks for bearing with me
Floyd
02-12-2008 05:25 PM
02-12-2008 06:07 PM
Woo Hoo!
Thanks Tom
I was able to compile both in RTX and Windows. This should be a big leap forward. Again much appreciate your assistance in this,
02-13-2008 04:14 PM
Hi Again
As I have noted I have been successful in getting the Analog Input Examples to compile and execute both in win-visa and RTX but I have been unsuccessful in getting any good data from the card. aiex1, 2 and 3 are returning 32767 counts for a 2 volt differential signal in A0/A8 input pins. I can use the Test Panel for the 6221 card in MAX and it all works fine although I must first "Reset" the device if I have run the example code prior to calling up the test panel.
I have found some notes that I will not need the AdcReset routine for a 6221 card and there was a comment that 80 should be used for a Time Divisor? I am wondering if there are any other modifications that I need to do to the example code for it to work with a 6221 card?
Also note that I am using a PXI-6221 which resides in a remote chassis bridged to my PC using MXI-4. I have no idea if that should affect anything as it has been really transparent to all the rest of the cards I am using.
Again any help you can provide I will be eternally grateful.