PSA: Enable Vision Race Condition

[flemdogmillion]

Just solved a really sneaky race condition last night, so I thought I would do something so other people don't fall in that trap and blame their vision slowness on "LabVIEW is slow."

In Robot Main.vi, there is a bit of code shown in the attached image that applies what is effectively a constant (an unwired control) to the global variable Enable Vision. You need to remove this bit of code if you are going to at all use this variable, say, to turn a ring LED on or off. If you do not, you can easily miss this, since you're "not supposed to edit Robot Main.vi." I certainly missed it.

This race condition is characterized by your vision code taking almost exactly 50 ms to loop every time, while it appears to take about 300 ms to update the result variables. As a result, it pretty much just looks like it's running slow.

Happy coding!

[Hess1113]

I found that the enable vision variable in Global Data.vi (or something like that) is false unless you press the button and save it as true.

[flemdogmillion]

Originally Posted by Hess1113

I found that the enable vision variable in Global Data.vi (or something like that) is false unless you press the button and save it as true.

You can still write code that manipulates the variable, causing it to change.

[Hess1113]

Originally Posted by flemdogmillion

You can still write code that manipulates the variable, causing it to change.

Or replace any instance of the "Enable Vision" variable with a true Boolean.

[flemdogmillion]

Originally Posted by Hess1113

Or replace any instance of the "Enable Vision" variable with a true Boolean.

If you do that while using the variable to simultaneously enable vision code and turn on a ring light, the ring light will be always on, which is not allowed.

[JeffB]

Wouldn't it make more sense to create a variable to control your ring light rather than alter the way it's already functioning to control the vision system as a whole?

[thatnameistaken]

Originally Posted by flemdogmillion

If you do that while using the variable to simultaneously enable vision code and turn on a ring light, the ring light will be always on, which is not allowed.

Per which rule? I'm not seeing it.

[flemdogmillion]

Originally Posted by thatnameistaken

Per which rule? I'm not seeing it.

R07-M.

Originally Posted by JeffB

Wouldn't it make more sense to create a variable to control your ring light rather than alter the way it's already functioning to control the vision system as a whole?

It seems clumsy to leave your vision code, which uses a lot of resources, running when it's not in use. Just my opinion, so I followed it.

[Bkeeneykid]

Originally Posted by flemdogmillion

R07-M.

R07-M really depends on which light source you're using. If you're using something with a 300 lumen output, you're probably going to have a bad time, but if you're simply just using the LED ring in FC or a smaller LED that was mentioned in another thread, I doubt anyone will rule that illegal.

Please note: I am not an inspector. Please at least run it though a spike just in case. The ability to be able to turn it off will not be a bad choice at all.

[JeffB]

Originally Posted by flemdogmillion

R07-M.

It seems clumsy to leave your vision code, which uses a lot of resources, running when it's not in use. Just my opinion, so I followed it.

I'd imagine you're planning on your team operating in the portions of the field clouded by one, or both, airships. Is your vision code not streaming a feed to your drivers to help them drive the robot in these cases?

[flemdogmillion]

Originally Posted by JeffB

I'd imagine you're planning on your team operating in the portions of the field clouded by one, or both, airships. Is your vision code not streaming a feed to your drivers to help them drive the robot in these cases?

The streaming code is a self-looping VI that starts when Vision Processing.vi initializes. It is separate from the actual vision loop that you write. It lies far outside the Enable Vision case structure.