A recent comment asked what I thought the limits were on complex programs in the NXT-G language. The short answer is "I don't know (yet)", since I've not had the time to push it to the maximum in this way. Additionally it's hard to judge what's ment by "complex" here as well: How big? How much decision-making ability? How many things going on at once? It seems clear to me that NXT-G allows significantly more complex programs than the old RIS code. Not just in the choice of "blocks" availible, but in the ways these blocks can interact. With parallel tasks, wiring of values between blocks, and flexible loops and switch structures, the complexity can get much higher. So perhaps a better way to phrase the question is "what limits does a NXT-G program bump up against?" Keep in mind, I may be completely wrong on these issues - it's going to take a bunch of new Mindstorms users to really test these limits. That said...
Speed of the editor is a factor: as a program gets larger, the editor slows down, especially with deeply nested control structures like loops & switches. This has generally limited me to nesting only 4-5 levels deep, although I've gone as deep as 12. Note you can bypass the speed issue somewhat by using MyBlocks, so with proper structuring, this might not be the limiting factor.
Program size can be much larger than I'd like at times: the largest program I've written has 39 blocks, 6 loops, & 1 switch (named "Nesting7.rbt", this is the program that gives JennToo her territorial behavior): this is 2 Mb (!) on my hard drive, but compiles down to 23.5 kb in the NXT. Based on having about 106 kb free memory on the NXT, it would seem you could hold a program of about 200 blocks, loops, and switches. But, I'm sure some blocks are "bigger" than others, and probably getting that big a chunk of contiguous memory is tough, so... I suspect I practical upper limit is around 150 blocks, if there's little else on the NXT itself.
Procedural & representational complexity is pretty good: NXT-G allows three types of variables (integer, logical, and string), a file access system, and "advanced" (over RIS) blocks like compare a value to a range (does the value fall inside or outside a range), or switch on a string value. The lack of arrays is a real problem... but one that can be gotten around in a couple of ways. It lacks string operators (parsing of strings). I've not yet bumped into limits on the number of parallel sequences (tasks) or variables. The fact that you can define your own MyBlocks actually helps a lot here as well: for instance, NXT-G does not contain a Modulo block, so I wrote one, and it was easy and transparent to use (good for kids or adults, but perhaps especially for adults teaching kids). I've done this for negation, trig functions, arrays, etc.
Talking completely off-the-cuff here, I'd say NXT-G is comparable to Robolab, and I've seen some amazing things done in Robolab under what I'd say are tougher constraints. Personally, I suspect the program size may ultimately be the limiting factor: compiled NXT-G programs just seem really large given what I think might be possible at the firmware level. For FLL, I don't think this will be a problem at all (especially as downloading new programs can be done easily and wirelessly, without worrying about IR interferance).
For adults pushing the limits, size may be the factor. Taking a Tic-Tac-Toe playing RCX-based robot and duplicating it on the NXT-G system is going to be very difficult, I think (I've built RCX-based ones, but even there I used NQC; at least on the NXT, I don't have the variable limits thankfully).
Final footnote: this may not be the end state for NXT-G (LEGO released upgrades for the RIS firmware and software over time; hopefully they will do the same here), and there are already third-party offerings (NBC by John Hansen, ROBOT-C by Carnegie Mellon, a Java-based environment from others, etc.) that appear to unlock much more of the power in the platform. Already NBC has clearly shown that NBC NXT programs can be much smaller than their NXT-G counterparts, and John has already been developing for both the PC and Mac communities (thank you!). I've got no worries about having powerful options, only how long I will stay with the "official" NXT-G language. For the RCX, I used Robolab for about 2-3 months before I moved on to NQC... for the NXT, I've not yet begun to tap the potentials of NXT after at least that long. And that's good news.
--
Brian Davis
Speed of the editor is a factor: as a program gets larger, the editor slows down, especially with deeply nested control structures like loops & switches. This has generally limited me to nesting only 4-5 levels deep, although I've gone as deep as 12. Note you can bypass the speed issue somewhat by using MyBlocks, so with proper structuring, this might not be the limiting factor.
Program size can be much larger than I'd like at times: the largest program I've written has 39 blocks, 6 loops, & 1 switch (named "Nesting7.rbt", this is the program that gives JennToo her territorial behavior): this is 2 Mb (!) on my hard drive, but compiles down to 23.5 kb in the NXT. Based on having about 106 kb free memory on the NXT, it would seem you could hold a program of about 200 blocks, loops, and switches. But, I'm sure some blocks are "bigger" than others, and probably getting that big a chunk of contiguous memory is tough, so... I suspect I practical upper limit is around 150 blocks, if there's little else on the NXT itself.
Procedural & representational complexity is pretty good: NXT-G allows three types of variables (integer, logical, and string), a file access system, and "advanced" (over RIS) blocks like compare a value to a range (does the value fall inside or outside a range), or switch on a string value. The lack of arrays is a real problem... but one that can be gotten around in a couple of ways. It lacks string operators (parsing of strings). I've not yet bumped into limits on the number of parallel sequences (tasks) or variables. The fact that you can define your own MyBlocks actually helps a lot here as well: for instance, NXT-G does not contain a Modulo block, so I wrote one, and it was easy and transparent to use (good for kids or adults, but perhaps especially for adults teaching kids). I've done this for negation, trig functions, arrays, etc.
Talking completely off-the-cuff here, I'd say NXT-G is comparable to Robolab, and I've seen some amazing things done in Robolab under what I'd say are tougher constraints. Personally, I suspect the program size may ultimately be the limiting factor: compiled NXT-G programs just seem really large given what I think might be possible at the firmware level. For FLL, I don't think this will be a problem at all (especially as downloading new programs can be done easily and wirelessly, without worrying about IR interferance).
For adults pushing the limits, size may be the factor. Taking a Tic-Tac-Toe playing RCX-based robot and duplicating it on the NXT-G system is going to be very difficult, I think (I've built RCX-based ones, but even there I used NQC; at least on the NXT, I don't have the variable limits thankfully).
Final footnote: this may not be the end state for NXT-G (LEGO released upgrades for the RIS firmware and software over time; hopefully they will do the same here), and there are already third-party offerings (NBC by John Hansen, ROBOT-C by Carnegie Mellon, a Java-based environment from others, etc.) that appear to unlock much more of the power in the platform. Already NBC has clearly shown that NBC NXT programs can be much smaller than their NXT-G counterparts, and John has already been developing for both the PC and Mac communities (thank you!). I've got no worries about having powerful options, only how long I will stay with the "official" NXT-G language. For the RCX, I used Robolab for about 2-3 months before I moved on to NQC... for the NXT, I've not yet begun to tap the potentials of NXT after at least that long. And that's good news.
--
Brian Davis