NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Property Object file will not write 0 as numeric in TS 4.1.1

Solved!
Go to solution

Hey Everyone,

 

So I came accross a weird issue and wondering if it was a "feature" or if I'm missing something.

 

Basically when I write a numeric 0 to a property object file, using the API Write method, it does not seem to be writing.  I'm attaching a simple example of what I want to accomplish.  Here are the reproduction steps:

 

1- Open the sequence file in TS 4.1.1

2- Run the sequence

3- Ignore the error the first time it pops up....it has to create the file first.

4- Insert any value other than 0

5- Run the sequence again (shouldn't get an error this time)

6- See if the value returned is the same one you initially put in

7- Type 0 as the new value

8- Run the sequence again (still no error...assuming you did it right)

9- See if the value returned is 0...if you see what I'm seeing it will not be 0, it will be your original value.

 

Any thoughts are appreciated.

 

Thanks,

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 1 of 12
(5,339 Views)

Hi jigg,

 

I got the same behaviour in TS4.0

You are right. It is the PropertyObject -Object because on Locals it is the same.

Only the 0 is making the problem. Negative values are working well.

 

If the "Blue Ones" has no idea

i would serialize with the EngineObject.

 

Juergen

 

 

 

 

 

  

--Signature--
Sessions NI-Week 2017 2016
Feedback or kudos are welcome
Message 2 of 12
(5,328 Views)

Hi,

 

It might be that because 0 is a default value, it just deletes the property from the file.

 

 

regards

Ray

 

PS: could you post your example as text

Regards
Ray Farmer
Message 3 of 12
(5,326 Views)

Hi Ray

 

I have change the default to other an 0

The same behavoir! The 0 is still ignored!

 

Juergen

--Signature--
Sessions NI-Week 2017 2016
Feedback or kudos are welcome
Message 4 of 12
(5,312 Views)
Solution
Accepted by ~jiggawax~

Jigg,

 

If you use the ReadWriteOption RWOption_EraseExistingObject or RWOption_EraseAll when writing to the file you will get the behavior you require.

 

The cause is two part.

 

1) One is that in order to minimize memory and file space usage, and to maximize speed, TestStand generally does not write out default values. When reading in a file, if the value is does not exist, it's assumed to be the default.

2) Without the Erase readwrite options, when you write to an existing file, it just adds new information to the file and does not delete any old information. For example, without erase it would also leave subproperties from previous writes in the file too.

 

It's a reasonable argument to make that when writing out a property with a default value, any non-default value already stored in the file should be removed. I will record this issue for future investigation, however, you should really be using one of the erase options anyway as I doubt you want subproperties from previous writes to be kept in the file either.

 

Hope this helps,

-Doug

Message 5 of 12
(5,302 Views)

Thanks Dug,

 

It makes sense now that you put it that way..... 🙂  I thought I had tried that but I guess not.  Have a great day!

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 6 of 12
(5,293 Views)

On a side note dug-

 

Is there a reason why the SequenceFile.Save() method won't work with just the deployment license?  Basically we were just setting the fileglobal defaults in our file and saving it on the fly.  But when we deployed we realized the deployment license wouldn't allow this.

 

Thanks,

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 7 of 12
(5,288 Views)

I think it's just a restriction to keep people from using a base deployment license with a custom editor. A custom editor license allows saving.

 

Also, although it might be ok in your situation, modifying sequence files on a deployed machine can make it harder to verify that an undesired change wasn't made to the system either accidentally or on purpose.

 

I think if you just want to persist some settings across runs of your system, using PropertyObject.Read/Write like you are doing is probably the best way to go. Another alternative, if you just want to load settings for variables dynamically at runtime is to use the propertyloader step type.

 

Hope this helps clarify things,

-Doug

 

Message 8 of 12
(5,284 Views)

Thanks a bunch dug,

 

That's pretty much what I figured and sometimes it does make sense that if you open the API too much people can really get in trouble. 

 

The problem w/ the property loader is that there isn't a solid dynamic way to write to it.  We have a VI that pops up and changes calibration and cable loss settings.  We need to do this on the deployed machines abt once a week.  The property object file is the best solution.......especially now that it can handle default values.

 

Thanks again,

 

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 9 of 12
(5,270 Views)

Hi Doug,

 

with the options it running!

but just a question on the "default" value for more understanding this.

 

If i change the variable in editor from "default" 0 to 1 (now think "1" is the default  )

Note: Write-> NoOptions! 

but if i run the example 0 is still ignored i assumed that 1 is ignored

(so my upper thoughts seems to be wrong)

 

So so that do you descripe as default? value in editor, or value that comes as default with type

when inserting a variable in editor.

 

Juergen 

--Signature--
Sessions NI-Week 2017 2016
Feedback or kudos are welcome
0 Kudos
Message 10 of 12
(5,255 Views)