Here is one that I cannot even begin to explain. I have a test system that performs a variety of tests on a small pneumatic pump driven by a low voltage dc brush motor. For a specific test sequence, the system instructs the operator to connect the electrical leads to the motor and click OK (via mouse or enter key) The pump then begins to run and another dialog opens that instructs the operator to manually determine the motor speed via an external stroboscope aimed at the crankshaft portion of the pump. If all goes well, the operator enters an RPM value in the dialog box and hits the enter key (or mouse if desired)
When this dialog box opens the focus is forced to be on the field where the speed is entered and not the OK button. The problem that has shown up is on a new product, the electrical connection has proven to act intermittently. I have not positively identified the cause though I suspect my test leads may be contributing to this.
When the intermittent connection occurs, it, in many cases, causes the dialog box to close whether there has been an entry by the operator or not. I can reproduce this by intentionally disconnecting and reconnecting one test lead to the pump motor and can see the OK button actually start actuating on the screen. This is even though this control does not have the focus.
I am using a wireless keyboard/mouse combo and am wondering if there is actually enough interference coming off the brush motor to compromise the wireless signal of the keyboard/mouse. I plan on trying a hardwire keyboard/mouse to see if this might remedy the problem but wanted to post this odd behavior in the hopes that someone might have seen something similar and discovered a cause that I might be able to look at here.
Using LV 8.6 on an XP box with a USB-6221 DAQ box
Any thoughts are appreciated. I can post code if needed but I have been using this test system on other products for over a year with no issues. This is a new issue that corresponds to the use of a [very] low cost brush motor.
Seems I may not have garnered much interest in this problem so I though perhaps I would display the specific code that is acting wiggy.
During normal operation of the application, only the green shaded section will be visible to the operator when the dialog pops up.
There are options for what text is displayed to the operator based on test parameters for the specific product being tested. Before going into the while loop, the key focus is placed on the RPM control
The code cycles in the While loop until the operator hits the OK button on the front screen or the Enter key on the keyboard.
The problem that is occuring is that if the electrical connection to my UUT (unit under test) becomes intermittent, something is causing the OK button to be activated, closing the dialog before an entry is made. I have monitored this to verify that the operator is not inadvertently hitting a button or key. By manually disconnecting and reconnecting the lead wires on the UUT, I can replicate this problem. I can actually see the OK button cycle on the dialog box even though the focus should be on the RPM control.
Do I need to move the keyfocus property node to the inside of the while loop ? I can easily play around with this and perhaps fix it but I am hoping to understand the root cause so I gain the knowledge of what not to do in future projects.
My UUT is a small pump driven by a low cost brush motor that may be producing excess electrical noise. I do have all my control wiring shielded and grounded so don't really believe that is an issue but I mention it becasue this is the first time this has happened and it conicides with using this motor.
Thanks for any thoughts on this.
Since the original post garnered little repsonse, I am posting screenshots of the code that is giving problems with the hopes someone might have a suggestion.
During normal execution, the operator will see only the area with the green background. The yelow box will contains instructions to measure and record the RPM of the UUT (unit under test) in the appropriate box and then click OK with the mouse or by pressing the Enter key on the keyboard.
The code below is pretty straight forward whereas various controls dictate the specific message displayed to the operator and prior to entering the while loop, a property node is used to place the focus onto the RPM control.
The problem has developed with the intorduction of a product (small pump) using a low cost brush motor. If the electrical contact with the motor becomes intermittent for any reason, the dialog box is subject to close on its own before any entry is made. I can reproduce this effect by manually disconnecting and reconnecting the electrical lead to the motor multiple times. I can actually see the OK button on the front screen start to depress and eventually fully activate, closing the dialog.
I'm just not sure what is causing this since the focus is supposed to be on the RPM control.
Should I move the property node to the inside of the while loop? While I can experiment with rearranging and tweaking the code in various ways, I would really like to understand what is happening here so I know what to avoid in the future.
The new motor that conicides with this issue is a very low cost brush motor that has little noise suppresion bult in. I do however have all my control wiring shielded and grounded as is good practice. I have thought that the wireless mouse / keyboard signal might be getting compromised by the electrical noise and am going to test this theory but I am hoping someone may have some other input that I might be able to investigate.
Running LV ver 8.6 on an XP box with a USB 6221 DAQ if it makes any difference.
Thanks for any help or suggestions
Are your DAQ card connections electrically isolated from the motor and it's power supply?
Have you tried a reverse biased diode and/or filter capacitor across the connections to the motor power leads to dampen any inductive trainsients and brush commutation noise?
Yes, power to the UUT runs through an isolated SSR so there is no physical path between motor power and any signal line.
Unfortunately, I cannot add any type of component, passive or active, to the power circuit as we have to test the unit in an "as shipped" condition. That being said, I can try that approach just to see if it resolves the issue and if so, I can at least then look at other options to attack the problem.
Will be trying options over the next couple days and will report back accordingly.