VI speed problem

[GeorgeR]

 Hi, just wondering if anyone can help with this problem.

We are using the USB 6501 to generate and acquire TTL signals, and already have some componants working fine using this. We have two units which have motors which turn a swivel arm on each clockwise/ anti clockwise depending on which line gets a high (if both lines are high the swivel arm stops turning). On each unit is a slotted interrupter (SI) with a light breaking diode, once the swivel arm turns and consequently breaks this, a signal is sent. One swivel arm will turn, and then depending on what's happening a vi this will be going into, it will either turn back to its original postion, or the second units swivel arm will turn ('change' on the sub vi).

We want the swivel arms to stop turning as soon as a the signal from the slotted interrupter goes high (we send a high to both motor lines then a low to both) but at the moment  the arms continue turning for a short period of time which is not acceptable for our experiments as the arms are then positioned at a slight angle. Our program dosnt seem to be running fast enough to send a high to the swivel arm line soon enough once the slotted interrupter line goes high to stop the swivel arm turning when we want it to.

We tried using an event structure as this seemed like the fastest option available but this didn't seem to respond properly to the slotted interrupter 'high' event, although the boolean control was indicating true to send a high to the motor line (the subvi containing the event structure received a true from the main motor vi), true was not being sent to the 'DAQmx Write' in the event structure. We were then told that an event structure would probably not be useful for what we are trying to do as we're not manipulating the front panel so the event sructure would just keep waiting for an event to occur. We are now using case structures instead, and the vi is doing what it's meant to do, but still too slowly.   

I attach the sub.vi (stop turn) and the vi (motor) and appreciate any advice on this. Once we have this working, all our equipment setup will be completed so really want to get it sorted!

Thanks in advance
George

[Tom O]

Hi GeorgeR,

I can't see any problems with your code in terms of the response time of the digital lines. Once the program enters the first while loop in the parent VI, it will run Stopturn as soon as the first line on "SI Inputs" goes high. The behaviour of Stopturn depends on the boolean inputs; I'll assume this is all correct for your system!

Some points that might help diagnose the issue:

• Your program includes some 250ms waits - are these the delay that you're seeing?
• Under what conditions does Stopturn's while loop run more than once (line 0 high and line 1 low)? How does the loop finish when this case occurs?
• Are you sure that the DIO line goes high exactly when you'd expect? If you can test this, you can find out if it's your code or your system. It may be that you're expecting the code to set the line high at a certain point, when in fact it's elsewhere in the program. It may also be that your system has some additional mechanical/electronic complications that are delaying the motion. Testing the DIO lines will help to identify this.

If you could consider these things and try them out, perhaps it will help us identify and solve the issue.

I hope this helps!

Best regards,

[GeorgeR]

Hi Tom, thanks for your reply

We managed to fix the problem, the swivel arm just seemed to pass through the slotted interruptor too quickly for it to detect. We now turn the arm 75% of the way and then in 10ms steps untill the slotted interruptor line goes high, this is working fine, just takes a bit longer to complete the turn than before, but this is acceptable.

So anyway, all is now working!

Best wishes
George

[johnsold]

George,

I had not looked at this thread earlier. I have seen exactly the same type of problem.

Another issue is OS latencies. If the OS delays the response to a signal from the USB port (or goes off to look for software updates or whatever!), the signal can be missed.

The way I solved this was to put the stop in hardware. The software sends a Run to Home command. This sets a latch in hardware. While the latch is set the motor runs. The optical interrupter (at the Home position) or a Stop command from the computer resets the latch and stops the motor. If you have analog or digital inputs available, one can be used to monitor the state of the latch. This approach allows precise control of the positioning (to any point with a sensor) without requiring a real-time operating system.

Lynn