NI-DAQmx history: enhancements and issues

[john-judge]

From Meyer:

As for the NI interface programming, I have a preference for using NI_shutterOpen simply because it is very easy to implement. The timing of illumination is not as critical and it is easy to use it independently of the other interface functions. But my main reason for preferring it is that I do not understand the programming to control the NI interface. If I can learn how that works I could be more flexible about how we incorporate that into photoz.

From Sarwagya:

Can you send me DapController.cpp with your changes highlighted, or better yet, incorporate them into the version I sent you with NI_shutterOpen(int) at the end. That would be the easiest way for test things out.

John told me that he was going to give you the latest version of PhotoZ to test out. There were some minute mistakes in the DapController files I sent out to you last time which I have fixed now. I did see the function you implemented for the LED specifically. However, I think it is a better idea to have the LED, and stimulus, as a part of the same task, so that they can run parallelly. That is what I had done earlier. Let me know if any issues occur.

I changed

DapController::createAcquiDapFile, //configures timings and calls fillPDOut

DapController::fillPDOut, //creates an array with the data to send through the output lines

DapController::acqui, DapController::pseudoAcqui, //starts the acquisition tasks and call functions like singleTake from Camera.cpp

DapController::setDAPs //creates tasks for RLI, acquisition output, and acquisition input, and add ports and lines to those tasks

Also, doesn't pdv_start_image start acquisition from the camera? Is the camera connected to the NI board via "PFI 1 / 74 sync" or some other line?

Thank you for the information. I see data being written through analog outs A0 and A1 for the DAP board. On the layout they correspond to DAC0 and DAC1 out (pins 27 and 28) on the DAP board. If you could check what those are connected to, we can confirm if we need similar lines for NI. I also see that there is data being sent to digital out 7 which according to the comments relate to the camera. I do not completely understand the use for this. Could you tell me what digital out 7 (pin 0) is connected to on the DAP board and its use?

I have also converted the code to be compatible with the NI board. I have taken a little different approach from what we had earlier, but I think it should work. There are a couple tricks I have tried to not use too much memory in the converted code, which might cause issues. Let me know if you get any compiler errors and/or otherwise.

From Meyer:

Hi Sarwagya

The analog inputs are pins 1, 4, 7, and 10. Grounds are connected to pins 19, 22, 25, and 28.

We do not need to use more than 4 inputs even though photoz-lilJoe uses 8. We only use two or three of them.

We use digital outputs for the stimulus not analog outputs.

PF1 (pin 74) is the output currently used for stimulus. I suggest using PF3 (pin 76) for the second stimulus.

I do not know if we have a layout for the DAP board but it is a Microstar DAP 820. Maybe you can get the information you need here

http://www.mstarlabs.com/dataacquisition/isa/820spec.html

http://www.mstarlabs.com/docs/tn209.pdf

Here is the pin diagram for the NI-USB-6341 from p 211 of the users manual that I downloaded. It is a big file but I can send it if you want. This figure looks exactly like what you see when you take off the cover.

This is how things are connected.

There are four analog input lines connected on the left

P0.0 / 65 is sync

P0.1 / 66 is shutter (we use this for the LED)

P0.2 / 67 is stimulus (photoz has two stimulus outputs and we will have to use on of the unused digital outputs)

PFI 1 / 74 sync

[john-judge]

This email thread gives background on how Meyer and Sarwagya arrived at the current NI-DAQmx code, should it become useful in the future to sift through.

From Sarwagya:

I have a couple of things that we can try.

Can you change the samplesForRLI parameter on line 615 to &samplesForRLI like this: DAQmxErrChk(DAQmxWriteDigitalLines(taskHandlePut, 348, true, 0, DAQmx_Val_GroupByChannel, &samplesForRLI, successfulSamples, NULL));

Can you also try changing "uint8" on line 594 to uint32? If that doesn't work can you also replacing freq on line 55 of MainControllerAcqui.cpp to 500 like this:

dapControl->setDAPs(500);

*This is just for test, and we should revert this back right after.

Let me know if this works.

Thank you for the cpp file that Chun sent. It will be helpful!

Thank You!

From Meyer:

I tried many variations with the DAQmx calls but never saw the light turn on.

However, I do see an “active” indicator light on the interface blink on briefly when I click take RLI so something is being sent to the NI interface. In the DAQmxCreateDOChan call I tried all values of line0:n from n=0 through 7. I see you had it set as 7. Why?

I attached a file from Chun which has a lot of DAQmx calls. Have a look at these lines after 1470.

DAQmxErrChk(DAQmxCreateTask("", &taskHandle_out));

DAQmxErrChk(DAQmxCreateDOChan(taskHandle_out, "Dev1/port0/line0:2", "", DAQmx_Val_ChanForAllLines));

DAQmxErrChk(DAQmxCfgSampClkTiming(taskHandle_out, "/Dev1/PFI12", output_rate, DAQmx_Val_Rising,

DAQmx_Val_FiniteSamps, output_sample));

This looks like the part of the program that sends a signal to turn on the light. But it uses line0:2. I suspect that it the correct one.

However, the pin diagram on the interface itself indicates the light is connected to a pin labeled 66 p0.1

Finally, I changed the declaration of SamplingRate to float64 to match what I found here

http://zone.ni.com/reference/en-XX/help/370471AM-01/daqmxcfunc/daqmxcfgsampclktiming/

From Sarwagya:

It's nice to hear that the GUI is not freezing now. Do you know what the problem was?

Also, I don't see a call to DapController::stop() anywhere in the MainController::takeRli() function, do you know where the call is originating from? (This is not very important.)

Finally, you should be able to try different combinations by changing the port number on line 804 of DapController.cpp. The line looks like this:

DAQmxErrChk(DAQmxCreateDOChan (taskHandlePut, "Dev1/port0/line0:7", "ledOutP0L0", DAQmx_Val_ChanForAllLines));

*I picked up the samples for RLI from the output that was being sent to DAPio for RLI previously. I don't remember the exact significance of why it is 348 in length, but I will check it again and let you know.

From Meyer:

I have returned to the DAQmx issues and tested things further, all in DapController.cpp.

First of all, the calls in DapController::stop() starting on line 256 do appear to be called upon startup because there is an output command fl_alert("DapC line 264 DAQ taskhandles \n");

This message appears after the two DAQmxErrChk calls.

I don’t know if that is useful information.

More importantly, the takeRli is not locking up now. When I click the take rli button I see

Sending Sample for RLI

Followed by

Samples For RLI Sent

This is followed by camera commands and I commented them out. Now takeRli finishes and I can use the GUI, click take RLI again and see the same console messages. So the commands complete but to not turn on the light.

I tested TurboSM and it does turn on the light so the hardware is correctly connected.

DAQmxWriteDigitalLines(taskHandlePut, 348, true, 0, DAQmx_Val_GroupByChannel, samplesForRLI, successfulSamples, NULL);

Put in a cout and saw that sizeof(SamplesForRLI) = 348.