#
# matplc.conf - configuration file
#

# the speed of the light-chasing (interval in seconds)
Chaser: delay = 0.3

# I could have also written that like this:
# 	[Chaser]
# 	delay = 0.3
#
# The section:variable syntax is convenient when there is only one variable
# to be set, possibly in the middle of some other section.

# shared memory map section

[PLC]


# run the modules!!!
#
# Note: the Kbd module cannot run as a deamon, as it reads the
#       terminal's keyboard. It is therefore launched in the demo script.
#module Kbd ../basic//kbd
module Chaser "../basic/chaser"
module vitrine "../../mmi/curses/vitrine"
module plcshutdown "../../lib/util/plcshutdown"



#   P O I N T S
#   -----------
#
# These are also specified in the PLC section. However, it's not specified
# whether they are inputs or outputs here - that should be specified in the
# section(s) relating to the I/O modules. (That way, a point can be both an
# input and an output, or it can be output in several places. Also, some
# points are just internal coils and don't get input or output at all.) 
#
# syntax:
# point name "full name" owner at offset.bit
#
# where:
# point     = 'point' identifier
# name      = Name used to refer to the point throughout the PLC
# full name = More extensive description of the point
#             This might be displayed by various diagnostic tools.
# owner     = Name of the module with write permission on the point
# at        = 'at' identifier
# offset    = location of word in the globalmap that holds the point's state
# bit       = the bit in the word (0-31), that holds the point's state

point L1	"light 1" Chaser at  0.0
point L2	"light 2" Chaser at  0.1
point L3	"light 3" Chaser at  0.2
point L4	"light 4" Chaser at  0.3
point left	"<- (key L)" Kbd at  1.4
point right	"-> (key R)" Kbd at  1.5
point quit	"quit (key Q)" Kbd at 1.6

# read in the configuration of the display
# (this might equally well be simply specified here, but for the sake of 
# demonstration it's in a separate file)
*include vitrine.conf


[plcshutdown]
# configure which point will be used to shutdown the plc
quit_pt = quit
# for simplicity sake, we will not synchronize the plcshutdown module
# with the others, we will simply tell it to run periodically
# every 100 ms.
scan_period = 0.1


#
#     S A M P L E    S Y N C H R O N I S A T I O N    C O N F I G
#     -----------------------------------------------------------
#
# The synchronisation config to run the chaser and vitrine modules in synch,
# one after the other. The kbd module runs asynchronously with the other two.
#
# The synchronisation system uses a petri net to synchronise the module 
# execution. This petri net may be configured by _one_ of two methods.
# The first, the simplified method, is merely the definition of the sequence
# by which the modules should execute. 
# The second, more complete and complicated method, requires the complete
# definition of the petri net. Although more complex, this method is also 
# more powerfull, and supports some synchronisation sequences that can not be
# configured by the simple method.

[PLC]

#
#     THE SIMPLE METHOD
#     -----------------

# After the Chaser, run the vitrine...
synch Chaser -> vitrine
# After the vitrine, run the Chaser...
synch vitrine -> Chaser

# Start off by running the Chaser.
synch_start Chaser


# With the above configuration the vitrine -> Chaser -> vitrine -> ...
# loop will run as fast as it can, taking up almost 100% of cpu time.
# This is not required, and we can reduce the cpu utilization by stating the
# scan period, i.e. the inverse of the number of times the cycle should
# be executed in each second
# Since the Chaser and the vitrine are running in lock-step, we need
# only specify the scan_period of one of the above two modules
#
# Let's use a scan period of 20 ms (= 50 Hz)
Chaser: scan_period = 0.02



# NOTE:
#
# By using weights in the arrow, it is also possible to have a
# module run several scan loops once the first module finishes its scan.
#
# For e.g.:
#
# synch Chaser --2--> vitrine
#
# Would tell the vitrine to run its scan twice when the Chaser finishes its
# own scan.
# Note that now it would not be a good idea to have
# vitrine --> Chaser
# as the chaser would now run twice, once for each execution of the
# vitrine. This would result in an ever increasing number of
# scan loop executions in each cycle!
# Nevertheless, we would require the following line
#
# Chaser ---> Chaser
#
# to keep the execution running in an infinite loop.
# Since the Chaser is limited by its period, the vitrine would most
# probably have finished executing it's 2 scans before the Chaser gets
# to execute again.
#
# Please see the sample matplc.conf file in the manual appendix for a
# complete description of the possible syntax for the arrow with an
# explicitly defined weight.





#
#     THE COMPLEX METHOD
#     ------------------

# please see/use the matplc.conf.complex file.