Page 2 of 2

Re: NXT-G GUI behaving weird as code gets longer

Posted: 06 Feb 2012, 12:39
by mightor
Well, NXC and ROBOTC are both C-like, so there are some common elements in that respect. ROBOTC is aimed much more at the educational market, which is also reflected in its price.
As for switching, I use both NXC and ROBOTC, but mostly ROBOTC. It's just a personal preference and also due to the fact that I maintain a suite of drivers for ROBOTC for almost every NXT sensor on the market. NXC is much more popular among the hobbyists than ROBOTC is. ROBOTC is great for educational institutions because Robomatter/Robotics Academy offer courses for teachers and material for learning. ROBOTC is also used for the FTC.
In any case, try them both. You can try ROBOTC for 30 days without the need to actually buy a license.

Your programming environment should be a good fit, like a shoe. Nobody can tell you one is better for you, you'll have to decide yourself :)

- Xander

Re: NXT-G GUI behaving weird as code gets longer

Posted: 06 Feb 2012, 14:24
by HaWe
I can confirm that both RobotC and NXC are quite similar in API and syntax, but RobotC costs money and NXC doesn't.
With RobotC you can connect only 2 bricks by Bluetooth, with NXC 4.
RobotC has only up to ten tasks or so, in NXC usually more than 30.
RobotC has up to 20kByte for variables (IIRC), NXC more than 32.
RobotC is a bit faster.

Re: NXT-G GUI behaving weird as code gets longer

Posted: 06 Feb 2012, 19:54
by mattallen37
cfp999 wrote:In the meantime, I would love to check out some of the text-based languages. From searching the net I get the feeling that NXC is very popular. RobotC on the other hand comes with a simulator. Are the two very similar in terms of syntax? Will I be able to switch between them, once I start to get the hang of one of them?
NXC and ROBOTC are both very popular C/C++ based NXT programming languages.

NXC and the BricxCC IDE are open source, developed by the community (currently mostly developed and maintained by John Hansen, a very active member of these forums). Most of the more advanced members here use and discuss NXC as a basis for questions and discussion. These forums are not specifically for NXC by any means, but there is a lot of support for it here.

ROBOTC seems to be geared more towards education. It's an ever developing closed source software with a licensing fee. Although rarely talked about in detail on these forums, many people here are able to provide support, and there are forums on the ROBOTC website specifically for it. The virtual world you speak of is an optional addition to the software, and is not included with the Mindstorms NXT SW license.

Because both programming languages are based on C/C++, the syntax with be similar, but specifics will be quite different. From the basic user's perspective, the biggest difference is probably the API function names. There are tremendous advantages to both languages.

I would say you could switch, but you probably won't want to. I personally use both of them, but I have been using NXC for a lot longer, and understand it far better. When I use ROBOTC, I feel like I think in NXC, and then program the equivalent in ROBOTC.

Because you are just starting with text-based programming languages for the NXT, I suggest you try NXC to begin with, but you can also try ROBOTC for free for 30 days.

Edit: :oops: didn't realize there was a page 2 with a couple replies, so most of this probably sounds redundant.

Re: NXT-G GUI behaving weird as code gets longer

Posted: 06 Feb 2012, 21:02
by pepijndevos
Yea, I would. IMO, Lua is a very easy language. Due to the REPL, it's also very easy to experiment.

Re: NXT-G GUI behaving weird as code gets longer

Posted: 06 Feb 2012, 21:31
by HaWe
we had some pblua users in our German forum who had even good contacts to Ralph Hempel (also formerly developer of pbForth). But because of several reasons (console/terminal-based interpreter ?) pbLua is meanwhile quite extinct and only very few people use it any longer. Only 400 posts of nearly over all 40,000 posts were about pblua.

I would suggest any newbie to use a common, widely used language.

Re: NXT-G GUI behaving weird as code gets longer

Posted: 07 Feb 2012, 16:34
by mightor
It's been a while since you last used ROBOTC, doc.
doc-helmut wrote:RobotC has only up to ten tasks or so, in NXC usually more than 30.
RobotC has up to 20kByte for variables (IIRC), NXC more than 32.

Code: Select all

#define	kNumbOfTasks						(20)														// NXT
#define	kNumbOfGlobalVariables			(7500)													// NXT
So 20 tasks and 7500 variables at max 4 bytes each, equals 30K (roughly). This ROBOTC bashing is so lame.

- Xander

Re: NXT-G GUI behaving weird as code gets longer

Posted: 07 Feb 2012, 16:40
by HaWe
I stand corrected, when I once was using it, it was 10 tasks and 20k variable mem.
Is the 2-BT-Bricks-issue still valid?

Re: NXT-G GUI behaving weird as code gets longer

Posted: 07 Feb 2012, 16:50
by mightor
Yeah, BT is still 1:1. I doubt it will change, they're implementing ZigBee support, which is pretty much N:N and uses the RS485 port together with the NXTBee from Dexter Industries. It will also work with their Arduino port of ROBOTC which is still under development. It'll be nice for doing swarm stuff, but I doubt it will be of much use to non-educational people.

- Xander

Re: NXT-G GUI behaving weird as code gets longer

Posted: 16 Feb 2012, 19:03
by peter-cocteau
On my side I use NXT-G and I'm very happy with it, in fact I don't like to write code and don't understand much to syntax.
As it was already said,if you follow these rules you should not have much problem:
http://www.teamhassenplug.org/NXT/

You use all NXT memory by using NXT-G? without using your own "myblock"? I'm very curious about this point cause your program must be very, very, very long. I work on big programs with NXT-G and never reach NXT memory limit.

Peter.

Re: NXT-G GUI behaving weird as code gets longer

Posted: 16 Feb 2012, 21:19
by HaWe
the demand of much memory is not only caused by the length of a program but also by lots of variables, especially arrays.
When I get to the memory limit it's always caused by the variable memory.