Argument processing is done using Unix long argument syntax.
The values of all of the parameters listed here (whether or not they were supplied on the command line) are printed on stderr when the program starts.
Either the --local or the --remote argument must be supplied.
If this argument is not supplied the default is "localhost".
The DBMAN_HOST environment variable is used if present.
The default is "DUTEC".
If this is not supplied it defaults to 0.
If this is not supplied it defaults to 63.
It’s used to enable printing of various IOTRANS lists when the program is started with the --show_tbl argument.
The value is in hex and each bit controls the printing of one list. If the bit isn’t set then the pointer to the head of the list is printed. This is a quick check to see if there is an IOTRANS list for a particular function for a motherboard.
0x0000 - default value
0x0001 - conf list
0x0002 - analog control list
0x0004 - status control list
0x0008 - analog read list
0x0010 - status read list
0x0020 - watchdog list
0x0040 - watchdog virtual list
0x0100 - fast analog read list
0x0200 - fast status read list
If this argument has the value all I/O configuration transactions will be logged whenever the binary data value changes.
If this argument has the value all I/O analog control transactions will be logged whenever the binary data value changes.
If this argument has the value all I/O analog read transactions will be logged whenever the binary data value changes.
If this argument has the value all I/O status control transactions will be logged whenever the binary data value changes.
If this argument has the value all I/O status read transactions will be logged whenever the binary data value changes.
If this argument has the value all I/O status read transactions will be logged whenever the binary data value changes.
If this argument has the value all I/O analog fast loop read transactions will be logged whenever the binary data value changes.
If this argument has the value all I/O status fast loop read transactions will be logged whenever the binary data value changes.
This has limits because it appears the dutec system doesn’t support querying for input configuration so the only thing you can get is the output configuration info.
The value is in uS and defaults to 20000 i.e. 20 mS if not overridden by this argument.
If the value is set to zero no delay is added.
In all cases C is used to select the Dutec motherboard number.
One entry of this type and an entry of DUanInp type is required in the AccelNET database for each analog channel used.
All channels which are configured as analog inputs must have their corresponding bit set in this word to enable them to operate.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
One entry of this type and an entry of DUanOut type is required in the AccelNET database for each analog channel used.
All channels which are configured as analog outputs must have their corresponding bit set in this word to enable them to operate.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
Digital inputs require an entry of this type and one entry of DUdiInp type is required in the AccelNET database.
All channels which are configured as digital inputs should have their corresponding bit set in this word to enable them to operate.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
Digital outputs require an entry of this type and one entry of DUdiOut type is required in the AccelNET database.
All channels which are configured as digital outputs should have their corresponding bit set in this word to enable them to operate.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
Dutec extended Digital Input Configuration
Extended Digital inputs require an entry of this type and one entry of DUdiInpE type is required in the AccelNET database.
All channels which are configured as extended digital inputs should have their corresponding bit set in this word to enable them to operate.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
Dutec extended Digital Output Configuration
Extended Digital outputs require an entry of this type and one entry of DUdiOutE type is required in the AccelNET database.
All channels which are configured as extended digital outputs should have their corresponding bit set in this word to enable them to operate.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
Dutec Analog input word
Each configured analog input channel requires an entry of this type and a single entry of DUanInpC in the AccelNET database.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field is used to select the module number. The valid range is 0-15.
Each configured analog output channel requires an entry of this type and a single entry of DUanOutC in the AccelNET database.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field is used to select the module number. The valid range is 0-15.
Digital inputs all share a common word. The bit offset in the word corresponds to channel number in the motherboard.
One entry of this type and one entry of DUdiInpC type is required in the AccelNET database if digital inputs are used.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
Dutec Digital output word
Digital outputs all share a common word. The bit offset in the word corresponds to channel number in the motherboard.
One entry of this type and one entry of DUdiOutC type is required in the AccelNET database if digital outputs are used.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
Dutec extended Digital input word
Extended Digital inputs all share a common word. The bit offset in the word corresponds to channel number in the motherboard.
One entry of this type and one entry of DUdiInCE type is required in the AccelNET database if extended digital inputs are used.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
WARNING: If this field is present in the database and there is NOT an extended motherboard connected to the main motherboard I/O to the main motherboard will fail. This is because the configuration I/O to the motherboard times out and DUtask declares I/O to the motherboard dead and removes the motherboard from the I/O list(s).
The problem may be corrected by setting the I/O mask for this record to zero. This prevents DUtask from running the configuration I/O.
NOTE: 3/4/2009 - The warning given above may or may not still be true. Over the years we’ve run this on many different versions of the dutec firmware. It’s hard to say what’s what anymore.
Dutec extended Digital output word
Extended Digital outputs all share a common word. The bit offset in the word corresponds to channel number in the motherboard.
One entry of this type and one entry of DUdiOutC type is required in the AccelNET database if digital extended outputs are used.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
WARNING: If this field is present in the database and there is NOT an extended motherboard connected to the main motherboard I/O to the main motherboard will fail. This is because the configuration I/O to the motherboard times out and DUtask declares I/O to the motherboard dead and removes the motherboard from the I/O list(s).
The problem may be corrected by setting the I/O mask for this record to zero. This prevents DUtask from running the configuration I/O.
NOTE: 3/4/2009 - The warning given above may or may not still be true. Over the years we’ve run this on many different versions of the dutec firmware. It’s hard to say what’s what anymore.
The timeout delay value.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
See the "Watchdog system configuration and operation" section below for more information.
Analog channel default values. These are the values which are used when a watchdog timeout occurs.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
See the "Watchdog system configuration and operation" section below for more information.
Digital output bit mask.
The bit values determine which outputs are switched "off" when a watchdog timeout occurs.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
See the "Watchdog system configuration and operation" section below for more information.
Extended digital output bit mask.
The bit values determine which outputs are switched "off" when a watchdog timeout occurs.
The N field isn’t used and can be set to any value to facilitate sorting the database in the Module listing.
The ChNo field should be set to zero.
See the "Watchdog system configuration and operation" section below for more information.
Normal polling is performed at 1Hz.
Fast polling is performed at 100mS intervals. Communication time to the dutec hardware is a significant portion of the time in the I/O loop and can change dramatically according to the number of motherboards in the hardware communication loop etc. The program dynamically adjusts the delay time between fast loop polls to keep the polling rate constant.
When a dutec motherboard is powered up configuration information must be written to the board. DUtask queries each motherboard known to it once every 10 seconds and if the board responds the configuration information is written to it.
If there is no response the motherboard status is set "bad" and all other I/O to the motherboard is suppressed except the station query which is used to determine if the motherboard is alive.
NOTE: 3-13-2009rlk - this is presently disabled pending debug.
The watchdog system is divided into digital and analog components.
The motherboard allows setting different values for digital and analog timeout. However, the AccelNET implementation uses one value for all of them.
The digital output section allows one to specify which outputs are turned on or off when a timeout occurs.
DUtask has extensive diagnostics which collect statistical information from various levels of the software. This information may be viewed while the program is running.
Sending SIGHUP to the program causes it to dump the information to stderr. This may be performed at any time.
Occasionally a message about an interrupted system call may be generated by the delay functions in duteclib. This is a harmless error meaning that the inter-transaction delay was interrupted by the signal. The worst that can happen is the next transaction **may* need to do a retry. So far that hasn’t been observed.
The logging dump is on two levels.
One portion provides information about each motherboard. The motherboard status is reported along with several counters and time values. See "Diagnostics - motherboard information" below.
The other portion provides information about duteclib. This is the library with manages the conversations between the application and the motherboard. All traffic from the motherboard layer passes through this layer. See "Diagnostics - duteclib information" below.
Each motherboard serviced by the program has a DU_MB_IO record in DUtask. The I/O is divided into 7 sections.
They are:
cf - configuration
ac - analog control
ar - analog read
sc - status control
sr - status read
wd - watchdog service
ar_f - fast analog read
sr_f - fast status read
An I/O list may be present of each section. Fast I/O list are created and destroyed dynamically based on requests from dbman(8) for addition or removal from fast I/O service.
Each I/O section has several items associated with it.
They are:
skip - the number of times an I/O pass
was skipped.
pass - the number of completed I/O passes.
Tskip - the total amount of time accumulated by skipped passes.
Tpass - the total amount of time accumulated by successful passes.
Tpass_avg - the average amount of time taken to run the I/O list.
dirty - if value is 1 the I/O list is dirty and needs to be flushed to dbman.
Tio - the last time the I/O list was run
Tpost - the last time the I/O list was posted to dbman.
A record is printed for each motherboard.
This library contains functions which among other things carries out the conversation with the motherboards. All motherboard traffic passes through here.
A listing is generated containing a line of information about each type of transaction performed by the library.
The fields are:
name - the name of the library function
attempts - the number of times a transaction was attempted
completed - the number of completed transactions
retry - the number of times a retry occured.
attempts - Each time the function is entered this counter is incremented. Retries occur within the function and do not increment the counter.
completed - The number of transactions completed by the function. If an error occurs during transaction processing this counter shouldn’t increment because it’s a failed transaction.
Presently
this isn’t quite true, certain failures may increment this counter.
03-13-2009rlk - I think this is fixed.
retry - The number of times a retry occured. The counter is only incremented on 2nd and subsequent attempts. The first attempt does not cause this counter to increment.
The diagnostic information provides quite a bit of insight into how well a Dutec system is performing. We have used Dutec for many years with many revisions of both their firmware and our software. It’s quite possible that there are bugs which have been fixed on both sides.
Historically we found it necessary to insert a delay after every transaction else the hardware didn’t always reply. Therefore the software defaults to a 20mS delay between transactions.
Recent testing (02-21-2009) shows this may not be necessary with newer hardware.
The best idea is to run the program for a while and dump the statistics. If the retry counters are zero or very low it’s a pretty good indication the system is performing solidly.
Next try starting the program with the --io_set_delay argument. First try 10000 (10 mS) and let it run for awhile and dump the statistics.
If all is still well try zero and see how it goes.
DUtask --dbman_host csdev1 --remote csdev11,ETSraw1 --cmin 1 --cmax 2