LabVIEW for LEGO MINDSTORMS and LabVIEW for Education

cancel
Showing results for 
Search instead for 
Did you mean: 

Flatten and flatten from string creates errors

I am trying to store U8's and SGL's in strings.  Then, I want to store those strings in arrays.  Yes, this makes for a 2D array.

However, I keep getting, "File Error!" on my NXT brick.

 

I've tried to set the size of the "type in" array to the same size as the string, but to no avail.

Attached you should be able to find my last attempt to use flattening...I'm going to try something else unless anyone here can help.

Download All
0 Kudos
Message 1 of 12
(6,455 Views)

You zipped up deep folder hierarchies without even telling us what the name of the toplevel VI is. You are also not telling us where the ""unflatten" occurs and what the error is. Please be more spefic. We don't what to dig through deep VI hierachies of a project we don't know.

 

We are much more likely to help if you would reduce the problem to a single small VI containing a 2D array of typical default data, the flatten operation you use, the unflatten operation you use, and the desired output you want. Shouldn't take more than a minute to create. 😄

 

The "type" does not contain size information. Easiest would be to set "prepend size" to true when flattening and unflattening. Else you would need to stick with 1D arrays and reshape to the (independently) known 2D dimensions later.

0 Kudos
Message 2 of 12
(6,441 Views)

Oh crud, my apologies! It's in the scrap/ subfolder, called "FGV_map_Test.vi."

That VI is the top-level, and I hope you can dig into the VIs from there.

Both zip's should have the same VI in the same folders.

 

And the flatten to string, and unflatten from string, seemed to crash an NI engineer's NXT program.

The guide I found claims that these two functions will work within the NXT:

ftp://ftp.ni.com/evaluation/mindstorms/LabVIEW_for_NXT_Advanced_Programming_Guide.pdf

 

And includes the following note:

Unflatten from String
You must write a fully constructed template for value into the type input. The size of data in type input must match the flattened data in binary string exactly, including array sizes.

 

True, or False, as an input to "prepend array size," does not change the behavior.

The NI engineer and I believe that the documentation is wrong, as this line about Flatten makes no sense:

Flatten to String
The toolkit does not support the output type string value.

 

But still, I wondered if someone out there had some experience making the flatten/unflatten work within the Lego NXT.

0 Kudos
Message 3 of 12
(6,433 Views)

Running your FGV_map_Test2 VI from the mapTest2 folder works for me and displays "Good Length" on the NXT. Is this the VI that is giving you an error?

 

Edit: Ok, it only throws an error when deployed. I see it now. For an immediate solution, you might want to use something other than Flatten functions for organizing your data. If you'd like to narrow down the issue with Flattening, it would be a good idea to isolate the error to the smallest set of code possible.

Zach P.

Staff Software Engineer | LabVIEW R&D | National Instruments
0 Kudos
Message 4 of 12
(6,400 Views)

Seriously, what are you running?

 

I have LabVIEW 2012, Firmware 1.31.

 

And it appears to run for a few seconds, but reports "File Error!" before anything prints out.

 

-Mike

0 Kudos
Message 5 of 12
(6,396 Views)

I see the same error when deploying, even with matching array sizes for the Type input of the Unflatten from String function.

 

Since you are using a small array of U8s, can you substitute a cluster for each of your inner array elements? That should make the bundling/unbundling process easier.

Zach P.

Staff Software Engineer | LabVIEW R&D | National Instruments
0 Kudos
Message 6 of 12
(6,384 Views)

Zach,

 

While disappointed that it doesn't actually work, I'm glad we've got consistency.

🙂

 

Unfortunately, I'm pulling the same stunt with single floating point values as well.  See, I'm programming a robot to wander a maze, and I use the u8 map for tracking and the singles for sensor data.  Given that the full program blows up at new places on almost every run, I think I'm fighting with a RAM limitation.

 

I have tried:

  • 2D arrays (not compileable)
  • Clusters of Arrays (too complex - but maybe only for singles)
    • From the advanced programming guide, data types supported are:
      • Clusters containing integers, Booleans, strings, 1D arrays, or
        other clusters
      • Single-precision floating point numbers
  • 1D arrays of U8s
    • I use the inputs row and column to step along in the 1D array.
      • My full program now steps further through the algorithm, but still dies unexpectedly.

At this point, I'm working to improve my 1D array usage by limiting the number of calls I make, and possibly by only preallocating a smaller part of the map.

0 Kudos
Message 7 of 12
(6,376 Views)

Hi reydelsol,

 

First of all, true that the prepend array size and also byte ordering inputs have no effect on the NXT implementation of flatten to string. Also true that you must wire the correctly sized data into the Type terminal of Unflatten from String on NXT (but not on EV3, we fixed that).

 

I'm not sure why you're getting a file error. That can mean a lot of things, and I'll keep trying to figure out what's happening. I ran your program on an EV3, and all went swimmingly, so you might try that if you have access to an EV3. Otherwise, I might contribute that the error might not have anything to do with flatten to string. 

0 Kudos
Message 8 of 12
(6,362 Views)

I do not have an EV3, must be an NXT.

And I'm curious why this doesn't work.

 

The test program, FGV_map_Test2, should blow up on an NXT.

Flatten and unflatten would be a powerful command for my programs if I could use it.

0 Kudos
Message 9 of 12
(6,356 Views)

Alright, so...I've gone with the 1D array replacement option.

After much tinkering with the main program, I've got it so that my state machine will run all the way through.

Once the program could go through the state machine, I figured that it would have finally allocated all possible memory - and perform continuously.

 

Unfortunately, it seems that my state machine loop will only run about 4 times, and then I get the file error again.

You should find my source code attached.

The robot has:

Motor A - Left motor, Motor B - Right motor

Port 1 - Ultrasonic pointing off to the left, Port 2 - Ultrasonic point off to the right, Port 3 - light sensor in front.

 

There is reflective tape on the course at the start and at the finish line.

The robot is to navigate a field of obstacles, and end at the finish line.

You should be able to see my state machine in source5/main/NavigationStateMachine.vi

That is the main VI.

 

I coach USFIRST teams all the time, and they don't have memory problems like this.

I've eliminated the program's need for a SGL array - all those values are converted to I32s and immediately processed.

That sensor data is then processed to determine where an obstacle exists on the field.

So the internal map is updated with my 2D array function (replace array subset) for every obstacle registered.

 

The internal map is stored in a functional global variable, _fgv_map.vi.

 

The robot should follow the states:  scan environment, plan path, go, and then jump to "End" when it finds the finish line.

There is an optional "hazard avoidance" subVI running in a constant loop outside the state machine (you can see it in a diagram disable structure).

I was afraid that little loop was running without any delay, and tripping up the "file error!" problem.

Sadly, the problem is still present.

 

I've been trying to meet a deadline for this little project, and my last extension is Thursday afternoon.

If anyone can see what is causing this thing to blow up, let me know.

Right now...I think I have to unpack the state machine and let it all run in a line.

But I'd hate to undo all that design if I don't have to.

 

Any ideas?

0 Kudos
Message 10 of 12
(6,320 Views)