So….after a few weeks of not blogging, I have some serious catching-up to do. The weeks of working on Volturnus have been flying by, and writing simply hasn’t been first on my mind. Here’s a quick summary of what has been accomplished.
Week 3 was fairly hands-on, for we were focused on diagnosing and repairing remote reset issues. Our wireless bridge system had been dropping packets while sending data to shore, and had locked up several times while communicating. The team wanted a way to remotely reset it, so we installed a relay system that could be controlled by our onboard National Instruments cRIO chassis. A watchdog relay was also installed, so if we couldn’t communicate to the controller due to the wireless bridges being locked up, the system would automatically reset itself. A Labview VI was integrated into the source code to ping the watchdog relay when the system was functioning properly, thus preventing a communication reset.
Another problem that was fixed during week 3 was a faulty mooring line load cell. The sensor was reading extremely high values in our remote human-machine interface, and the other load cells were reading fine. After simply testing the resistance with a digital volt-ohm meter, it was properly diagnosed in a matter of minutes; the internal wheatstone bridge circuit had a short across two of the resistors. The assembly is a sealed IP68-rated unit and could not be repaired, so a new load cell was installed.
The last task I was given this week was to spec out accelerometers and inclinometers for the structure. The data analysis team wanted to have accurate pitch/roll/yaw measurements from the unit, so I got to work helping to figure out our options. After some deliberation, we decided to stick with two inertial measurement units from Microstrain that had already been purchased. A wireless accelerometer system was also purchased for redundancy.
This week was all about one thing: Labview. I have a fair amount of experience programming in Python and some basic C++ knowledge while playing with my Arduino and APM2.5 flight controller, but I had never programmed in a graphical language until this summer. The fundamentals are the same, but the process of visualizing code is completely different. I’m a very visual person, but learning the Labview programming language is tricky. The entire data acquisition system is coded in Labview as well as the Renewegy turbine system, so learning the language is integral to understanding what exactly is going on. I spent week 4 in a classroom doing NI’s self-paced online training, and I learned a significant amount of the Labview syntax and language structure. I haven’t even touched the surface of what is capable in the language however.
Since Thursday of week 5 was the 4th of July, I ended up only working two days. Monday was dedicated to installing the redundant Microstrain wireless accelerometer that had been purchased two weeks prior. The IMU’s hadn’t been incorporated into the DAQ code yet, and the data analysis team wanted pitch/roll figures asap. To get over this slight hurdle and keep the project moving ahead, a standalone wireless system was installed. We mounted the base on the land, and routed communications and power to it. The included antennas were omnidirectional, so the largest mounting consideration was a clear line of sight between the base (the wireless receiver) and the node (the accelerometer and transmitter on VolturnUS). Once the base had been mounted, we took a boat out to the structure and installed the node on the turbine. After verifying the communication link was working properly and the data was being recorded, the day was done.