User:Steven J. Koch/Notebook/Kochlab/2009/07/06/Feedback 96 Looptime debugging

From OpenWetWare
< User:Steven J. Koch‎ | Notebook‎ | Kochlab‎ | 2009‎ | 07‎ | 06
Jump to navigationJump to search

Steve Koch 23:38, 6 July 2009 (EDT): I am using two pieces of software for looking at the Feedback 96 mx looptime:

Using these applications, I am able to look at the loop timing a bit. So far, I just did one "hold and take data" and looked at the timing:

  • About 3 data points per millisecond; some spread around 7500 cycles of the 20 MHz clock per data point. Both of these mean the loop time is about 375 microseconds. This is significantly slower than using the old version in LV 6.1, and on Windows98. At this point, I'm not sure if that's just the way it will be for now, or whether I can significantly improve it. Many things that can be tried.


(Note, had to delete a rogue copy of 'get data file path if necessary' that was being loaded from the wrong place. Deleted from the VSS database...need to delete from local machines.)

It's the Daqmx VIs that are slowing it down (not surprisingly)

The timing depends a whole bunch on whether I have the VIs open

Potentially very bad bug (in LV, not feedback96)

Steve Koch 00:32, 7 July 2009 (EDT): I noticed in the two DAQmx VIs that are taking so long that the task (variant) is being fed directly into the DLL which is expecting a U32 data type. Often in the past, we found datatype casting to be a real time synch. However, when I try typecasting it before the DLL, it indeed runs faster, but it appears to corrupt memory, as LV crashes when I try to run the loop more than once.

  • Tried making the VIs not subroutine priority. The loop time doesn't seem that much different.

Not a bug--just "type cast" doesn't work to produce the valid task ID

  • I tried reading out the taskID into an unititialized shift register, and using an "initialize?" boolean. This seemed to work just fine, but it didn't appear to change the loop time at all. So, perhaps casting the value isn't really a big deal? Maybe we'll just have to live with this slowness?

Another potentially very bad bug

Steve Koch 00:54, 7 July 2009 (EDT): I haven't fixed the previous bug, but noticed another one. When taking multiple segments of data, the first segment seems OK, but the following segments the deltaT is all zero. See datafile 0012 from 090706.

Steve Koch 01:12, 7 July 2009 (EDT): I have noticed irregular behavior in the reporting of average loop time as well. This is probably related. In any case, it looks like it goes to hell after one data set.

More details on behavior

  • If I click "write data to file" and then "set" again, the entire next file is corrupted (unreadable by simple plotter).
  • If I click "write data to file" and then stop program, and run again, the data file is same as when first starting program, except that the first segment is much slower deltaT times (and remaining segments are empty or corrupted, that is)
  • If I exit LV altogether, and restart Feedback96, the behavior reverts back to the "fresh reboot" behavior.
    • Because loop time is more or less constant during the first segment run, I think this means something is getting screwed up between segments? Or at least I hope this is true, allowing me to possibly fix this bug with my code (versus worse problem if it's just related to DAQmx problem)
  • Interesting: Running "Hold and Take Data" module twice in a row works OK with no apparent inconsistency between modules.
I am suspecting these DAQmx VIs in the bottom right

OK, I think it's because I'm not really destroying the task

Steve Koch 01:40, 7 July 2009 (EDT): Upon running DAQmx config the second time, I get errors -200089, "Measurements: Task name specified conflicts with an existing task name."

That fixed it!

showing all 3 segments have valid data, and timing seems consistent too

Steve Koch 01:46, 7 July 2009 (EDT): By deleting the task names, the bug went away. I had tried to unreserve those tasks, but apparently this doesn't quite do it. The task names are never needed, so deleting doesn't matter as far as programming goes. Whether it is a huge memory leak or something, I don't know. But it works. Now, this could have been causing the above complete LV crash as well, I don't know. Worth trying again?

Backup and sharing Local Data folder

Steve Koch 01:01, 7 July 2009 (EDT): Using SyncToy2.0 (and existing scheduled task), I think I can easily share the local data directory by copying to the webpub share on the server. I am using "contribute" instead of sync, since I don't want to remove information from server. My thinking is that we'll proceed with data anlysis using the webpub directory.

Steve Koch 01:07, 7 July 2009 (EDT): Check this shit out: http://kochlab.org/files/data/Kochlab-daq1/koch.steve/Testing%2096 Caleb kicks ass. It's amazing to me that sharing raw data is so easy: just copying to the correct share, that rocks. Of course, the data are binary and require software or knowledge to convert them, but this is a huge step. Not to mention that once we do basic conversion, we can make the data ASCII (at least I think we do).

Retrieved from "https://openwetware.org/mediawiki/index.php?title=User:Steven_J._Koch/Notebook/Kochlab/2009/07/06/Feedback_96_Looptime_debugging&oldid=322034"