Issue with new FTC Disable Robot.vi

[Philbot]

I've just started getting to know the new LV FTC Toolkit and I have a question regarding the new FTC Disable Robot VI.

It looks like this VI has been created to respond to the state of the telemetry link (onlin/offline start/stop) and automate the disabling of motors and servos.

That much looks good.

However, in doing this, it also creates an output terminal called "Enabled?"

My problem is:  Despite the fact that the Icon for this VI is a LED that is on/off and despite the fact that the naming convention for this output implies a yes/no answer,  the output isn't a Boolean.  It's something else (spin, enumerator whatever).

So wherever it's used, it needs to be compared with "Enabled" or Disabled" to decide if the robot is Enabled. 

Even the autonomous Template has to compare the signal before it can do a boolean operation on it.  D'OH!

This complicates a very simple concept (ie: Enabled? true or false) with a bunch of LV cleverness.

So.....   how come this output isn't a simple Boolean so it can be used directly with boolean logic and true/false case structures?

[Kevin_F]

Hey Philbot,

The reason it was done this way is likely just cosmetic. In most cases it makes things more readable.  The biggest example of this is with Case Structures.  If you wire the Is Enabled? terminal into the case selector you automatically get a case named Enable or Disabled instead of True or False.   An example of this is shown below.  Let me know if you have any other questions.

[ESearl]

Hey Phil,

I'm not wild about the enum type either. I think the only reason for it is that it increases the readability of case structures because case structures display the string, "enabled" vs "disabled", when the enum is wired directly to the selector.

It will be difficult to change now b/c it could break existing diagrams and its not a critical issue. I will keep it in mind though for next years release. Thanks for the feedback.

-Ethan

[Philbot]

At some level I understand the reasonning that Enabled/Disabled makes some portions of the code simpler, but at other locations it makes it much messier.  eg: where did that list of names come from???

If a signal has two states, and that signal can be named in a way that makes the true/false state clear (like "Enabled") then I feel strongly that it whould be left as a boolean (otherwise why have them?).

If you are going to give a signal ennumerated states, then to me, you should assume that there may be more than two in the future, and NOT name the signal as if it's a boolean...

eg:  "RobotState"  rather than "Enabled?".

I know it's a fine point, but it helps to have rules that can be used to set a clear path for rookie programmers, and I thik a good rule is:

If a signal has two defined states/functions, then make that signal a Boolean and name it such that the name indicates the TRUE boolan state.

If a signal has multiple states/functions, then make it an ennumerated signal and name it such that the name describes the category of conditions.

JMHO