12-09-2013 09:56 AM
Please excuse my ignorance, but I have been searching for an answer to this question and couldn't find anything...
I have two parallel while loops in my VI that are handling user events (one of then sends serial commands to run a motor and the other is used to zero sensors). I was wondering if I need to put a wait timer in the while loops to improve the VI execution. I had been assuming that if an event is not triggered the while loop remains idle.
To add to this, my main problem is communication with a USB data logger. I am trying to aquire data for an extended period of time (~20 hours) and the VI seems to run fine for a while but eventually the DAQ hardware stops resopnding and it ruins the test. It never happens at the same time into the test, but it's usually anywhere from 1-2 hours. I thought that I might be bogging down the CPU with these parallel loops, but I am still quite new to LV and I'm sure there could be another culprit for my issue.
Any recommendations would be greatly appreciated. Thanks in advance.
12-09-2013 10:07 AM
You do not need a wait function. The loop is indeed idle while thte event structure is waiting for an event.
I would check the power settings for the USB ports. A common problem is that the PC will power down a USB port when not in use to save energy. In reality, it wastes energy because of the time and frustration the programmer needs to put in to figure out why the app seemed to stop working.
12-09-2013 11:01 AM
Thanks for clearing that up. The USB power issue had occured to me and I've made an attempt to change the power settings to prevent powering off USB. Still no luck.
I came across this thread which describes the same issue (except I'm not using wireless USB)...
My DAQ involves 15 differential analog inputs which I would like to sample at 0.5S/s or once every two seconds. I've tried to slow this down to 0.25S/s thinking it may help, but it doesn't. As I already said, these are aquired through a USB data logger. I also have communication (TCP) with an envirenmental chamber at the same rate (I query the chamber for its current temperature, and it replys back). I've setup the VI so that the USB and TCP communication doesn't happen simultaneously, but I don't know if that provides any benefit. Communication with the motor driver only occurs once at the beginning of the test, so I don't think I have any problems there.
I'm considering switching the USB data logger to something that is PCI connected. I'll lose resolution (22-bit vs. 16-bit), but if you think it may solve my problem I'll go ahead and do it.
Thanks again for the help!!
12-09-2013 11:26 AM
You are opening and closing the VISA resource every time your event fires.
STOP THAT! Why, because some equipment does not really like opening and closing sessions multiple hundreds of times (and the OS is doing a lot of dancing in the backround that is totally unneeded) Open the session once, use it however long you want, close it when you are done. This also prevents some other process from getting in your way while you are running.
12-09-2013 12:32 PM
And you really should not be using the Mouse Down filter event. Just use the Value Changed event.
12-09-2013 01:13 PM
The reason it's written as a mouse down event is because its to start a motor jog...
I have two buttons on my front panel ("jog up" and "jog down"). Basically I want the motor to run while a button is held down, and I want it to stop when the button is released. If I were to use the value change event, the code would execute twice (false-to-true and true-to-false) which is not good. I have the mouse down event (which is shown) and a mouse up event which is similar but is simply a serial string that tells the motor to stop jogging.
Any thoughts on my DAQ problem? That's where I am really struggling.
12-09-2013 01:29 PM
Use the mechanical action Switch Until Released. Then use the value change event. You will grab a value change upon the button being pressed and when the button is released. The value of the button when the event case executes will determine whether to start the motor or stop the motor.
12-09-2013 01:31 PM
@AsstToRegionalMgr wrote:
The reason it's written as a mouse down event is because its to start a motor jog...
I have two buttons on my front panel ("jog up" and "jog down"). Basically I want the motor to run while a button is held down, and I want it to stop when the button is released. If I were to use the value change event, the code would execute twice (false-to-true and true-to-false) which is not good. I have the mouse down event (which is shown) and a mouse up event which is similar but is simply a serial string that tells the motor to stop jogging.
Any thoughts on my DAQ problem? That's where I am really struggling.
That event is not going to do what you want. The event on happens once per click. So even if you leave the left mouse button down, it will not keep retriggering. You need to either poll the buttons or come up with something more imaginative for your event setup.
12-09-2013 01:51 PM
That's exactly it... I don't need the event to keep triggering. Once the motor driver receives the serial string that tells it to go, it doesn't stop until it receives the serial string that tells it to stop.
I'm not having any problems with this part of the code, but I will change the event to a value change event and use a case structure to determine whether the motor should run or stop. I hope that will appease everyone.
The matter at hand is still regarding DAQ, I think I'll start a new thread to get away from talking about my event structure.
12-10-2013 01:40 PM
I recommend putting the VISA Open and Close outside of the while loop. This was mentioned before, but it really is good practice not to open and close the reference repeatedly.
Additionally, the event structure will not execute until it registers one mouse down event. Why not get rid of the event structure, and instead add a stop button to stop the while loop? Then close the VISA reference after the while loop stops.