NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Binary String to Database

Solved!
Go to solution

Hello all,

  This is sort of an addon to the "Image data to SQL database" thread I started. My question is more targeted though as I have done quite a bit of investigation.

 

  I am trying to write image data to my database. I successfully wrote and retreived an image to/from the database using LabVIEW without TestStand. However, when I try to write to the database (Column: DATA Table: PROP_BINARY) using TestStand it does not work. The entry made using LabVIEW is not the same as the entry TestStand made.

 

Is there a way to get TestStand to pass the value to the database without molesting it first?

 

Thanks,


Corey Rotunno

0 Kudos
Message 1 of 8
(4,317 Views)

Corey,

 

I want to make sure I understand exactly what we're looking at.  That thread had the suggestion to use an adapter and have the adapter (LabVIEW in this case) handle the database write.

 

If I understand things, you can run this VI external to TestStand and get the results you desire.  However, if you call the VI as an adapter in TestStand, you get different results using the same image.

 

Is that a correct understanding?  If not, what's different?

Message 2 of 8
(4,265 Views)

Jeff, 

 

  Firstly, I have to admit that I kind of screwed up and created two threads about two parts the same issue. In my other thread it looks like I found a solution to my particular situation. The thread is http://forums.ni.com/t5/NI-TestStand/Image-data-to-SQL-database/td-p/3617405

 

To answer your question:

 

Yep, I can do what I need in LabVIEW and actually am using a workaround that leverages that. TestStand doesn't have any issues passing around my binary string from VI to VI without corruption. The problem was when it came time to write my binary string to the database it became changed in some way. I tried a few things:

 

1) I tried writing it to the standard PROP_RESULT_TABLE in the DATA column by changing the DATA column to be varchar(max) and increasing the data size in the TestStand schema to the max value. This did not work, I could not change that string back into a picture.

2) Same as above but using nvarchar(max) instead of varchar(max). I thought that might help as nvarchar is 16bit UTF vs ASCII if I am not mistaken. Results were exactly the same.

3) I tried writing the binary string into the DATA column of PROP_BINARY by creating a 1D Array of binary string as a step result. I was successful in writing to the correct location but again, I could not convert back to image.

4) Create a custom table (PROP_IMAGE) and pass my binary string into LabVIEW and let a LabVIEW VI manage this table. THIS WORKS, but someone offered an improvement  in my other thread I am going to employ.

 

Thanks,


Corey Rotunno

0 Kudos
Message 3 of 8
(4,259 Views)

Jeff,

 

  As a follow up: I did not find an acceptable solution. I can pass my binary string around TestStand just fine. Also, I made a custom data type which is just a string and get TestStand to log said data type to the DATA column in the PROP_BINARY table. However, the value it records to the database is still NOT the actual value of the binary string. I tried playing with properties in the CustomResults container for the step I am using to get the binary string value with no luck. I also tried changing the "Value To Log" entry of the schema to Logging.PropertyResult.GetValString("",0). This still gives the same (wrong) value as the plain Logging.PropertyResult.

 

I suspect that when TestStand writes a string to the database it is changing it to ASCII, but while it is being passed around to different steps it is in UTF-16. Am I onto something or do you have any ideas that could put me in the right direction?

 

EDIT: I found some information at the link below. Unfortunately it seems TestStand changes and compresses my string before putting in database? That kind of stinks...I do not want to have to rely on TestStand to retrieve the values once they are in the database. I am writing an application in LabVIEW to navigate through executions in the database that features a picture viewer to display any charts produced during the selected execution. Is there any way to decompress this data without TestStand? If not, it looks like I am back to my dirty workaround of having a separate table that I have to manage using Action steps with a LabVIEW adapter.

 

https://zone.ni.com/reference/en-XX/help/370052R-01/tsreports/infotopics/retrievingbinarystrings/

 

Thanks much,


Corey Rotunno

0 Kudos
Message 4 of 8
(4,223 Views)

I found an acceptable solution for anyone who comes across this problem. For a short summary, I was having issues writing a binary string to a database using TestStand and then retrieving the value using LabVIEW. Turns out TestStand encodes and compresses the string before putting it into the database. 

 

What I ended up doing is to turn the binary string into a byte array in LabVIEW and passing it into TestStand as a custom datatype(Array of numbers). I made a new statement in my schema for handling the custom type and storing it as a single-byte format.

 

Convert binary data (picture) to byte array:

Picture_GetByteArray.png

 

Make new schema statement to handle my binary data type:

PROP_IMAGE Statement.png

 

Format DATA column:

PROP_IMAGE DATA Column.png

 

Get binary data from DB (in LabVIEW) and convert back to picture:

GetPicFromDB.png

 

Now that I know TestStand was encoding and compressing my binary string, I wish I could find a way to leverage that compression and still be able to convert back into an image in LabVIEW. Using the solution I found, my image takes 5.1MB in the database. Using the compression/encoding TestStand does it only comes out to be 2.1MB, so less than half the size. However I do not know how to uncompress it outside of TestStand so it does not work for me. If anyone knows how I can let TestStand compress the binary string and then convert it back in LabVIEW please let me know.

 

Here's to hoping someone has a better way of doing it! If not, I might just mark this post as "solution", although I hate marking self-posts as solutions.

 

Thanks everyone!,


Corey Rotunno

0 Kudos
Message 5 of 8
(4,201 Views)

This is my quick two second thought on this. If I get a chance I will do some test.  Have you considered if this is an endianness issue?  I believe that TS stores binary data in little-endian and LabVIEW uses big-endian.  If you write using TS and read using LV I believe you would have to convert from little to big before you tried to use the data.

Herrlin

Just trying to spread the LabVIEW love.
0 Kudos
Message 6 of 8
(3,955 Views)
Solution
Accepted by topic author Corey.Rotunno

For your solution since you are using an Array of U8 you don’t need to worry about endianness as I initially guessed.  The reason I questioned this is that I ran into that problems storing waveforms via TS, see partial explanation here.

 

For your compression question I don’t think that you could really utilize the TS encoding and compression as that has to do with text encoding and I would guess you would lose data needed to recreate the image.

 

Is there a reason you need to store the image as a Image Data type or pixmap?

 

If not, you could consider storing the image in a more compressed format such as JPEG.  The below example illustrated the storage trade-offs of using an Image Data format vs JPEG.  As you can see the JPEG is an order of magnitude less in size.  Pixmap was about the same size as a Image Data type.

 

Image Data vs JPEG.pngCapture.JPG

Herrlin

Just trying to spread the LabVIEW love.
Message 7 of 8
(3,910 Views)

Herrlin,

 

  I had ended up using the GZip compression toolkit to reduce the image (image data type) size to roughly 1/7th the original size. I see you did a good bit better than that using the JPEG compression. That is a creative work around to having to use the iMAQ vision toolkit just for image compression. 

 

 I ended up implementing your suggestion by allowing test engineers to write images to the database using both methods of compression, with a type identifier to allow decompression later on. However, I think I might take the GZip compression method away before anyone gets to used to it. I think there are advantages to saving in a more standard compression format so that a future image viewer can be built in any language easily without relying on the LabVIEW specific GZip toolkit.

 

 


Corey Rotunno

0 Kudos
Message 8 of 8
(3,817 Views)