Lease Squares using Block Memory inside a SCTL

[jp82]

I am trying to make a least squares program to calculate the slope (I know the intercept is zero) of a set of data. I have data coming in on 16 channels (interleaved). I am trying to use block memory to keep track of the three sums (Sx, Sxx, and Sxy) and an address 0 - 15 for each channel. I am running the code on a 7962 card. I followed the example in the help file and included the appropriate feedback nodes to allow the block memory a full clock cycle to write/read from/to memory.

Right now I have all three memories configured the same way:

• Request Number of elements: 16
• Implimentation: Block Memory
• Data Type: I64
• Interfaces are set to never arbitrate as there are never multiple requestors
• Initialization: I also have code (not shown) that initializes all of the addresses in the block memory to zero every time the code starts.

The code seems to work for most of the channels using simulated data; however, it does not work for all the channels. The channels that fail the slope calculation change depending on the number of elements I select in the block memory setup page (I always am choosing a number greater than 16).

1. What does NI mean when they refer to Block Memory as lossy?
2. Am I using the block memory correctly?
3. Is there another problem somewhere in this SCTL?

Thanks,

Jim

[j_bou]

Hello jp82,

Regarding Block Memory items (called Memeory Items in LabVIEW ) being lossy, you can compare this behavior to how a local variable is lossy. In both cases, data can be overwritten before another process has had the chance to read the value. Thus, it is typically useful for applications where the latest value is of primary interest.

I don’t see anything apparently wrong with the code itself or in the way you are using the Memory item (except for the stop condition not being connected). You mentioned that some of your memory items fail depending on the number of elements you select in the block memory setup page. Can you provide more details regarding configurations that fail and configurations that work? Did you notice any patterns?

Regards,
J_bou

[jp82]

Regarding lossy - thanks for the clarification. That's how I interpreted it. It seems like block memory should work for this application.

Regarding memory initialization - when I set up a block memory, I can select what values I want it to initialize to. Can I force the memory to use these initialization values every time the code restarts or does it only initialize when the code is downloaded?

The memory items don't fail so much as I don't get the results from the slope calculation. For example, I'll generate test data for the sixteen channels with slopes from 1-16. When I look at the slope calculated by the LS, the code will get the slope for most of the channels correct, but typically one to three of them with be wrong and the calculated slope will continue to grow the longer the code runs. I'll try to add some more specific examples on Monday of next week to help clarify.

[jp82]

A little more investigation today shows that on the first run of the code after downloading the produces the correct slopes for channels 0-15 except 9 and 15. The attached figure shows the result. The Slope array is the slope for each channel from the host machine and Data is the resulting slope from the LS calculation. The two should match.

On the subsquent runnings of the code, I see the correct result only for channel 0. The other channels the output slope changes in time and continues to grow.

Any advice is greatly appreciated.

[j_bou]

Hello jp82,

Memory initialization (when using Memory Properties:Initial Values option) will only occur when the hardware is power cycled. Changing the Memory Properties:Initial Values settings and deploying a recompiled FPGA bitfile should also initialize the memory's values.

Best Regards,
J_bou