Having trouble converting from BricX C code to LabVIEW !

[EDNEDN]

Hello!   We are trying to convert a fairly complicated BricX C program for the NXT Robot into LabView. 

We have simplifed the current problem and cut out everything but the basic stuff.   Attached is a BricX program that does a good job following a line using two light sensors that stradle the line on each side.   The sensors are being read in RAW mode.   Each light sensor value is compared against a threshold that will determine if the sensor is over the line, or off to the side of the line.

There are four possible states.   In two of the states, one sensor is on the line and one sensor is off the line.  In those states the motors are told to turn the robot back towards the line. 

Our team is having a difficult time translating this logic to LabVIEW.  Attached is an attempt to duplicate the C code in LabVIEW.   The While loops seems to only run once even though we have False being fed into the Stop condition for the loop.   But the While loop is running once because we see the motors kick and move a few degrees.  We have a few beeps in the block diagram to help us understand what is actually happening but other than that, we are trying to do a 1 for 1 translation.

I thing a big part of our problem is we don't understand the difference between the Purple NXT in and out dots on some of the function blocks and the Green Sequence (in and out) dots on the more complicated function blocks.

Can somebody offer up some advice on what we need to do to make our LabVIEW block diagram work similarly to the Bricx C code version?   (Incidently, the Bricx C version can do an amazing job following very jagged and complicated line patterns!  We are hoping to accomplish the same thing with the LabVIEW version!)

Thanks so much for any help that can be offered!

[ESearl]

You are indeed misunderstanding the purpose of the boolean (green) sequence wire. It is only used to control which block will execute first and which second; itshould never be used to hold data or govern logic as you are attempting. It seems like you are expecting that supplying a false value to a function block would prevent execution but this is not the case. What you are looking for is a case structure, which is like a switch statement in C. You can find it on the structures palette under programming.

I'm not positive why the loop is not working properly but I think it is because you are attempting 4 synced distance moves in parallel. Its possible each one prevents the others from executing, leaving you in a deadlock state. I expect the problem will be fixed by switching to a case structure.

[EDNEDN]

Thanks so much for the help!

That explaination was very helpful.  We will get busy trying to do the conversion as you suggested.  But can you tell us the difference between the Purple NXT in and out dots on the simpler motor (and sensor) controls and the Green dots on the fancier ones?   One thing we do know is LabVIEW refused to let you wire a Green dot to a Purple dot!  But other than that, we are in the dark!

[ESearl]

They are for two incompatible NXT APIs. The functions with a boolean (green) sequence are the legacy toolkit included mostly for backwards compatibility and more advanced users.They work only in remote (compiled) mode.

There is also another legacy API that have a brown sequence you might see. These ones work only in "direct mode" (tethered). In this mode the program is running on the host computer and interacting with the brick continuously.

The new version have the purple sequence wire and will work in both direct and remote mode. You can use the file menu item "Target to..." to switch your program between modes.

[EDNEDN]

Wow!  That is super helpful!   But now we are all scratching our heads.   The only function blocks we could find that had the capability we needed were the ones with the Green dots which you say are only included for backward compatibility. 

It sounds like we should only be using function blocks that have the Purple dots, especially since we are writing new code and don't have backward support issues.   But when we go to Functions / NXT-IO / Motors (or Sensors) and drag those into the block diagram, we don't get to control things like the Steering, Synchronization  or Coasting vs. Braking.   Obviously, we are missing something because that stuff is too useful to just eliminate it.  There must be a way to use the new function blocks (with the Purple dots) and still be able to control that stuff????

[ESearl]

Its true there is a little less control/functionality with the newer API, the decision was made to keep things simple( aka easier).

There are steering and move distance functions though, they are just not available on the polymorphic vi.(a block with the dropdown selection)

You can find them at this palette.

NXT Robotics : NXT I/O : Complete : Motors

[EDNEDN]

OK!   We have everything coverted as suggested.   Everything looks right, but we can't get it to compile.

Apparently, we are doing something the Formula Node translator doesn't like.   We have tried everything we can think of and are back to pulling our hair out!   😞

Also, we are not entirely sure we have done the Case block correctly with the motors.   Because we don't have full control of all the parameters on a single motor block, we staged them together.   For example, we start by using the Steering motor block and tell it how we want to turn (or go straight) and we feed that into a motor block where we can tell it how far we want the motors to turn.   Will the down stream motor blocks inherit the properties of things that happened earlier?      I guess we would know if we could figure out why the compiler doesn't like our Formula Translation block.

We also have a question about Race Conditions.   When exactly does the logic in the Formula Translation block get evaluated.  As you can see from the VI, we need it to get evaluated after the second light sensor gets read, but before the Case block gets executed.   Is there a simple rule that gets followed to help us understand that?

Thanks so much for any guidance you can give!!!!

[ESearl]

Ok I see two things wrong with your diagram.

The formula node on NXT is only for formulas and assignment operations, it wont allow any kind of programming statements like If else switch etc. This is probably a documentation bug, the issue is that the formula node does support those things in general, just not when compiling for NXT. Sorry about that.

That being said you can write the logic to generate your state in dataflow! I attached a screenshot.

Also you cannot stage the motor blocks together like that. Each call will overwrite the state of the output port. If you need a combined steering and distance move, you will need to use the older API or create it yourself by reading the encoder.

[EDNEDN]

Thanks for the response!   We gave up on the Formula Node because even when we put something super simple into it, it complained.  In fact, we couldn't even use a "int state;" at the top to declare the output type.   And I guess you noticed the documentation clearly says C like statements are allowed.   It would have saved us a day if they had said it wasn't allowed in an NXT target!   Arrrghh!!!

We actually got clever and did something very close to what you suggested.   Except we didn't know about those Select gizmo's.  So we multipled one output of the comparison gate by 2x and added it to the other to get a number in the range of 0 to 3.   And we found out exactly what you said...   The new motor controls aren't going to do what we need.     I'm attaching the current version of the VI so you can see what we are up to.   But it is very similar to what you suggested.

I'm wondering....  We can't mix the old and new function blocks because it won't let us wire purple dots to green dots...  So how do we mix old and new?   I guess the first thing to try is to see if we can just have old green dot function blocks inside the Case block even though stuff outside it is purple dots ???

[ESearl]

I think you are getting the hang of labview.

Your solution for generating state is ideal and you can also place the old steering VIs in the case structure as you suggest.

The sequence terminal is never required to be wired, it is only there to help you define execution order. In your case the ordering is already defined by the case structure being downstream of the lightSensor nodes due to the data dependency.

Good luck!