Bugfixing a frozen EV3Lab .ev3 file

Recently a case of freezing / hanging LEGO Mindstorms (EV3Lab) file was shown to me by a coach heading to a competition with her kids the very next day.

The problem

The file would not open and the EV3Lab app on the Windows laptop was just loading-loading-loading without ever opening the project.

What could have happened? How to fix this ugly problem that is endangering kids success?

To dig deeper we must understand that the EV3Lab is built upon the LabView application by National Instruments around / before 2014.
Therefore the application must be a 32 bit app and therefore has a maximum memory allocated by any app of 2GB.

Root cause

Digging deeper into the underlying struture one can find that the .ev3 file is a zip-compressed version of many mainly xml files that are known to typically be quite memory inefficient.

We are not talking about large chunks of memory, as the competition.ev3 file size seems to be 211kB only. However there is one catch. The EV3Lab app runs on SilverLight platform, that was originally invented by Microsoft to replace Java and sandbox the application over the web.

Opening a file in Silverlight, packaged within a windows exe, emulating an interpreted intermediate LabView (vix files) can get quite memory hungry.
Such a program eats up enormous amount of memory.

The solution

Ultimately our problem roots in an out-of-memory situation, that is caused by opening several files at once. Namely 2 programs and 37 myblocks.

Our solution will be to disable the auto-opening of programs.

Within the structure you’d love to look for a Project.lvprojx file.

Within the project file we are looking for blocks of <SourceFileReference/> of .ev3p files. As a next step we are adding a line of instruction to disable auto opening.
I suggest to use a proper xml enabled code editor such as Visual Studio Code.

Original code snippet

<SourceFileReference StoragePath="Program1.ev3p" RelativeStoragePath="Program1.ev3p" OverridingDocumentTypeIdentifier="X3VIDocument" DocumentTypeIdentifier="NationalInstruments.LabVIEW.VI.Modeling.VirtualInstrument" Name="Program1\.ev3p" Bindings="Envoy,DefinitionReference,SourceFileReference,X3VIDocument" />

Modified code snippet

<SourceFileReference StoragePath="Program1.ev3p" RelativeStoragePath="Program1.ev3p" OverridingDocumentTypeIdentifier="X3VIDocument" DocumentTypeIdentifier="NationalInstruments.LabVIEW.VI.Modeling.VirtualInstrument" Name="Program1\.ev3p" Bindings="Envoy,DefinitionReference,SourceFileReference,X3VIDocument">

<X3DocumentSettings ShowFileOnStartup="False" IsTeacherOnlyFile="False" IsHiddenDependency="False" xmlns="http://www.ni.com/X3DocumentSettings.xsd" />

</SourceFileReference>

Closing and re-packing the file into the .ev3 zip structure will do the trick and out file will open in two seconds.

Why are there so many blocks?

Normally kids (longest footnote you can imagine goes here) do not create 30-40-50 programs/myblocks for a competition. It is simply inefficient. They typically copy paste, leave some dead code around.

If we look close enough on the program structure with the help of EV3TreeVisualizier we find that many blocks are duplicated. A key control block is duplicated five times!

Visual diagram of the app using EV3TreeVisualizer
block names are hidden to keep intellectual property of the team

These MyBlock copies are created when kids backup their program by using the builting “Copy-Paste” on any program block that contains myblocks. Automatically the myblock is duplicated and “Program 2” will reference “MyBlock 2” instead of the original “MyBlock1”.

It is very hard to resolve afterwards – either edit the xml file (doing many original backups) or change one-by-one the references in the app.

Avoid the program copy-paste at all costs. Use this method instead.

  1. Select all blocks in the program (Control-A) to copy
  2. Create a new program (Control-N)
  3. Delete the lonely start block
  4. Paste everything (Control-V)

Leave a comment

Design a site like this with WordPress.com
Get started