DIAdem

cancel
Showing results for 
Search instead for 
Did you mean: 

DataBlInsert Bug?

Solved!
Go to solution

I've been shifting waveform channels using the "wf_start_offset" property, however I want to keep the data in a given x-range (i.e. -180° to 180°). When I shift the data using this property (say by 6.74°), this makes the data from -173.26° to 186.26°. To correct the data, I've been trying to use a call to DataBlInsert to take the last 14 rows (the x-step width is 0.5°) and insert them to the top of the channel and then I use DataBlDel to delete the last 14 rows. Now the data is from -180.26° to 179.76° and I can resample using the interpolation channel that goes from -180° to 180°. 

 

The problem is that the insert call seems to be manipulating the data (possibly inversing and interpolating?) before inserting it.

 

The code I'm using is:

Call DataBlInsert(oChn,707,14,oChn,1)

 What I expect to happen is that the first 14 rows should be identical to the last 14 rows (which is shown in the table below as "Copy rows"), with the first row value 1.0778 and row 14 value 1.0979. However, I get the resulting "HS_P_FILT_CYL1" channel where row 1 value is 1.0933 and row 14 value is 1.079. In the image below, the top plot is the resulting channel and the bottom plot is the Copy Rows channel.

DataBlInsert_Bug.jpg

 

However, if I use DataBlClpCopy and DataBlClpPaste instead, the code works as expected.

Call DataBlClpCopy(oChn,707,14)
Call DataBlClpPaste(oChn,1)

DataBlCopy_Paste.jpg

Ultimately, I was trying to keep the code clean and fast and was thinking the insert code would be quicker when running the code many times on a large amount of channels.  I suppose using copy/paste instead of insert will work, but I'm just curious as to why this is happening and if the insert code would be faster to execute, then I'd still like to use that.

0 Kudos
Message 1 of 7
(3,700 Views)
Solution
Accepted by topic author meatballosaurus

Hello,

 

I have been testing the DataBlInsert command and I have a theory. It seems to me the command first adds the additional (probably empty) space in the target channel and then, gets the data from the origin channel and copies it into the target channel.

 

Since in your case the origin and target channels are the same, when you call the command, it first adds 14 spaces starting at index 1 and by the moment the command goes to index 707 to get the 14 samples, I think they have already been shifted 14 spaces down. Can you try changing 707 to 721? Does it work for you?

 

Regards,

Camilo V.
National Instruments
Message 2 of 7
(3,627 Views)

Camilo,

 

You are right! I adjusted the copy start index to 721 and now the pressure traces look great! Thank you so much for figuring that out. 

 

It might be nice to include that into the documentation for the DataBlInsert command that it first makes room for the number of rows its inserting, then copies data.

 

Thanks again,

Nick

0 Kudos
Message 3 of 7
(3,619 Views)

Hello Nick,

 

Glad to help! Smiley Happy

 

Agreed! I am actually doing some research to figure out if I should report this as a bug or just as a need for additional documentation but as soon as I get a clear idea, I will send a report. I'll make sure I post here when I don in case someone else stumbles upon this.

 

Regards,

 

 

Camilo V.
National Instruments
0 Kudos
Message 4 of 7
(3,606 Views)

Hello Nick,

 

If you work with DIAdem 2015 then you can also use new commands of the Data-API. Here is an example:

 

dim oChn, oGroupChns

call Data.Root.Clear()
set oGroupChns = Data.Root.ChannelGroups.Add("Test").Channels
set oChn = oGroupChns.Add("Test" ,DataTypeChnFloat64)

set oChn = oGroupChns.Add("Test_neu" ,DataTypeChnFloat64)
call ChnLinGen(oChn, 1, 15, 15, "")

Greetings

Walter

0 Kudos
Message 5 of 7
(3,589 Views)

Hello,

 

CAR#645135 was filed about this. Additional documentation about this behavior will be added to the DIAdem help, but we don't really know when this may be. At least, you have two workarounds to chose how to address this.

 

Regards,

 

Camilo

Camilo V.
National Instruments
0 Kudos
Message 6 of 7
(3,575 Views)

So the previous method of just adjusting the copy row number by the ValNo value has been working well so far until today I tried using this code on a different dataset and have been getting errors. The dataset I've generally been using is 1440 points long, so my call ends up looking like:

 

Call DataBlInsert(MyChns,1441,16,MyChns,1)

but now I'm working with a longer dataset that is 207,360 data points long so my call looks like:

Call DataBlInsert(MyChns,207361,16,MyChns,1)

When I try running this however, I get the following error:

image.png

If I go back to the original way I was calling, where the "ChnRow" is "ValNo" rows less than the channel length, then the call runs and the behavior is as I saw before where the data copied is not the last 16 rows but instead starts at row n-32 where n is channel length. So with n = 207360, I need "ChnRow" = n - 15 (anything less than 15 will throw the above error) and ValNo=16 before the code will run:

Call DataBlInsert(MyChns,207345,16,MyChns,1)

Any thoughts on why this is happening or a workaround? Thanks!

0 Kudos
Message 7 of 7
(2,800 Views)