Cryosystem Server Software

The server software refers to the program code for the Nios II processer in the cryosystem interface qsys system. The program maintains the higher level control, coordinates the qsys modules and interact with user IO and the connected clients on the network.

The program is coded in C programming language under NIOS II SBT IDE. The project contains a bsp subproject which defines all the hardware implementation details, and the name project which contains all the source files.

Refer to \References and App notes\Altera Literature\GUI folder for information on how to use to GUI IDE.

At the time of writing this document, the current software package used for the project is cryosystem2013 and cryosystem2013_bsp.

Note that in the cryosystem2013_bsp project, it is important to set the linker script to use ram as memory region for all program code regions in bsp editor. This is done to ensure that all the program code resides in onchip ram memory, not SDRAM memory.

SDRAM memory are accessed by addresses hard-coded in the source files, so it is desirable to avoid the linker from assigning arbitrary regions of it to be used for some program sections, as these locations may overlap with the hard-coded regions in the source code.

Detailed descriptions of how each source file implement each specific functions are shown below:

Card_reader

The RFID reader used in this project uses RS232 interface. Upon reading a nearby RFID tag, the PIC controller in the device send out character streams on the RS232 lines to the card-reader UART module.

It is important to configure the RFID reader to format the character streams in the exact format that can be recognized by the interface controller.

Install pcprox_config and use it to configure the connected reader to the PC, before using the reader in the system. The manual is included under the install directory. Look under \firmware design\rfid_reader settings folder.

In the config software, use desktop_ver.hwg to configure the desktop USB reader (for enrolment); use rs232_ver.hwg to configure wall-mount RS232 reader (for access).

For the RS232 reader, use an USB to Serial converter with breakout cable. Observe pinouts below:

Note that the unused TXD need to be connected to GND for the cable to work.

Refer to card_reader.h and card_reader.c, there are 3 functions implemented for this module:

Init_card_chan initializes the card reader semaphores and register the UART port in the interrupt service routine vector table.

Card_chan_isr is the interrupt service routine that reads from the unbuffered UART module, and store the card data in a global buffer, removing the start and end header characters and set up semaphores.

Get_iclass decodes the card message stored in the global buffer and produces the facility ID and user ID.

Def

Def.h defines the data types and other constants used in the project.

Note that the admin class IDs are obtained from one special person’s UBC card information, and this number gives access to both dispensing (even works if user list does not contain this ID) and the network configuration page.

SDRAM addresses used for network data storage, user list data, and RTD data are also defined in def.h.

Def,c implemented two functions generally useful but not specific to any of the hardware modules:

Format_string converts a 32-bit binary number into a character string representing the number in base 10. Note that this only works upto 10 decimal places.

Decode_number produces a binary number from a character stream of decimal numbers. Note this only works in 32-bit binary number range.

Fram

Functions implemented for the fram module interface to the SPI slave device with standard common flash interface protocol, and the transaction layer on top of that to update custom data structures, user lists and billing records.

For CFI protocol, refer to datacheets for the fram device. Unlike standard CFI for flash devices, erase operations are not needed (still exists in the command set, but does not do anything), and it is not required to query erase/program completion flags.

Each function is describe in more details below:

Write_fram writes streams of 8-bit bytes to fram, from the specified data source of 8bit, 16bit, or 32bit data buffer. The sequence of operation is as follows:

Assert device chip select Set write enable latch, discard dummy read byte Send write command with starting address Enter control loop to break up data packets to 8-bit bytes, and send streams

of bytes out continously until all data are used Deassert device chip select

Read_fram reads streams of 8-bit bytes from fram, into the specified destination of 8bit, 16bit, or 32bit data buffer. The sequence of operation is as follows:

Assert device chip select Send read command with starting address Enter control loop to receive 8-bit byte data and format them into the

specified data word fields in the buffer until number of specified data length is reached

Deassert device chip select

Fill_parameter fills up the local parameter buffer in on-chip ram with valid values from the default values stored in program code area or from fram parameter storage area.

First a check value is read from fram to determine if fram contains valid parameter values. Then a decision is made based on the validity of the parameter data and the option argument passed to the function, whether to read from fram or use default values.

If condition is true, then all parameter data in fram are read out, and then assigned to the corresponding locations in the local parameter buffers.

Otherwise, the local parameter buffers are assigned the default values stored in the program code section.

Store_parameter writes the parameter values in the on-chip memory to fram. All parameters are copied into a local buffer formatted in fram storage format, then written to fram with a single call of write_fram.

Fill_user_list fills up the userlist buffer in sdram with valid entries from fram userlist region or, in case of invalid fram data, only the admin ID is copied to the userlist buffer.

First the check value is read from fram, and if the check value is valid, user list values are read from fram, and assigned to corresponding positions in sdram; otherwise, only the admin values are copied to sdram userlist buffer.

Store_user_list writes all userlist data from sdram to fram. Each sdram userlist entry is formatted in a local variable, then sent to fram with one fram_write call.

Init_record initializes the billing record data structure’s semaphores depending on whether fram contains valid billing record data.

A check value is read from fram to determine if bill data is valid. Number of records and read/write indices are read from fram if data are valid; otherwise, records are assumed to be null, and a new record file is started at record reference 0.

Get_record_addr is a helpwer function that computes the fram address for the specified billing record by current reference number and saved reference number.

Save_record updates the billing record information held in ram, and writes it to the next available position in fram space. Billing records are ordered sequentially by reference number, and whichever record is saved first, gets the next available reference number.

Note that all records are saved to fram immediately after each associated fill is finished, so this function is called everytime a fill process finishes, and writes exactly one record to the next available entry space in fram.

Record2sdram read billing records are fram in the specified reference number range, and write these data to specified sdram space all data are written or the specified sdram address range becomes insufficient.

Note that if current reference number matches the global variable read reference number, then fram check value and number of records are appended in the beginning of the specified sdram space. This creates a start header for the billing record information file.

This function is used to provide a record file when sending record report to the remote client.

Reclain_record_space delete the old records while preserving the current records. This is done by writing the current records in the beginning of the assigned fram billing record space, and updating the reference indices and number of references.

It is important to note that the old records are the records that have reference numbers smaller than the specified reference number passed to the function. There may be new records after that reference number, and therefore must be written to the biginning of the file, and the number of records would be nonzero.

Key

Functions written for the key module drive and read the switch lines from the keypad matrix and determine the key being pressed. Note that only single key strokes are read properly.

Each key has its ungie key code assigned, depending how the lines are driven. For details on how the combinations are worked out, refer to the datasheet and the driving sequence expressed in the source code.

Key_init configures lines 0, 1, 2, and 3 as outputs and lines 4, 5, 6, and 7 as inputs. So when line 0, 1, 2, and 3 are driven sequentially, lines 4, 5, 6, and 7 are read to determine the connection node of the matrix switches.

Initially, the drive lines are driven low, making the sense lines low.

Check_key drives each independent drive line high sequentially. In each case, the sense lines are read and interpreted; if no key press is detected, it is carried on to drive the next line.

Note that by the nature of the implementations, certain key presses take precedence over others if multiple keys are pressed (if multiple keys are pressed, invalid key codes may be generated).

Get_num decode the key codes and return the decimal number equivalent (0 to 9).

Lcd

Functions implemented for lcd module deal with low-level commands for the LCD modules. These modules have microcontroller on them to decode these serial commands and drive the lcd driver appropriately. Some bug are known about this microcontroller interface, but it is determined that anomalies tend to fade away at 9600 baud rate.

It is necessary to set the lcd module to use RS232 protocol and with 9600 baud rates. Both are default settings from the factory, but if changes are required for any

reason, solder the jumper wires on the bottom side of the module and use a usb-serial cable to change the settings. (consult the datasheet)

Refer to the lcd module datasheet for a full description of the command set available.

Send2lcd is the low-level routine that writes serial data to the selected lcd module by lcd_num.

Note that no arteficial delays are added in the communication sequence. It is assumed and observed that at this speed, the microcontroller and update the LCD screen display as fast as it receives the serial commands.

Lcd_ctrl sends control code to the module. For a list of control codes, refer to the datasheet.

Set_lcd_cursor sends command sequences to adjust the position of the text cursor, and the appearance of the cursor.

Lcd_contrast adjusts the contrast of the lcd module.

Lcd_backlight adjusts the intensity of the backlight for the lcd module.

Param

Functions implemented for the param PIO module issue commands and download rtd parameters to the HDL section of the design. Data becomes valid to the RTL design when the valid strobe is asserted (many clock cycles though).

Param_init is called in the beginning of the application, download all rtd parameters and reset all rtd processes. Note that when all 3 processes are placed in reset, the HDL system reset is asserted.

Rtd_send_cmd sends a simgle command word to the RTL design. Available commands are:

Start_param: start the dispense process Stop _param: stop the dispense process Reset_param: reset the dispense process Set_misc_op: set the run status indicator Reset_misc_op: reset the run status indicator Set_speaker: set the speaker enable Reset_speaker: reset the speaker enable

Rtcc

The rtcc module is controlled by the I2C master available from opencores. Read opencores I2C master documentation to learn how the I2C master is implemented and the register explanations to learn about the software programming model.

Read the rtcc chip datasheet to learn all the register definitions, and the available dat and time information from the chip.

An rtc_time data structure is used to keep all the time information, and updated as requested. The time keeps counting as long as power is applied to rtcc module, and with power removed as long as battery is kept.

Rtcc_init sets up the I2C settings at 400kHz clock frequency and as a master device.

Rtcc_set sends all update time information to rtcc module to overwrite the current times. This is usually followed by an update time from the remote client, where this time information is refered to as the standard time for the rest of the world.

Rtcc_get reads all time information form the rtcc module, and update the rtc_time data structure.

Rtd_adc

Data stored in the rtd fifo modules are read, and buffered in another larger buffer in the ram section of the processer system. Note that this is necessary to gain random access to the rtddata words, and to improve performance dealing with imbalanced dataflow between the processer system and the RTLsection.

The data strucure, rtd_fifo_status, the data buffer and the read/write indices. The overrun flag is implemented, but never checked in the main application, only used in debugging. It is implied that overrun should not occur during normal operation of the application, and may only happen in debug when the code execution is halted while RTL execution is not.

Init_rtd_fifo resets each rtd_flag.

Rtdn_fifo_work is called in main work loop body to move any data in the fifo to the server local buffer, ready for processing.

Note that when overrun occurs, it is flagged, and old data are overwritten. There is not data recovery, and should never happen in normal program flow.

The rtd data are saved in buffer as their raw data format. The main application may decode the messages according to their rtd number and address numbers.

Time

The 64-bit timer counts continously and provide a higher resolution time keeping function suitable for timing processes in the application such as lcd clear screen process, yet the count range is large enough to keep time in dispense alarms.

The timer can be used time time multiple events simultaneously when using multiple data variables for keeping the start time value, and compare with computed end time (start time + elpased time) to give an indication of timeout.

Refer to embedded IP Quide for more information about the timer IP.

Init_timer starts the timer. This may not be required for timers with start bit disabled.

Get_time write a value to the snap-shot register to take a snap shot of the timer count value. Then the timer value is read and returend to the caller.

Check_timeout computes the time_elpased by taking the difference between start time and current time. To deal with the overflow time count, the max. timer count value is added to restore the overflow timer value. It is implied that the vlaue cannot overflow more than once, since the application should loop reasonably frequently to detect the timeout.

Note that counter_load_val looks like an arbitrary number that is larger than the specified 1800sec count value when the timer is instantiated. Looking into the Verilog source file reveals that the IP has a bug to generate the wrong number for the timer module. So this number is used instead.

The function returns true as timeout if true elapsed time exceeds the specified duration.

Wiznet

The wiznet module is an ethernet controller that handles all ethernet protocols including managing connections, receiving and transmitting etehrnet packets. On the perspective of the connected master component (Nios II processer system), wiznet exposes read/write FIFO memory and command/status registers in the connected processer memory bus.

On the avalon bus, the PIO components mapped on the avalon memory-mapped bus occupy a small range of addresses. But these PIO addresses are used to interface to the much wider wiznet processer memory map of 10 address lines.

Transactions with the wiznet FIFO memory are done by exchaning data with the memory-mapped registers. Refer to w5300 datasheet for details on how the interface works.

The software implementations foe this module are done by operating the various PIO components connected to the wiznet module processer interface (data, address, control, status).

8 connection pipes are available, and 4 of them are used in this application. After the network servers are configured, the main application polls the connection status by reading the interrupt pin, if attention is needed, working through the status registers and perform the required actions.

The data strucure, wiz_status, contain semaphores and sdram memory locations assigned for local buffer storage, for each port connected. The SDRAM buffers are used to gain random access to the FIFO memory from wiznet.

The data structure, wiz_config, contains all network configuration parameters required to reconfigure the ethernet controller. These parameters are saved in fram as part of the parameter file, and can be changed through the network configuration page in UI if admin ID is used.

All register addresses are defined in the header file. Note that the addresses for these registers are the same for each port, only offset by a fixed number, wiz_sock_reg_oft.

wiz_init initializes the control PIO lines and apply a hardware reset pulse of 2 usec and 10msec idle time. Then, retransmission settings are set, and the socket FIFO memory boundaries are set. Finally, wiz_reconfigure is called.

wiz_reconfigure sets the mac address, gateway ip, subnet mask, and source ip from the wiz parameter to the wiznet module.

Then for each socket, the connection is specified as TCP socket with interrupts enabled on specific events, and opened with assigned port number. Each socket is then put in listening state, and the associated sdram addresses are reset.

Read_wiz_reg is a low-level routine used to read register value from the wiznet module. The reading sequence follows conventional processer memory protocol:

Latch address Assert chip select and read strobe Latch read data Deasset read strobe and chip select

Write_wiz_reg is a low-level routine used to write values to the wiznet device registers. The writing sequence follows conventional processer memory protocol:

Latch address Latch write data Assert chip select and write strobe Idle write clock Deassert write strobe and chip select

Wiz_work is the main working process for wiznet data interface operation. It is called constantly in the main application’s work loop.

First the function reads the module’s interrupt pin to determine if any new event has occurred.

If a new event is detected, it then reads the interrupt register to determine the events, and work through each event in sequence. Depending on the events, it may set semaphores, perform reset operation, continue to send out remaining transmit data in the sdram buffer, or read received data from read FIFO register into sdram read buffer.

Finally it checks for any error encountered in the module, and clears them. Note that these error conditions are just ignored, and normally should not occur in normal program flow but in debug mode.

Wiz_write initiates write operation to the wiznet transmit FIFO memory on the specified socket.

It starts by calculating the available data length that can be written to the FIFO. Then it writes exactly that amount of data into the transmit FIFO and issues the send command.

If there are more transmit data than can be sent at this moment. The remaining data will be sent when at a later point, wiz_work detected that send_complete is flagged, and continue sending the remaining data.

Wiz_reset_sock issues a disconnect command to the specified socket, then listens for the connected client’s response to close the connection. Acknowledging the response, it then opens the socket again and put it in listening state.

Wiz_reconfig closes all connections violently by issuing cldoe commands to the sockets directly without negotiating with the connected clients. Then it calls wiz_init to restart the entire wiznet configuration process.

One important point about the ethernet controller is that the manufacturer did not assign an unique mac address to the device. Instead, it is configurable by the connected controller. In this application, mac address is assigned a completely arbitrary value, while it works generally, may cause some network interrupts at some other times.

When the ethernet connection is lost on the network, it is necessary to reset the controller. However, there is no way to detect that the server connection to the network is down because it is assumed that the controller is normally not connected to any client.

It is then necessary to reset the ethernet controller manually by triggering an action that calls wiz_reconfig, or effectively wiz_init. This can be done by cycle power to the cryosystem control box, or better, change the network parameter (or change to the same value), which will cause a wiz_reconfig.

Main_app

The main application source file implements the high-level cryosystem control program. It’s responsible for interacting with the user interface, servicing requests from the connected clients, and managing 3 dispense processes.

The main program include a few helper functions, and data structures that organize the program flow more efficiently.

The enumerated type, us_state_code, define the ui state values used in the ui state machine. Different tasks are performed in different ui states.

The enumerated type, dp_stage_code, is used for the submodule state machine inside the ui state machine. It is used to differentiate the different display pages within each ui state.

The enumerated type, display_code, is used for the display pipeline. The enumerated values specify the nature of the display messages and define how the passed arguments should be interpreted when display messages are sent to the lcd modules.

The enumerated type, alarm_code, is used for the staion 2 timer alarm state machine.

The data structure, display_pipeline, contain buffers for display_code, and the indices to refernece the display_code. It manages the order of the display messages, and process them at the end of each main work loop, so to avoid holding down the sequential dat processing performance of the work loop, where time-critical processes may require that the non time-critical tasks such as lcd displays be postponed.

The helper functions are described below:

Check_user determines if the ID passed to it is present in the user ID list. It also identifies the admin ID.

It reads the user IDs from the sdram buffer sequentially from the beginning of the file, and compare each one to the passed ID. As soon as a matched ID is found, the function returns true, otherwise it returns false when all user IDs are read and no matched ID is found.

Approx_temp calculates the approximated temperature given the raw rtd data, and write that into a character stream buffer.

The approximation is done using a 7-step linear model: the rtd value range is divided into 7 ranges, where each range gets a different linear transformation. Out of range values are deemed invalid values.

The computed values are then written into a character stream buffer. The number of characters for that stream is returned to the caller.

Note that a more accurate polynomial transformation can be done in the client software to obtain a more realistic temperature measurement interpretation from the raw rtd values. Refer to rtd characteristics curves for more information. Also note that rtd data is predicted to take the value by the following:

Rtd value = resistance of sensor * 10737482 / 100ohm

To specify the rtd parameters, the rtd values are used instead of the temperature reading. Refer to the resistance table.

Service_rtd reads the raw dispense process update data from ram buffers, interpret the messages, and update the display pipleine and rtd profile data buffers.

It reads available rtd raw data, and if profile update required and sufficient space is available, save the rtd raw data into the sdram buffer. Then it decodes the raw data message, and update the corresponding message buffers and temp/time variables.

Note that multiple instances of temp/time updates may be present in a single call, and the temp/time variables are just overwritten. After all raw dat are read, the temp/time display messages are updated at once if any new values are received.

Add_display_pipeleine add a new instance of display message to the display pipeline structure. It adjusts the semaphores and the cyclic buffer indices accordingly.

Process_display_pipeline reads the display pipeline structure, and process each display message sequentially.

Depending on the message type, it may incorporate arbitrary texts from the display buffer passed to it. A typical display message contains:

Adjust cursor position to proper location Send the message of full 20 character length (overwriting any previoud

message in the lcd module on that line) Optionally adjsut cursor position Optionally send out an arbitrary text from the display buffer

The main control algorithm is explained in detials below:

The main function consists of the initialization part and the infinite work loop. All modules and variables are initialized, then the program enters the work loop to continously service requests from users.

The initialization part starts by reseting the display pipe strucature, followed by: Get transaction files in ram by loading parameters, user lists, and billing

records from fram storage. In debug mdoe, it can also force a clean record by passing load_default true to these function calls.

Initialize hardware modules including timer, dispense parameter bus, card-reader channel, rtd fifo channels, keypad module, rtcc module, and wiznet module.

Clear all state variables for rtd 1, 2, and 3. For each rtd station, also issue clear lcd screen command, followed by setting the lcd_clear timer session.

Reset all semaphores and state variables for ui and netword request state machines, etc.

Then the main program enters the work loop which should be repeated frequently (less than a few milisecond) under normal program flow. Debugging is tricky as certain portion of the code is not designed to be halted during operation, and will not yield expected results if halted.

The mayor sections of tasks in the work loop body are explained below:

Key_peripheral

Check_key is called to read a key press from the keypad. It is noted that in order to avoid missing a key press, the work loop should be repeated at least every 100 msec.

Rtcc_peripheral

The system time structure is updated by a call to rtcc_get. It is important that the slow I2C transaction completes without error (rtcc module works) to avoid long delays from the opencores I2C driver, which mess up the system timing significantly.

Card_reader_peripheral

The card-reader semaphore is checked to determine if any new card information is available. If yes, then the card ID is read, and the card_arrived semaphore is set; otherwise card-arrived is reset.

Session status OP4

If semaphores indicates that any one of the 3 stations are running, then Op4 is driven high to light up the LED in the stop push buttonl otherwise OP4 is reset to turn off the LED.

Operate speaker

The state variable, alarm_state, is init to alarm_disabled, and set to alarm_ready when station 2 dispense process is started.

The state machine first checks that station 2 is running, then decode the state variable to advance states with the following taskes:

Alram_ready: keep current time and advance to alarm_armed state for timing alarms

Alarm_armed: reset the alarm start time is a key press is detected; otherwise check if alarm time is passed, if so, turn on speaker , keep current time for timeout timing and advance to alarm_sound state

Alarm_sound: turn off speaker, get new time for timing alarms and return to alarm_armed state if a key press is detected; otherwise check if alarm timout time is passed, if so, turn off speaker, stop station 2 process and return idle state.

Run ui

This state machine determines tasks to be taken in different stage of the UI (composed of LCD screens, keypad, card_reader, and the underlying dispense processes).

A second state machine is embedded in each ui state to determine the exact display page the lcd screen is showing to help transition through muliple pages of the Ui menu.

Each ui state is described below:

Por_init

This is the initial state from power on reset. On power on reset, all 3 lcd modules are issued an lcd_clear command, and interval timer started timing the lcd_clear delay.

The state machine stays in this state until the lcd_clear delay has passed, then idle messages are sent to each lcd module, and the display backlights are turned down by the go_sleep message.

State machine exits this state to enter idle state.

Idle

The idle state sits idle while looking for key presses 1, 2, or 3 to carry on UI with one of the 3 lcd modules as output device.

When one of the displays is selected, the wake_up message turns the backlight up for the specified lcd module.

state machine exits this state to enter station_authen state.

Station_authen

This state services authentication for user’s ID by reading the card reader data.

Key presses are decoded to select admin netwrk config menu, exit to staion_cleanup state, or exit to station_alt_authen state.

If card data is available, then card ID is checked and admin status, station idle vairable, and billing record space are also checked, in order to determine if access to dispnese process is granted.

If admin request is passed (both admin key has been pressed, and card ID is admin ID), then state machine exits to admin_util state.

If user ID is matched, and given other conditions are also met, then state machine advances to station_user state.

Station_alt_authen

This state serves the same function as station_authen except that it reads user ID from the keypad instead of the card reader.

The keypad entry follows the dp state machine flow as follows: Dp_init: lcd module is cleared and timer started timing lcd_clear delay Dp1: after lcd_clear delay, al_authen_ui display message is added to display

pipeline, and input ID number is reset to default zero. Dp2: keycode is decoded to perform backspace, escape, confirm, or actual

ID input number. for ID input number, the key press is debounced, and with each additional digit, the entire number is added to the display pipeline to show to the user the number they have inputed.

Dp_end: the input number is split into the two iclass numbers for facility and user ID.decisions are made based on the matched user ID, admin selection, and other operation conditions to advance ui state to admin_util or station_user, or no change (which can be exited in Dp2 by pressing escape).

Station_cleanup

This state is the intermediate state to clean up the lcd display before sending the current display back to sleep by turning down the backlight.

First lcd screen is cleared, then specific display messages are added to display pipeline before sending the sleep message.

Admin_util

This state allows the administrator to change the wiznet parameters and to reset to ethernet controller. This display states are as follows:

Dp_init: lcd is cleared and lcd_delay timed. Dp1: depending on param_index, the corresponding wiznet parameter is

displayed. Dp2: key presses are decoded to escape, confirm or accept number entry.

Both escape and confirm advance param_index to move on to the next parameter. Number key presses are debounced and new numbers are displayed.

Dp_end: after all six parameters are scrolled through, depending on if any paramter is changed (confirm is pressed), the new parameters are stored to fram and wiznot module is reconfigured.

Station_user

This state regosters user’s data and starts the dispense processes. Eahc dp state is described below:

Dp_init: lcd screen is cleared and delay timed. Dp1: after lcd_clear delay, if station 3 selected (purge), go to dp_end, else

full_ui message is added to display pipeline, and state advances to dp2. Dp2: key presses are decoded to backspace, escape, confirm or accpet

number keypresses to enter volume amount. Number keys are debounced and new numbers are displayed as new digits are added.

Dp_end: depending on the station selected and whether any stations are running, combinations of station 1, 2, and 3 are started.

Station 3 is started if specified or no station is running. Billing records are registered in temporary buffer and start_assert is acknowleged.

Station 1 is started if specified. Billing records are registered in temporary buffer and start_assert is acknowleged.

Station 2 is started if either station 1 or station 3 is already running, with billing record registered and start_assert asserted and alarm state set to ready. If not, then wait flag is set AND start_assert is not set (note that in this case, station 3 must be started at this time).

The run ui tasks run continously, and independent of the other tasks, only connected through semaphores and loacal state variables.

It is important to note that each iteration of the work loop works on only one task outlined under the dp state under each ui state.

Update station123 status

Information from each rtd fifo update is processed and saved or updated to lcd display module.

When new rtd data is available, decision is made based on whether a client’s request to retrieve profile data is false, and if enough profile data space is available, to enable rtd profile record.

Then service_rtd is called to update lcd message and optionally save profile data. Then start_assert is reset to acknowledge that cryosystem_interface confirmed that the dispense process actually starts.

If service_rtd returns true, then the dispense process is stopped. Then status variables are reset, and number of profile data entries is logged if enabled. By this time, the associated record data is written to fram on the next available record entry space.

If staion 3 is stopped and wait flag for station 2 is set, then station 2 is started at this point, along with start_assert and alarm_state set to alarm_ready, while wait flag is reset.

However, if no rtd data is available and the station is not idle (indicates that start command is issued) and start_assert is not ack’ed (star message not received from RTL), then station_inhibit is triggered and operation cancelled. This is probably because system alarm in electrical section is tripped or the emergency stop push button is held down.

Update display

Process_display_pipeline is called to send buffered display messages to the designated lcd modules.

Process client request

Wiz_work is called to identify incoming connections from clients and service requests by reading data or compleing writing data, etc.

Sock 0 accepts user list updates

When data is available from sock0 buffer space, a special code is compared against the first data to determine if incoming data requests an update to the user list. If so, then the number of data entries is read right after the previous data.

When update_user is registered true, for each work loop, the incoming data is moved to the user list buffer in sdram space.

When all entries are read, a confirmation message is sent back to the client and the new user list is saved to fram.

Sock 1 accepts bill record requests

When data is available from sock1 buffer space, a special code is compared against the first data to determine if incoming data requests the current billing records. If so, then a bill record packet is started by writing a special code and number of data entries. And if another special code is detected from the incoming data outside of a bill record request, then reclaim_record_space is called to delete the old records.

When query_bill is registered true, for each work loop, the sdram transmit buffer is filled by the record2sdram function call to continously fill up the transmit buffer with remaining record data until all records are sent.

Sock 2 accepts rtd temperature profile requests

When data becomes avaialable from sock2, the special code is read to determine if a valid profile data request is received, and if so, depending on the availability of the profile data, special codes are sent to signal requested rtd data coming, zero records, or denied access. Otherwise, an alternative code from the client signals that the controller give up the old profile data.

When query_profile is registered true, remaining profile records in sdram rtd record space are copied to the sdram sock2 transmit buffer space for writing out to wiznet until all data are transferred.

Sock3 accepts controller parameter updates

When data becomes available from sock3 read buffer, a special code is decoded to determine if a valid parameter update request is received from the client. If so, update_parameter variable is set.

While update_parameter is registered true, the program skips each time work loop comes around if insufficient data is received (incomplete parameter data strucure).

After full update parameters become available in sdram receive buffer, all rtd parameters are updated, along with the time information updates. Then a confirmation code is sent back to the client.

The parameters are stored in fram, and the new_parameter flag is set.

Update dispense parameters

When new parameters are present and all stations become idle, the new parameters are downloaded to RTL section by calling param_init.

The server software section is fully described. For implementation details, refer to the source code. For detialed sequence of operation for the cryosystem and the UI, refer to the operator’s manual.

The standard interface details and data structures the clients are required to abide in order to conduct succesful communication with the server are discussed in details in Client Software section.

Also note that the wiznet module is reset every 10 minutes if no pending transactions are running. This is done in the hope to clear ocassional wiznet module hang on the network.