RF Measurement Devices

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -370024 for CW generation

I've been debating this darned error Which occurs at probe 1 here. (Haaa Probes don't snippet.... The "clear error" is there for a reason.  I hope you understand)

VST2.png

Probe one shows"

 

Error -370024 occurred at niRFRIO Waveform Sequencer 1.0.0 Shared.lvlib:Error Handler.vi

Possible reason(s):

You cannot write data outside the boundaries of your waveform.

Make sure you are not trying to write more data than your waveform can accommodate.

Complete call chain:      niRFRIO Waveform Sequencer 1.0.0 Shared.lvlib:Error Handler.vi      niRFRIO Waveform Sequencer 1.0.0 Host.lvclass:Write Waveform Impl.vi:1      niRFRIO Waveform Sequencer 1.0.0 Host.lvclass:Write Waveform.vi:1      5644RGeneration.lvclass:Write Waveform.vi:1      5644RGeneration.lvclass:Configure Generation Mode - CW.vi:1      VST Out.vi      Test Tx Path Gain.vi.

"

 

The calling vi is pretty straight forward:  Open a Acq and Gen sessions, Configure for CW out and acquisition of waveform, Get Gain, Change frequency and get another gain measurement repeat for all freqs and close the sessions.   You can safely ignore the vi's with the Null method shown below.

VST.png

 

If we get all the way down to here:

zzz.png

We see that the write pointer retains the previous value from the first call to this VI where we ran this sub vi in the false case of tat snippett.

zzz1.png

 

 

Thanks for bearing with me so far.  What I expected was that I would just overwrite the CW Waveform. no harm no foul no error. (Maybe no points for style but certainly not lunacy! its a simple CW measurement optimization doesn't really trump simplicity here)

 

But what's really running around in my head is the question of if it is appropriate for  niRFRIO Waveform Sequencer 1.0.0 Host.lvclass:Write Waveform Impl.vi to throw an error simply because it is called twice?  (go ahead, work it through, the error is generated simply because the vi was called twice but in about the most round about way of tracking I've seen)  There's got to be a simpler method to write this.  My mind is thinking of some Globally initiallized feedback node but I'm really not certain.  Run your noodles over this one more time please.

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 1 of 3
(5,724 Views)

You are running into a valid error (vs bug) with the Waveform Sequencer, as you are trying to overwrite an existing waveform (the CW mode waveform in this case). If Write Waveform.vi is called, the FPGA allocates just enough memory to contain that waveform, and updates the write pointer to the end of that waveform. If the write pointer goes any further (with an additional call to Write Waveform.vi), it goes past the allocated memory for that waveform and errors out. The Configure Generation Mode - CW.vi only needs to be called once for the waveform to be written to the FPGA. In order for you to rewrite the waveform, you would need to delete the existing one using the Clear Waveform.vi (with the waveform name "__CWwave" without quotes) in the Generation.lvclass of the sample project, then call Configure Generation Mode - CW.vi again.

 

The reason for this behavior is because we provide an additional function, Allocate Waveform.vi, that allows the user to set how much memory gets allocated to a given waveform (to write the waveform in chunks).

Message 2 of 3
(5,698 Views)
Thanks for the clarification. As I said I've been debating that feature and agree the bug is in my code.

My reservation is with the manner which the error can be thrown. Ideally there seems to me that an overwrite if wfm exists flag might be one way to elegantly save a developer from himself.

"Should be" isn't "Is" -Jay
Message 3 of 3
(5,676 Views)