Dear Bernd, Um, what I said
Dear Bernd,
Um, what I said was, if one had the stated skills, one had the _technical_ pre-requisites to achieve the result,
as noted furthur down the post, the "degree of difficulty" to achieve any given result is an entirely-seperate problem analysis/solving process... 
In the coding example:
- you either typed, or copy/pasted, the coding. IE all the same PC skills one would use to post here on MRH.
- as far as "logically thinking thru the process"
ProfK: comments inserted within code
void setup() {
ProfK: setup the program
pinMode(13,OUTPUT);
}
ProfK: Configures a given physical hardware pin on the microprocessor to perform a given task.
In this case, Pin #13 is configured to act as an Output
void loop() {
ProfK: START of the sequence of commands,
(implies a looped series of commands,
with START and END points, that repeats)
digitalWrite(13, HIGH);
delay(1000);
ProfK: Sets Pin #13 HIGH (assume "ON", remember we already declared Pin #13 as an Output)
ProfK: Then wait for a "count" of 1000, likely milliseconds, = 1 second
digitalWrite(13, LOW);
delay(1000);
ProfK: Sets Pin #13 LOW (assume "OFF")
ProfK: Then wait for a "count" of 1000, likely milliseconds, = 1 second
}
ProfK: End of sequence of commands, presumably we then return to the start, and do it all again,
ad infinitum
Assuming that the "Output Pin #13" is connected to a LED or bulb, we've got a simple flasher circuit
(Connect to a motor, and we have a repeating start/stop motion,
connect a sound module and we have a "regular repeating sound effect" trigger).
Wider point being, by simply walking thru the sequence of commands, and applying a logical thought process, we can easily work out "what's going on" in the software. By then kitbashing these commands, we can adapt the commands to control any form of animation mechanism as we require
A simple mod would be to lengthen or shorten the WAIT time, to adjust the "flash" rate. By adjusting the WAITs to different values, we can adjust the relative time or duty-cycle of the ON/OFF states, (think of a lighthouse, where the "bright/on" state is significantly shorter than the "dim/off" state for each cycle).
It's worth noting that adjusting a "strobe flash" CV in a DCC decoder is effectively the same, only all you're doing is adjusting the WAIT values in someone _elses_ existing code+hardware, not building your own from scratch
To provide a "more mechanical" alternative, consider a motor-driven CAM switch system.
Speed the CAM motor up in RPM = faster flash rate
Slow the CAM motor down in RPM = slower flash rate
Modify the length of the physical CAM lobe = adjustment of the "duty cycle"
(Indeed, entire automated layouts have been built back as early as the 1950s,
using a motor-driven tin-can and multiple "contact finger" cams to give "programmed" sequences of electrical On/Off control signals. It's an electrical "multi-cam" linear sequencer. Think of it as a rudimentary model RR equivalent of the old western "pianola" or player-piano
NB that such "programming in hardware" is likely to scare most modellers as much, if not more, than having to type some sequential code commands on a familar PC keyboard into Notepad ).
IE, the same basic results and "outputs" of the Microprocessor version,
but significantly harder to adjust "at the drop of a hat".
(adjusting "duty cycle" of a flashing-light by taking a file to the CAM lobe,
or adjusting the "hole" in a pianola-roll, anyone?)
Of course, for those who are more comfy with "programming in solder", a basic 555-timer circuit
(1x 555 chip, 1x carefully-chosen capacitor, and 2x carefully-chosen resistors) is another option to achieve the same "single repeating pulsed output".
Bernd, there's umpteen number of ways to peel a feline when it comes to controlling layout animations.
Whether you're
- a "program in mechanics" kinda person,
(I still love the old 2x2x6' tall glass-cased "marble run" Rube Goldberg machines often found in pinball parlours
http://3.bp.blogspot.com/_mGfPN5qiryw/THF-35qA0tI/AAAAAAAAA0M/1Zs_rj_-cMo/s1600/045.jpg ),
- a up-to-the-second Arduino or similar programmer,
- or somewhere in the middle (somewhere between straight "Plug-n-Play" and "programming in solder"),
if one _wishes_ to go there, I stand by the comment, programming an Arduino or Launchpad only requires basic PC-literacy and a logical thought process.
How one applies these basic "cookbook" skills to any given modelling mission,
(of indeterminate degree-of-difficulty, while we're still talking in generalisations ),
_that's_ where things get "too difficult", all too quickly...
Happy Modelling,
Aim to Improve,
Prof Klyzlr
PS It's a little O/T, but the following Youttube shows a On30 micro layout which is "fully automated".
No Arduinos, Pis, or Launchpads in sight, although arguably such a "control solution" may well have been cheaper to deploy, and more flexible in terms of timing and control config...
