Code Generation motor issue

[mathterizer]

Steve:

Good to hear that you're able to move along. Yesterday's meeting was a challenge for us...oddly enough the 'generate code' was working consistently, but I couldn't get any response from the tetrix motors when using the RC Editor PROTOTYPE mode. The NXT was connected, and we could run the motors from the Schematic Editor. the game controller was connected and active (as per screen feedback), but the TANK mode PROTOTYPE wouldn't do anything. When we did a 'generate code', deploy, and 'TELEOP' style of running...it would work. Go figure. I hope they can work this out soon. I can't imagine how rookie teams are dealing with this.

I have been sending ni the optional 'error reports' that have been generated at times (shown when I exit). They seem to implicate plenty of 'BrickReference.lvclass' errors. I hope this helps them track down the issues

[7351ftc]

Thanks to Mathterizer for bringing us to this thread.

Our Rookie Team has been having somewhat realated issues.  As noted in the thread

(https://decibel.ni.com/content/message/60992): our tank drive (and any other related coding in FCS teleop mode (other than inserted autonomous routines) is not working:

"We are a rookie team having a similar problem.

1. Autonomous is fully functional

2. Program Chooser picks the correct teleop program and operates (as seen by display text)

3. Controller is in D position and works when testing via Labview.

4. The controller will not work in Teleop mode.

We are stumped and have spent a great deal of time searching for answers.  No luck so far.  Any help would be appreciated."

and after turning off bluetooth based on some feedback,

"Thank you so much for your fast reply!

Unfortunately, turning bluetooth off has not fixed our problem.  To recap, the (sample) robot is fully functioning when tested via wireless in Labview.  The controller acts as intended when with Labview.  The program chooser file is seeing the correct teleop program as seen by the FTCConfig.txt file.  When switching to the FCS to attempt a simulated match, autonomous works correctly but when the event move to teleop the robot switches programs (as seen by text on the display) but will not receive signal from the controller (which is in D with the mode button set to off 'no light').  We have compiled code to simply run tank for testing purposes and it matches your code exactly from what we can tell.  No success.  We then added a short autonomous routine within the teleop to test that the program actually works.  It runs the autonomous portion of the teleop code but still will not see the controller for operation.

We have uninstalled all programs and reinstalled and tried various naming conventions when uploading files but with no success.  We are so close, but the lack of ability to operate the controller from the FCS has deflated us and taken away time to make further progress.  This has been a multi-hour/multi-week adventure with no luck.

I would say this is challenging, but it has become frustrating.  Thanks again for trying to help us through this challenge.  Any additional ideas would be welcome as we are at a dead end."

So while we are able to develop and generate code that appears to be correct, it does not deploy the correct controller code for teleop operation via the FCS.  Everything else appear in good order.

If this is a sufficiently different occurence, I will be happy to start a new thread as I don't want to hijack the discussion occuring to date.  My concern is that while we are able to advance with robot development and testing, I am concerned we will not be able to operate at an event if we can not solve this problem.

Any assistance and feedback would be apprecaited.  I am also open to taking discussion offline and/or utilizing webcasting to collaborate towards a solution if anyone is interested.  As a rookie team, we appreciate the efforts of those who are responding and are happy to share any knowledge we have gained through this experience.

7351

[mathterizer]

7351

I believe that we are all experiencing the same problems - we each describe them a bit differently and the problems don't seem to have an obvious consistency about them. I will start a new thread that lays out a 'vocabulary' we can talk to so that the National Instrument employees can more clearly see what's at issue here. Perhaps we can collect the 'experiential data' they can use to track down in resolve this issue in a timely manner. I will label the thread: "LVLM 2012 Trials and Tribulations"

In the meantime, based on a review of your previous thread.....please be sure that your Remote Control 'generated code' is indicated to be an 'NXT Target'. The icon to the left of the program name in the project list should look like an NXT face, not a Computer Monitor icon. NOTE: LV will successfully compile and deploy a 'Computer Target' to your NXT, without any warning or error messages. However, the NXT will DO NOTHING when that program is run (it's been compiled into the wrong 'language' for an NXT).

To fix: Edit the vi, select File, choose 'switch to NXT Traget', make sure that all your motor constants are solid black, and tetrix motors, SAVE (both Front Panel, and Block Panel). . Re-deploy to the NXT.

Keep an eye on this, as I have witnessed vi's spontaneously reverting to 'Computer Targets' in this new LVLM 2012.

(review my previous posts in this thread with the red highlighted trouble-solution steps we've had some success with so far)

[ESearl]

@mathterizer,

I think you are confused about what computer target means. Nothing is getting deployed to the NXT, the code is just running on your computer, not the NXT. That is why you are not seeing any warning messages, because it is a valid use case, just not one that has a lot of meaning within the context of an FTC Teleop vi.

When you use NXT subvis in a vi for computer target, they can interface with NXT IO by communicating over USB/bluetooth, but the execution is happening locally(nothing is getting deployed).

Hope this clears up any ambiguity between computer vs nxt target. (sometimes this is also referred to as direct mode vs remote mode).

[mathterizer]

ESearl wrote:

@mathterizer,

I think you are confused about what computer target means. Nothing is getting deployed to the NXT, the code is just running on your computer, not the NXT. That is why you are not seeing any warning messages, because it is a valid use case, just not one that has a lot of meaning within the context of an FTC Teleop vi.

When you use NXT subvis in a vi for computer target, they can interface with NXT IO by communicating over USB/bluetooth, but the execution is happening locally(nothing is getting deployed).

Hope this clears up any ambiguity between computer vs nxt target. (sometimes this is also referred to as direct mode vs remote mode).

I believe that what is at issue for many rookie (and vetern teams) with the new LVLM 2012 is that the 'deploy' will ocur even if the vi is a 'Computer Target'. Of course, the deployed program will DO NOTHING on the NXT when you run it. Unless you know how to 'look for the signs' that you are not in a vi 'targeted for the NXT', you think you've done all the proper steps to deploy your program. (LVLM 2010 prevented you from doing this; LVLM 2012 does not.)  And to add confusion the vi's ARE spontaneously/randomly reverting to Computer Targets, under no action on our part.  Many final error reports (that I have sent to National Instruments through their error rporting dialog) indacate many 'BrickReference.lvclass' errors).

As I think back on this ongoing issue, I wonder if the switching back to the computer target is happening when we exit the vi (or the project for that matter), and at the time of the 'deploy' it was an NXT target - but all the motor constants where in a grayed out state (or set as Lego Motors - meaning that the program would DO NOTHING too. I'll try to keep a closer wye on this....but, at any rate it's not behaving  as it should. It may be that we performed a 'download and run' from the RC Editor that appeared to have compiled and deployed the 'Computer Target' vi. At any rate, I KNOW that it happened...because the file was on the NXT...but, the vi was indicated as a Computer Target when I saw it listed in the Project Programs list (NOTE: We never utilize Computer Target for our vi's, and do not initiate running in direct mode.)

I am working on a post for a new thread where we can try to get a common vocabulary established that we as FTC teams can use to define more clearly the problems we've been experiencing with the LVLM 2012/MCT setup.

I am hoping that a consistency will be revealed that allows for a bug fix.  Clearly, it could be related to the difference between how LVLM 2012 RC-editor/Schematic-Editor treat the NXT, contrasting  'direct and remote mode'.

Unfortunately I've experienced issues in all areas (even sessions where RC Editor Prototype mode NOT working, but Schematic Editor working.)

Thank You!

UPDATE: Just confirmed that the RC Editor (in 'Telop' mode) will deploy a 'Computer Target' to the NXT !!  That's what had me stumped for my first 2 days with LVLM 2012 - when no programs worked. The addition of the non-linking motors, just added to the confusion.

[7351ftc]

Repost from tank drive not working thread (https://decibel.ni.com/content/thread/19055?tstart=0) in appreciateion of your asistnace for our team.

7351

Thanks to all for their help.  What appeared to be a dead end, ended up being a case of getting too close to the problem.

We spent significant resource trying to track down an error with the controller not connecting.  All functionality was working, programs were connecting and all signs seemed to point to either the generated code not correctly specifying the controller or the FCS not recognizing the controller.  I am a bit embarrassed to say that in the end the error was . . . user error. ; )

After reviewing all of the comments and feedback, I went back to the drawing board and to the basics.  In reviewing the FCS materials yet again, I noticed that our FCS was not showing the controller on the dashboard as in the instruction materials thanks to a comment by jmarkesino that triggered further investigation.  Now, that must mean it is an FCS problem right?  Wrong!  The error ended up being that we were operating the FCS thinking everything was assigned correctly as we could see the robot on the game dashboard. Little did we recognize, that the controller was not being shown.  Truly a rookie team mistake!

Reading the manual a bit further confirmed that removing the FCS controller question mark and enabling the controller requires:

"The “?” indicates the system is waiting to know which controller will be associated with Red Team 1, Driver 1. Press any button on the appropriate control to configure."

Pushed the controller button and up pops a 1 on the game dashboard.

Such a simple solution that we couldn't see it from right in front of our own face.  I am pleased to say that we now know the error of our ways and now have a fully functioning setup.  Our appologies to any teams that we may have sent on a wild goose chase to uncover this error and to those who may have been thrown off track with apparently related problems.

While we look at this and laugh now, this journey taught us a lot about Labview basic programming, the transfer of files, operation of program chooser, debugging files and FCS to name a few.  We look forward to learning about advanced programming skills in Labview (and begin learning Creo) as we proceed down our rookie path.

FYI, We have named our practice field Edison Field with a motto of 'from Edison to Einstein'.  A big dream for a very young rookie team of 12 year olds.  But we have time to live and learn and share with the First community.  Thanks for all of your help and inspiration.  We hope to pay it forward many times over : )  We welcome others to follow our journey at 7351ftc.tumblr.com.

7351

[mathterizer]

Good news on the horizon regarding the 'generate code' issues:

17. Nov 4, 2013 11:11 AM (in response Re: teleop controller button no response

Jerry, Mathterizer

Thank you for your pateince and coorporation on this issue. We believe we've found the source of the code gen bug and it is currently being testing by LabVIEW R&D. We will provide a patch as soon as possible to addess this as well as other issues that have been brought to our attention through the forum. This patch will be needed for Mac and PC installations. I will post back on this thread as soon as the patch is avalible.

Thank You

Hunter

reposted from https://decibel.ni.com/content/thread/19271?tstart=0

[APena · Accepted solution]

Hi everyone,

The MINDSTORMS Competition Toolkit for 2013-2014 has been patched and posted here:

Windows: http://joule.ni.com/nidu/cds/view/p/id/4331/lang/en

Mac: http://joule.ni.com/nidu/cds/view/p/id/4332/lang/en

The code generation motor issue described in this forum should be resolved. Please let me know if it is still an issue.

Thanks!

- Aaron