What exactly is generating the "one shot" pulse on IP1?

______
Rob

[release]

Here's a code snippet to get you started.

Code:

#define IP1 2  // use your pin numbers here
#define IP2 3
#define RELAY 13
#define N_PULSES 40

void setup () {

  pinMode (IP1, INPUT);
  pinMode (IP2, INPUT);
  pinMode (RELAY, OUTPUT);
  
  digitalWrite (RELAY, LOW);
  
}

void loop () {
  // wait for button to be pressed
  // NOTE: input doesn't really need to be debounced
  //       assumes pull down resistor on switch
  while (digitalRead(IP1) != HIGH) {};
  
  // relay activated
  digitalWrite (RELAY, HIGH);
  
  for (int i = 0; i < N_PULSES; i++) {
    // just use pulseIn() to count the pulses
    // don't care about the pulse width
    pulseIn (IP2, HIGH);
  }
  
  // relay deactivated
  digitalWrite (RELAY, LOW);
 
  // assumes the one-shot on IP1 is set to < the time N_PULSES takes
  // if not then wait here for IP1 to go LOW again ie. button released
 
}

As you said a monostable on the button I'm assuming a short debounced pulse on IP1.

If it's really just a pushbutton the release of the buttton will have to be debounced.

Hope that will allow you to have a crack at it.

______
Rob

Do I understand correctly.

IP1 goes active, start injecting and count injection pulses on IP2.
After N pulses stop injecting.
If power fails stop injecting.

Is that the guts of the matter?

______
Rob

are those connections still can be used

All signals not used by the installed shield(s) can be used for other purposes.

______
Rob

you mean that because the cables are spread all over the house over too long distances, I will have problems with the operation?

Yes, for example a temp sensor may only produce 1v if it's cold, you don't need much noise to stuff that up and also if there is a voltage drop in the line you could read a much different value.

RS-485 doesn't fix the problem as such, what I (and I think marklar) am suggesting is that you have several processors (or "nodes", could be Arduinos or any other processor/board type) distributed around the house, each taking local readings and feeding the information back to a central controller.

RS-485 is probably the best medium to feed this data between nodes and the controller.

______
Rob

better get the Arduino Mega coz it has more I/O connections

One thing to remember though is that your sensors and actuators will be placed over a very large area, IMO it's not practical with many such devices to have long cable runs back to a central uC. Too much noise, voltage drop, ESD potential etc.

For this reason I would suggest distributing your processing, and that means a network of some kind. It can be something simple based on RS-485 or similar.

As for the various Mega options, I'll let someone with more Arduino knowledge answer that.

_____
Rob

Here's my initial take on the job.

Code:

#define N_LEDS 4


struct led {

      long count;
      byte pin;

} ;

struct led      leds[4];

void scanCounters (void) {
// this gets called every 100mS, or whatever granularity makes sense for your app
      struct led *l;

      for (int i = 0; i < N_LEDS; i++) {

            l = &leds[i];
            
                  if (l->count != -1) {
                  l->count--;
                  if (l->count == -1) {
                        // do LED timout stuff, EG
                        digitalWrite (i, LOW);                  
                  }
            }
      }

}

boolean led_3_should_go_on() {
 return true;
}

void startLed (byte led, long time) {
      leds[led].count = time;
      digitalWrite (leds[led].pin, HIGH);
}

void stopLed (byte led) {
      leds[led].count = -1;
      digitalWrite (leds[led].pin, LOW);
}

void setup () {
      // map logical LEDs to physical pins
      leds[0].pin = 3;  // use your pin numbers here
      leds[1].pin = 5;
      leds[2].pin = 9;
      leds[3].pin = 12;
      
      // init counters
      for (int i = 0; i < N_LEDS; i++) {
            leds[i].count = -1;
            pinMode(leds[i].pin, OUTPUT);
            digitalWrite(leds[i].pin, LOW);
      
        }
}

void loop () {

      if ((millis() % 100) == 0) scanCounters(); // scan 10x a second
      
      if (led_3_should_go_on() ) {
            startLed(3, 1000);
            stopLed(2);
      }
}

I missed the "LED2 turns off LED1" bit at first but depending on the exact relationship between LEDs that can be handled in the main loop I would think.

This compiles but is untested and of course doesn't handle the serial commands.

______
Rob

Another way to do this is to set up a few software timers with callback functions to turn LEDs off. The timers are incremented every say 100mS and you do something like this to start a LED

Code:

turn_LED_on (LED_NUM)
start_timer (LED_NUM, LED_TIME)

The timers tick away in the background (on an timer interrupt, can that be done with Arduino? if not use a timer directly) and every time a timer times out it turns the appropriate LED off, either directly or using a callback function.

This way there's no testing for states or if..this..then..something...else statments for each LED.

______
Rob

That doesnt look complicated not even for a small PIC

And even if it was they do make big PICs so you could stay with the PIC family if you want.

However I'm sure we'd love to see you cross over from the dark side, on the surface this sounds like a pretty easy thing for the Arduino.

_____
Rob

Not really sure exactly how quickly the avr responds to an interrupt.

Pretty fast, the order of events is something like this

int happens (a pin change int takes 4 clock cycle to be recognised)
wait for end of current instruction
push current program counter onto stack
load int vector into PC

IIRC I've seen it take about 1.5uS to get into the ISR.

Thats at the ASM level, however if using C there could be a stack of extra code to save registors as well.

Just as an aside, it can be faster to poll, if you really need to react fast to say a pin change it will be faster to just constantly read the pin. Of course you don't get anything else done  

______
Rob

Thanks guys, I think I'll have two-bob each way (for passive components) and get some ziplock bags plus some pill organisers. I happen to be near a city at present so may get into town in a few days and see what's available.

As for ESD sensitive devices, maybe a sandwich of the static foam in the tackle-type boxes I already use, enough foam to hold the chips firmly when the lid is closed.

______
Rob

For years I've been using all manner of plastic fishing boxes and compartmented storage boxes for components but with the advent of SMDs I find they aren't really appropriate.

For example 0603 resistors, to use a full (say) 1x3" compartment in a box for a 100 resistors is way overkill when something the size of a thimble would be more than enough.

It's not really that big an issue for new components because you can just leave them in the tape, but I find I'm salvaging a lot of stuff from dead motherboards as well and I need a good way to store the bits.

Any ideas?

______
Rob

Don't see why not.


______
Rob

Does the speed of the relays physically opening and closing make much difference?

Sorry BrIDo I lost track of this thread somehow.

I'm sure you've figured something out by now, you can't use relays for PWM the frequencies are way too fast, you can use them for your direction control if you like.

______
Rob

Reading that board, it apparently puts out all data from the sensors as 'serial'. Can this input data (3 varying voltages per sensor) easily be deciphered by another controller via serial?

Yes, presumably there's a simple protocol you'll have to follow, but this should be easy.

By PWM - is that just the process of rapidly turning the pins on and off to control the motors speed?

Yep, you adjust the duty cycle (ratio of high to low) to change the motor speed.

Here's the detailed design we've been pushing forward with:

That's a serious-looking piece of kit.

______
Rob