Need help understanding LabView VI Relationships

[ghowell01]

Apologies if I don't use all the right language here.  New to LabView.  Man I have a lot to learn.  Getting help from a few people that has been priceless.  Here's some questions I have.

-Are VIs portable?  Like if I sort out one out for a use case like vision, can I just drag it into another project?

-In a simple motor control I've seen examples where someone opens a controller in begin.vi, then in teleop.vi connects it to a joystick and a motor.  Seems like you'd then have a bunch of instances in your program where you are attaching a single button from an joystick to things (example here in teleop.vi)

-Worked with someone who had a different approach.  He defined the joystick once in perodic tasks.vi and named all the buttons then connected it to the motor in a separate while loop in the same vi (periodic tasks a/b attached)

Curious on folks thoughts on the 2 different approaches above?  What are the differences between teleop and periodic tasks?  Benefits to one of the approaches.

Also, what has he done with the global data?  It's like a vi with no block diagram?  Is is just a portal to key data?

Thanks in advance for any thoughts!

Greg

4908

    

[JimASim]

A couple of things to consider.

1) the latency between the two separate loops.  (In other words if the loops aren't synced, the data from the joystick could be up to 40ms late if you consider the communications and loop sync delays.  (You could move the joystick read to teleop.vi to reduce the communications latency.)

2) Consider any things that slow down the loop that does the motor outputs in the second method. 

(I didn't look at these closely, but I think both would work as long as you understand the potential side affects.)

(If you are new to LabVIEW this might be a resource.  See the Secret Book of LabVIEW post.  This wasn't done by NI.  Sorry.... shameless promotion.... I did the revisions for the 2nd version...)

Jim

[ghowell01]

Thanks Jim.  What are you thoughts on defining the Joystick in one singe array vs spreading the joystick connections throughout the vi and attaching a button/control one at a time to each channel?  Are both acceptable?  Is there a best practice?

I'll check out that post!

[oscarfonseca]

To contribute to Jim's answer:

1. Go to http://www.learnni.com/ and go through the basics of LabVIEW (will not take more than a couple of hours to finish all the tutorial).
2. Have the Secret Book of FRC LabVIEW handy as you program
3. Watch the LabVIEW FUNdamentals for FRC videos
4. Review other resources in the ChiefDelphi post: Learning 

Good luck with Infinite Recharge!

[JimASim]

Sorry it has taken me so long to see and respond to this.  The other responses have a lot of good information.

I've been trying to teach the students on the teams that I help to break a control system into three parts:   ACQUIRE (read, scale, filter) data,  DECIDE (turn the acquired data into setpoints and requests for actions -- drive speed, shooter speed, elevator height setpoint, arm grab command, etc.),  and ACT (turns setpoints into device outputs, does speed control, runs state machines, etc.)

That being said, for the joystick inputs I think it is easiest to put ACQUIRE and DECIDE in the same routine to make things simpler and to make certain not to miss transient events if ACQUIRE and DECIDE where to be put into two different loops.  So, I'd suggest reading the joysticks, separating the arrays into the individual things needed, process the axes and buttons and write the results to global variables so the ACT routine, probably running in "periodic tasks" (or "timed tasks") can act on the generated requests.  Hope this helps.

Jim

Thanks Jim.  What are you thoughts on defining the Joystick in one singe array vs spreading the joystick connections throughout the vi and attaching a button/control one at a time to each channel?  Are both acceptable?  Is there a best practice?

I'll check out that post!

[JimASim]

Sorry it has taken me so long to see and respond to this.  The other responses have a lot of good information.

I've been trying to teach the students on the teams that I help to break a control system into three parts:   ACQUIRE (read, scale, filter) data,  DECIDE (turn the acquired data into setpoints and requests for actions -- drive speed, shooter speed, elevator height setpoint, arm grab command, etc.),  and ACT (turns setpoints into device outputs, does speed control, runs state machines, etc.)

That being said, for the joystick inputs I think it is easiest to put ACQUIRE and DECIDE in the same routine to make things simpler and to make certain not to miss transient events if ACQUIRE and DECIDE where to be put into two different loops.  So, I'd suggest reading the joysticks, separating the arrays into the individual things needed, process the axes and buttons and write the results to global variables so the ACT routine, probably running in "periodic tasks" (or "timed tasks") can act on the generated requests.  Hope this helps.

Jim

Thanks Jim.  What are you thoughts on defining the Joystick in one singe array vs spreading the joystick connections throughout the vi and attaching a button/control one at a time to each channel?  Are both acceptable?  Is there a best practice?

I'll check out that post!