I started the day off by figuring out once again what the initial motor position would be if I connected everything up to the computer and ran the motor control code. Once again, I found that it was initialized to -16,777,216. This number must have some meaning, but I am not sure what.
Following this, I attempted to figure out how to do a little programming challenge to see if we could make the motors do what we want them to in the long run, or figure out if the existing code we have can accomplish this. The task is as follows:
1) Tell the motor to rotate 3.5 turns and stop.
2) Move back 1.2 turns and stop.
3) Report the position as 2.3
4) Save this position so that when the program is closed and reopened it still recognizes that the motor is at 2.3, ceteris paribus.
As it turns out, this is a bit more difficult than it would seem. The reason for new positions in the motor becoming zero each time the control board is unplugged as opposed to the program being closed and reopened is because the motor position is stored in the control board’s memory, not the program’s.
So how difficult is it to create a vi to do what was described above? Not very, but you need to have the right tools. Tasks 1) through 3) can easily be accomplished with the base code that I’ve been working with, but the unit “turns” would have to be figured out empirically. This is not optimal, so I set out to figure out what the units were, and more importantly, how this motor code works in the scheme of the whole program.
It turns out that the units, speed, and voltage of the motors can all be calibrated in a nice little calib.ini file. This file is then called by a CalibConstants.vi which appears everywhere in the overall tweezers.vi code structure. This CalibConstants.vi should be able to figure out the units and normalize instructions from turns to what the base code I was using earlier uses for units.
CalibConstants.vi is unfortunately not run-able because there are two important files missing: Reset Position.flx and Read Position.flx. The observant reader would note that these file endings are different for every other LabVIEW file that I’ve discussed so far. That’s because, (after doing a little bit of research) these files are related to the NI-Motion set of *stuff*. .flx are Flex Motion files, used by the NI-Motion driver. These .flx files appear several times throughout the tweezers.vi and are most of the missing files in all of the code.
With the inclusion of these two .flx files, CalibConstants.vi should be run-able, and by extension, simplemove.vi, which is the overhead code for the base motor code I’ve been using, which should mean that the programming task I outlined above is entirely executable by the existing code we have. Also, since much of the tweezers.vi code has CalibConstants.vi throughout it, more of that code will be run-able too. This is exciting since our camera and other optics equipment just arrived today.
So what’s the bottom line? Either we rewrite the code or get this NI-Motion driver which should contain the .flx libraries. I did manage to comment out sections of the CalibConstants.vi and SimpleMove.vi that referred to the .flx files we don’t have. I managed to get both running, but since I commented critical sections out, the code was stuck in an infinite while loop and I was unable to proceed further.
