The Initialize Statement

We've seen that State Machines are built from tables, and tables are built from rows. So far, rows have been built from When/State/Then statements. A row can also be built from an Initialize statement.

"my_just_initialize_table": [
  {Initialize: {out: "on"}}
]

Above is a table with one row containing an Initialize statement. This table isn't very interesting. It doesn't respond to any events, because it has no When statements. Instead, it tells a State Machine what to do at initialization time. Here, it tells its State Machine to set its "out" signal to on.

Like the When/State/Then statements, you can write multi-signal Initialize statements.

"my_just_initialize_table2": [
  {Initialize: {out1: "on", out2: "off", out3: "idle"}}
]

And you can initialize input signals as well.

"my_just_initialize_table3": [
  {Initialize: {in1: "on", in2: "off", out: "off"}}
]

How They Work

Initialize statements are similar to Then statements - they both generate events. Then statements generate events when their When and State statements are satisfied. Initialize statements generate events at initialization time.

Initialization time happens after a State Machine is created and before it has seen any non-initialization time events. The events from an Initialize statement are among the first events a State Machine sees (the only other events it might see first are events from other Devices creating events at initialization time).

If we made a slightly more complex State Machine table:

"initialize_and_run": [
  {Initialize: {in: "off"}},
  {When: {in: "off"}, Then: {out: "off"}}
]

The State Machine would set its "in" signal terminal off. All Devices wired to the terminal would then see an "off" event. The State Machine would see the "off" event as well and would set its "out" signal terminal to off.

How They are Used

Initialize statements let your State Machines generate events when they start up. Other than causally, Initialize statements are the only way State Machine terminals can create events. At initialization time, your State Machine could be stuck in limbo, waiting to get to state which allows it to do something, but unable to get to that state until it does something. If you find yourself using a Reset Device to kick off your State Machine, you probably should be using an Initialize statement.

Setpoints

Here's a trivial example of a State Machine which generates a setpoint (which could be used by another Device to learn if a value is above or below the setpoint).

"setpoint": [
  {Initialize: {setpoint: 75}}
]

Clocking Edge-triggered Devices

Here's an example of a State Machine clocking an edge-triggered Device. Sometimes you want your State Machines to clock edge-triggered Devices (e.g. OneShots, Registers). Your table will have When statements telling it when to turn the clock on and off, but what about the first time you turn the clock on? If the clock output was not initialized, it will go from nothing to on, and your edge Device won't do anything (edge Devices need an off to on edge). That's probably not what you want. To fix things, you can initialize the clock to off.

"clock_generator": [
  {Initialize: {clock: "off"}},
  {When: {condition1: true}, Then: {clock: "off"}}, 
  {When: {condition2: true}, Then: {clock: "on"}} 
]

Start Up Sequencing

Here's an example where you want to generate a sequence of events. Sequences can come in handy when you have Devices which need to be initialized in a particular order. The Initialize statement starts up the sequence.

"sequencer": [
  {Initialize: {out1: "on"}},
  {When: {out1: "on"}, Then: {out2: "starting"}}, 
  {When: {out2: "starting"}, Then: {out3: "done"}},
  # clean up
  {When: {out3: "done"}, Then: {out1: "off"}}
]

This table creates a State Machine which starts up with an on event on its "out1" signal, followed by a starting event on its "out2" signal, followed by a done event on its "out3" signal. After the done event, it resets its "out1" output to off.