User:Steven J. Koch/Notebook/Kochlab/2009/03/04/Feedback program tweaking

Note: This page was transferred from the private wiki, and thus links and images may be broken until they are fixed.

Steven J. Koch 15:45, 4 March 2009 (EST):I want to take a few hours to see if I can make any progress on the feedback program and to break through some of the mental blocks. The first one I am wrestling with now is: how the hell do I work on this application in the context of SVN? I think I probably should avoid learning SVN, unless it's super-easy. I am worried about breaking something, but that is probably stupid.

It looks like version 7 is a good one to fall back on. It's from March of last year and compiles if you have the right NI-DAQ installed on the machine.

Even though I don't know how to use SVN, I think it's safe for me to try. SO, I'm going to try to check out the files and start hacking.

Steven J. Koch 15:53, 4 March 2009 (EST): I created some kind of branch / tag since I didn't know what I was doing. Not sure how to undo this. Going to try to ignore it. I think I already have all the software "checked out?"

Software loads and compiles in LabVIEW 7.1

Steven J. Koch 16:13, 4 March 2009 (EST):Tried this on my office computer. So, what's the point of using 6.1? And this is surprising to me, because I have later version of DAQ installed on my office machine. This seems like really good news, but I am still confused. My gut is telling me to move on to 7.1

Steven J. Koch 16:16, 4 March 2009 (EST):It also compiles on Kochlab-03 in 7.1, but I think I don't have DaqMX on that machine. One thing I can do, possibly fairly quickly is to get rid of all the RLP (register-level programming) stuff by switching to DaqMX. "Piezo Hold and Take Data" is a good one to work on first. I should get rid of DVE card stuff in that VI too.

Prospects for DaqMX

You can see all the DLL calls I had to use back then, in order to get fast data acquisition. This was all because point-by-point acquisition using LabVIEW VIs and Traditional DAQ had a huge latency. Thus we were forced to set flags manually on the DAQ board, which of course was very confusing and tedious. But it ended up working. If I knew DaqMX really well, I think it would be pretty quick (say an hour) for me to replace this core VI with DaqMX stuff. But since I don't know it very well, it may take me longer. Maybe a lot longer. Plus it's tough to debug. Maybe I should make sure I can get Piezo Hold and Take Data working first in 6.1, by removing DVE stuff.

Fake DLLs may be too fake

Steven J. Koch 16:38, 4 March 2009 (EST):I am wondering if even Richard's stop condition DLL is fake. Probably it is. That's why the Piezo Hold and Take Data isn't working (or any module). Trying to find the real DLLs. This is the only one I can find so far:

\\Controller\users\koch.steve\My Documents\Graduate Work\Koch_Semi Old_Personal and Proj 5\Programming\VelocityClamp\RLP_Scan_AI_Testing\RLP_November2000.dll

or:

\\Controller\users\koch.steve\My Documents\Graduate Work\Koch_Semi Old_Personal and Proj 5\Programming\VelocityClamp\RLP_November2000\Debug\RLP_November2000.dll

Worried, though, that it's not updated enough?

Steven J. Koch 16:47, 4 March 2009 (EST):OK, I found a CD from September 2001 that had the software shadow on it, and the directory DLLs-Real, so I think I have those DLLs now. Copying the CD. Copied to here:

\\Controller\users\koch.steve\My Documents\Graduate Work\Valuable recoveries from CDs\User 2 and Software Shadow\SoftwareLibrary\LabView-shadow\DLLs-Real

tweezerscontrol2 branch is compiled in 7.1 and I am putting in real DLLs

Steven J. Koch 17:18, 4 March 2009 (EST):Definitely the fake DLL was causing the stop condition not to work, which of course is obvious. I can't immediately think of a reason why we need a fake DLL for RLP_November2000 if I have a PCI-6052E baord.

Installing updated NI-Daq to kochlab03

Steven J. Koch 17:06, 4 March 2009 (EST):Since it works on my office machine and I want access to Daq-MX. Also, NI-MAX was not finding the board correctly.

• Steven J. Koch 17:24, 4 March 2009 (EST):OK, I did this, rebooted, and feedback0b-main compiles in 7.1 still. That's good. Now I have access to daq-mx

Trying to run a simple program, is really slow

Steven J. Koch 17:27, 4 March 2009 (EST): Just trying to acquire 1000 data points with Piezo Hold and Take Data doesn't really seem to work. This could be for any number of reasons, including RLP not working on XP.

• Steven J. Koch 17:33, 4 March 2009 (EST):Actually it doesn't hang, but it took like 180 seconds for I don't know how many data points (I requested 1000). \\Controller\users\koch.steve\My Documents\Data\Feedback0B\090304\0000.dat I can access the data in the file, though, and it doesn't look corrupted. Using "Secret Peeking Software", I can see that the sum signal is doing something versus time.
  • Looking at a converted data file, it looks like each data point is about 200 milliseconds apart.
  • Actually, I was averaging 100 data points! I put that factor down to 1, and it seems to work well (except, of course having a 1 millisecond delay instead of a couple microseconds--that's probably an XP thing).
  • Using Profile VIs, the VI "START and Read Scan.vi" is using all the time.
    • It's already subroutine and reentrant, so basically I think this is an XP (or LV7.1) thing and the best way to approach it is to ditch the RLP stuff via Daq-MX. That's simple on the level of this VI, but the problem is changes have to be made throughout the program.
• Using DaqMX in a separate program (had to reset the card, by the way after running feedback0B) I can get 400,000 data points (100,000 x 4 channels) in about 3 seconds. That's about 10 microseconds per data point, I believe. That's not as good as what we had with RLP on Windows 98, but it's probably good enough to live with for now if I can get Daq-MX going .

The timing is going to be a bitch

Steven J. Koch 18:15, 4 March 2009 (EST):I can figure out pretty well how to acquire the data points. However, It's going to take me a while to figure out how to access the counter like we were doing. It was pretty complicated, and I was even doing things like only using 16 bits of the counter to save access time, etc. Ouch.

• Using MAX, I think I need to find something like this: /Dev1/20MHzTimebase
• This is probably a lifesaver: http://zone.ni.com/devzone/cda/epd/p/id/826
• Steven J. Koch 19:09, 4 March 2009 (EST):OK, so that example VI helped a ton. I basically know how to do it now, but I'm going to be confused by the rollover problem. We were so worried about speed back in the day that we only used 16 bits of the 24 bit counter value. So, we had a 16 bit rollover correction. This worked fine as long as there was no hiccup longer than 65536*0.05 microseconds=3.3 milliseconds, I believe. Although, was I using the 20MHz clock? Or a slower one?
  • Looking at Richard's geometry conversion VI, it does indeed look like we were using the 20 MHz clock. Thus we were counting deltaT in 20MHz ticks.
  • 2^24*0.05 us = 839 milliseconds?

Timing is solved I think

Steven J. Koch 19:22, 4 March 2009 (EST): I think this VI: C:\Program Files\National Instruments\LabVIEW 7.1\development_sjkoch_7.1\Code Experimentation\DAQ\Count Digital Events_rollover testing.vi shows that we can use Daqmx to read the full 32 bit value (representing the 24 bit counter) and use the similar roll-over scheme to store the same 20 MHz deltaT tickcounts. We could also use the paired counters as in that NI example, but unless we expect a longer than 839 millisecond hiccup, we don't need that, and it's a waste of time. There are lots of long pauses (several milliseconds), though, and we will need to address this, probably: /feedback loop delays This shows how to use the counter and rollover. Pretty simple, actually. (Ignore the windows timing stuff, I've disabled it in the code)