#
# 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
point L2	"light 2" Chaser
point L3	"light 3" Chaser
point L4	"light 4" Chaser
point left	"<- (key L)" Kbd
point right	"-> (key R)" Kbd
point quit	"quit (key Q)" Kbd

# 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.