Performance/Threading Question

[Sigal]

I'm an experienced RT SW engineer, yet, this is my first year with FRC and Labview (as a mentor)

Our SW includes one complicated state machine with two relevant (to this question) charachteristics:

1. Some of the transitions may take long time (including time delays)

2. Sometime, during a transition, it is possible to realize another state transition is required.

The state machine transitions are triggered by the driver (joystick button) but due to possible lengthly response I don't want it to run under the teleop thread (to avoid delaying other responses to driver operation).

I thought of analyzing the joystick buttons from teleop but then "signal" the need for state machine activity in another context.

One possible solution is using one of the periodic tasks loops, one we have no other use for, to check a global variable denoting whether to run the state machine.

Another possibility I thought of is using Occurrence or Notifier from teleop to a waiting VI.

Are these acceptable solutions? will they behave as I expect? what would be your suggestion to handle such a case?

Thanks for any thoughts shared.

[MarkBalla-Tecnova]

Hi Sigal,

One  of the things I try and encourage when programming the FRC robot is to separate output process from each other.

We did this by using separate parallel loops in the timed task area.

Keeping these loops or systems separate prevents slower systems from affecting ones that need a quicker response.

Our Robot last year had a separate while loop for each of the robot's systems.

We created simple state machines inside their own while loops to controlled the system outputs.

Drive Train

Ball Shooter

Ball Picker

Ramp Push down

Vision

Our Ball shooter would sometimes take 5 seconds to come up to speed and we prevented it from firing until it was ready.

The Vision analysis we needed to run at 2 updates per second and the Drive train was updated 20 times per second.

Each system is prevented for interfering with the other because they are running in a separate loop (thread).

Information is transferred to the systems via some global mechanism either FG(Functional Global), Notifier or Queue.

The globals are written by either Teleop or Autonomous code and Read by the system loops.

In teleop we read the joysticks and write the values to the globals and in Autonomous we read the sensors and the autonomous code writes the globals.

Keeping the Input commands separate from the output controls allow you to use the same system control code for both teleop and autonomous.

I hope this helps

Mark

[Sigal]

Hi Mark,

Thanks a lot for your reply, it helps a lot and explains exactly what I was looking for.

Sigal

[Mark McLeod]

Just to add on.

If all you are checking in Teleop is the state of a Joystick button, then there's no reason for a global.

Just check the state directly within Periodic Tasks.vi.

All Driver Station inputs can be checked directly from anywhere in your code.