10-18-2012 10:17 AM
We really appreciate all the help we have been getting here! But we are at the point where we are getting very nervous about what we are doing. Right now we are trying to make a Calibration routine for our Light Sensors. What we want to do is place our robot with both Light Sensors on the line and press a button to read the values. Then, we want to place our robot with both Light Sensors off the line and press a different button to read those values.
Once we have that set of data, we want the program to average the two values and save that result as a data file for later use when we start our line following program.
Attached is a VI that averages the values like we want. We do not have it saving the values in a data file yet. But we have a list of concerns that we are hoping to get guidance from the LabVIEW community about. We don't have much time to waste and programming our robot is proving to be very time consuming. We are hoping that by asking the right questions we don't head down paths that are a dead end.
- Is it OK to split the sequence path in two directions to feed both Case blocks? Because at that point, you are not really sure which one will be performed first? In this case it doesn't matter. But we are worried about the correctness of how we structured this.
- Is it OK to have multiple references to local variables in the same VI? And as you can see, in some situations, we are reading from them, and at other times we are writing to them. Is that OK?
- We don't have a single continuous path through our logic. Does everything within a While block get executed every pass through the loop? If so, we are good because we don't really care if something gets displayed this time through the loop or the next time through the loop. But right now we are uncomfortable that we can count on everything happening (probably in some random order) every time through the loop.
- What are all those local variables on the top of our block diagram? When we create a local variable to use, it seem to insist on putting a copy of it on our control panel and sticking those icons on our block diagram even though we don't have anything wired up to them. We kind of just collected them a put them up there in a nice orderly manner, because we were scared to delete them. Do we have to leave them laying around cluttering things up?
- We ended up with an extra While block (due to careless editing). We can't seem to delete the outer While block without killing the entire block diagram. When we get resolution to some of our questions, we plan on adding the code to save the calculated data values to a data file when we exit the inner While block. But we don't need that outer While block so we need to figure out how to kill it.
- Is it possible to connect a wire to a Case block as a Sequence-Out to allow execution to continue at some other block when the Case is finished? We can't seem to get that to work. It seems like it should be possible. But everytime we try to wire something up to come after the Case, we get those X's on the wire complaining we can't do that. That is why we had to split the Sequence flow to go to both Case blocks instead of cascading them. And that also is part of the reason we have all those pieces of logic with no sequence control on them. In the documentation we can only find mention of 'Output Tunnels' for values. Nothing about Sequence Control.
We apologize for the amount of information being requested! But hopefully, you can see we are really putting in the time to understand this stuff!
Thank You for whatever help you choose to give!!!
10-19-2012 09:40 AM
Hi EDNEDN,
Thank you for posting!
I have answers to most of your questions.
- Is it OK to split the sequence path in two directions to feed both Case blocks? Because at that point, you are not really sure which one will be performed first? In this case it doesn't matter. But we are worried about the correctness of how we structured this.
A: This should be okay, as long as you do not care which is executed first.
- Is it OK to have multiple references to local variables in the same VI? And as you can see, in some situations, we are reading from them, and at other times we are writing to them. Is that OK?
A: This is also okay. It would be best to wire the variables directly together (using the indicator or control) than using variables, but sometimes you have to use them.
- We don't have a single continuous path through our logic. Does everything within a While block get executed every pass through the loop? If so, we are good because we don't really care if something gets displayed this time through the loop or the next time through the loop. But right now we are uncomfortable that we can count on everything happening (probably in some random order) every time through the loop.
A: Everything within the While Loop should execute each iteration, but as you said without flow control it will not be in any set order.
- What are all those local variables on the top of our block diagram? When we create a local variable to use, it seem to insist on putting a copy of it on our control panel and sticking those icons on our block diagram even though we don't have anything wired up to them. We kind of just collected them a put them up there in a nice orderly manner, because we were scared to delete them. Do we have to leave them laying around cluttering things up?
A: Local variables reference a front panel object, such as an indicator or control, which is why they were created. What you did by putting them up top neatly is the best way to deal with them.
- We ended up with an extra While block (due to careless editing). We can't seem to delete the outer While block without killing the entire block diagram. When we get resolution to some of our questions, we plan on adding the code to save the calculated data values to a data file when we exit the inner While block. But we don't need that outer While block so we need to figure out how to kill it.
A: I believe you can remove the outer while loop by right click on the edge and selecting remove while loop.
- Is it possible to connect a wire to a Case block as a Sequence-Out to allow execution to continue at some other block when the Case is finished? We can't seem to get that to work. It seems like it should be possible. But every time we try to wire something up to come after the Case, we get those X's on the wire complaining we can't do that. That is why we had to split the Sequence flow to go to both Case blocks instead of cascading them. And that also is part of the reason we have all those pieces of logic with no sequence control on them. In the documentation we can only find mention of 'Output Tunnels' for values. Nothing about Sequence Control.
A: I believe this should also be possible. I know that in LabVIEW you just have to be sure that you wire up all the Cases within the structure, that is, if there are two cases (like True & False) you need to make sure the wire passes through both cases and exits from the same tunnel.
Please let me know if this helps!
10-19-2012 04:20 PM - edited 10-19-2012 04:21 PM
Thanks Matt for the help! That really helped us a lot. But we didn't quite understand one of your answers.
- Is it OK to have multiple references to local variables in the same VI? And as you can see, in some situations, we are reading from them, and at other times we are writing to them. Is that OK?
A: This is also okay. It would be best to wire the variables directly together (using the indicator or control) than using variables, but sometimes you have to use them.
We don't really understand what your answer means. It is probably because we don't have enough experience yet.
What is the 'Best Practice' ? It seems we can't wire everything up to a single instance of the variable because at a minimum we need to be able to read from one and write to the other instance of it. We can't denote a variable as both read and write. The other problem we found is we can't use the same read instance of the variable because some times we need it evaluated after something else has set it. So in that situation, we need to make a new instance of it within the Case or For block. That seems to force it to be calculated when the Case or For block gets initialized. (We are no longer working on the Calibrate code... We have moved on but this question is still causing us some hair pulling)
And lastly... I think we are getting by, but is there a way to connect up the newer Purple Dot functions to the older Green Dot functions? It seems like the ability to mix and match would be very beneficial!
10-22-2012 08:05 AM
Hi EDNEDN,
Generally speaking, it is preferred if you have the ability to directly wire something that you do so, but if that is not feasible then it is perfectly acceptable to use local variables. Essentially, what you are doing is fine since you cannot easily wire them straight up.
I'm not sure what you mean by Purple Dot functions and Green Dot functions, but my guess is they accept different data types that cannot be coerced, so that they cannot be mixed. Ultimately though, can you define what a Purple Dot and Green Dot function is? Thanks!
10-23-2012 08:54 AM
Hi Matt! You can tell we are not experts just from how we describe things! 🙂 For an example of what we call a Purple Dot block, check out PolyMotor.vi which can be accessed from the Function Menu by going down the path of: NXT Robotics / NXT IO / Motor-Control
You can get a Green Dot block by loading a VI from C:\Program Files\LabView 2011\vi.lib\NXT\Remote Library\Move\NXT_Sync_Distance.Vi
There are useful function in both places and it seems like it should be possible to mix and match them together!
10-24-2012 08:18 AM
Hi EDNEDN,
It is possible that the data types are incompatible for those two VIs to be able to be directly connected. Thanks!