LabVIEW Toolkit for LEGO MINDSTORMS NXT bugs

[John Field]

When you find bugs in the toolkit, post them to this message thread.

This board will be regularly monitored by both NI Application Engineers and members of the development team.

Thanks for helping us create a better toolkit going forward.

John Field
MINDSTORMS Software Group Manager
LabVIEW R&D

[Ale914]

First of all thanks NI for this toolkit!

I made some preliminar test yesterday and i have some strange issue to report
when i try to run a VI on next during the compile time i have the CPU at 100% and the RAM grow very fast (100MB in only few minutes 5-6) i wait for minutes without result so i abort the compile process , after this my RAM decrease a little bit but CPU start to oscillate form 0 to 70% doing nothing (apparently) when i exit from labview all return done.
The test VI was very simple, on fwd motor A for 360 degrees.
I make this test on centrino signle core 2 Ghz 1000MB Ram using labview 8.2 and 7.1

Ciao,
Alessandro.

[Joel_Dixon]

The first question to ask is did you mass compile after you installed the toolkit? If not, the compile can, indeed be VERY long. I believe this is specified in the ReadMe or getting started document and you should mass compile 'vi.lib\addons\NXTToolkit'.

Joel

[Ale914]

Hi Joel,
yes i have mass compile for both LV8.2 and LV7.1
consider that with another VI the compile time is very low, this second test is a scrolling hello world on NXT display, make sense for you?

Ciao

[UlfM]

Hi, all!

A short note: In "Keep alive" (DirectCommands\NXTToolkit.DC.KeepAlive.vi) the output "NXTObject dup" isn't connected to anything in the block diagram. If you include this VI in a command chain passing the NXTObject cluster, the chain gets broken by this VI.

Cure is trivial: Move "NXTObject dup" outside the case structure and wire it directly to "NXTObject",  the corresponding input.

Regards

Ulf

[Joel_Dixon]

Alessandro,

If I understand you right, there is one particular program that takes a long time to compile (or maybe a class of programs?), but most programs do not take a long time?

If you could narrow the problem down a little bit or perhaps just attach an example program that takes a while to compile, we could try to reproduce the problem.

Joel

[Borsch]

I will get the following error message during compiling a VI which uses NXT_TouchSensor.vi (or various other VI´s):

ERROR: Unsupported case structure value. Only single value cases  and Default, are supported.

The error message is caused by any Case-Structure where a U8, U16 .... is connected to the Case-Selector.

What is the problem?

[Albert.Geven]

probably you have no default case, so all not named numbers generate this error.

[John Field]

It also could be that you've entered '0..50' or '0,2,3,5' into the case value. The NXT-G compiler only supports single values in cases. I know that it requires a bit of programming, but just put that logic outside the case structure rather than in the case name.

- john

[Borsch]

Hi John,

Problem: Unsupported case structure values in NXT Toolkit VIs.

I think the problem is, that the VIs of the NXT Toolkit do not follow the restrictions of the Programming Guide of the NXT Toolkit. The programming Guide says at page 6 (Structures, Case Structure) that

“Only one specific value (or "Default) is allowed in the case selector lable for each subdiagram."

But for example the "PortSemaphore.AccessSemaphores.vi", which is part of the NXT Toolkit (and which is a Sub VI of "NXT_SyncUnlimited.vi") uses a Case Structure with the values “0, Default”, “1”, and “2”. This is only one example. I found many VIs in the NXT Toolkit which are using case structures with more than one specific value or with a “0, Default” value.

Why does the NXT Toolkit include VIs whitch are not programmed according to the Programming Guide of the NXT Toolkit?

How can I solve the problem? Do I have to modify each NXT-Vi with incorrect case structure values?

I am using LabVIEW 7.1 and NXT Firmware 10.3.

Regards

Manfred