L0 Hardware objects read and diagnosis

dear Bassel, as we said 4 years ago when I didn’t know both of you in deep, I draft
such specs in particular the L1 and on top the structure to handle the Hardware Type
leaving to both of you in particular Nour the problem of from my draft having
studied in detail each board / hardware element, to define which the variables to be
considered to read – write – collect diagnostics – and procedure for getting writing
out the data; from such studying that has been paid to Nour we should have had the
definition of a common structure like union and one specific udt for each type of
hardware and so define one type of function for each type of hardware element
being handled by a caller function that according to the type of hardware in a vector
would have to call the specific function passing the reference of the DBs where to
read the parameters regarding the type and for each type implementation where to
write diagnostics, to read data for out / write the data from input following the
procedure of presetting and then how acting; such operation to be activated at the
first polling in the cycle hardware checking and reading: if from L1 input is necessary
to poll the first input for each module being the first connection to module would be
verified and updated its diagnostic to proceed then with the acquisition in block or
by single as the module could be handled: by direct or by protocol driver like on
Modbus boards on a link.

So what written below is ok but the architecture should follow as I wrote above so
the Dbs of implementation of hardware description and real time being defined with
greater space of memory, could be available at run time to acquire extension of
boards being of the same type already in the vector of types and relevant
specialized function;

There is 2 data block for the HW objects, description and runtime now in the project there is
10 different classes of HW;

1- Cabinet: is not in the hardware configuration, it is a virtual hardware object, there is

no diagnosis to do, the cabinet is an elementary plant object and it based on script
function, we can only put the total numbers of error that happened on the HW
objects that belonging to this cabinet in the plant obj belonging IX .
2- Rack: central rack belonging to itself as hardware and belonging to the cabinet as
elementary plant object, distributed rack for each DP slave belonging to the master
bus system CPs (communication processor) as hardware and for cabinet as
PlantObject, the diagnostic or the rack gives the slot status.
3- PS: belonging to the rack and to the cabinet, the power supply diagnostic working as
acyclic mode, gives the batteries faults and the voltage fault.
 4- CPU: belonging to the central rack, CPU diagnostic function works in cyclic mode
gives the status if run or stope and if working in redundant mode or solo mode and if
master or standby.

5- CP: internal belonging to the CPU or external belonging to central rack.

6- Interface Module (IM): belonging to distributed rack gives the global diagnostic of
the Slave DP.

7- DI Module: belonging to the distributed rack, this object has 2 functions, one to read
data and other to read diagnosis.

8- DO Module : same as DI

9- AI Module: same as DI.

10- AO Module: same as DI.

Till now we was working with fixed UDT size for all types, in the specs the description UDT is
fixed size but the runtime UDT is different depend on the type of the HW object,

Please check the excel specs L1 line 23 to line 35,

So I will define runtime UDT for each type, and let you know the new structure,

For data read we need 32 bits for DI 32 but for AI card (8 channels) we need 16 bytes,

For the diagnostic we will put only the total number of errors and bit map for the error,

For more details about the error it will be from the error table or diagnostic buffer that must
define in the description.

For channel diagnostic is not convenient to put it here we must put it in L1 channel that
belonging to this card because for each channel we have 3 bytes to define the error details.

Yes ok

Overview of execution in OB1:

At the beginning of OB1

Call CPU diagnostic cyclic call

Call PS diagnostic cyclic call

Call DP salve diagnostic cyclic call and acyclic call depend on the OB diagnostic interrupt,
Cause of SFC diagnostic working in asynchronous mode and sometime need more than one
cycle to be done, the interrupt call will be saved in ring buffer and executed with higher
priority than cyclic mode.

Call IN/OUT cards diagnostic

Call IN card DI/AI read in case of block reading

At the ends of OB1

Call OUT Card DO/AO write data in case of block writing.

Please check the above info and let me know if it is ok.

NOTE and overview of excel specifications Hardware Object

Description data:
- All bit pattern must be with WORD format not INTEGER like OP SETTING and MASK…
because the integer is compatible with word only in STL language for other language
and for the IN/OUT formal parameter need to do INT_TO_WORD conversations and
vice versa, so we must change it. OK
- For diagnostic we need the diagnostic address and the logic address and the
geographic address by other words we need the following :Master system Number,
diagnostic address, logic base address, Node address , slot address, so we must add
2 fields in the description to cover the necessary address. In the description is
enough the links to belong to: because at higher level is enough the or and going in
detail could be possible to derive going down the origin of the error: I do not
understand why it needs 2 more fields
- Forcing and simulating must be in runtime as we discussed before and please let me
know if this just for data read/write or also for diagnostic? Could be forced only if in
the description is defined allowed to be forced on both type of variables
- N Parameter is not clear for me, if you mean for read/write data not for diagnostic
so to read/write from any card we need to know the length of data in the card if 4
bytes (DS0) or less than can read/write directly if more than 4 bytes (DS1) we must
use SFC/SFB. N Parameter sets has been introduce to support eventual recursive
type specialized routine for instance if you have a DI of the same type of channels
but 16 or 32 or 48 or 64 channels for using the same function you need to know
how many set of parameters you need expect in the description to handle the
board reading and parking and for each set of many parameters like offset to base
set of the address where to preset the hardware filter ad where to read the answer
back; the same in case of reading by protocol values to be used to send the request
to protocol and then displacement in the buffer where to read the answer back
(depend on the board and is convenient not to replicate functions for a little
difference)

Runtime data:

- OP Setting: for all object we change the setting in the description data. Could be
.that the channel is by description “usable” but at run time is <forced> or is
blocked
- About the alarm reset and ack and their time stamp is not defined. Yes because
Alarm is an Operational attribute and Alerting – wrong quality – validity is a
systemistic Attribute: on an hardware module the OrCountAlert is FF means full
hardware wrong
- Nbuffers : read/write data and time stamp this buffer is only for data, there is no
buffer for the diagnosis, RACK and CPU and PS and IM and CP not read data only has
diagnosis, the most important variable must be exist on the runtime data block to
show the status on SCADA,BitMapError and Actual TimePoll keep record the
 alerting in detail for each block of channels considered in the Buffers: there is not
any Operaating Alarm, if HMI needs an Alarm then is necessary to configure a
PlantElementaryObject as Module alarm

Per example : to show the status of the cpu we need at least one byte for each cpu( we have
OrCountAllert plus according to the capability of CPU active the possibility to define Nbuffers
(1) and NInfoRed (5):one for the memory, one for duality, one for the MPI, one for Ethernet
channel and one for the low battery on board according to the CPUType), for the rack need
at least one bit for each slot (OrCountAllert updated by the belongers to it) and 2 bits for
each module for each IM need (OrCountAllert auto updated if intelligent or the poller
updates it) 2 byte to show the status (Nbuffer (1), NInfoRed (2))

Please recall this object and advise me about to do it in perfect mode.

I recall here concept I wrote on the email:

mean time i read  i write few things more than previous time:
 we have  as in the specs  about the hardware modules definition one structure regarding
description  and one regarding real time;;as now  is written we should  generate a DB 
description and one  DB for the real time;
  according to what in  the description the function can navigate from starting and ending of
each module implementation in the DB because at beginning of each structure, supposed
not udt,  is defined starting and the length of each structure and in each  description  is the
reference to the function specific for type of module described in being able to handle the
type of module and so its  type of structure  (description and  real time);
at beginning  have been also done by Nour one init function that according to a description
in an excel should have had the possibility to pre allocate addresses in the DB of the entry
point to each structure hardware modules and consequently to L1 Now the base concepts
are the same and should be done finally better and complete.
Near the hardware DBs that could be in size also much greater to make free to add at run
type new implementation of the same type, we need to generate  a vector containing in
every row a  type of hardware module identifier: each row a record containing the reference
to  the specialized function call,  the relevant module type (to confirm in L0 to be right
function to handle the implementation), the park of last row index in which done the action
also for diagnostics, the DB L0 from which displacement find the index of object of mapping
, and the eventual parameters necessary to the specialized function to be able to handle
one type implementation  module on the base of the instantiating  data  in the dATA BASE
OF THE DESCRIPtION  OF MAPPING THE MODULE TYPE L0 considering that for instance one
parameter surely is necessary   for  referring to  eventual other DB entry in case the module
is provided of its  communication cpu as for instance the encoder  or the axes controller
should be inserted in the L0 DB Description and RT:  boards autonomous that when make
available the data on a common buffer could also be able to generate an interrupt to the
main CPU; such data  written in a buffer need to be addressed  in the L0 vector row  in
passing has entry point he L0 object Index; buffer start: the specialized function knows the
structure and then can reach the hardware from the data pre configured in the description;
the eventual interrupt routine could also according the type of module do the same 
navigation and then entering in the mapping instance in the buffer find the reference of the
belonging toL1 where to update the variation counter and error state in a mode that the L1
routine noting happened a variation could go on in update the L1 and L2..
So that should be the architecture on which our structure should map;; be careful that we
need to map data type compatible with Tia Portal and with AB std
Tomorrow i read your email in detail

Part2
Hello,
We have in the Hardware description excel line 18,
 we do a function that could loop any way with base periodicity on the vector of
the all modules hardware following an L0 description and real time buffers of big
size to make possible at running time to add new installation of boards;
 the modules of hardware passive type (without CPU inside) are driven by initiative
of the L1 function looping by the way of calling L0 handling function passing module
implementation address in the L0 buffer: the L0 function entering in such descriptio
finds type of module and the relevant Module Type function that is the one knowing
the board modes and parameters which are present in the structure of L0 mapping
the instance of the module; (so is necessary to have a vector of type of modules and
consequently a lib of functions one for each type of module that become the only
limitation of the system: if is the function then you can add a new board in L0
without stopping the system else not!
 the module of hardware active type (having a CPU inside) they are used to
communicate by message or by memory shared but in any case when they put the
message in the buffer could activate a flag of ready that could be managed under
interrupt of by polling too; if by interrupt is necessary define a function under the
interrupt DB else is necessary define a function under OB software interrupt which
is going quick to verify if any event has arrived from any board; in both cases such
interrupt handling mode when change something need to anticipate the poller
function of the L0 to go to care for the arrived variation ; of course the active type of
module has it’s own internal diagnostics but the external function handling to
collect such internal diagnostic mean time verifying communication diagnostics;
probably the internal function needs a state machine to activate according to some
flags or commands that the external function should pass and this kind of handling
should be supported by the structure parameters in description and in the run time
variables that are to be used and defined in the L0 structure;
 according to the type of module the Mode operating Byte should have a flag to
support both functions: L0 handler and ModuleType hardware specialized function
in both the information must be handled if under polling or due to interrupt;
 so having understood very good each hardware module (4 years ago I said maybe
10 times to Nour to read the hardware and extract the needs to generate the
parameters and modes to be written in the L0 structure) is necessary to define in
the specific structure the parameters that the function L0 and HtyFunction should
find the handle the boards and give / get tie information expected/available in the
L0structure.
Mode Operating: BYTE: (it is not OpSetting)

bit 1:
0 (free) : mean no data to read from peripheral? The function is only for diagnostic means
to be handled in native mode ; if input: it is written the value of the field and if in output:
it is sent out the value of the register that at start up could be zero or floating or casual
depend on the board when getting power: it means from board type reading is necessary
to find the right OpMode configuration of bits to support the function L0 and
HMTyFunction;

1 (also block reading) : read and update diagnostic then block reading, read the data and
store it in the buffer (recalled all the action that the the type function should do actually).
Piloted mode it means that (according the module capabilities) we make the module
expects appositely command to read or to write else made available 3 rd state position: if
input type the module expects a command of get input and when the input is ready it is
latched a latched (it means that the function handling the module need to implement the
sequence of action and similarly) if is an output piloted : starts in 3 state and then when
issued the command to output goes out what preset in the latch register;

bit 2= 0 (no alert) it means eventual variation is not cared by the specific function handling
the board that is working by polling: such L1 function must realize polling the eventual
variation happened ; 1 (if changing set bit map it means the function handling the module
sets the bit map of in input variations realized and alerts the L1 function that happened a
variation to be handled in input or in output immediately: being L1 requested to act
being just waked up such L1 function could also continue to verify the other channels if
any variation has been happened)is demanded to each channel configuration and relevant
reading writing addresses the mode of using the module facilities if by single channel or (D
I/O) by bit map of block to be read / written. It means the function handling the module if
flag is one sets the channel in which happened the variation and increments also in L1 the
input or output the number of channels where happened a variation to wake up the L1;
for instance suppose L1 needs to read a input channel: it is the first time in OB that
initialize the reading then goes in DB L1 gets the hardware board where is the channel to
poll, the bit masc and the address of the channel to pass to the hardware function such
request, L0 function enters in the vector of type and calls the module type function
passing the DB and displacement where the parameters plus the mode of handling
according to the description in L0 DB; being the first in cycle for such board L0 requests
also the diagnostic of the board and relevant I/Os if available to set as Objbelongest to in
the L1 real time db as diagnostics OR; then according to the description it pilots the I/O
channel of the boards: if other channels in the boards got modifications go to increase
modifications on L1 to make L1 to continue the actions on the other channels that could
got modification.

bit 3=0 not consider local diagnostics; if bit = 1 consider the local diagnostics to integrate
to the L1 channel diagnostics it means if locally a channel could be defined in error then
such alert could be used in L1 to reinforce the diagnostic on the module in complete mode:
channels and module able to respond;

bit 4 = 0 module passive it means is handled directly by L1 through the L0 Hardware

Function and Module type Hardware function; =1 module provided of a CPU, it means
that the L1 activates the hardware function L0 which from module type activates the
installed module type function that is handling the buffer and eventual protocol with the
CPU module; such module type function that should be actually an FB watches the
evolution of the hardware and when the hardware comes with data ready then sets in L0
and in L1 DB the flag of variation ready dropping down the polling time of L1;

bit 5 = 0 normal ; 1 by interrupt software: it means the module figures to have its own
instantiated a function in the OB 37? (hi speed looping) that realizes the variation soon
parked on the same db L0 and increments the belonging to flag in L1 dropping the waiting
time for of L1 function to start doing the polling in accelerated mode

bit 6=0 normal; 1 by interrupt hardware: DB of hardware interrupts where to each event
are the function to be activated configured to start on interrupt which actually have also
the parameter of L0 and L1 to be incremented flag of variation and to drop the waiting
time and then go out from function.

Bit 7=0 passive: do diagnostics in the case of requested and action from upper level L0
which is pushed by L1; =1 do any way just a verification module by module (not channel by
channel) if responds to address query with the state. It means that in OB1 at first action a
loop on L0 DB Description to verify if any hardware has configured to be checked
diagnostics and relevant belonging’s updates by OR: a I/o board belongs to a
communication board If one board is no good the state of the communication board
would appear in L0 as FF which means the communication board no good

Please note:

I don’t know exactly how the hardware handling must be processed, and how I must use the
Nparameter set (line 22 to line 29 in the excel). As per above written according to the type of
board is necessary in the description define the parameters of behavior to be passed to the
board as presetting and in the real time similar values that should be parked to support the
module type function in completing the action on the board and some of them be used also
by L0 to relate with L1

For diagnostic: The command to the function of the hardware handling must come from
interrupt OB error and after startup the system. As above wrote according to the type of
board the error handling information if is specific relevant to a board type we need in OB
error insert a module type function that gets error code but also he address where is
matured the error but if the error is abstract as at such address we got and error then we
configure the L0 function that getting the address in inputs sets up the L0 structure in error

NEXT I Answer below!!!!!!!!!!!!!!!

And from the user in the hardware page in the WINCC if need to check network or on DP
slave,

And cyclic via polling time but I cannot do all diagnostic function in cyclic mode it take long
time and sometimes has no meaning.

For data read/write: must be cyclic via polling time even if block reading or not to save the
raw data and visualize it on WINCC.

So I need to define some commands like job identifier to execute diagnosis.

Per example:
For each DP slave I have 2 diagnosis functions,

First function for the global diagnostic to check if the IM153-2 is connected or not and which
interface is active and which is standby,

Second function: for details diagnostic and update channel related diagnostic.

Here there is no data to read/write from peripheral.

Below this object is the I/O cards :

Up to 11 cards for each Slave in our project,

I/O cards must check the belonging to Index (DP Slave) check the runtime state,

If the diagnostic is done then check if ok then read/write data else only update validity.

Could you please help me to know what is the perfect way to do it ?