The Labview VIs

On the PC (client) side, MuRC consists of a handful of Labview programs (also called virtual instruments or VIs). These were written in Labview 2010 and so will be tricky to use with earlier versions of Labview, but are hopefully okay with later versions.

Here’s a brief description of each VI:

VI nameRuns it on its own?Function
SmrDriverClient.viYesHandles TCP communication with the FPGA - sets parameters for each SmrDriver
DataReceiver.viYesReceives and saves data from a single SmrDriver on the FPGA, which is sent via multicast (UDP). Can be launched by clicking a button in SmrDriverClient.vi
MultiChannelDataReceiver.viYesReceives and saves data from up to 12 SmrDrivers simultaneously.
LockInSweep.viYesUses the zeroth SmrDriver to generate a drive signal that gradually increases or decreases in frequency, all the while measuring the input amplitude at that particular frequency (behaves as a combined signal generator and lock-in amplifier). This is used to measure device transfer functions. Cannot be run simultaneously with SmrDriverClient, as they both require the use of a single TCP socket.
SetArrayParameters.viYesTakes as input a transfer function for an array of cantilevers. Finds the resonances and quality factors, then sets the parameters for each SmrDriver to enable a particular behavior (e.g. open-loop oscillation, or closed-loop drive with PLLs with a given bandwidth).
MultiCantileverAligner.viYesPlots the data from multiple SmrDrivers at once, for laser aligning purposes (or any sort of real-time optimization of the system behavior). First set all the SmrDrivers to operate in open-loop, and set them to transmit their amplitude measurements, not the frequency. MultiCantileverAligner.vi works a lot like MultiChannelDataReceiver, except it also tells you the average and the standard deviation of the resonator signal amplitudes (the ideal alignment in many cases has a high mean and a very low standard deviation [all resonators have effectively the same gain]).
getCurrentSmrDriverParameters.viNo (auxiliary)Some VIs call this to obtain a 'cluster' of resonator parameters. Note that this VI asks SmrDriverClient for the parameters (therefore SmrDriverClient must be running), and SmrDriverClient hands them back directly - it does not check with the board to first ensure that it is in sync with the board.
UserParametersToRegisterValues.viNo (auxiliary)It would be a mess if we had to give the board parameters in the form it likes them (say, a 32-bit integer where the top 16 bits mean one thing and the bottom 16 bits mean something else). Instead, we give the SmrDriverClient human-understandable parameters. UserParametersToRegisterValues is responsible for converting these to the integers that the board actually uses.

 

Leave a Reply