codecubepi
commented
4 months ago Today, @npetersen2 and I did a lot of debugging in the lab with the current version of the code (see the previous commit) in the conversation.
Test Setup
As seen above, we configured a full system including an AMDC + AMDS + uInverter. The intent is similar to the Tutorial 4 from the AMDC docs website, i.e., an open-loop voltage source inverter. The addition is the AMDS which is using 4 Low Voltage Cards---BNC cables are used to connect the measured current (voltage) on the uInverter to the sensor card.
The point of this set up is so that we can:
- Use the AMDC PWM to create ac current
- Use both the AMDC ADC sensor and the AMDS to measure the uInverter ac currents
- Log both of these and ensure they match well
Results
For these results, we are using the v1.3-staging firmware which is the full integration of the new AMDS driver and the new Timing Manager. The timing manager is set in the "legacy" mode, i.e., the ISR is triggered regardless of the sensor complete signal. In other words, the scheduler starts running tasks RIGHT when the sensors start sampling, synchronized to the PWM.
In these tests, we created a task which reads from the AMDC ADC and the AMDS and stores to log variables.
Here are some results we captured:
No delay between ADC and AMDS sample
In this test, there is no delay in the task, and it uses high_priority scheduler registering such that the task runs first.
One cycle of delay between ADC and AMDS sample
In this test, the first code in the task is to run 3000 nop instructions in a for-loop, which translates to about 6 us of delay.
Again, it uses high_priority scheduler registering such that the task runs first.
Note: as measured by the timing manager, the AMDC ADC takes 0.8 usec to sample, while the AMDS takes 10.8 usec. Therefore, this nop delay loop should make it so that we log the data between when the internal ADC is done and when the AMDS is done. This should cause a 1 timestep delay in the feedback.
Discussion of Results
These tests validate the Timing Manager functionality and the AMDS-AMDC interface.
In the first test, due to the fast speed of the scheduler ISR callback and C code, the data logged is "stale" i.e., it gets logged BEFORE the sensors are done sampling. We see this since the waveforms align nearly perfectly. Notice how well the AMDC ADC and the AMDS waveforms exactly match.
In the second test, we show that, if the callback code waits, it can get the NEW samples.
Next Steps
We will continue testing the new code, specifically the "new mode" of the timing manager where the callback happens AFTER the sensors are done sampling. In this new mode, we should never be able to make this "off-by-1-cycle" plot since any delay in the task callback should not matter.
npetersen2
This PR combines the work of @codecubepi and @annikaolson into a new feature release:
v1.3.0. This is a pretty large release---it adds the most features of any release yet to the AMDC codebase. While it is technically a "feature" release, it does break some small things with new function renames and such. However, the aim is to predominately add the so-called "Timing Manager" functionality which interfaces to all parts of the system (sensors/FPGA, PWM/code callback timing, overall timing alignment / phasing).The full changelog is forthcoming. In addition, we will also make a new discussion post on this repo which outlines the changes and the recommended pathway for users to upgrade to this release. We expect this to include these three steps:
v1.3.0release in git and rebuild your AMDC bitstream in Vivadoamdsinstead ofmotherboard---you need to rename all your user-space functions appropriately, and update include paths, etc.usr/user_config.hfile. See the documentation for more info on this.