LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

motor crashing labview

Solved!
Go to solution

You're doing a lot of weird things with the first loop, so I want to elaborate a little bit. I removed the other code to get a simple version of the queue stuff. Here's what you have:

Enqueue.PNG

 

After removing the unnecessary queue code, you get this:

Noqueue.PNG

All of the data gets to the next structure just fine, it just doesn't get enqueued and then dequeued again.

 

Removing the extra logic and data that will never change, you get this:

Nosearch.PNG

You can even simplify it a little bit by checking the beginning of the string for the characters you want without even converting to the byte array.

 

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


Message 11 of 19
(2,280 Views)

Wow, thanks a bunch for your help. The VI is running much faster now but it's still not quite perfect. Do I need to flush the VISA and all the serial data coming in to avoid the buffer filling up? When I run the VI now it doesn't read it correctly as it did before. 

 

James

0 Kudos
Message 12 of 19
(2,257 Views)

The VI works pretty well. There's only on issue I can see. The 'filter' will allow a string of zeros through the comparison with the 85 84 array for some reason.

0 Kudos
Message 13 of 19
(2,232 Views)

@JCG77 wrote:

The VI works pretty well. There's only on issue I can see. The 'filter' will allow a string of zeros through the comparison with the 85 84 array for some reason.


By filter, do you mean the first While loop that is checking for the 85/84 match? Are you still using your queue code, or are you using code like I have above?

The loop I showed you above will only stop when 85 and 84 are the first two elements of the byte array, so it will never output anything else but an array that starts with those two.

(Because it will never stop, you may want to add some timeout criteria in there to stop it after a certain amount of time has passed. Infinite loops are no fun.)

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


Message 14 of 19
(2,221 Views)

I got the VI to do what I need it to do now. I had to change the part where the first while loop checks for the 85/84 match because it would let through a 00/00 match/ I don't really understand why this happens because I coded it exactly as you suggested. But it's alright, I just switched i tto the code I had originally that was used to search for the 85/84 match and now the first while loop performs as expected. 

 

The VI runs almost exactly as I need it to except for one flaw. The PWM part of the code causes the VI to slow down too much. I ran a couple tests and I verified that the first while loop where we check the 85/84 match takes about 1-2 ms to find a match and end while the PID part takes about 380 ms to run on average and the PWM part of the code may take as much as 2 s to run. If I create a new VI with the PWM part of the code I can observe that the new VI will only take about 1-2 ms to run. Is there a way to fix this so that the PWM part of the code will run faster? Is it possible to create a second VI and have the two VIs running together and interacting with one another? Do you think that would decrease the Vi run time? Please let me know if I'm not being clear and I need to explain better.

 

And once again, I really appreciate your help.

 

James

Download All
0 Kudos
Message 15 of 19
(2,192 Views)

You shouldn't need to use the separate VI to speed up the process if it is the same thing. Try to figure out what the difference is between your faster VI and this one. Are the input values allowing the faster one to skip some code that would normally take longer?

 

You haven't supplied the subVIs that go along with your Main VI, so I can't test or replicate your issue. Can you supply both the fast version of your code (including subVIs) and the slow version?

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


Message 16 of 19
(2,176 Views)

I'm running the LabVIEW myRIO 2015 version and the subVIs are exlusive to the myRIO version I think and maybe that's why they're not showing up correctly for you. Is there a way to show you these subVIs even though you're running a LabVIEW and not the myRIO LabVIEW? The subVI opens the PWM channel to the myRIO and then takes the frequency and duty cycle using a 'Duty Cycle and Frequency' myRIO block and then, when the stop button is hit on the large while loop, the error goes to a myRIO reset block.

 

When I have the PWM frequency set to 0 Hz the VI will take 380 ms to run the entire large while loop once. When I set the frequency to anything else (100 Hz, for example) the time will increase by 300 ms (minimum) to 1700 ms (maximum)

 

James

 

 

 

0 Kudos
Message 17 of 19
(2,157 Views)

Perhaps these will help. The first image shows the blocks that I'm using. I think they're appear as subVIs for you because they're from the myRIO version of LabVIEW. Additionally, I've taken two screen shots of the front panel. The images show the time it takes for one iteration of the large while loop as well as the frequency of the motors. The first image has the motor PWM frequency as 0 Hz and the second shows the frequency as 100 Hz. The loop time with the frequency set to 0 Hz runs constantly at 380 ms while the loop run time for 100 Hz can range between 680 ms and about 2100 ms as shown in the second image. 

 

Thank you,

 

James

Download All
0 Kudos
Message 18 of 19
(2,152 Views)
Solution
Accepted by topic author JCG77

I was able to make the VI run at 380 ms with the frequency set at 100 Hz. We were using ther myRIO to power the touchscreen as well as the motors and the motors couldn't draw enough current to run properly. You'be been a fantastic help and I appreciate it so much. 

 

Thanks once again,

 

James

0 Kudos
Message 19 of 19
(2,143 Views)