Don Y wrote:
> On 7/5/2011 6:41 PM, Mr.CRC wrote:
>> I've developed a machine which implements a real-time dynamically
>> reconfigurable state machine. This is done by having two sets of state
>> transition tables in memory, ping-pong style, then synchronously
>> switching from one state machine data structure to the other when it is
>> appropriate to do so.
>
> Presumably, you mean "build the 'new' FSM while still using the 'old'
> FSM and, once complete, wait for a convenient time (e.g., TDC) to
> switch from one to the other -- ensuring that the 'current state'
> maps conveniently into the new FSM" (your reference to "ping pong"
> left me with the impression that you were bouncing back and forth
> between the two FSM's "often"/regularly)
What you presume is correct. The state changes within an existing FSM
can occur frequently, at up to a 3600RPM engine cycle rate, or 30Hz.
But changes to a new FSM configuration are less frequent. New FSM data
is sent and digested casually in the background.
A nifty file system was devised to enable sending only the fragment of
the data structures that changed, then the DSC rebuilds the new FSM
configuration in the second half of mem using the changed part, and
re-copying from the running FSM the chunks that didn't change.
A large part of the user interface challenge is in dealing with
generality. The ability to jump from one FSM to another of completely
different topology is presently permitted, although that would be atypical.
There are some controls such as whether it is permitted to transition to
a new FSM based on the current state, whether to reset the cycle count,
reset the state number, etc. The output waveform tables of a given
state may be "single paradigm" meaning containing only the waveform for
one cycle, or "multi-paradigm" meaning containing more than one cycle of
waveforms, for a further complication.
>> Transitions are done in 2-4us on a TMS320F2812 DSC. The output of the
>> state machine is waveform generation tables that produce digital
>> waveforms and time-domain pulses as a function of crank angle in an
>> engine lab experiment. The inputs to the state machine are the cycle
>> count, external world input bits and button presses. The state machine
>> is evaluated once per engine cycle.
>>
>> The main purpose of this is that with optically accessible engines,
>> combustion is usually "skip-fired" so that a burn takes place only 1 in
>> 10 cycles, for ex. Thus, rather than make a single waveform table with
>> 9 duplicate cycles and 1 fired, by using a state sequencing waveform
>> generator, only the waveforms of unique cycles need to be stored. Also,
>> the state machine can modify the waveforms based on external input
>> conditions, which a simple sampling arbitrary waveform generator
>> cannot do.
>
> So, your FSM might (typically) sit in a "thumb twirling" state for
> 9 "cycles" before advancing to the "meat and potatoes" portion of
> the machine for the "cycle that matters".
Yes.
>> The only problem with this scheme is that the users are challenged by
>> the state machine concept, and the programmer who has to develop the
>> user interface (which must be backward compatible with an older system
>> without sequencing capability) is also "not used to thinking in the
>> state machine metaphor." So he is stressed trying to figuring out how
>> to make a generalized user interface to this, that doesn't let the users
>> hang themselves.
>
> How "general" does the interface need to be? I.e., is it always
> "skip N cycles and then run the *real* cycle"? (trivial to
> generalize)
It used to be that way. Then when I proposed that waveforms could be
sequenced based on external inputs and the experiments naturally evolved,
Or, are there more convolutions involved?
> (e.g., "skip N cycles UNLESS button 5 is depressed -- in which case,
> run this *other* cycle instead of a 'skip' cycle")?
Yes, now it is like this. Quite a bit more difficult to can into a set
of basic templates.
>> 1. Dynamically reconfigurable waveform tables, synchronous with the
>> engine cycle boundary, must have all decisions deterministically made
>> and internal data structures switched in 2-4 us, but frequency of this
>> process needing to happen is low, about 30Hz max.
>
> You've said 30Hz -- implying ~30ms to build a new table. But, what
> is the overall latency tolerated? I.e., if you can build tables
> at 30Hz but they are 3,000 degrees out of phase, does that pose
> problems?
>
> Can the tables be pre-built and then just switched into place
> at the appropriate run-times?
That is what is done, as described above. This is the only way to get
the job done in 2us. The transition table must be searched for matching
input conditions, state changed, then also check for a new FSM data set,
then re-init all the waveform table pointers with the new locations,
then be ready for the first angular waveform generation event in 2us.
And a few other things.
>> 2. Absolutely glitch-free waveform table switching.
>
> Are you constraining the waveforms such that they always
> "start at a fixed amplitude at a certain crank angle"?
> E.g., 2.904 (or whatever) at TDC? I.e., this solves your
> problem as long as you always switch at TDC...
I should point out that the waveforms are 32-bits of digital output, not
analog. But effectively it is the same thing, as when a state change
occurs (switch to new waveform table) or switch to new FSM altogether,
the "phase" of the waveform must not have a discontinuity.
> You could also look into an interpreted, procedural language -- even
> if it is application specific. I recall evaluating an industrial
> controller (as part of an acquisition program) many years ago that
> I initially dismissed as "a toy" -- it only had a handful of
> "command". But, when my boss (knowingly) told me to "humor him"
> and give it a more serious evaluation, I was stunned at how much
> could be done with those few commands! Picking a good set of commands
> could mesh neatly with your application and might be more palatable
> to "procedural thinkers".
I've thought about embedding Lua. But I don't think it's feasible to
have a language interpreter doing the real-time part. Even if it could
do *most* programs fast enough, there is no way to guarantee that the
user doesn't program something that fails to meet real-time deadlines.
That is one of the main reasons the state machine is so useful, because
it can have a guaranteed maximum evaluation time.
Alternately, is to use the programming language as the input the user
sees, but this just gets translated by the UI program into the suitable
data files. Well, this is what we already do! There is a text waveform
definition file, with which they don't want to loose backward
compatiblity. On top of that they are attempting to add syntactical
elements to enable specifying FSM behavior.
I had my idea of how this might be done, but the programmer is doing it
differently.
Thanks for input.
--
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17