Touchpanel numerical control bug

[Stijn_Schacht]

When you input a number with a alfanumerical keyboard in a numerical control on a WINCE (not XP) touchpanel which is running only ONE loop: it will be updated.

If you try to input that same number with an alfanumerical keyboard in a numerical control on a touchpanel which is running parallel loops, it will be ignored. However, using the up/down arrows to change or input a numerical control on a touchpanel running parallel loops, will update the control.

Very nasty bug when using touchpanels in operating systems: the operator has no id what hit hem, when he started his machine using default values, because the ones he entered with the keyboard, weren't updated...

there are two attachements:

TEST.vi

TESTHMI.vi
TEST.vi is the main vi to run. It contains one loop, and a reference to TESTHMI.vi, which includes another loop. So essentially, two loops in parallel. You can monitor the parallelness by looking at iter1 and iter2. Normally TESTHMI.vi should be the on top window, so you can experiment with the irresponsiveness of the numerical control, as illustrated above. You should connect an USB keyboard to the touchpanel to reproduce my bug, or you can also use the built-in software keyboard of windows CE.

I have no id wheter windows CE is responsible for this, or wheter it is the CPU that cannot handle keystroke events with multithreated applications?

To test this bug, you will need LV PDA + a touchpanel and a keyboard. I have tested this bug with LV8.5 and LV PDA 8.5 + TPC-2012 and TPC-2006T, I believe it is a general bug!!

If this gets not fixed, I will have to stop using NI touchpanels all together, since they are to dangerous to use.

[altenbach]

Duplicate

[Stijn_Schacht]

I know it is a duplicate, I appoligized for that in the other thread... I only want to have an answer as soon as possible, since I cannot continue with my development.

I feel rather dissapointed, since I'm developping a huge framework, to continue using LabVIEW and its products in machine control. I don't understand that people can use the products, since this bug is this serious that any machine control application would have to deal with this? Or is NI lying about the fact that they have other clients using their productis in machine control? I have nothing against LV, I think its a great product that suffers from growing to fast in different fields.

But nobody complains about this error I've seen?! I've tested it with two different computers now: a new fresh installation and my old installation on a different laptop. This on two panels: TPC2006T and TPC2012. I've seen the same bug now for four times... 😞 Nobody gives me an answer, instead I get

"duplicate"

or

"you are in the wrong thread"

yeah, so much for helping each other out. Excuse me for being a bit impolite, its just that I've been working for some weeks straight to sort it out myself, but after all I've done I can't imagin what the h*ll it is that I'm doing wrong... So I must conclude by exhaustion that it is the product itself that fails, not me. The included vi's together with somebody else that just runs the code, and than that person telling me that it is correct what I've done and he also sees the problem, would relief the pressure on my shoulders and give me a sparkle of hope that someone will find an answer to my problem. It is only a small thing to do, not? I'm not begging, but I hope this post will not fade out into the great mists of *nothing*

Imagin that you have sold some applications, that can NOT run because of a bug. Who will have to pay you guess? What will you do with your bussiness if you cannot go developing/selling applications anymore because they wouldn't run anyway? I hope later on I can be really ashamed of this post, because it turned out not to be a bug, and just a simple mouseclick that I didn't do. I will be more then happy to appoligize to anyone. But we will see when we get there, if we ever get this far.

[tst]

The answers you've been getting are simple - when you posted in the bug thread, you were asked to start a new thread in the LabVIEW board, because people are not guaranteed to watch this board. Instead, you started two threads here (which possibly happened because of a known bug in the forum software). The "duplicate" response is not for you, but for others - no point in people posting replies to this thread when the discussion happens in another thread. No one is out to get you.

---

Stijn Schacht wrote:

The included vi's together with somebody else that just runs the code, and than that person telling me that it is correct what I've done and he also sees the problem, would relief the pressure on my shoulders and give me a sparkle of hope that someone will find an answer to my problem. It is only a small thing to do, not?

---

It's a small thing to do if you have a TPC. Most people don't, especially not on a Sunday night (which it is in the US). I would still suggest that you post in the LabVIEW board and then wait.

Personally, I can't see anything wrong with the code, but I'm not sure exactly what the problem is. When running on Windows, the VIs behave as expected and I don't have a TPC.

That said, there was something weird with that subVI. After I played around for a minute (running, stopping, etc.) it sort of got locked. I couldn't open the BD and when I tried to close it it threw an error message. I don't think that's the source of your issue, but it's a bit weird.

[Stijn_Schacht]

I already posted it in the labview thread, and didn't expected to see anything else here. I am aware of the fact that it must be middle of the night across the sea. I will wait 🙂

thanks anyway for trying to look at it, I also know that this productline is apparantly not very well spread so I can only hope that someone else already has a sollution. I already found an earlier post from a couple of months ago, from someone that had the same problems. He just could find the source of it, but these problems only occur when trying to use multithreads on CE.