Quote:
Originally Posted by aeastet
What do you think about these upgrades?
I added a state machine to the code.
I simplified the communication.
I changed it so you only make one call to get the registry values vs calling for every vi.
I added action engines (functional globals) so that the data is easy to get into the robot code. If you drop the example two code into the periodic tasks all you have to do is open the vi and get the action engines that you what data from. Drop them in your code and it works that easy.
I wanted to get your opinion of what I did before I went any further. I would be happy to help contribute to the development of this library. I have used the NavX board for the last two years. I took the code that you developed the first year and simplified it to do only want I wanted it to do. This time I made it do everything still.
Thanks,
Tim
|
Hey Tim,
I'm always open to feedback and/or if I'm doing something backasswards. I've tried to keep the navX library for LabVIEW as easy to use as possible. The user just needs to open the device and use the get/set VIs similar to the default FRC NI sensor VIs. Originally there was a loop VI that needed to be placed in the Periodic Tasks.vi and a Global var for the registry but when I rewrote the code I decided against that as it was an extra hoop the user would need to jump through to get started.
Looking over your code from your ChiefDelphi post, I assume this is the latest, I have a few comments. First, placing the DrvrStn Start Comm.vi loop inside your state machine will cause you to never exit the 'INI' state, never ending loops in loops. Unless you will be rewriting how the data processing is handled and the Open*** VIs, how you are currently writing the 'Action Engines' you are going to be caching a cache, and there is a small possibility where you could read across two updates with how they are decoding the data. In addition caching all of the values inside of the VIs will inflate the memory footprint of the library.
I would like to hear what your definition of easier to use is when it comes to the current library. To me it is currently on par with the native FRC NI sensors, Open -> Get/Set -> Close, the processing happens 'magically' in the background.