dprohe
commented
2 weeks ago First, the reason that the 2.0 version isn't working is it looks like you have it pointing at the control law file from the 3.0 version. The 2.0 control laws used fewer arguments than the 3.0 control laws (the 3.0 control laws receive more arguments to allow you to make control decisions using some computed data quality metrics).
As far as your question regarding your initial setup with the 3.0 version goes, it sounds to me like the software is mostly working correctly. With a 1x1 control problem, you should get a prediction of 0 dB error, because at each frequency line, the controller thinks it can just turn up or turn down the volume until it matches. Basically, you can invert a 1x1 matrix to exactly match any response desired. The response error plot should appear to be only one line, because the prediction line should be identically on top of the specification line due to the zero db error. Because you only have a 1x1 CPSD matrix, and the diagonals of CPSD matrics are real, there should be no imaginary part. Only the off-diagonal terms of the CPSD matrix have imaginary parts, and with a 1x1 CPSD matrix, there are no off-diagonal parts.
It seems like the real error is that the output that the controller desires is too large for your data acquisition system to output. You put a limit of +/- 4V in your channel table; however even with a 2 V RMS output signal, we would expect the peaks to be something like 6-8 V. You might try increasing the gains of your amplifiers so a smaller voltage output from the data acquisition system results in larger response. This should result in less voltage out from the controller resulting in a similar response.
I do have some questions on how you have your channel table set up, which may be contributing to your issues with requiring too much voltage. It looks like you have your accelerometer is not set up as an acceleration channel, but rather a voltage channel with sensitivity of 80 mV/V. I've seen this done when you are using an external signal conditioner; however you also have ICP turned on on that channel, so I'm not sure exactly what your setup is. Regardless, when you specify a channel in the NI-DAQmx libraries with a voltage type, the sensitivity and current excitation source are ignored; it's just measuring the raw voltage. So what's happening is the controller software thinks the sensitivity of that channel is 80 mV/V, but the data acquisition system never applies that sensitivity, so you are getting out the raw voltage as if it were 1000 mV/V. As you can imagine, this could add a 12.5x scale factor that is not accounted for, and may be the reason that you are getting a larger voltage than you expect. The other thing could be the issue is that you have the specification loaded from the that other issue, which was defined in G^2/Hz. The specification doesn't have units associated with it, but assumes it's in the same units as your channel table, so you're actually specifying your test in V^2/Hz, and the scaling in your test between Gs and Vs for your accelerometer is also perhaps adding some unknown scale factor between what you wanted your test to control to and what Rattlesnake is trying to control your test to.
As far as the variability between the output predicted from 2-20 V, I usually only see that when your system identification phase is in the noise floor of the test. The transfer functions are then noisy and can vary run to run. If the response is large enough and the transfer functions are clean, baring any huge nonlinearities in the system, you should see fairly consistent transfer functions being developed, which means if your specification is not varying, your output voltage should also not be varying.
My suggestion would be to modify your channel table to make your accelerometer channel have the Acceleration type, and enter the unit as Gs and type in the sensitivity in mV/G. Then your specification, which is defined in Gs, will be consistent with your channel table. Alternatively, if you must keep it as a voltage channel for whatever reason, put the sensitivity of the channel to 1000 mV/V, which is what the data acquisition system will actually use. Any other value will result in a disconnect between what the controller thinks is happening and what the data acquisition system is actually doing.
ArakisIII
More of a question than a bug since this may just be a problem with how I set up my hardware. Hoping you can provide some guidance on why I may be encountering this issue in the Random Vibration environment. I have a single axis voice coil shaker powered by two audio amplifiers. I am using a NI DAQ USB 6002, and an analog accelerometer set up as a differential input. I have the accel as the first entry in the Channel table and the analog output to the audio amplifiers teed off to an analog input and that is the second entry. I believe I have these all set up relatively correctly as I am able to get pretty far in the System ID steps such that Rattlesnake is controlling the output to the vibe table and reading in and displaying the response.
I have loaded up a modified (reduced Grms) specification from the example you created in another issue on here along with pseudoinverse control, then I perform the system ID. I see the transfer function and phase plots start to populate and take shape. Then when the System ID stops after 20 frames. I switch to the Test Prediction tab. Here I see the Output RMS anywhere from 2 to 20+ depending on my Vrms output during the test predication step. The Response Error is always 0 db. With the "Real Spec" shown but nothing else. I can switch to the Run Test tab and start a test, but this results in the output spiking and the DAQ control loop erroring stating the output is too high.
I also tried the pre-compiled 2.0 version, which lets me get to the Test Perdiction step, but upon completion of all the steps, it give me an error shown below:
Any help or tips on how to debug further would be greatly appreciative. Thanks for the awesome work!
Rattlesnake_SignalGenTableList_5.xlsx