11-22-2013 07:45 AM
I ran into an odd issue using program chooser - it doesn't appear to update the teleop program selection until after the NXT is power cycled. Using LabVIEW 2012 with the f5 patch and current FTC Competition toolkit.
Steps to reproduce:.
I also tried deleting TEST1 from the NXT after TEST2 is deployed - running teleop in FCS gives 'file not found' error until NXT is power cycled
I'm going to try a few more test cases, for now I'm advising our Michigan teams to power cycle the NXT after running Program Chooser
Brian Smith
Affiliate Partner, FIRST in Michigan FTC
Technical and Equipment Support
11-25-2013 01:44 AM
I have 2 questions regardig your 'Steps to Reproduce' list,
By powering off the NXT, you then re-establish the FCS connection by 'CHOOSE'-ing it; this would make the FCS read the current .txt file.
I don't know how often the FCS goes out to read the FTCofig.txt file, but that might be what is creating your issue.
11-26-2013 12:00 PM
Deploy is done over USB, so the FCS connection is broken.
I don't think I ever re-chose the bot from the FCS, just reconnected after downloading the new program and running Program Chooser. I'm planning on playing with this a little more this weekend to see if I can narrow down the issue.
Robots programmed with RobotC don't require a power cycle after running Program Chooser - the change to FTCConfig.txt is recognized the next time the teleop period is started, so at least for RobotC the file is read every time teleop starts.
11-26-2013 12:31 PM
I can't imagine that the FCS would treat LV and RobotC differently on when it goes out to read the file. So, that lends to the idea that the NXT file might not be closed properly by Program Chooser. However, if that were the case, wouldn't it be necessary to restart the NXT even the very first time you run P.C.?
Do you exit out of Program Chooser completely? Maybe could try going to a higher NXT sub-menu?
We just had a 30 hour 4-team lockin meeting and expereinced the issue you describe a couple of times, but escaped it most of the time. But since we had multiple programmers using different laptops - we had a lot of NXT power ups and downs. Next time we have the FCS up, we'll do some more targeted experimenting on this issue.
11-27-2013 06:56 PM
I got completely out of program chooser, started the autonomous program and ran the FCS just like at a competition.
11-30-2013 11:05 AM
My experience is that the FCS does NOT re-read the selected teleop program each time it runs a match (or even connects).
I've seen this several times during software inspections, when teams change the selected teleop program, and it continues to run the old one.
You need to be more pro-active to force the FCS to re-read the program name.
Exiting the FCS and re-starting definately has the desired effect. So this indicates to me that it's not an NXT problem.
It may be enought to manually disconenct the NXT (from the FCS) and then re-connect.
Phil.
11-30-2013 11:35 AM
Bottom line is that the NXT firmware is still 1.31 and the FCS is still v3.0.6 - the same as last season. The change is the LabVIEW 2012 release. Last season these files came in during 'firmware update'; this year we bring them in by running the NXT in 'direct mode' once, as per NI's advisement. (re: Program Chooser, Samostat, NXTShell)
When tracking down the 'Program Chooser' files between the LVLM 2010 and LVLM 2012 releases I noticed a few different sizes in kB for the .rxe's located (and generated). I posed this queston to NI a while back. I have posted instructions for locating the .vi and compiling a fresh .rxe using LVLM 2012. https://decibel.ni.com/content/docs/DOC-17939
Today I'll try a fresh compile, instead of relying on the .rxe in the \subs directory where the 'NXTShell' and 'Samostat' .rxe's live also (the ones downloaded too th NXT when you first run in 'direct mode').
Another option to try is using last season's .rxe for Program Chooser - However, if the 2012 version of the 1.31 firmware is not identical to the 2010, this might not work - in fact, that could be what's happening here.
If a good Program Chooser .rxe is made (found), then it could be moved into the \subs directory used for auto-download during 'direct mode'.
I'll provide an update regarding my file locations found (used) and test results within a few days - maybe some of you can beat me to this
12-04-2013 11:54 AM
Today I'll be testing a 'My Chooser' vi that I compiled from the 'Program Chooser.vi located in [ C:\Program Files (x86)\National Instruments\LabVIEW 2012\examples\FTC Toolkit\Program Chooser 2.0 ] directory. (Why they ever named a folder with a 'dot' in it, I'll never know).
I ended up pulling in all the .vi's from that directory and having to change them to 'NXT Targets' to deploy the program. I have not found a way to add to the 'vi Search Path'. The 'Tools - Option' location has the 'insert' ability greyed out. I even treid to do it from the 'native LabVIEW environment' - no go.
The compile size for this .rxe is 5.31 KB, quite different than the one in the directory where NXTShell.rxe and samostat.rxe are [ C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\NXT\Subs\OnBoardFiles ] which is an .rxe that is 3.32 KB (compiled 10/25/13).
So, I'll compare if one works better than the other.
I've been having so many other strange issues the past 2 days, I may be attempting a full reinstall.
I did a deploy for the samostat.vi from the directory [ C:\Program Files (x86)\Samantha Field Control System\Labview ] and the file size was 5.9kb versus the one in the \OnBoard Files directory which is 2.14kb (compiled 10/25/13).
Has anyone had issues with a non-working samsostat program?
12-04-2013 12:21 PM
I re-ran the Program Chooser test last night with more controlled conditions -
I'm not sure what was happening the first time I tried this - the programs were more complicated but that shouldn't matter. I'll keep watching for this, but it appears to not be a problem with Program Chooser at least for now.
12-05-2013 03:01 AM
So far it seems to be a issue we need to keep an eye out for. Sometimes the newly deployed code for the teleop is being used, sometimes it seems the programming changes didn't work (take)...that is, it still uses the old version. This is happening to us when in LabVIEW RC Editior 'teleop' as well.
Initially I thought that deploying from the vi itself would be preferable...but, it appears that using the 'download and run' option from the RC Editor's 'teleop' testing mode is the most effective way to ensure that we get our 'NEW' mapping used.
When it comes to the FCS and Program Chooser? It's a bit hit and miss so far, but we'll keep watching out for it.
12/11/13 update: So far we have had no problems with P.C. We just had a 10 team event where 8 were using LabVIEW and all was well