LV4E LEGO 2014 repeatedly loads Brickreference.lvclass

[JLEGOL]

We just upgraded to the 2014 version of the software so we could use our EV3s. Whenever we choose something from the pallet that is lego specific (such as a motor block) to the block diagram, a dialog comes up showing the loading of BrickReferecne.lvclass. This takes under a minute. When I click "add constant", again the dialog appears and loads these ctl files, but it takes about 5 to 10 minutes. If I pick the drop-down to select a motor port, again the dialog loads and another 10 minutes. This doesn't just happen the first tiime, but every time an ojbect is added or constant created, even if a similar object (i.e. another motor block) was just added.

Anyway to have it just load these once?

[JLEGOL]

I notice that when I turn off wireless, the problem goes away. Is there something that NI does over wireless everytime one changes the block diagram? Is there a service I can turn off?

[garrett8357]

Hi,

I'm sorry you are seeing long delays between operations. Are you using a Mac or Windows machine? When you say turn off wireless do you mean turning Bluetooth off on your laptop/PC?

[JLEGOL]

Thank you for your attention to this.

I am sorry to not have provided this information:

I have a site license for my high school class and it happens on Windows 7, 8.1, and 10 machines (all the windows machines in the class, which are laptops owned by the students, so a variety of machines with their personal software on it.) It does not happen on the macs, of which there are a handful in the class.

If I go to my tray (lower right of the screen) and turn of the wireless network connection (so I am no longer communicating with the the internet or school network), the problem is attenuated. The class library still loads, but it loads much faster, taking maybe 20 or 30 seconds instead of several minutes.

I tried to upload some images of the dialog box but it doesn't seem to work. The title has the NI loge follow by BrickREference.lvclass. In the dialog box it says: Loading:, then on the next line <vilib.:\NXT\LegoClasses\MINDSTORMS\some other path info that changes. Several hundred of these get loaded, about one a second with my wireless on, all in about 20 seconds with my wireless off.

The status of my bluetooth doesn't seem to matter.

[garrett8357]

So if you drop a Move Motors VI, BrickReference.lvclass loads, and if you drop a second Move Motors VI on the same diagram, it loads again?

Are you working inside of a robot project?

[JLEGOL]

I am in a robot project working with a EV3/NXT Target. Perhaps the best way to show whats going on is to show you. This should take you to a video demonstrating the issue.

https://drive.google.com/file/d/0BzCks-xycNL5eWJWM21ZRVdJX2M/view?usp=sharing

Thanks again,

[menay]

Hey JLEGOL,

It seems like there is some sort of software corruption causing this behavior. Have you tried uninstalling and reinstalling the software? 

[garrett8357]

Thanks for providing the video, that is very helpful to me. I have been trying a few things, but unfortunately, I have so far been unable to reproduce the issue. For the operations you're performing, I'm seeing about a half of a second delay on the virtual machine and do not see that BrickReference.lvclass is being loaded and unloaded repeatedly.

Sorry, but here are a few more questions: Is LabVIEW installed in Program Files? This is the behavior for all Windows machines in your classroom? Was LV4E installed using physical media or an online installer?

[JLEGOL]

Thanks for your attention to this:

1. Installation was from physical media. Selecting setup.exe and saying yes to everything.

2. LabView.exe was installed in C:\Program Files (x86)\National Instruments\LabVIEW 2014 (copied from file explorer)

3. I provided mis-information intially - the problem is not on all the classroom computers. I initially asked a few students to try it and saw the problem, but it is just on mine and one other computer, both Windows 10. This makes it much less urgent as I've just move the student to a classroom machine (that also works fine.) So it is likely more specfic to a few computers and not a LabView thing.

I tried untistalling, running ccleaner to clean out the registry, and reinstalling, but the problem persists.

Given it is better with the wirless off, I am suspecting it is something related to my syncing my documents folder with Google Drive. Although terminating the Google sync process alone does nothing to improve the situation it is the only non-standard process occuring. Since my projects are in my user folder which is synced, maybe that is the cause? To test this I will move my folder back to their default location, which isn't something I can do imediately.

I thank you both for your attention to this. Unless there is something obvious, the next thing for me to try will be to test the folders. I'll update this thread when I am able to do that. If that doesn't work I'll try a bare metal (can you still say that with an SSD?)  reinstall of Windows 10 and see what happens.

Thanks again.

[JLEGOL]

I did a clean install of Windows 10. Created a USB drive from MS site, deleted all disk partitions, and ran install program.

LabView worked well right after that install, but no longer does. The same problem persists.

I never installed Google Desktop sync, which was my main suspect, so I am removing that as the cause. I had installed Google App Sync (so my school-issued Gmail will sync with Outlook) and LabView worked fine after that. Same with Office 365.

It might be related to OneDrive. A OneDrive sync was the last thing I remember doing before LabView once again became unusable. However I unlinked my account, disabled the oneDrive service in the task manager, used the group policy to forbit oneDrive syncing and LabView is still misbehaving.

I've uninstalled Google App synce. As far as I know nothing on my computer is syncing with anything else. As in the video, with wireless on things take minutes per step (create constant, specify moter, add another motor) , seconds with wireless off. With wireless off it still isn't snappy, but workable. I can't think of anything that is related to wireless that is causing this. I've disabled every startup process except the touchpad.

Is NI doing anything to check licenses or updates that takes time? Anything it wouldn't be doing if wireless if unavialble?

Using Task Manager I see the following (too many IMHO) NI routines runing.

In startup we have:

NI Registration Wizard, NI Error Reporting Server

In Services I have:

Application Web Server, Application Web Server (64-bit), Authentication Service, Domain Service, Licesnse Server, mDNS Responder Service, Network Discovery, Service Locator, System WEb Server, and Variable Engine.

In Processes I have:

National Instruments Network Discovery Service (32-bit), National Instruments Zeroconf Service (32-bit), NI Auth Daemon, NI Service Locator, NI Variable Engine, NI Web Service Container (6 instances of this), nidmsrv, ni Citadel 4 service.

I think I'm at the end of what I can do, but if anyone has any suggestions, I'll be happy to try.

I'm going to put back all the things I uninstalled because they are needed for efficient work flow. No other programs seem to be affected. (Virus scan did not show up anything either.) The HP laptop is running an i5-3317U processor at 1.70 GHz, 4.0 GB RAM, and has 56 GB free on its 128 GB SSD.

Unfortunately it may be time to say goodbye to LabView as a classroom solution as we are having far too many problems.

1. Bricks are working fine, but then report firmware mismatch between laptops and EV3 bricks requiring firmware updates.

2. Files become broken (can't download, broken arrow) for reasons we can't find, only to be OK when we close and restart LabView.

3. Macs all generate an error (likely related to the file path) that has to be closed every time they communicate with the brick. Things work, just an error to close every ttime.

4. The software doesn't work at all on some Macs, so kids are limited to the few hours the computer lab is open. I think it is because the file path of the install is different than the file path it thinks it installed to and the path has a strange name that include something like "(64-bit)" in it.

5. General confusion with things like the schematic editor not forwarding port information to programs (so have to specify ports anyway), too many ways to pick the wrong sensor (NXT vs EV3 ultrasonic, for example), and inconsistent implementation (e.g. rotation sensor reset is its own "sensor" setting, while resetting the gyro is one option of the gyro sensor.)

6. Still can't figure out how to transfer files without breaking links.

I'll look into the native EV3 software. It's a shame because LabView makes it more "High School" than middle school.