108 Relays

image of relay contacts, active

Home

Sitemap

Software

Downloads

Articles

Kit Suppliers

Resources

Troubleshooting

Acknowledgements

Contact

Donate

Order

image of relay contacts, inactive
Last update:
Oct 31/16 (65)

    

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.  

 display_wiring.jpg (80767 bytes)

 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
K108 display board.jpg (75387 bytes)
K190 display board
K190 display board.jpg (160206 bytes)
  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 sentat 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 tocreate 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.      
  
(Jul/10)  The K108 has 2 modes of Relay addressing:  "Rxx", which sets all relays at once, and "T/N/Fx", which sets one relay only.  The K190 has only the one mode:  each relay is addressed on its own -- there is no global command.

  
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

  

 

                                                                                           Copyright 2007 -  2015 by John Gray