Stuttering relay output

[Edbarrow]

Hi there,
 
I am using a USB-6009 and Labview 8.2 to control a series of relays. On one side of the USB-6009 I have three analogue voltage inputs from a 3-axis joystick which give out a voltage of 1.15V, plus or minus around 1.5V at full travel in each axis. The outputs then go to the digital side, to six relays. When the joystick is moved in one axis, the program monitors this voltage change, and relates it to a time delay. The output to the relay is then pulsed, firstly open for a period of time as defined by the front panel, then closed for a period of time as defined by the voltage input. The relationship between the time delay between pulses and the voltage input is controlled by the numbers input to the front panel, I usually use 15 for value 1 and 300 for value 2.
 
The program works well, and will pulse fast enough for the speed we want it to, but sometimes when the joystick is released from a position if full travel the relay will still actuate one extra time and give one extra pulse. Given that this is an undesired effect, is there any modifications I could make to the code to stop this from happening?


Pulse program.vi:
http://forums.ni.com/attachments/ni/250/42189/1/Pulse program.vi

[James McN]

hi Ed,
Nothing really leaps out at me from your program as to why you are getting this effect.  I would suggest looking closer at your voltage profile from your joystick as two possibilities come to mind.

- Is your loop executing too fast.  If your voltage is not reducing fast enough when you release the joystick it may manage to gain a second reading out of threshold before it reaches the origin.

- Is there any sort of spike if it is released and bounces back from the origin?  Perhaps this may only occur high enough if released from the full displacement.

I can see from your code that there has already been some consideration of these situations so it may not be this.  Equally perhaps you may have to trade off some of this behaviour at one extreme compared to undesired effects at the other extreme e.g. too much delay may miss a small movement.
Hope this may help.

[James McN]

Hi Ed, Was just trying to follow this thread up and see if you had made any progress with your problems and if you needed any more help with it. Regards,

[Edbarrow]

James, I found the problem with the program- it seems that the timings were not acting in the right place, but by moving the task inside the case structure it now acts much quicker. I think the peculiarity was that the program would sense the input, then wait for the time delay before it passes the command signal onto the task, where it would then actuate. In the new version, the program commands the task before the delay time, therefore eliminating the strange timings we were seeing before. I have attached the code so you can see what I mean. Cheers, Ed


Pulse program 2.vi:
http://forums.ni.com/ni/attachments/ni/250/42320/1/Pulse program 2.vi

[James McN]

Excellent! I can see what you mean.  Just a word of warning though, as you have it set up the wait and the DAQmx command will be able to begin in parallel so your timing might be slightly out.  Better still would be to have the DAQmx task in the sequence structure before the wait, this would make your timings more reliable and guarantee the DAQmx executing before the wait. Regards,