|
Writing Your Own
Software
Here you will find tips and techniques
for coding your own programs. This page will be periodically updated with additional
ideas.
A couple of preliminary notes:
- I write software for other peoples' hardware -- I don't have source code for
their hardware.
- The source code for my software isn't available -- please don't
ask.
| Display
Test
Jig... |
| If you are writing a
program to control a relay board (like a K108 or K190), it's handy to have a
visual display for testing relay operation, without having the actual loads
connected. For the K108 it's also useful to have a set of switches and
display indicators for the 4 Input channels. This is a circuit diagram for
a K108 relay and input display.
For
a 4-channel relay board, just cut the relay display circuit in half. As noted in
the diagram, power for the display circuit can be picked off the board power
supply.
Example
displays:
K108 display
board, with Input switches
 |
K190 display
board
 |
|
Both of these displays were built using strip board (similar to Vero
board). |
|
| |
| Sending
commands to a board...
(Jan/09) |
1. When you send a command, wait for
(and verify) the return value before sending another command. (eg: if you send a
"T1" to a K108, wait for the "#" before sending another command.)
2. If there's any possibility that commands may be sent at the same time from different sources (eg: from a button click and an Input trigger),
you need to ensure they can't collide. The way to do this is to create a
"command queue" to manage the multiple commands ("queue" as in lineup, like passengers queuing
up to board a bus). This is really just a list of commands that are
to be sent to the device. Once a command has been sent, it's cleared from
the list.
|
| |
| Pushing
and Polling... (Jan/09) |
With devices such as
the K108 and K190, you need to request data. That is, you have to send a command
to the device, asking data to be sent (Input status and Relay status for the
K108, and temperatures and relay status for the K190). This is polling.
Devices like the K145 and VK011 automatically (and repeatedly) push
data out to the serial port without asking. All you have to do is receive
it and process it as desired.
|
| |
| K108
and K190... (Jan/09) |
|
Remember that the 4 K108 Inputs are independent of the 8 Relays. If you want an Input change to drive a Relay, you have to create the linkage in your code.
The same idea applies to the K190: there is no internal firmware
connection between the sensor inputs and the relays -- you do that in your
software.
|
| |
| Logging
data... (Jan/09) |
| There are generally 2
kinds of data that are logged: "events" -- information about
something that happened, like a relay action, or resetting displays, and
regularly repeating data (like temperatures). Technically, both are
events, but it helps to differentiate them, from a programming point of
view.
Events occur at irregular
intervals. In terms of logging, all you need to do is write the
information into the Log with a timestamp, whenever the event
happens.
Temperature values are more
useful if they're recorded at regular intervals -- generating a plot is easier
with evenly spaced data. Receiving the data at regularly spaced intervals
may not be possible though. Eg: Devices like the K145 send data at a fixed
rate, but that rate changes, depending on how many sensors are
connected. You might also want to record data at a different interval than
what's available from the device. As well, you're at the mercy of the Windows multitasking system,
which determines when data is sent or received through the serial port.
The trick here is to use a set of buffers to receive the data as it comes
in. Then, set up a timing system that pulls data from the buffers at the
desired interval, and puts it into the Log.
|
| |
| K108
and K190 Relay state... (Feb/09) |
| When you send a
command to the board to get relay state (eg: "S1"), what is
actually returned is the logic state of the relay control pins on the
microcontroller. Depending on the intended use for the controller, this
may have safety implications -- how do you know if a relay is actually energized
or released? How critical is knowing this for your application?
The
relay contacts are fairly reliable as long as they're not switching high load
currents, so for general hobby/home use this may not matter too much. For
high-end commercial or industrial applications it may be absolutely critical, in
order to provide some kind of fail-safe scheme.
With the K108 it is possible to
verify 4 relays by using the 4 Inputs. To do this, you would use secondary
relays each with an extra set of contacts. One set does whatever switching
is required for your application, the other set is used to switch the Inputs
high/low. Your software would then read the Input states to determine
relay state. You lose use of the Inputs for anything else of course, by
doing this.
With the K190, this is not
possible.
|
| |
|
K108 and zone
detection (a sprinkler example)... (Feb/09)
|
| Let's say you want to
set up a computer controlled sprinkler system, using the K108. Each relay would
control one water line with a number of sprinkler heads, by switching a solenoid
valve. For safety and economy, you want to know if a water line
breaks. You could do this by using flow switches in the water lines, and
sending the switch signals to the K108 Inputs.
But the K108 has only 4
Inputs. What you do is wire 2 flow switches in series back to one
Input. In your software you create 4 "zones" each containing 2
water lines. Each zone is linked to an Input. If an Input is tripped
(changes state), both water lines in that zone are shut down.
|
| |
|
Enhancing
functionality... (May/09)
|
|
The K108, K145, K190, and the
VK011 all use the serial port for communication with a pc. Besides the
actual transmit and receive data lines, a serial port has other signal lines as
well, there for use in modem communications. In particular, the DTR and
RTS lines could be used for additional relay (or other) control. See this page
for one idea.
|
| |
|
Debounce the K108
Inputs... (July/09)
|
|
Whenever you mechanically close a set of
contacts, be it a switch or a relay, the contacts don't make or break cleanly -- there's always a bit of chatter. You wont see this if you're
switching a light or a heater, because of the way they work. But the K108 Inputs are sensitive to
this chatter.
In some situations, this may not
matter: if all you're doing is linking a Relay to an Input, you'll never
notice the chatter. If you're counting pulses on an Input however, then
stability is critical. The solution is to introduce a bit of a time delay after the
first detected pulse, to let the chatter die out. Length of the time delay will
depend somewhat on what's being switched, but typically it should probably be in
the order of a few hundred milliseconds. This technique is called
"debouncing".
|
| |
|
Musical or
Dancing Lights... (Dec/09)
|
|
The K74 (parallel port relay
controller) is a popular device for controlling musical Christmas lights.
Theoretically, code could be written for the K108 to perform a similar
function. The problem is the limited life of the relay contacts (applies
to the K74, too). The relays used in the K108 have a rated mechanical life
of approximately 100,000 operations. At a switching rate of once per
second, that works out to roughly 28 hours of contact life. Generating
musical or custom light display patterns will likely require even faster
switching.
A possible workaround is to adapt
the K108 to use solid-state relays instead of the electro-mechanical ones
supplied with the kit. These relays have a switching life rated in the
millions of operations.
|
| |
| |
| |
| |
| |
| |
| |
top |
