User:Steven J. Koch/Notebook/Kochlab/2009/06/29/Feedback 96 Debugging
Steve Koch 13:08, 29 June 2009 (EDT): Feedback0b.ini file was not copied over. Copied it to the Versatile Feedback DAQ main directory. Since I am not sure how often / whether it's name is hardwired into the program, I'm not going to rename it. I am going to edit it to remove all of the old modules.
Steve Koch 13:54, 29 June 2009 (EDT): I am still getting some inconsistencies between compiling on my office machine and kochlab-03. It has to do with the subVI "Sum Ratio to New AOD Voltage.vi"...probably something to do with the subVI "1D Polynomial Evaluation" ... can't figure it out, so ignoring now.
Config file stuff
(Still haven't updated the feedback list)...fixed some config file stuff:
- Decided that storing config file stuff on local harddrive makes most sense.
- Directory will be: "C:\,Local Data\koch.steve\" (username is automatically detected)
- params.ini is the file for real time params (loading rate clamp, etc.; which is not yet implemented in 96)
Some kind of DAQ error
Steve Koch 16:00, 29 June 2009 (EDT): Upon running the program, I was able to get it to work with the config files (as far as I can tell), so that is all good. It also appeared to acquire data. However, the program was VERY slow to the point of seeming to crash, when in the "pre-acquisition" mode. I don't know exactly where it was hanging, but suspect it is a problem with the DAQ:
- I noticed that mx_GetBitResolution_DAQWrapper was returning 0 instead of 16. The property node for AI.Resolution was returning an error.
- I tried running MAX explorer, and the card returned an error on self-test. Also when trying to reset. This crashed MAX. I rebooted the computer, and this error went away. So did the error with mx_GetBitResolution. However, I haven't run feedback96 yet, so it's likely that running the software causes the error. We'll see.
- Steve Koch 16:03, 29 June 2009 (EDT): Yup. Running the entire VI I get the error in mx_GetBitResolution. Quitting feedback program, mx_GetBit... remains broken.
- MAX broken too. Error is: "Executable version (7.1.1) doesn't match resource file (7.1). Check your configuration.
- I get the error -200324 "DAQmx Reset Device.vi<append>" when trying to reset from within LabVIEW.
Looking for DLLs
- Replaced "DVESetFreq" with a fake version (no DLL)
- Steve Koch 16:47, 29 June 2009 (EDT): OK, I think I removed all DLLs except: PID DLLs; stop condition DLL; a couple other LV-related DLLs.
Error seems to be gone, now DIO port error
Steve Koch 16:54, 29 June 2009 (EDT): OK, so whatever I did with the DLLs and other things seems to have fixed the error that showed up in mx_GetBitRes... My guess is that it was the DVE call, not really sure though. Anyway, now there is a new error in the DIO port. Not sure where / why. The VI that popped up when I finally quit is "Feedback0b-Dialog-Release Footswitch Please.vi."
"Footswitch DIO0 State--Replace CIN_2ndTry.vi" doesn't work, but "Read from Digital Port.vi" does work.Actually, that's not true, behavior is erratic. Probably should reboot.- DIO Port error is gone (reloaded program; didn't reboot)...actually seems to be working great.
Working on Kochlab-daq2 now
Steve Koch 20:41, 29 June 2009 (EDT): DIO Port does not work on the new machine. I notice that the version of NI-MAX is much earlier than on kochlab-03, so possibly it's due to an outdated Daqmx. Thus, I am now installing NI-DAQmx 8.9 (a huge download of 1 GB, which I put in my temporary directory on the controller).
Steve Koch 20:59, 29 June 2009 (EDT): After intalling, accepting a whole slew of actions in windows defender, and restarting, it detected the m-series board as new hardware. But running "Read from Digital Port.vi" still gives me error -10401 !!!
Steve Koch 21:09, 29 June 2009 (EDT): I think it's possible that this is because I'm using the M-series board, and old (traditional) VIs for DIO port reading. Also, given that I don't know how to connect DIO on the new BNC connector, I think the smartest thing to do is to put the E-series board into kochlab-daq2. My only worry is that something got a little smoke the other day. I hope it wasn't the E-series card!
- : Hmmm...now I'm thinking this is really lame for the long-term? Making it work for daqmx shouldn't be too hard...
Example of how to read switch using BNC-2111
- http://kochlab.org/files/Software/Code%20examples%20for%20linking/Digital%20IO%20DAQmx%20BNC%202111%20example.vi This links to a VI that sets one line to be true (high) and reads the line via another port. If the two are connected via a switch, then the second port goes high.
- This would be a lot easier if I knew how to default the port to true, and then connect the port to digital ground via the switch. This is the way it behaves with the E-series board, the BNC-2090, and traditional daq calls. I don't understand why.
Fixing footswitch--making mx
Steve Koch 22:30, 29 June 2009 (EDT):Richard had a little orange footswitch VI that is used to ask whether the footswitch is depressed. Actually come to think of it, how is the footswitch accessed during DAQ? I need to look into this, hold on...I'm suspecting a "fake DLL" problem.
Yup, I am pretty sure that DLL reads the footswitch to check for stopping. I don't remember why exactly it's a DLL -- likely a speed issue, which is no longer relevant? At the moment, I'm thinking I should just ditch the DLL and write in LV code. Plus, I can simplify the hell out of it--well, maybe that's a bad idea, but I can at least make it easier to read? Don't know, though, whether I'll be able to find Richard's source code.
- Steve Koch 22:52, 29 June 2009 (EDT): Found Richard's stop condition code: /Richard Yeh stop condition C dcode
- Steve Koch 23:10, 29 June 2009 (EDT): I think I've confirmed that the current DLL is not working as far as reading footswitch goes.
Began moving DLL to LabVIEW
Steve Koch 01:22, 30 June 2009 (EDT): Made stop condition_mx file, along with subVI for "compare_stop_condition_values." I think it will work out fine, but too tired to continue doing it now.
