RRM 3-14 Array Subroutine - Revision history

TimMooney: EFLG actually defaults to "ON CHANGE", not to "ALWAYS"

2013-03-12T22:54:45Z

EFLG actually defaults to "ON CHANGE", not to "ALWAYS"

← Older revision		Revision as of 22:54, 12 March 2013
Line 22:		Line 22:
	<tr><td>OVAL<td>LONG<td>No<td>0<td>Yes<td>Yes<td>No<td>No		<tr><td>OVAL<td>LONG<td>No<td>0<td>Yes<td>Yes<td>No<td>No
	<tr><td>LFLG<td>MENU(IGNORE, READ)<td>Yes<td>IGNORE<td>Yes<td>Yes<td>No<td>No		<tr><td>LFLG<td>MENU(IGNORE, READ)<td>Yes<td>IGNORE<td>Yes<td>Yes<td>No<td>No
	<tr><td>EFLG<td>MENU(NEVER, ON CHANGE, ALWAYS)<td>Yes<td>~~ALWAYS~~<td>Yes<td>Yes<td>No<td>No		<tr><td>EFLG<td>MENU(NEVER, ON CHANGE, ALWAYS)<td>Yes<td>ON CHANGE<td>Yes<td>Yes<td>No<td>No
	<tr><td>SUBL<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No		<tr><td>SUBL<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
	<tr><td>INAM<td>STRING<td>Yes<td>Null<td>Yes<td>No<td>No<td>No		<tr><td>INAM<td>STRING<td>Yes<td>Null<td>Yes<td>No<td>No<td>No

LewisMuir: Correct border attribute on tables

2012-10-18T19:48:02Z

Correct border attribute on tables

← Older revision		Revision as of 19:48, 18 October 2012
Line 17:		Line 17:

	== Field Summary ==		== Field Summary ==
	<table border>		<table border="1">
	<th>Field<th>Type<th>DCT<th>Initial<th>Access<th>Modify<th>Rec Proc Monitor<th>PP		<th>Field<th>Type<th>DCT<th>Initial<th>Access<th>Modify<th>Rec Proc Monitor<th>PP
	<tr><td>VAL<td>LONG<td>No<td>0<td>Yes<td>Yes<td>Yes<td>No		<tr><td>VAL<td>LONG<td>No<td>0<td>Yes<td>Yes<td>Yes<td>No
Line 89:		Line 89:
	== Field Descriptions ==		== Field Descriptions ==

	<table border>		<table border="1">
	<th>Name<th>Summary<th>Description		<th>Name<th>Summary<th>Description

AndrewJohnson: Simplify registry code

2012-04-17T15:38:08Z

Simplify registry code

← Older revision		Revision as of 15:38, 17 April 2012
Line 239:		Line 239:

	== Use of the aSub Record ==		== Use of the aSub Record ==
	The aSub record has input-value fields (A-U) and output-value fields (VALA-VALU)~~. The record makes no association between the fields A and VALA~~, ~~etc~~. The input-value fields have associated input links (INPA-INPU), and the output-value fields have associated output links (OUTA-OUTU). Both inputs and outputs have type fields (FTA-FTU, FTVA-FTVU, which default to 'DOUBLE') and number-of-element fields (NOA-NOU, NOVA-NOVU, which default to '1'). The output links OUTA-OUTU will only be processed if the subroutine returns a zero (OK) status value.
			The aSub record has input-value fields (A-U) and output-value fields (VALA-VALU), which are completely independent. The input-value fields have associated input links (INPA-INPU), and the output-value fields have associated output links (OUTA-OUTU). Both inputs and outputs have type fields (FTA-FTU, FTVA-FTVU, which default to 'DOUBLE') and number-of-element fields (NOA-NOU, NOVA-NOVU, which default to '1'). The output links OUTA-OUTU will only be processed if the subroutine returns a zero (OK) status value.

	=== Example database fragment ===		=== Example database fragment ===

	To use the A field to read an array from some other record, then, you would need a database fragment that might look something like this:		To use the A field to read an array from some other record, then, you would need a database fragment that might look something like this:

Line 268:		Line 270:
	}		}
	...		...
	return 0;		return 0; /* process output links */
	}		}

	Note that the subroutine code must always handle value fields (A-U, VALA-VALU) as arrays, even if they contain only a single element.		Note that the subroutine code must always handle the value fields (A-U, VALA-VALU) as arrays, even if they contain only a single element.

	=== Required export code ===		=== Required export code ===
	Aside from your own code, you must ~~include something like~~ the ~~following along with your subroutine code~~. ~~This tells EPICS how to handle references to your subroutine~~:
			Aside from your own code, you must export and register your subroutines so the record can locate them. The simplest way is as follows:

	#include <registryFunction.h>		#include <registryFunction.h>
	#include <epicsExport.h>		#include <epicsExport.h>

	static ~~registryFunctionRef my_asub_Ref[] = {~~		static long my_asub_routine(aSubRecord *prec) {
	{"my_asub_routine~~", (REGISTRYFUNCTION) my_asub_routine}~~		...
	};

	~~static void my_asub_Registrar~~(~~void~~) {
	~~registryFunctionRefAdd(my_asub_Ref, NELEMENTS(my_asub_Ref));~~
	}		}
			epicsRegisterFunction(my_asub_routine);
	~~epicsExportRegistrar~~(~~my_asub_Registrar~~);

	=== Required database-definition code ===		=== Required database-definition code ===

	The .dbd file loaded ~~into~~ the ioc must contain ~~something like~~ the following, ~~so EPICS can find~~ the ~~subroutine~~:		The .dbd file loaded by the ioc must then contain the following line, which tells the linker to include your object file in the IOC binary:

	~~registrar~~(~~my_asub_Registrar~~)		function(my_asub_routine)

	=== Device support, writing to hardware ===		=== Device support, writing to hardware ===
Line 300:		Line 298:

	=== Dynamically Changing the User Routine called during Record Processing ===		=== Dynamically Changing the User Routine called during Record Processing ===
	The aSub record allows the user to dynamically change which routine is called
	when the record processes. This can be done in two ways:		The aSub record allows the user to dynamically change which routine is called when the record processes. This can be done in two ways:

	* The LFLG field can be set to READ so that the name of the routine is read from the SUBL link. Thus, whatever is feeding this link can change the name of the routine before the aSub record is processed. In this case, the record looks in the symbol table for the symbol name whenever the name of routine fetched from the link changes.		* The LFLG field can be set to READ so that the name of the routine is read from the SUBL link. Thus, whatever is feeding this link can change the name of the routine before the aSub record is processed. In this case, the record looks in the symbol table for the symbol name whenever the name of routine fetched from the link changes.
	* The LFLG field can be set to IGNORE. In this case, the routine called during record processing is that specified in the SNAM field. Under these conditions, the SNAM field can be changed by a Channel Access write to that field. During development when trying several versions of the routine, it is not necessary to reboot the IOC and reload the database. A new routine can be loaded with the vxWorks ld command, and Channel Access or the dbpf command used to put the name of the routine into the record's SNAM field. The record will look up the symbol name in the symbol table whenever the SNAM field gets modified. The same routine name can even be used as the vxWorks symbol lookup returns the latest version of the code to have been loaded.		* The LFLG field can be set to IGNORE. In this case, the routine called during record processing is that specified in the SNAM field. Under these conditions, the SNAM field can be changed by a Channel Access write to that field. During development when trying several versions of the routine, it is not necessary to reboot the IOC and reload the database. A new routine can be loaded with the vxWorks ld command, and Channel Access or the dbpf command used to put the name of the routine into the record's SNAM field. The record will look up the symbol name in the symbol table whenever the SNAM field gets modified. The same routine name can even be used as the vxWorks symbol lookup returns the latest version of the code to have been loaded.

BruceHill: Added link back to RRM home page

2011-09-21T03:25:20Z

Added link back to RRM home page

← Older revision		Revision as of 03:25, 21 September 2011
Line 1:		Line 1:
			[[RRM 3-14\|EPICS Record Reference Manual]]


	= aSub - Array Subroutine =		= aSub - Array Subroutine =

	The aSub record is a variant of the 'sub' (subroutine) record with array~~-valued~~		The aSub record is a variant of the 'sub' (subroutine) record with array or scalar
	input and output fields, whose types are user specifiable at database-configure time, and associated input and output links.		input and output fields, whose types are user specifiable at database-configure time, and associated input and output links.

AndrewJohnson: Explain how the return status is used

2011-09-17T03:19:43Z

Explain how the return status is used

← Older revision		Revision as of 03:19, 17 September 2011
Line 11:		Line 11:
	Never, Always or just when any element of an array changes value.		Never, Always or just when any element of an array changes value.

	The VAL field holds the value returned from the routine called during record processing.		The VAL field holds the value returned from the routine called during record processing, which is a status value that controls whether the output links are used or not.

	== Field Summary ==		== Field Summary ==
Line 89:		Line 89:
	<th>Name<th>Summary<th>Description		<th>Name<th>Summary<th>Description

	<tr><td>VAL<td>Value returned from process routine<td>This field holds the value returned from the user defined		<tr><td>VAL<td>Value returned from process routine<td>This field holds the value returned from the user defined process routine, which must be zero for the output links OUTA...OUTU to be processed.
	process routine.

	<tr><td>OVAL<td>Old VAL<td>Previous VAL, used to decide when to post events.		<tr><td>OVAL<td>Old VAL<td>Previous VAL, used to decide when to post events.
Line 188:		Line 187:
	* If the SNAM routine set PACT to TRUE, then return. In this case, we presume the routine has arranged that process will be called at some later time for asynchronous completion.		* If the SNAM routine set PACT to TRUE, then return. In this case, we presume the routine has arranged that process will be called at some later time for asynchronous completion.
	* Set PACT to TRUE.		* Set PACT to TRUE.
	* ~~Write~~ the output values using the output links.		* If VAL is zero, write the output values using the output links.
	* Get the time of processing and put it into the timestamp field.		* Get the time of processing and put it into the timestamp field.
	* If VAL has changed, post a change-of value and log event for this field. If EFLG is set to ALWAYS, post change-of-value and log events for every output field. If EFLG is set to ON CHANGE, post change-of-value and log events for every output field which has changed. In the case of an array, an event will be posted if any single element of the array has changed. If EFLG is set to NEVER, no change-of-value or log events are posted for the output fields.		* If VAL has changed, post a change-of value and log event for this field. If EFLG is set to ALWAYS, post change-of-value and log events for every output field. If EFLG is set to ON CHANGE, post change-of-value and log events for every output field which has changed. In the case of an array, an event will be posted if any single element of the array has changed. If EFLG is set to NEVER, no change-of-value or log events are posted for the output fields.
Line 196:		Line 195:
	Asynchronous-completion processing:		Asynchronous-completion processing:

	* Call the routine specified by SNAM.		* Call the routine specified by SNAM (again).
	* Set VAL equal to the return value from the routine specified by SNAM.		* Set VAL equal to the return value from the routine specified by SNAM.
	* Set PACT to TRUE.		* Set PACT to TRUE.
	* ~~Write~~ the output values using the output links.		* If VAL is zero, write the output values using the output links.
	* Get the time of processing and put it into the timestamp field.		* Get the time of processing and put it into the timestamp field.
	* If VAL has changed, post a change-of value and log event for this field. If EFLG is set to ALWAYS, post change-of-value and log events for every output field. If EFLG is set to ON CHANGE, post change-of-value and log events for every output field which has changed. In the case of an array, an event will be posted if any single element of the array has changed. If EFLG is set to NEVER, no change-of-value or log events are posted for the output fields.		* If VAL has changed, post a change-of value and log event for this field. If EFLG is set to ALWAYS, post change-of-value and log events for every output field. If EFLG is set to ON CHANGE, post change-of-value and log events for every output field which has changed. In the case of an array, an event will be posted if any single element of the array has changed. If EFLG is set to NEVER, no change-of-value or log events are posted for the output fields.
	* Process the record on the end of the forward link, if one exists.		* Process the record on the end of the forward link, if one exists.
	* Set PACT to FALSE.		* Set PACT to FALSE.

	~~=== get_value ===~~
	~~Fills in the values of struct valueDes so that they refer to VAL.~~

	=== get_precision ===		=== get_precision ===
Line 240:		Line 236:

	== Use of the aSub Record ==		== Use of the aSub Record ==
	The aSub record has input-value fields (A-U) and output-value fields (VALA-VALU). ~~There is~~ no association between A and VALA, etc. The input-value fields have associated input links (INPA-INPU), and the output-value fields have associated output links (OUTA-OUTU). Both inputs and outputs have type fields (FTA-FTU, FTVA-FTVU, which default to 'DOUBLE') and number-of-element fields (NOA-NOU, NOVA-NOVU, which default to '1').		The aSub record has input-value fields (A-U) and output-value fields (VALA-VALU). The record makes no association between the fields A and VALA, etc. The input-value fields have associated input links (INPA-INPU), and the output-value fields have associated output links (OUTA-OUTU). Both inputs and outputs have type fields (FTA-FTU, FTVA-FTVU, which default to 'DOUBLE') and number-of-element fields (NOA-NOU, NOVA-NOVU, which default to '1'). The output links OUTA-OUTU will only be processed if the subroutine returns a zero (OK) status value.

	=== Example database fragment ===		=== Example database fragment ===
Line 269:		Line 265:
	}		}
	...		...
	return(0)		return 0;
	}		}

	Note that the subroutine must always ~~treat~~ value fields (A-U, VALA-VALU) as arrays, even if they contain only a single element.		Note that the subroutine code must always handle value fields (A-U, VALA-VALU) as arrays, even if they contain only a single element.

	=== Required export code ===		=== Required export code ===
Line 298:		Line 294:
	=== Device support, writing to hardware ===		=== Device support, writing to hardware ===

	~~Note, by the way, that the~~ aSub record does not ~~talk to~~ device support. If you want to write to hardware, you might use your output fields and links to write to some other record that can write to hardware.		The aSub record does not call any device support routines. If you want to write to hardware, you might use your output fields and links to write to some other record that can write to hardware.

	=== Dynamically Changing the User Routine called during Record Processing ===		=== Dynamically Changing the User Routine called during Record Processing ===
Line 304:		Line 300:
	when the record processes. This can be done in two ways:		when the record processes. This can be done in two ways:

	* The LFLG field can be set to READ so that the name of the routine is read from the SUBL link. Thus, whatever is feeding this link can change the name of the routine before the aSub record is processed. In this case, the record looks in the symbol table for the symbol name whenever the name of routine fetched from the link changes.		* The LFLG field can be set to READ so that the name of the routine is read from the SUBL link. Thus, whatever is feeding this link can change the name of the routine before the aSub record is processed. In this case, the record looks in the symbol table for the symbol name whenever the name of routine fetched from the link changes.
	* The LFLG field can be set to IGNORE. In this case, the routine called during record processing is that specified in the SNAM field. Under these conditions, the SNAM field can be changed by a Channel Access write to that field. ~~Thus, during~~ development ~~work,~~ when ~~it is often required to run a modified version~~ of the routine, it ~~will no longer be a requirement~~ to reboot the IOC and reload the database. A new routine ~~will~~ be ~~called during record processing if the routine is~~ loaded with the vxWorks ld command, and ~~cau is~~ used to put the name of the routine into the record's SNAM field. ~~After the SNAM field has been changed, the~~ record ~~automatically looks~~ up the symbol name in the symbol table. ~~Note that, if the~~ same routine name is used~~, this is not a problem. The record finds~~ the latest version of the code ~~which has~~ been loaded~~. Obviously, one needs to take care of the amount of memory used in the system, if the vxWorks unld command is never used~~.		* The LFLG field can be set to IGNORE. In this case, the routine called during record processing is that specified in the SNAM field. Under these conditions, the SNAM field can be changed by a Channel Access write to that field. During development when trying several versions of the routine, it is not necessary to reboot the IOC and reload the database. A new routine can be loaded with the vxWorks ld command, and Channel Access or the dbpf command used to put the name of the routine into the record's SNAM field. The record will look up the symbol name in the symbol table whenever the SNAM field gets modified. The same routine name can even be used as the vxWorks symbol lookup returns the latest version of the code to have been loaded.

TimMooney: /* Field Descriptions */

2010-12-03T18:15:06Z

Field Descriptions

← Older revision		Revision as of 18:15, 3 December 2010
Line 123:		Line 123:

	<tr><td>FTA,..., FTU<td>Field Type of A Field Type of U		<tr><td>FTA,..., FTU<td>Field Type of A Field Type of U
	<td>Field types of the input values. These can be CHAR, ~~STRING~~, ~~DOUBLE~~, LONG, ~~etc~~.		<td>Field types of the input values. These can be any of the following:
			"STRING","CHAR","UCHAR","SHORT","USHORT","LONG","ULONG","FLOAT","DOUBLE, "ENUM".


	<tr><td>NOA..., NOU<td>Max elements in A,.. Max elements in U		<tr><td>NOA..., NOU<td>Max elements in A,.. Max elements in U

AndrewJohnson: Remove some non-existant fields, improve other descriptions.

2010-04-14T17:33:40Z

Remove some non-existant fields, improve other descriptions.

Show changes

TimMooney: /* Device support, writing to hardware */

2009-09-10T21:47:31Z

Device support, writing to hardware

← Older revision		Revision as of 21:47, 10 September 2009
Line 325:		Line 325:
	=== Device support, writing to hardware ===		=== Device support, writing to hardware ===

	Note, by the way, that he aSub record does not talk to device support. If you want to write to hardware, you might use your output fields and links to write to some other record that can write to hardware.		Note, by the way, that the aSub record does not talk to device support. If you want to write to hardware, you might use your output fields and links to write to some other record that can write to hardware.

	=== Dynamically Changing the User Routine called during Record Processing ===		=== Dynamically Changing the User Routine called during Record Processing ===

TimMooney: /* Field Summary */

2009-09-10T21:40:59Z

Field Summary

TimMooney: /* Dynamically Changing the User Routine called during Record Processing */

2009-09-10T21:36:55Z

Dynamically Changing the User Routine called during Record Processing

← Older revision		Revision as of 21:36, 10 September 2009
Line 315:		Line 315:
	Note, by the way, that he aSub record does not talk to device support. If you want to write to hardware, you might use your output fields and links to write to some other record that can write to hardware.		Note, by the way, that he aSub record does not talk to device support. If you want to write to hardware, you might use your output fields and links to write to some other record that can write to hardware.

	== Dynamically Changing the User Routine called during Record Processing ==		=== Dynamically Changing the User Routine called during Record Processing ===
	The aSub record allows the user to dynamically change which routine is called		The aSub record allows the user to dynamically change which routine is called
	when the record processes. This can be done in two ways:		when the record processes. This can be done in two ways:

← Older revision		Revision as of 21:40, 10 September 2009
Line 29:		Line 29:
	<tr><td>BRSV<td>MENU<td>Yes<td>0<td>Yes<td>Yes<td>No<td>Yes		<tr><td>BRSV<td>MENU<td>Yes<td>0<td>Yes<td>Yes<td>No<td>Yes
	<tr><td>PREC<td>SHORT<td>Yes<td>0<td>Yes<td>Yes<td>No<td>No		<tr><td>PREC<td>SHORT<td>Yes<td>0<td>Yes<td>Yes<td>No<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>INPA<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No		<tr><td>INPA<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
	<tr><td>INPB<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No		<tr><td>INPB<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>INPU<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No		<tr><td>INPU<td>INLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>A<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>No<td>No		<tr><td>A<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>No<td>No
	<tr><td>B<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>No<td>No		<tr><td>B<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>No<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>U<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>No<td>No		<tr><td>U<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>No<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>FTA<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No		<tr><td>FTA<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
	<tr><td>FTB<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No		<tr><td>FTB<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>FTU<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No		<tr><td>FTU<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>NOA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NOA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
	<tr><td>NOB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NOB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>NOU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NOU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>NEA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NEA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
	<tr><td>NEB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NEB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>NEU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NEU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>NEVA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NEVA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
	<tr><td>NEVB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NEVB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>NEVU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NEVU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>OUTA<td>OUTLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No		<tr><td>OUTA<td>OUTLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
	<tr><td>OUTB<td>OUTLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No		<tr><td>OUTB<td>OUTLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>OUTU<td>OUTLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No		<tr><td>OUTU<td>OUTLINK<td>Yes<td>0<td>No<td>No<td>NA<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>VALA<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>Yes<td>No		<tr><td>VALA<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>Yes<td>No
	<tr><td>VALB<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>Yes<td>No		<tr><td>VALB<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>Yes<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>VALU<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>Yes<td>No		<tr><td>VALU<td>NOACCESS<td>No<td>0<td>No<td>Yes<td>Yes<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>OVLA<td>NOACCESS<td>No<td>0<td>No<td>No<td>No<td>No		<tr><td>OVLA<td>NOACCESS<td>No<td>0<td>No<td>No<td>No<td>No
	<tr><td>OVLB<td>NOACCESS<td>No<td>0<td>No<td>No<td>No<td>No		<tr><td>OVLB<td>NOACCESS<td>No<td>0<td>No<td>No<td>No<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>OVLU<td>NOACCESS<td>No<td>0<td>No<td>No<td>No<td>No		<tr><td>OVLU<td>NOACCESS<td>No<td>0<td>No<td>No<td>No<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>FTVA<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No		<tr><td>FTVA<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
	<tr><td>FTVB<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No		<tr><td>FTVB<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>FTVU<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No		<tr><td>FTVU<td>MENU<td>Yes<td>DOUBLE<td>Yes<td>No<td>No<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>NOVA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NOVA<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
	<tr><td>NOVB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NOVB<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
	<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...		<tr><td>...<td>...<td>...<td>...<td>...<td>...<td>...<td>...
	<tr><td>NOVU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No		<tr><td>NOVU<td>ULONG<td>Yes<td>1<td>Yes<td>No<td>No<td>No
			<tr><td><td><td><td><td><td><td><td>
	<tr><td>TOVA<td>ULONG<td>Yes<td>0<td>Yes<td>No<td>No<td>No		<tr><td>TOVA<td>ULONG<td>Yes<td>0<td>Yes<td>No<td>No<td>No
	<tr><td>TOVB<td>ULONG<td>Yes<td>0<td>Yes<td>No<td>No<td>No		<tr><td>TOVB<td>ULONG<td>Yes<td>0<td>Yes<td>No<td>No<td>No