Introducing the Minblocks
A lot of folks have commented 
(to put it nicely) on the size of NXT-G programs relative to the memory on the NXT. Well, LEGO and NI it seems were listening. The new patch allows the user to add more blocks to the NXT-G pallets, including soon to be released blocks for 3rd party sensors, custom blocks individuals create with the LabVIEW Toolkit, and a selection of blocks straight from National Instruments called "miniblocks". The miniblocks are stripped down versions of some of the larger "stock" blocks, like the Display or Motor blocks. By going over those blocks with a fine-toothed comb, a (very!) hardworking team at NI has created specialized, targeted versions that upon being compiled only generate the needed bytecodes.
To put that another way, the miniblocks result in smaller programs on the NXT, as well as in some cases faster execution. For instance, 16 consecutive Display blocks generates a program on the NXT that is about 4k in size; but making the same program using 16 of the new miniDisplay blocks results in a program just 2.2 to 2.5 k in size, close to a 40% savings in memory. The miniMotor blocks are even more impressive, resulting in a savings of almost 70% over the "stock" Motor blocks! The miniblocks are also slightly faster in execution: Display a point, for instance, is about 30% faster than with the original Display block, as well as being smaller.
This doesn't answer all the issues folks have brought up with NXT-G and the memory on the NXT brick, but it shows two important things to me: first, LEGO & NI have been listening, and responding to things filtering out of the community (I strongly doubt this is the last time that occurs). Second, there are multiple solutions to any problem. Nope, they haven't added more memory to the NXT, they just reduced the amount of memory that programs need to run in... and done it less than a year after the product release. Well done!
For those who like numbers, here's the figures I got:
16 Move blocks: 11.8 kb
16 miniMove blocks: 7.7 kb
16 Motor blocks: 12.5 kb
16 miniMotor blocks: 3.9 k (!!)
16 Display blocks: 4 kb (with one Display block of a point taking 1.3 ms)
16 miniDisplay a RIC: 2.5 kb
16 miniDisplay a string: 2.4 kb
16 miniDisplay a point: 2.2 kb (with this miniDisplay block taking 0.93 ms)
Footnote: quite apart from these savings, I've also noticed that some FLL teams have gotten around any memory problems by using MyBlocks to save lots of memory, and even condensing down everything to one program where the kids select which mission to run on-screen (that way, any MyBlock used gets stored just once, instead of once per mission). Kudos to a number of FLL teams for working within the limits, and learning (& teaching!) something new.
The patch to NXT-G itself is rather nice: it adds another option under the "tools" menu, allowing you to import and export custom blocks into any of the subpallets within the Common pallets. I put the miniMove block in the subpallet with its big brother, and the miniDisplay blocks in with the original Display block... but you could put them anywhere you like. Keeping the the import tool in the menu keeps the interface from becoming cluttered as well, and it's fairly easy to use.
--
Brian Davis
(to put it nicely) on the size of NXT-G programs relative to the memory on the NXT. Well, LEGO and NI it seems were listening. The new patch allows the user to add more blocks to the NXT-G pallets, including soon to be released blocks for 3rd party sensors, custom blocks individuals create with the LabVIEW Toolkit, and a selection of blocks straight from National Instruments called "miniblocks". The miniblocks are stripped down versions of some of the larger "stock" blocks, like the Display or Motor blocks. By going over those blocks with a fine-toothed comb, a (very!) hardworking team at NI has created specialized, targeted versions that upon being compiled only generate the needed bytecodes.To put that another way, the miniblocks result in smaller programs on the NXT, as well as in some cases faster execution. For instance, 16 consecutive Display blocks generates a program on the NXT that is about 4k in size; but making the same program using 16 of the new miniDisplay blocks results in a program just 2.2 to 2.5 k in size, close to a 40% savings in memory. The miniMotor blocks are even more impressive, resulting in a savings of almost 70% over the "stock" Motor blocks! The miniblocks are also slightly faster in execution: Display a point, for instance, is about 30% faster than with the original Display block, as well as being smaller.
This doesn't answer all the issues folks have brought up with NXT-G and the memory on the NXT brick, but it shows two important things to me: first, LEGO & NI have been listening, and responding to things filtering out of the community (I strongly doubt this is the last time that occurs). Second, there are multiple solutions to any problem. Nope, they haven't added more memory to the NXT, they just reduced the amount of memory that programs need to run in... and done it less than a year after the product release. Well done!
For those who like numbers, here's the figures I got:
16 Move blocks: 11.8 kb
16 miniMove blocks: 7.7 kb
16 Motor blocks: 12.5 kb
16 miniMotor blocks: 3.9 k (!!)
16 Display blocks: 4 kb (with one Display block of a point taking 1.3 ms)
16 miniDisplay a RIC: 2.5 kb
16 miniDisplay a string: 2.4 kb
16 miniDisplay a point: 2.2 kb (with this miniDisplay block taking 0.93 ms)
Footnote: quite apart from these savings, I've also noticed that some FLL teams have gotten around any memory problems by using MyBlocks to save lots of memory, and even condensing down everything to one program where the kids select which mission to run on-screen (that way, any MyBlock used gets stored just once, instead of once per mission). Kudos to a number of FLL teams for working within the limits, and learning (& teaching!) something new.
The patch to NXT-G itself is rather nice: it adds another option under the "tools" menu, allowing you to import and export custom blocks into any of the subpallets within the Common pallets. I put the miniMove block in the subpallet with its big brother, and the miniDisplay blocks in with the original Display block... but you could put them anywhere you like. Keeping the the import tool in the menu keeps the interface from becoming cluttered as well, and it's fairly easy to use.
--
Brian Davis
Comments
I'm supposed to be a NXT expert and had been waiting and waiting for these Mini Blocks. Our state starts the FLL competitions tomorrow. Too late for those teams, but the events after Thanksgiving will give teams the time they need.
Here are the details of the install and a bit of commentary.
Thanks again for a great site.
One big thing that appears to be missing from the mini Move block is the ability to control only one motor. So lets say you have a typical FLL robot with two motors controlling wheels and one motor controlling an arm. You can control the wheels with a mini Move block, but you need either a mini Motor block or a "big" Move block to control the arm.
As I understand it, every time you add a new type of block, it eats up a lot of memory compared to reusing an existing type of block. Therefore, while the mini blocks may be smaller, if you use the mini blocks, you now need two types of blocks instead of one.
I think people need to do some testing to make sure this is not going to end up using MORE memory than the "big" blocks.
> ability to control only one motor.
True; in fat, simplifications like that are some of the main resonse the miniBlocks are more streamlined. That ability is uncovered, however, in the miniMotor block. So to move the two wheels synchronized, and a third motor moving an arm, you would need either at least two cases of the full Move block, or one miniMove and one miniMotor. Testing...
Move BC + Motor A --> 8.0 kb
Move BC + Move A --> 5.7 kb
miniMove + miniMotor --> 4.5 kb
So it would appear even here, the miniblocks offer a smaller solution, memory-wise (although your point about using a minimum number of different types of blocks as also good, as is shown by the first example in theat list of three).
Your point about "more testing" is a good one (my "testing", above, took about 10 minutes), but it's going to depend on the individual program - in other words, it's *always* something to keep in mind, but rules of thumb (like "miniblocks save memory") can be very useful as well. Conservative, tight coding under NXT-G is something we're all still learning... but I'm really glad there are more options now availible.