The documentation for the project WIP (ZODIAC- Counterbox).

INDEX

1. Introduction.
2. Solution architecture.
3. Scope Of Project.
4. Description.
5. CounterBox.
1. Communication Protocol.
1. Init
2. Wake Up
3. Flash
4. Set
5. Get
6. Junk Rectify
2. Tools to Check.
3. Electronic Problems with Box.
6. File Structure.
1. Client
1. probeD
2. processD_local.pl
3. ntp.conf
4. syslog.conf
5. flagFile
6. processD.conf
2. Server
1. wipDB.conf
2. GenerateReport.java
3. lock.sh
4. report_n.flag
5. report_n.sh
6. report_n.stop
7. report_n
7. Logs at Client Machine.
1. probeD
2. processD_local.pl
8. Logs at Server Machine.
1. report_n.sh
2. mysqld
3. AlcnDataEntry.jsp
9. WIP GUI.
1. Login
2. Index
3. Operation Balancing
4. Job Allocations
5. Operations
6. Set Count Manually
7. Report
10. Set up of WIP Client.
11. Set up of WIP Server.
12. FAQ.

Introduction:
   

   Zodiac is interested in monitoring, in real time, the precise rate of
work in progress on the assembly lines of their garment making factories. For this purpose,
they wish to record a data point on a central computer each time a worker on an
assembly line finishes a job and starts working on the next job. This information will then
be processed on the central computer and mapped to a graphical image of the assembly line,
showing the speeds at which each station on each line is processing jobs. Starcom Software
Pvt Ltd (starcom) proposes to design and develop an integrated hardware software solution
custom-designed to address Zodiac's requirements.

Solution architecture:
   

   The solution we propose has the following components:

• intelligent counter nodes, one at each tailors station
• Monitoring workstations, one per assembly line
• Backup monitoring workstation for all assembly lines in factory

The counter node will contain an LCD panel, a switch (infra red - sensor unit), a microcontroller, and industrial
data cabling connection to connect it to a monitoring station. Each time the switch on a node
is pressed, it will increment the job counter and update its LCD display for the tailor to see.
Whenever the monitoring workstation queries the counter node, it will report the current
value of the count. These queries are expected to be done at least once a minute.
The counter nodes will also have a job target display, which will inform the tailor how many
jobs he needs to complete to reach his current target. Each time he finishes one job, he presses
the switch and the target count is decremented, to indicate the new target.
The monitoring workstation will be hooked up to the counters via high speed industrial
data links. It will poll each counter node at least once a minute, and get the current counter
values. It will also reset and initialize the nodes in its assembly line on first startup at the
beginning of the day, and after power failure. If one of the nodes momentarily loses electrical
power due to a supply problem, the monitoring workstation will detect this and initialize its
counters to the last reported values.
The monitoring station will plot the report of work in progress at each station of its
assembly line, and make this data available through a browser based interface. Any desktop
computer on the factory LAN with a GUI Web browser will be able to see this information,
updated once a minute. This data will also be made available to the backup monitoring
station.

Scope of Project:

   The backup monitoring workstation will communicate with all the monitoring workstations
and get the aggregate data for all assembly lines on its local storage area. This will act
as a backup for the data in each assembly line monitoring workstation. An officer sitting at
any desktop on the LAN will be able to connect to the backup monitoring workstation and
see the work in progress graphs and data for all assembly lines.

   The scope of the project is to collect the current count of jobs
done at each machine in the factory and store in some central
database. Then according to database the reports are generated
and can be viewed by HTTP.

Description :

   In the factory, the machines are kept in 7 - 8 rows.
Each is generally referred as assembly line. In each assembly
line there are 48 - 50 machines are arranged. The product (e.g. Shirt)
in the factory is produced in sequential manner. i.e the cloth is
passed through no. of operations to get converted into the shirt.
Thus after performing one operation at one machine, the job is transfered
to next machine to perform new operation on it.

   Thus to monitor the status of jobs done, the counter unit is
kept at each machine. The counter unit is a hardware device, designed
with its protocols of communication, attached at each machine,
called CounterBox.

CounterBox:

   Basically the counterbox is a hardware device, which keeps
counting the jobs done as well as target remaining. The counter box mainly contains
a microcontroller 8951, NV RAM. The counterbox holds the counts still no power to
the counterbox due to NV RAM.

•    The counterboxes in assembly line are connected as shown in diagram in a daisy chain manner.
  The first counter box is connected with the line monitoring client machine through serial port.
  The serial port is accessed as /dev/ttyS0 in the file system. Communications through counterbox is
  done by commands. The command is a 10 Byte ASCII text with specified format. The commands
  that the counterbox recognizes are
  • Init
    

    The counter box operation starts after initializing it. We can not communicate with
    the counterbox without initializing. The command for initialize the counterbox is
    
    "IXXXGOINIT".

    The response to this command being executed successfully, is
    
    "IXXXISINIT".
    

  • Wake Up
    

    The counter box after initializing should Woke up. The command for wake up the counterbox is
    
    "wXXXwwwwww".

    The response to this command being executed successfully, is
    
    "wXXXWOKEUP".
    

  • Flash
    

    After waking up the counterbox, the counts are flashed to indicate to the user
    that the counterbox is working OK. The formate of flash command is as
    
    "fXXXTTDDff".

    The response to this command being executed successfully, is
    
    "fXXXTTDDOK".

    TT    is the parameter, no. of times to flash the count.

    DD   is the delay parameter.
    Larger the value - slower the blinking.
    

  • Set Count
    

    Using this command, we can set the count to the counterbox. By setting the appropriate
    value to parameter L, the corresponding LED is selected. For red
    count the display id is 1 and for green count it is 2.
    The formate of set command is as
    
    "sXXXLcccss".

    The response to this command being executed successfully, is
    
    "sXXXLcccOK".
    

  • Get Count
    

    As similar to set command, we can get the particular count of particular counterbox.
    Legends in this command are same as that of set command.
    The formate of get command is as
    
    "gXXXLggggg".

    The response to this command being executed successfully, is
    
    "gXXXLcccOK".
    

  • Junk Rectify
    

    This command is basically for debug purpose. Due to memory corruption, the counterbox some times
    sends the data as non-digit value. Which is considered as GARBAGE. To rectify this problem
    following two command are send to counterbox. The formate of this commands is as
    
    "eXXX102ptr".
    
    "eXXX204ptr".

    Where XXX is the Unique three digit Node No. assign to each
    Counterbox. The microcontroller in the counterbox, is programmed/burned with the Node No. thus, have
    unique identification.
    
    The ccc is a three digit count.
    To keep semantic of command, the count CCC is forcefully is of
    3 digit. ie. 23 count is specified as 023.

Tools to check the counterbox:

   

   There are the tools to check the counterbox status. Using the script
ConfigNode.sh, we can probe the particular counterbox. The general format of utility is as




./ConfigNode.sh <ip>
<command>
<to> <node_start> [<node_end>]
[[value1] [value2]]




Where
<ip> is the IP address of the assembly line monitoring client system to
which the counterbox of Node No. node_start is attached.

The commands executed by the tool are

stat

To see the status of counterbox.

test

To test the counterbox. It performs the init, wake up, flash,
set to default 888 and get the count.

init

It initializes the counterbox.

setcount

value1 is assigned to Red count of counterbox.

value2 is assigned to Green count of counterbox.

to

    describes whether to perform command on only one counterbox
or on sequence of counterboxes. When only one counterbox is used then give only
node_start address. And if you want to perform the same operation
in multiple nodes in sequence then give end address (node no.) also i.e.
node_end. To perform operation on single counterbox the
to parameter is node and for multiple counterboxes in sequence,
the parameter is seq

./ConfigNode.sh ip stat node XXX

e.g.
./ConfigNode.sh 192.168.0.51 stat node 219

The main tool used by above script is udpClient.o which sends the actual microcontroller recognizable
command to counterbox. Parameters passed to this program are as follows


./udpClient.o <ip>
/dev/ttyS0#ASCIICommand

e.g.
./udpClient.o 192.168.0.51
/dev/ttyS0#I219GOINIT

Problems with CounterBox :
   

    Some of the counterboxes suffers from some problems and do not work properly.
The problems are of specific type and can categorized in some class.

L = R

This problem occurs on Power Cycle. Power Cycle means when the counterbox changes the state
from switched OFF to switched ON. At this state, the counterbox shows counts that the
Left side - Green i.e. Jobs Done Count is copied to right Red Count loosing Red count i.e.
Target. But this problem is corrected by new updated software - processD_local.pl

Garbage

This problem also occurs at Power Cycle. In this problem, the counter box shows counts as non-digit
characters and this occurs due to memory corruption. This problem can also be eliminated, as
stated above by the software control.

Auto Increment

The counterboxes suffering from this problem increments the counts automatically without
any interaction. This may be due some hardware problem.

LED problem

In this type the counterbox LEDs are off and don't show any counts. In these type of counterboxes,
the LED devices need to be replaced.

Network

If this type of counterbox is connected in the daisy chain in the start or middle, then we
can not access the boxes beyond this box. Therefore to avoid this problem, the counterbox having
this problem should be connected at last in the daisy chain.

File Structure:   

   As shown in the diagrams below, both the clients and server should setup with the all the
executable binaries, scripts, configuration files in the specified structure. Client machines
generally called assembly line monitor systems and the server have different files at different
locations.



   Following is the short description of file laying at clients.





probeD:    

   The file structures describes all the binaries and text files used in the project.
As shown in the diagram, on each assembly line monitor client machine, daemon processes are running.
Basically two daemon process communicate with counterboxes to their serial port and the central database.
The binary executable probeD listens on port 1500, which sends and receive data by UDP. This daemon
communicates using sockets.

    The second main file is processD_local.pl script. This is a perl script, which
run as a daemon in background. This script provides main interface between the central database on server
and counterboxes attached to individual assembly line monitoring client machines.
To ensure that the processD_local.pl is continuously running, one daemon keeps watch on the script,
called processD_wrapper. This wrapper is a shell script executed in background. The wrapper script
calls the processD_local.pl continuously in infinite loop. As soon as one processD_local.pl stops ( or dies
on some error), wrapper calls new processD_local.pl. Thus ensures that the processD_local.pl is running
continuously.





processD_local.pl:    

    This is a main script running on each assembly line monitoring client machine.
This script provides the basic interface between central database on server to counterboxes at
individual assembly line. The parameter to this script is a configuration file viz. processD.conf ,
which has parameters like username, password for database, assembly line number, fetch_interval,
flagFile, etc.

ntp.conf
   

   This file is the configuration file for NTP. The Network Time Protocol
(NTP) is used to synchronize the time of a computer client or server to another
server or reference time source, such as a radio or satellite receiver or modem.
It provides accuracies typically within a millisecond on LANs and up to a
few tens of milliseconds on WANs relative to Coordinated Universal Time (UTC)
via a Global Positioning Service (GPS) receiver, for example.
Typical NTP configurations utilize multiple redundant servers and diverse network paths
in order to achieve high accuracy and reliability.

   The ntpd program is an operating system daemon which sets and maintains the system time
of day in synchronism with Internet standard time servers. The ntpd program operates by
exchanging messages with one or more configured servers at designated poll intervals.
When started, whether for the first or subsequent times, the program
requires several exchanges from the majority of these servers so the signal processing and
mitigation algorithms can accumulate and groom the data and set the clock.

    Therefore to synchronize the assembly line client machines in
time with server machine, the client machines should have entry in this file as

server 192.168.0.10.  Where 192.168.0.10 is the ip address of server.

syslog.conf
   

This is the system's configuration file for syslogd.
The syslog.conf file is the main configuration file for the syslogd(8)
which logs system messages on *nix systems. This file specifies rules for logging.
Every rule consists of two fields, a selector field and an action field.
These two fields are separated by one or more spaces or tabs.
The selector field specifies a pattern of facilities and priorities belonging to
the specified action.

   The selector field itself again consists of two parts, a facility and a priority,
separated by a period ('.').
The facility is one of the following keywords: auth, authpriv, cron, daemon, kern, lpr,
mail, mark, news, security (same as auth), syslog, user, uucp and local0 through local7.
The keyword security should not be used any more and mark is only for internal use and
therefore should not be used in applications. Anyway, you may want to specify and
redirect these messages here. The facility specifies the subsystem that produced the
message, i.e. all mail programs log with the mail facility (LOG_MAIL) if they log using syslog.

   The priority is one of the following keywords, in ascending order: debug,
info, notice, warning, warn (same as warning), err, error (same as err), crit, alert,
emerg, panic (same as emerg). The keywords error, warn and panic are deprecated and should
not be used anymore. The priority defines the severity of the message.

   Therefore we have added a entry in syslog.conf



# customized syslog log-files


user.alert       
      /var/log/counterbox/processD_local_pl.log

flagFile
   

   This file is like semaphore to communicate processD_local.pl
with timing. This flagFile is created (or touched) periodically ie. after 1 minute.
The perl script checks the existence of flagFile to load the database. Thus
in perl script, running infinitely loads the database fields in memory (hash) after one
minute only . As soon as the database is loaded, the flagFile is deleted. And then touched
after one minute by crontab.

    Thus we are having entry in crontab of user ctrbox as

0-59/1 * * * * touch /etc/counterbox/flagFile

processD.conf
   

    This is not any system file. This is a parameter file ie. argument provided
to processD_local.pl having configuration regarding database connectivity, line id, etc.
The file boot.local was used to start the daemons viz probeD, processD_wrapper at system startup.
But now it is handled by crontab with @reboot option.





@reboot echo "`date` : Starting server..." >> /home/ctrbox/start.log

@reboot /opt/counterbox/server/probeD &

@reboot echo "`date` : Starting client..." >> /home/ctrbox/strat.log

@reboot /opt/counterbox/client/processD_wrapper &

Logs at Client Machine :
   

To keep all record, for investigation and debug purpose we are logging all the required
information.

processD_local.pl
   

As the processD_local.pl is the main interface between counterboxes in assembly line and
central database at server. The standard output of this script is redirected to out file

/var/log/counterbox/processD_local_pl.out  and error is redirected to

/var/log/counterbox/processD_local.error   and logs are maintained at

/var/log/counterbox/processD_local_pl.log

These standard output and error are redirected to corresponding files through
processD_wrapper. And log is written by syslog in the processD_local.pl.

probeD
   

Similar to processD_local.pl, probeD writes its log in the default log directory
for counterbox as /var/log/counterbox. The log file is probeD.log

wipDB.conf
   

This is a simple property file used by the java class FactoryConnection .
This class is used as a java bean in *.jsp files to make/close connection
with database.

GenerateReport.java
   

The .class of GenerateReport.java is interpreted by java in report_n.sh.
This programs actually fetches the data from db on server according to queries and
writes formated the HTML text in the file.

lock.sh
   

Lock file is a shell script used to check that, only one instance of report_n.sh is running.
This script checks for existence of report_n.pid which contains the process id of
currently executing script. If .pid file exists, then it checks the process id written
in the file. If the process id matches with the pid of self ie. $$ then only
it continues else exists itself.

Usage : lock program_name pid_file [log_tag [log_facility]]

e.g..  lock report_1.sh $FLAG_PATH/report_1.pid "Report 1"

$FLAG_PATH   is  /etc/counterbox/flags

report_n.flag
   

The script report_n.sh checks the existence of this .flag file. If
flag file exists then and the report is generated else sleeps the script for given
sleep interval time. This .flag file created (touched) by report.jsp.
Means whenever there is a request to see the report this flag file is created.
The page report.jsp is auto refreshing after 240 sec, thus the flag file is generated
after 4 minutes.

report_n.sh
   

This is a shell script called by skeleton report_n which is insserved.
The skeleton report_n is kept in "/etc/init.d/ ". The script is an infinite loop with the
loop hole as existence of file report_n.stop , checks existence of .flag file
and calls the java code of GenerateReport.java by java interpreter. The interpreter
takes parameter as program name as GenerateReport . And The program takes
parameters as Line ID (i.e. n) and .tmp file in which the report's html text is to be saved.
After generating the report file report_n.tmp , this script deletes the .flag
file and copies the content of .tmp file to final file report_n.html . And also
this final file is saved to last saved file as report_n_yyyymmdd.html. This file used
to display the previously saved reports with fordate option in URL. If no flag file
found, the script sleeps for the sleep interval.

report_n.stop
   

The existence of this file is checked every time by report_n.sh to exit
from infinite loop. If .stop file exists, then the script report_n.sh removes this
.stop and .pid file and exists with status 0. The .stop file is created by the skeleton
structure report_n , when we say

" report_n   stop ".

report_n
   

This is a Template system startup script, for example service/daemon mysqld.
This is LSB (Linux Standard Base) compatible service control script called the shell script skeleton.
This template uses functions rc_XXX defined in /etc/rc.status on
UnitedLinux (UL) based Linux distributions. The skeleton is put in the system startup
by the utility insserve.

    insserve enables an installed system init script (boot script') by reading
the comment header of the script and calculating the dependencies between all scripts.
At boot time, the boot level master script /etc/init.d/boot is called to initialize the system.
It also executes some hardware init scripts linked into /etc/init.d/boot.d/.
Then it calls /etc/init.d/boot.local, which executes the local commands. The skeleton is
kept in the init dir viz. "/etc/init.d/" .

Usage: report_n {start|stop|status|restart}

E.g..     report_1   start

To synchronize the server in time with standard time servers,

the entries in the server's
ntp.conf should be

If ntpd or xntpd daemon is running, then the server synchronizes itself with standard time
servers whose ip addresses are given above.

Logs at Server Machine :   

report_n.sh

This shell script writes log through
logger with providing log_facility as
local3.info. Logger makes entries in the system log. It provides a shell command
interface to the syslog(3) system log module.   Therefore by
logger the logs are written in /var/log/local3.log.

The file /var/log/local3.log is decided by the configuration of log against log facility
in the configuration file /etc/syslog.conf. We are having the log facility as - local3.info .
Therefore entry in the syslog file is as

local3.info           -/var/log/local3.log

mysqld

mysqld is a daemon for database MySQL. Whatever queries fired on mysql can be viewed
from access log. Access log file can be specified in the configuration file /etc/my.cnf.
Therefore access file is "log=/var/log/mysqld.log".

AlcnDataEntry.jsp

This jsp page creates a allocation for balancing the operation with status FORECLOSED .
It writes the logs in file /var/log/counterbox/manual_data_log.txt for balanced
operation.

WIP GUI:   

    
The graphical user interface of project is a web interface on HTTP generated by JSP .

The following is the description about the graphical interface provided to user.
By this GUI, he can see the productions reports, operations - operators information,
monitor stations, set the allocations and desired updations wherever required.
Thus we 'll go step by step through some major screens.

Login
   

Like any general web based application, this application provides the authentication for any
transaction by log in. Once the user logged in by passing authentication, jsp keeps the user name
in the session to keep track the user. Depending on the authority, some of the operation are
allowed/denied to user. The user "admin" have all the authorities.

Index    

This is a main page called home page. This page has most of the options like Orders,
Job Allocations, Operators, Operations, Stations, Set Counters, Set Line Groups. By selecting
the appropriate line, VIEW REPORT shows the corresponding production line's report.

Following is the short description of all options.

   The orders Option shows the page OrderSmry.jsp. This page shows the
orders status - ACTIVE or Not Allocated, OC No. (Order Confirmation No.), the order
completing on which assembly line, entry time - when the order was entered.
You can modify the order by the button Modify , you can delete the order if
it is not active. You can add a order, by Add New Order , then you have to allocate
the order to particular allocations by clicking the link Not Allocated . This link
brings you to AlcmSmry.jsp - here you have to update the allocation by selecting
proper values.

   Operators: The page on this link shows the list of all operators with their
date of joining, their specialization, operator no etc. You can add, delete or modify this
information.

   Stations: At each station or each machine, the counterbox is
attached. This page shows the Summary of the station at particular
assembly line. It shows the information about station position, station no. ie. 3 digit
Node no. with modify and delete option for existing stations. We can add a new station with
providing the information about its position, Node (Station) No., description etc.
Also it has two main features viz Monitor Station and Replace Station . Monitor Station
shows the status of counterboxes as they can be Up, Down or Not Responding. By Replace Station,
we can reflect the changes about new counterbox in place of old faulty counterbox.

As shown in the diagram, the high privileged operations like Monitor and Replace Stations are
available to only 'admin' user.

Operation Balancing    

In the assembly line, sometimes it happens that any of the tailor may work slow.
As the jobs are sequentially, i.e. after performing one operation on job by one
tailor it is fed to next tailor to perform next operation. Therefore work rate of one tailor
affects to work rate of further tailors.

   To solve this problem, some of the jobs from slower operator
are transfered to the tailor who has finished his jobs and sitting idle or having less work
load and doing the same type of operation. The slower tailor is having high work load and
faster tailor has less. When few jobs are transfered from slower tailor, then his target is
reduced by the jobs transfered . This reduction in target is reflected in both
database and counterbox also. And at the other end where the jobs are transfered, a new
allocation is created with status 'Foreclosed' belonging to the faster operator.
And report shows the correct information which is balanced.

   This information need to be fed manually. Therefore the data entry
operator collects the information periodically about balancing operation and feeds it through
Balance option of AlcmSmry.jsp page. As soon as the manual data entry is done
the page shows the correct report with balanced operations.

Job Allocations    

This is very important page than other pages. The work of day start with this page and ends
with this page only. As shown in the diagram below, it allocate the tailors to particular operation,
target for the day, confirmation no of the order with station position. It shows the rows as
no of station present in the particular assembly line. Then accordingly we have to allocate
particular operator (tailor) to that station.

The allocation has attributes like start time, operation name/code, order no, target for
the day, status. At the end of day the user has to do Close Now and Continue On the next
day specified in the test box in from of the button. When we do 'Close Now & Countinue On', all the
active allocations will show the status as PENDING and are marked with allocation mod flag = 1.
The this allocation will become active iff after the date - time Continue On , still
it will show the status as Pending. If you want to stop the perticular allocation due to shifting of
tailor to new station, you have to close the allocation by Close. The closed allocation
then displayed by the status as ForeClosed. By selecting proper
value to fields you can modify the allocation by Update . The most important link at last
column is Balance Manually, this link is for operation balancing. The soure from where the jobs
are taransfered is the slower operator's allocation and the destination is the faster operator
who may be sitting idle or having less work load. The destination is specified in the next page
AlcnDataEntry.jsp on clicking the Balance link of source.

Operations    

This page shows the operations, performed on the garment, with operation code,
Operation Sequence No. and Modify - Delete option. It shows the details of
latest active Order.

From this we can set the sequence of operations that appears in the report. To get the report
showing balanced the line, operation must be in given sequence. There may be different sequence
for different orders. Thus according to order we can specify the Operation Sequence No. in
ascending order as we want. The report will show the sequence of operations according to
sequence no. specified. To set the sequence you have to press Set Sequence and not any Modify
button, though you are changing one or two values for operation.

Set Counter Manually    

If any problem occurred with the counterbox, and we need to change the counts of counterbox ,
we have a facility to change the counts of it.

It has input fields as Assembly Line no. - specify the counter box attached on which assembly
line, Position No. - is the no. given to particular counterbox in a line - it differs from the
3 digit node no. You can get the position no. for the counterbox from Station's Summary page.
The Production field - the jobs done by the tailor at that station ie. green count.
The Target is the field - as jobs remaining. Be clear about this field, this is jobs
remaining field and not the allocation target. Its value can be found by allocation target -
(minus) jobs done = Red LED target.

Report    

This is the output for what we are ding all the things. The major fields in this report
page are Line No., Order No., last updated time, tables of operations. Tables of operations have
information about operator, his target for the day, time elapsed, Current production and estimated
production at end of day (EOD). We'll see step by step the legends used in the report.

As shown in the above diagram, the report shows the information operation wise on
particular assembly line. It gives information as jobs done at a assembly line, having
the orders and orders having the operations. Therefore it shows first of all the order no.
and then the tables of operations belonging to that order. The table of operation may have
multiple tailor, if they are assigned to do the same operations but at different stations.
If any of operator working slower than the other operators then that allocation is highlighted
by red color. Like wise if compared to all operations for the
same order, whichever operation's total is smallest is displayed as slowest operation and also
marked with red color. The bullets in from of operators name shows the information about the
position and node no. for that allocation, in the tool tip text. The allocations with
yellow colored bullet and gray colored background shows the Fore-Closed Allocation.
This allocation may be either by shifting of tailor or due to operation balancing.

Set of WIP Client    

    If we want to add a new line set up, we should prepare the WIP client
machine with proper set up. Following steps describes the procedure to set up the new assembly
line.

Install Files

As explained above the client machine should have the file structure with some
changes. The property file processD.conf should have values for field

logid=processD_linen

lineid=n

Except these changes, all assembly line client machine should have same file structure.

Attach Counterboxes

1. Connect the first counter box to serial port of assembly line with provided gray cable.
   This is very important to know the node no. of each counterbox, before going to attached
   to assembly line.
2. Now try to probe the counterbox by the tools provided to test the counterbox.
   If we are getting the response from the counterbox with OK status as explained in tools
   to check counterbox. If we are not getting the response from that counterbox, then
   check for the physical connectivity with the cable. Before connecting the cable, be ensure
   that there is connectivity between corresponding end points pins. If you are getting OK
   response, go on adding next counterbox in daisy chain manner as shown in the diagram .
   Now perform the step 2.

Add IP address in Database

To recognize the server the new client with assembly line, the server should have
entry in the database. The table NODE_STRINGS contains the information about the assembly lines.
Insert the data as IP address of new assembly line and NS_ID as line ID.

Check Modules for PERL

To run the daemon processD_local.pl properly check whether the perl modules DBI,
IO::Socket, Sys::Syslog, Date::Manip, Config, etc. are installed on the client system.

If the client system has OS Linux with Ubuntu distribution then we need to
install debian packages.

Set of WIP Server    

Server set up requires rarely, because only once the server is set up.
The required script files and binaries are kept in a tar package
and should be deployed as the described by the file structure.
The report generation shell script for one line should be copied for another with the changes
related to line, are shown below.
<!--

-->


Above is the snapshot of screen, taken by the vimdiff of two different scripts for
two different lines. It clearly shows the difference of the assembly line Id n .
Following information shows the actual difference.

This table shows the difference between two assembly line scripts ie line1 and line3.
Rest of the things are understood by the files given in the file system above.

FAQ    

1. The report page shows the message " Your request is currently being processed...
   
   This page will automatically refresh in 30 (29, 28, ...) seconds. "
      
   

   This message is prompted when we tried to access a report page and the report is not
   generated till the request.

   Solution

   Yes, this message is displayed when requested to a report page which is not being generated.
   The may not be generated due to no corresponding generation script running. Therefore we need
   to start the report explicitly as described here. Before going to
   run the script directly, check the status of script by parameter status . The script
   is executed by providing full path as e.g.     /etc/init.d/report_1 status
   for report of Line1. Therefore to troubleshoot by software client ZODIAC,
   run the following commands
   
   
   cd /sbin
   reportGeneration_1  &nbsp status
   
   If status shows unused then run command
   
   
   reportGeneration_1  &nbsp start
   
   If status shows runnig then run command
   
   
   reportGeneration_1  &nbsp restart

   The command reportGeneration_n is just a simlink in the /sbin directory for
   /etc/init.d/report_n.

2. The CounterBox Status showing Down in the Station status page
      
   

   This shows when the Station is read for no of times (Max_Read_Attempts) and getting
   NORESPONSE .

   Solution

   If the counterbox is not powered ON then we get no response from it. If we get this for
   no. of times, then it is marked as DOWN status.Therefore check first of all for the power supply
   is present at counterbox. We get NORESPONSE from counterbox when there
   is problem with connectivity of counterbox with the daisy chain. For this, remove the
   connector cable from daisy chain line and check whether there is connectivity between
   corresponding pin points at both ends of connector cable. And then connect the cable
   carefully as shown in the diagram above. The cable connecting should be
   done gently and carefully, because majorly this problem occurs with improper physical connection
   of cables.

       After this, try to probe the counterbox by the tools
   provided. Repeat the step 2-3 times and confirm that we are getting the correct response as given
   in the protocols. After repeating the steps, though we are not getting
   desired response then replace the counterbox and update it through GUI also.
   And also update the Spread Sheet .

   ZODIAC maintains the spread sheet noted above with current information about all the
   Counterboxes used in the factory.
   

3. Last Date's Reports have no data.
      
   

   The report at the end of day is saved at /opt/counterbox/reports/saved/ as report_n.yyyymmdd.html
   but shows no report data.

   Solution

   The reports are generated at server only of active allocations. This is the key point of the
   problem stated above. The report is overwritten continuously for the same day. Therefore when we do
   Close Now and Continue On from the page Allocations, the
   allocations are marked as PENDING. And thus the report generation is continue, it do not get any
   ACTIVE allocation and hence writes no data in that. And as this file is overwritten to previous one,
   earlier data is lost. Therefore to prevent from this First stop the report generation
   by the script by giving stop parameter and then Close all allocations .