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 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