I am having a diffecult time getting LabView up and running to any capacity for the Challenge. I have followed all the instructions to install LabView (f5), the NXT Module (f3), and the FTC Toolkit (f1). I have connected the NXT Brick to my laptop, and updated the firmware. I have also tested the scematic, which runs the motors correctly when manually hitting the "go" button. However, as soon as I click the "New Remote Control" button, or try to load a pre-made configuration, labview either throws a "Access violation (0xC0000005) at EIP=0x76FC37A2" error, or simply stops responding without any message. Occasionally, it will briefly state that "the keyboard is not initialized" or "the joystick is not initialized," but then proceeds to crash. On one sigular instance I was able to click on one of the control selection buttons, but then it crashed as usual.
I have gone through and had the updater repair all related files, and have done one full reinstall from scratch. I have tested all procedures without any form of virus protection enabled, with no change. The problem is the same regardless of weather or not an NXT is connected, or any combination of peripherals attached.
I have read every posting on the forums related to it, and every other forum, none have this exact issue, and none have provided any workable solution.
I would appriciate any form of help on this, as I have not been able to even start any programming without the basic remote control worked out.
My laptop's relevent specifications:
Windows 7 64 bit
Have you gone into the 'FTC Arm & Gripper' project where there is a Remote Control configuration already made available to you (Default Configuration.rcc)? Have you tried controlling from the 'keyboard' when in there?
I did here of someone that had LabVIEW crashing on them, and they said that connecting 'a different keyboard' fixed it.
Does the joystick seem to be recognized by Windows, outside of LabVIEW? Could it be a 'plug and play' driver issue? There are times that I have to go into my devices list and remove some of the 'human interface devices' to get my peripherals recognized by the LabVIEW RC Editor - when the com port assignments get into the 'higher numbers'.
Consider using a USB 1.0 port (if one is available) ?
Joystick must be set to D (switch on bottom). If you had to change this, then re-initialize it at the Windows level (while exited from LabVIEW).
Just some ideas based on things I've seen posted and my prior experiences with the LV RC Editor and joystick issues.
I have indeed tried the Arm & Gripper configuration file, but opening it causes the same effect. I've also tested it with just the NXT plugged in (no controller attached), and the problem persistes, as well as when I plug in a different keyboard.
As for the joystick, it is definitely functional outside of LabVIEW, and I have used it on another application successfully.
My laptop only uses USB 3.0, but trying both the NXT and the joystick with a 2.0 external port has had not impact.
I did not know about the "D" thing, but switching it over and reloading everything has not changed the crash.
It seems that the problem is unrelated to any external hardware I use, and must be caused primarily by software conflicts in LabVIEW.
Still pretty clueless as to what's happening in general, though.
Seems that you've exhausted the obvious. Keep an eye out for that 'D' switch - even at competitions (sometimes kids 'prank' and switch it on teams - not funny, of course. It must be in D to function, and the 'mode' switch [green light] should be off.)
Have you had any success with a different computer?
Certainly sounds like some internal SW/HW incompatibility that is specific to you. Hopefully the R&D team at NI can work it out for you by tracking down that error. Sorry I couldn't help you more.
Good to know. I'll keep that in mind.
And I do not have access to another presently, but I suppose I could try in a week, when I will. I'm just not looking forward to losing a week of programming time.
And no worries mate, it's the NI guys that need to work out a solution. Thanks for the suggestions, though.
I'm just not looking forward to losing a week of programming time.
You mention being able to run in Schematic Editor, so it sounds like you have some level of functionalilty. Of course, you can test individual systems here and flesh out any mechanical issues.
Also, have you tried to write a simple VI that just moves somes motors? The kind of thing you'll be doing for autonomy.
Even if you can't map your controller and practice 'driver controlled' period, maybe you can work on learning some autonomy this week.
The good news is that one you get the RC EDITOR working and can 'generate code', that aspect will move along VERY quickly.
It sounds like there is something installed on your machine that may potentially appear like an input device (joystick). I've seen this happen before with some scanner drivers. Can you try the following experiment?
If you are using LVLM, first open labview in the full mode, (Tools ->Choose Environment).
This should give you an expanded palette set. Open a blank vi and navigate in the palettes to "Connectivity -> Input Device Control".
Grab "Query Input Devices.vi" off the palette and open it up. (This subvi is used by the RC Editor to find joysticks).
Run the VI and take a look at all three output arrays. How many entries do you see in "Joystick Info" / "Key Info".
Try running the "Initialize" subvis with different index inputs as well and see if some particular discovered device causes the crash. If so, and you recognize the device, it should be possible to disable it somehow from within control panels.
Hope this helps, good luck!
I have done as you instructed, but as soon as I try to run the file it either crashes immediately with an "Access Violation" error, or simply stops responding. Or sometimes both at once.
Not sure where to proceed from here.
Hi EPHorizon and Ethan:
I definitely think you're on to something with the 'input device control' initialization being at issue here (ie. devices found). As luck would have it, I actually had the opportunity to meet with EPHorizon at a recent event and sit down with him at his computer. He has been very thorough in his troubleshooting efforts regarding these 'RC Editor' crashes. Fortunately he was able to utilize the Schematic Editor to proof their mechanical systems, write vi's, and succesfully deploy them to the NXT for the competition. This gave him the valuable opportunity to write code at home. They ran 'RC Editor' on an alternate team computer and 'shared' the project between installations as required. I was very impressed with his level of expertise, and his ability to overcome the obstacles regarding the 'RC Editor'. (Way to go EPHorizon you are a great asset to your team - an amazing team all around; such dedicated kids and coaches.)
I have noticed that 'mouses' never show up in the list of devices. Could the 'touchpad' on your computer be something more than a standard mouse, and RC Editor is attempting to 'initialize' it when it shouldn't (or some other kind of internal device, as suggested by Ethan). Perhaps if you were to disable these devices, they won't be found, and no initialization would be attempted. Just some thoughts to explore.
His system is an Alienware with high end graphics. I've asked him to share more details with you regardiing those settings. (We didn't have the time to explore all those options, but I guarantee he is probably on that already.) If he's exhasuted the 'Human Interface Device' angle, perhaps there's something in the displaying of the RC Editor 'page' that differs from the other pages involved (that do work for him).
I did notice that his machine was very responsive to installing drivers for the joystick; we even flipped the switch on the bottom to 'X' while it was plugged in and Windows instantly installed the 'X-Box drivers' for the device. RC Editor still crashed. As he stated, it crashes with no joystick plugged in too. From my experience, on some of our installations, I have had to go out to device manager and remove all 'Human Interface Devices' to make room on the 'RC Editor' device list when I 'refresh'. Would removing all those HID's perhaps give the 'RC Editor' a clean slate to work with regarding devices, and help to determine if the issue is actually an existing 'device driver' incompatability?
Ethan, thank you for the post regarding how to see the 'Input Device Control'. I look forward to exploring that.