Control Module ABS 20 User Guide¶

This user guide is targeted to the SIR administrator, the responsible for adapting the SIR to transform the SIR users operations to multicast messages to be sent to the modules.

The main changes in the new version of ABS are the implementation of multicast packages for all the commands, implementation of new commands, and other features that will be displayed bellow. All the new commands were also implemented in the SIR Server, that is the responsible for sending the correct commands with correct package format.

Multicast commands¶

The following ones are implemented commands:

• RBOT: Stands for reboot, when sent make all the modules 2.0 restart but conserving their current data, it is useful for debugging. The SIR doesn't wait for the modules' answer.

• GETC: Stands for get char, when sent make all the modules 2.0 sends to the SIR their current beam coded as printable char (real_beam+33), it is useful for debugging.

• GETB: Stands for get beam, when sent make all the modules 2.0 sends to the SIR the corresponding number of the actual beam, which is from 0 to nbeams-1, it is useful for debugging.

• MNTR: Stands for monitoring, when sent the SIR will wait some time for all the modules 2.0 to respond, this let the SIR user know how is the connection between all the modules and the SIR.

NOTE: The response to this command contains an additional character which is the value of the monitoring pins plus 33.

• SNDF: Stands for writing, this command lets the user save new configurations in the memory of the modules, by default after a write operations all the modules are going to be pointing to beam n° 0. The protocol for the multicast message is shown below.

NOTE: The tests performed in the modules showed that the maximum number of beams that can be safely sent by multicast messages are 20. Therefore when the SIR user configures more than 20 beams, the SIR is responsible for sending in order the beams in packages of 20 beams following the protocol described above.

• CHGB: Stands for reboot, this command lets the user change the beam pointed by all the modules. It should be sent using the following format: CHGB$nbeam, ex. CHGB1, CHGB99, CHGB999 (is the maximum number of beams).

POST Messages¶

When an unexpected event happens in a module, this post a descriptive message to the SIR so the SIR administrator

• Invalid beam POST: This post is performed when the SIR tries to access to a beam that hasn't been written yet. This happens when the SIR access to a beam that is greater than the total number of beams or when the SIR access to a beam before it was sent.

• Reset POST: This post is performed when the module hung out and therefore the watchdog timer of the module gets the 0 value two times. This could happen too in some really weird untested cases where the module behaves correctly but a operation takes too much time causing the watchdog timer to trigger.

• GPIO POST: This post is generated when an unexpected change in the monitoring pins has happened or when after a change of beam operation(the initial load of the last beam counts as one) the monitoring pins read a value that doesn't correspond to the written beam. The post sent will contain the information about the pins that are wrong.

• Corrupt EEPROM POST: This post is generated after a module reset when the EEPROM tries to do any necessary recovery in case of power failures during write and fails. The SIR should show a message to the user when this POST is received to let the users know that they should perform a write operation because the data in the modules' memory are not reliable.

• Incorrect number of beams in package POST: This post is generated when a module detects that the SIR sent more than 20 beams, therefore the multicast communication was on the limit, to ensure correct transmission of the data the SIR administrator should review the SIR model and adapt it to only send package of 20 beams as maximum. If the SIR is configured correctly, this post should never happen.

• Corrupt Package POST: This post is generated when a package with incoherent data was sent. This should never happen is the SIR is configured correctly.

• Wrong Command POST: This post is generated when a package with a wrong command was sent. This should never happen is the SIR is configured correctly.

NOTE: Should be taking in account when configuring new and more complex experiments that some operations like POSTs from modules to the SIR takes from 1s to 2s approximately.

NOTE: Should be taking in account that is the SIR server is off when a module tries to sends a POST the module will wait until it can connect to the server and then will perform the post.