property node outputs wrong values

[aputman]

The good thing about code is that it does exactly what you tell it to.  However at this point, you haven't shared the actual code that is causing the issue, so it is really hard to help you any more than I have.  

[JohnEE]

If code does exactly what you tell it to do, why am I getting different data out of two reads of the property node?  Please explain, because as far as I can tell, it is not doing exactly what I tell it to.  Please let me know what I am missing.

While I didn't share this exact code (when I added reading the reference a second time), I did share the code where I first saw the problem of the reference being read incorrectly, as you had requested.  This isn't really any different, except for the second read.

[aputman]

If the control's position has changed between those reads, you will get different values.  Again it is all speculation without seeing the code.

[aputman]

FYI, this is what your Encoder Sim file should look like when calling a VI to be run asynchronously (meaning you want to launch the VI but not wait for it to finish completion).  There is no need to have two event loops or to register the Encoder event in those loops since you are not looking for that event to happen in this VI.  You only need to create the event and generate the event here.  Your File Data VI will respond to the event.

[aputman]

JohnEE,

I am not asking you to re-post the simulated code.  You have already stated that it works fine with the simulated code:

---

The property node outputs wrong values when run by DAQ system/VI, but not the encoder sim.

---

---

If I try to simulate the encoder, to eliminate the complexity, just creating a user event every second, I do not see the problem, so it seems it is possible it is related to the complexity of the system...

---

So you have confirmed yourself that the problem is not with the Filedata VI but there is something else going on in your top-level VI that neither you nor I am aware of.  

[JohnEE]

There is no mechanism in place to move the control...

[JohnEE]

You are quite right; there was no reason to register the event...  I'll remember the Asynchronous Call node for the future.  Thanks.

[JohnEE]

I never believed that the problem is in the FileData.vi.  I see the same issue when using the SetCursorPosn.vi in a different vi as well.  Neither of those vi move their controls nor change the width of those controls.  It's nice to say that the program only does what it is told to do, but that is ignoring that there is a very complex compilation process that went on - memory was managed, low level code was written, etc.

The top level vi does not have access to the controls in FileData and therefore cannot move them.  You can see for yourself that FileData.vi doesn't move the controls, yet two consecutive reads of the control properties yields different data.  If the control is not being moved, what other explanation is there for the different values?

[Ben]

Ben does some wild speculating...

Is the FP getting moved? If so sequencing the two property nodes (FP location and control location) using error wire to sequence between a pair of "DeferFPUpdat" nodes with the first being set to defer (will force screen update and stop further updates) and the second to un-defer (which will allow screen updates).

Could you be getting bogus numbers from your I/O that could be wildly out of range? May log the I/O values and check if any values are bogus... maybe rool-ver of a counter?

Done asking dumb questions.

Ben

[James.M]

I added an extra property node like you've shown and it has the same value every time as the first property node. Are you pausing the code between the two nodes, so you're seeing an old set of values on one indicator?

Otherwise, you haven't included the code that's showing this issue, you've just given us an top level VI set that moves the cursor around. If you can give us some simplified code that replicates your issue, then maybe we can help more.

P.S. You don't need to close control references. Darren says so.