SMt Applications

PLC Type Control

In the example below, by using SMt, the Parallax BS2 is able to emulate 4 Batch Counters effectively in parallel, where each handles Counting, End of Batch Output with Timing, and PC communication. The only additional resources compared to  partially emulating one B/C at a time, is 1 bit + 4 nibbles of RAM. 

PLC Template:

Both the Robotics & PLC Templates take care of the general organization. User code is essentially the same as for single-tasking, except that execution never waits for a required condition.

The PLC Template introduces two important functions not needed by the Robotics example - Individual Timers and Sequencers. 

Timers:

The Timers are effectively a background task, they are updated immediately after each new Tick, and prior to reaching the User code. They operate on whatever variable size the User chooses for each Timer - no other resources are needed - see Fig 2B below. The finest resolution is determined by the User selected Tick period.

One factor in deciding that Tick period is when Counters are used. The ideal count signal would be one change of state per count, as with the Robotics wheel encoders. But normally there will be two transitions per count. To be sure that counts are not lost, the Tick duration must be less than the shortest high or low period of the signal being counted.

The Template also includes a 'SnapShot' of inputs after handling the Timers. It ensures that all the subsequent logic decisions will be using the same data.

Sequencers:

Programmable controls are especially valuable when dealing with batch type processes. In those applications the control needs will vary with each stage of the sequence and are easily accommodated by a Stamp type controller. Especially if many parallel Timers are available.

When writing code for such a sequence, progression from one of those stages to the next is dependent upon specific conditions. Once those conditions are met, then that section of code is 'left behind', and will not be re-entered until the whole sequence is repeated. It is an inherent part of the program flow - there is no need for any mechanism to prevent that code from being repeated. 

That holds true for single-tasking, and also for interrupt driven multi-tasking. The 'no overheads' SMt does not switch Tasks transparently, but openly exits code whenever it does not see the condition it is seeking. This 'planned' non-interrupt exit has the advantage that there is nothing to be preserved. But by abandoning all stages of the sequence there is no inherent indication of what has been completed up to that point.

Fig 2C shows that this is resolved by maintaining a record of the last Stage# reached in a single nibble for each Task. The next time the Task receives CPU time, it re-enters its Sequencer always at the same point, but is then re-directed according to its Stage#. 

Not all applications will need sequential control, and therefore in some cases each pass may use the same logic. In such a case the Sequencer could be thought of as having just one stage.

Combining with microGUI for a Visual Demo:

Hardware:

The hardware shown is taken from the Robotics example but the needs of both examples are identical.

Software:

BS2 Code:

With the hardware still fresh in mind, take a copy of Demo_PLC.BS2 from the CD's \Green directory and re-allocate the DPin, CPin and Tick pins as needed. Already the code for the End of Batch outputs has been commented out and the count inputs are simulated. This Demo can be run without regard for port pins other than those just connected above.

At the same time look for the following code under 'INITIALIZATION':
Shiftout DPin, C1Pin, MsbFirst,[$05,$1D,$00,6]
If you are using an RS232 buffer rather than the resister shown above, then change the $1D to $15. Adding '8' to baud rate#5, says 'Using a resister / not-inverted'. It is now ready to be loaded.

PC Code:

There is a Demo version of microGUI provided as a simple means of interfacing with the PC. It is self-extracting and can be found here: \ Demos \ microGUI \ microGUI.exe.

Once installed, replace the startup project with \ Projects \ Demo_PLC.Prj to achieve the screen below. The Comm settings need 28,800 Baud, Full Duplex and Header Length options.

The sole purpose is for the Stamp to run as many Timers and Counters in parallel whilst still communicating with the PC bi-directionally at 28k baud. The fact that as a system it is not very practical, does not matter here.

Five times a second the 4 gauges are updated with their current remaining count. At the same time the BS2 is fed the 4 slider values as being the counts for the next batch.

 If watching the gauges drop down, there is a slight delay at zero as they output a high for a timed duration before they restart using the latest slider value. All the time each Batch Counter is running its own Sequence independently.

The accuracy of Batch counts is considered important so the BS2 used this SMt setup of 5, 16+8+5, 0, 6 where the addition of 16 (see table at end of page) calls for a checksum on all 'PC to Stamp' data. 

The returned data could also have a checksum but it is not important if for one fifth of a second the user sees the gauge with an incorrect length. It is there if needed.

Note that there are not sufficient I/O pins on the BS2 for all counters to have an output, and so the listing has those outputs commented out. But they still use the  Timing and Counting functions.

Sequencing a Batch Counter

Comparing to Single-tasking Code

If the above code was written for a single-tasking Stamp, every conditional test would be exactly the same as the above. But:

• Every time a conditional test failed, the code would patiently try again & again. From the entry point to the exit would be the duration time to complete the batch. Whether seconds, minutes or days.

• Whereas execution of the above SMt code, will typically, never last longer than one millisecond between Entry to Exit. Yes, it will return 40 times a second in the Demo - even so, that is a savings of 960mS every 1 sec - 96% of BS2's CPU time is saved!

A Set of Guidelines to create a Sequencer:

• Within a specific sequence, every label in single-tasking code that is used for waiting on an event, becomes the start of a new Stage. That label is then included in the entry 'Branch' command.

• Exit immediately when a test fails

• When a test succeeds, take the required action, adjust the Stage if necessary and Exit immediately

Remember that for processes larger than the Demo, one sequence may well be nested within another. But every sequence has its own Stage count and hence does not create any problems.

More PLC type Code

The Batch Counter example is essentially a PLC type application. It has simultaneous operations to perform, and those operations each have their own sequence to follow. There are several independent timers, plus counters, and everything works effectively in parallel. 

The following BS2 code handles slow process control type operations: to control a filling operation, debounce a level switch, monitor for filling problems, start a motor, and check its speed. Again, virtually impossible for a standard BS2 or other single- tasking Micro on its own.

The SMt setup bytes will be: 40, 8+5, 0, 6 (see table at bottom of page) where the 40 is to create a Tick every 200mS. Nothing is planned for the communication, but it is in place at 28k and no checksums. A user may wish to add code to send level switch states and return Timer values, Stage#, Port bits, and Alarm for display.

The choice of a 200mS Tick is to emphasize how opening and closing industrial process valves does not need 10mS reaction times. At the same time it allows a single pass to use lengthy statements. In this case the PulsIn is used to measure the motor speed. If the motor is not running, the PulsIn command will take the maximum time of 131mS which is well within the 200 target. If longer tasks are needed then 400/1000mS is also OK. Task switching only needs to satisfy the Application's needs - no one else's. 

SMt Initialization Bytes: