Team Fusion 364 2012 Code

[RyanN]

Here's our code for this year. I've striven for good, well documented code that is highly efficient this year. Of course with the build season rush, we didn't document it very well at the time, but now that we've had some time to relax, we've documented it, color coded it, and changed a few small things. Now we are in the position to test it to make sure everything still works.

Anyway, here's the code if anyone is interested. I was a LabVIEW Developer (not certified) for my internships over the past few years, so I'm pretty experienced at this point.

2012 Robot Code (Cleaned) 2-24-12.zip

I'd love to hear feedback, or questions regarding the code.

[DominickC]

Wow! Your code is quite professional and certainly highly sophisticated at first glance. I'll be taking a closer look tonight and seeing if I can't learn anything from it!

[Doc Wu]

Very impressive code. I'm hoping to learn a lot from it.

You use a lot of flat sequences in both begin.vi and teleop.vi. They are single frames that seem to group subsystems together and make the code very easy to read, but is there more to them than that? Why not just a decorative frame? Or do you want each subsystem to execute together?

Our teleop.vi, for example and most others I've seen, are just one big mess of code.

I'd be interested to hear your reasons behind this.

[RyanN]

Originally Posted by Doc Wu

Very impressive code. I'm hoping to learn a lot from it.

You use a lot of flat sequences in both begin.vi and teleop.vi. They are single frames that seem to group subsystems together and make the code very easy to read, but is there more to them than that? Why not just a decorative frame? Or do you want each subsystem to execute together?

Our teleop.vi, for example and most others I've seen, are just one big mess of code.

I'd be interested to hear your reasons behind this.

The flat sequences serve no purpose other than to just separate subsystems, which could be done with decorative frames. I generally don't like using decorative frames as they aren't as modular as the flat sequence. I can simply click and drag flat sequences to move them. Nothing wrong with using decorative blocks though. It probably adds a little overhead, but it's not much.

[plnyyanks]

I'm impressed with your code. It looks really well done (and well documented, which is almost as important). Kudos to your team for some nice software. One question: in your autonomous, was there any reason for using a bunch of sequential while loops instead of using a state machine(s)? Maybe it's just me, but I tend to prefer state machines for this kind of thing - we have many in our code....

[RyanN]

Originally Posted by plnyyanks

I'm impressed with your code. It looks really well done (and well documented, which is almost as important). Kudos to your team for some nice software. One question: in your autonomous, was there any reason for using a bunch of sequential while loops instead of using a state machine(s)? Maybe it's just me, but I tend to prefer state machines for this kind of thing - we have many in our code....

The student that did it went off of the demo autonomous code. It's in multiple while loops because of the safety configuration for the drive motors. If a value is not fed within 100ms, the motors will cut off. Since we're driving the motors for longer than 100ms in each pass, the motors would error out and cease to work. It's easier to see sequentially like the way it's done. State machines are often hard to follow in LabVIEW since they will most likely involve a case structure, which will hide code from you.

He could have just disabled the safety config on it, but in the long run, it doesn't matter either way.