property node outputs wrong values

[JohnEE]

I am having a problem with occasionally outputting wrong values for a control.  I am programmatically moving the mouse cursor around the screen, between 4 controls.  The vast majority of the time it works fine.  Every now and then, the cursor jumps to the wrong part of the screen.  I tracked it down to the property node connected to the control refnum.  I connected indicators to the refnum going into the property node and the values coming out as seen in the block diagram:

This sub-vi is called for each cursor move.  The normal outputs for one of the controls are shown here:

However, sometimes the wrong width is output:

Sometimes the wrong top position (this is the top position of the previously selected control:

Sometimes the wrong height:

It happens for different controls, and many times it outputs the same wrong values - e.g. the wrong width of 1944 came out several times while gathering this data.

I have a fairly complex system - a custom DAQ system (with a rotary encoder) connected over the network to my computer and a fairly complex top level vi.  There is a subvi panel that opens to set configuration parameters, using user events from the rotary encoder to move the cursor on that subvi panel.  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...

Any thoughts would be greatly appreciated!

John

[aputman]

You will have to post more information, more VIs.  We can't debug pictures unfortunately.  I can only debug 2012 VIs. 

[altenbach]

Hard to tell without looking at the rest of the code, e.g. how this subVI is called. What's in the dll?

Generally, a cursor is a control, i.e. under the control of the operator. I really hate any UI that tries wo warp the mouse, basically pulling the rug from under my feet. Many UI guidelines recommend against it.

[JohnEE]

Attached are the VIs, saved for V10.0.  The EncoderSim.vi is the top level, opening the subvi FileData when the FileDta button is pressed.  The EncoderSim.vi then simulates the encoder turning once per second.  The SetCursorPos of the User32.dll is called to position the cursor.

I understand that generally it is a bad idea to move the cursor around programmatically.  However, on the device on which this will be used, there is no mouse nor keyboard.  The encoder is the "mouse."

Thanks!

John

[aputman]

The sim code seems to do what you describe so I'm not sure where the wrong values are coming from.   You circled the width in the second image and said that 1944 is the wrong value but that is the same value that is shown in the first image in the Left indicator.  I'm not seeing where those values would get mixed up.  

I think the only thing I can offer you right now is tips on your coding practices.  

• You don't need two event structures in the Encoder Sim VI.  I realize this was just your attemp to simulate the encoder but the fact that you used two event structures here tells me that you have likely done it elsewhere in your code.  It's not good practice.  
• Learn to use latching buttons for your events so you don't have to explicitly set the value back to false. (see Exit event in FileData where you pass the button ref)
• In FileData, why subtract one from the array size and then compare "less than or equals"?  Just use the array size and a "less than" comparison.  

[JohnEE]

Hi Aputman,

You are correct about the 1944, I hadn't noticed that...  However, that's not the point.  The Left indicator is the output of a calculation, while Width is the output of the property node.  The property node shouldn't output anything different than the value of that property - certainly not what was output by the Left indicator.

Part of the problem is that the property node never screws up with the Encoder Sim vi running it, only with my more complex system.  Encoder Sim was written to try to simplify things for troubleshooting, but it isn't helping.

I don't normally use two event structures in a vi.  I did it in desperation, originally trying to use front panel buttons operated by the keyboard to simulate 3 different encoder inputs - CW, CCW, and button press.  Never got it to work....

I didn't use a latching button there because I was stopping two loops with it - if I used a latching button, it would stop the first loop but not the second and the program would never end.

True, I could have not subtracted one there, but I would have needed to do it in another case.  And, the way I had originally written the code, I would have had to subtract one in several places, which made using "less than or equals" in one place more attractive than using "subtract one" several times.

[aputman]

So how does this encoder work?  If you want to change the Location value, how do you scroll thru the values in the ring box without a mouse or keyboard?  And if the sim code is not the problem, why are you posting the sim code?  

[JohnEE]

As I explained above:  "I have a fairly complex system - a custom DAQ system (with a rotary encoder) connected over the network to my computer and a fairly complex top level vi.  There is a subvi panel that opens to set configuration parameters, using user events from the rotary encoder to move the cursor on that subvi panel."  You then asked me to post the VIs.  Since I couldn't post my hardware, and user events for the encoder needed to be created, I posted the simulated encoder vi.

The DAQ system is monitoring the encoder and sends data - CW, CCW, and button press.  My top level VI turns those into user events, which go to the FileData.vi.  The property node outputs wrong values when run by DAQ system/VI, but not the encoder sim.

[aputman]

Could there be some debounce in your encoder that is causing some issues?  

[JohnEE]

No, I debounce it in hardware, and I checked to make sure it was working.

Some more info:  I duplicated the control property node and indicators:  Obviously, reading the same control refnum twice should give the same results, right??

Reading the same control refernce twice sometimes gives different results:

In this case, the first time it read it, it was correct, but the second time is incorrect.  (The incorrect value, 36, is the correct value from the previous read of the previous control refnum.)  Sometimes the first read is correct, sometimes the second.