Show Posts
Pages: 1 ... 47 48 [49] 50 51 ... 64
721  Development / Other Software Development / Re: bug in the timealarm library on: July 02, 2011, 01:00:45 pm
That's actually a pretty good question, but like you said one is easy from the other.  So, it would be a teeny bit better to return the remaining number IMHO.  This is not a hard and fast recommendation at all, just a guess.  Perhaps it would be better to name it something like countersleft, remaining, not used or something.  Count implies used and blows my argument about using the remaining number.

flip a coin???

Just to help you understand how I and one neighbor use the timers dynamically.  He has a drip watering system that senses the moisture level in the soil a couple of inches below grade.  When it gets dry enough, he turns on the drips, but he wants to limit how long they run because he doesn't want to drain the water tank and have the wives (I share the tank, he's not Mormon) mad because they can't make iced tea.  So he turns on the drip and sets a timer for 1 hour from now to turn it off then sets another timer to check tomorrow for dryness.  You can't sample the tank because it's buried up to the very top to keep it from getting hot.  Maybe an ultra sonic from the lid, but that's another project.  But meanwhile, the little arduino is doing a ton of other stuff of a similar nature.  The ability to set a timer then just forget about it until it fires leaving the arduino free to do something else makes really cool control systems easy.  There's hardware out there that is so complex that you really can't predict what it will do next so, you check it; an alarm that fires daily and then decides when to fire again based on the data is really useful.  I don't have a clue why people don't do more of this.  Heck a standing light that turns on when a coyote comes in range of the chicken coop then sets a timer to turn off in five minutes is dynamic, multiply that times one light at each corner and you start to see something of the situation.  Of course, you want the lights independent, it confused the coyotes more.

Oh, so far, the testing has been working perfectly.  I still have a few things to try out, but it has stepped through a few years of daily alarms with them all firing at the right time.  I have not checked to see if any of them have missed, just that when they fire they fire on time.  More later.  And don't worry, if you change something and it needs to be tried, I'll crank up the little piece of code I'm using and do it again.

Besides, I have a vested interest in this because I use this library a lot for drip watering, pool control, blinking lights, etc.  The arduino makes an incredible timer when you need one. 
722  Topics / Home Automation and Networked Objects / Re: Measuring phase angle and power on: July 02, 2011, 11:47:24 am
Just a quick interjection that might (maybe) help you avoid a problem.  I tried solid state relays for a high current project, a water heater controller.  It was a 240V thing that was optoisolated.  Worked great, got hot.  It had to have a heat sink and airflow to keep cool enough to touch and couldn't be mounted in a box outside where I live (desert) because the ambient temperature and afternoon sun would destroy it.  I switched to an old fashioned contactor controlled by a little bitty relay off a 5V digital pin.  This was because an A/C contactor was easily available and ran off 24VAC.  It runs nice and cool and has been cycling now for over two years.  At first the noise was offensive, now its comforting because I know it's working.

Now, I know it may have been the particular device I got stuck with and your mileage may vary, but keep this in mind when choosing the device.  In my case, old school worked best.
723  Development / Other Software Development / Re: bug in the timealarm library on: July 02, 2011, 11:34:38 am
I want my count function.  Of course, it doesn't need to be called count, but for me and others that will do something similar I think it will be useful.

C'mon, trying to set a timer and having it fail because you have dynamic code that can't track of how many are used kinda sucks.  if you create a timer and it returns BAD, what do you do?  Hang up in a loop until one comes free to the exclusion of draining the septic tank?  The count function could be tied to a bell that rings because you added one too many timers and overdid it.  It would also be useful to measure how loaded your device is becoming.

With the clear, reset, whatever routine one could keep assigning timers until one ran out and then clear them all out to get the count, but that's the only way outside the library to tell how many are currently being used.  That seems a little silly when it is so easy to do in the library.  Looking at the index value doesn't meet with the idea of libraries controlling their data, otherwise, once could just get the id and start poking at the alarm itself.

How many of us have implemented something to tell us how close we've gotten to the end of memory because our arrays and such have put us a hundred bytes from oblivion.  Heck, if you're using streams you can run out and have exactly zero indication that there's a problem except for the burst of garbage on the serial output as you over write the stack.

If vicnet hadn't put in the free, he would have wanted a count, especially if he couldn't use the id as an index indicator.

You see, I envision a controller with sixty or seventy timers or alarms.  They check on devices periodically, take actions, then retry in a few seconds if it didn't happen, measure ph in the pool and time HCl injectors over a period of days, pan cameras toward the neighbor lady that sunbathes in the afternoon on Tuesdays when the sun is out.  It would be very bad if that alarm failed because it ran out.
724  Development / Other Software Development / Re: bug in the timealarm library on: July 02, 2011, 10:34:03 am
vicnet, your modules update worked, at least so far.  Saturday no longer fires every time through the loop.  I'll run some tests now that include saturday and such to see how it goes.
725  Development / Other Software Development / Re: bug in the timealarm library on: July 02, 2011, 10:22:34 am
vicnet, I'll be glad to give your pieces a try.  Get to it in a bit.

mem, first, let me bring up that the usefulness of daily alarms is huge.  I'm not sure why people aren't using the heck out of them and why this particular problem hasn't cropped up before except in my case where I reset the daily alarm each time the previous one triggered.  But household timers: alarm clocks, thermostats, pool controllers, chicken feeders, light controllers, etc all want daily alarms.  So, given that, I think a small change of philosophy is a good thing.  

And, frankly, it doesn't make much sense to me to set a daily alarm in any fashion other than alarmRepeat( everyDarnMonday, 10:00AM,etc)
because that reads well in the code except in the instances where the daily time is calculated.  In my experience there are extremely few instances where a daily time is calculated, sensors for sunrise, sunset, ph, drainage valves etc, prevail.

Net, having to use the calls with the day of week to set a daily alarm is not a problem, and not being able to use time_t shouldn't bother anyone.  I can't imagine how one would use that reasonably anyway.

Also, I don't see a problem having to set the time before using the alarms.  It's one silly call with easy to type parameters and one already has to have the time library included.  No big deal.
726  Development / Other Software Development / Re: bug in the timealarm library on: July 01, 2011, 10:27:03 pm
OK, testing again.  Daily alarms seem to work except for Saturday

the call  - saturdayAlarmID  = Alarm.alarmRepeat(dowSaturday,17,45,0,onAlarm);  will fire every time through the loop.  I have all the latest changes in place.  The next time you post a change, try to put the entire module in the box, my editing can cause errors.

There are a lot more tests to run though.  I haven't tried jumping by hours to see how far it will run and I haven't made sure it doesn't miss any.  Additionally, tests on a future date, like Feb 4, 2013 need to be tested.  However, right now the saturday thing is messing me up.
727  Development / Other Software Development / Re: bug in the timealarm library on: July 01, 2011, 08:16:13 pm
I think I have the source mixed up somehow.  Regrouping.....
728  Development / Other Software Development / Re: bug in the timealarm library on: July 01, 2011, 07:23:19 pm
vicnet's latest changes to DOW alarm don't help much.

tuesdayAlarmID   = Alarm.alarmOnce(dowTuesday,12,31,0,onAlarm);

fires on Thursday 12:31:12 1/5/1971  using the same test program shown above.

And alarmRepeat still cause the arduino to reboot, apparently on the second time it triggers.  Is everyone working from the same source?
729  Development / Other Software Development / Re: bug in the timealarm library on: July 01, 2011, 05:02:36 pm
There are problems.  I incorporated viknet's macros from post right above because the day of week alarms were firing every second.  After they were incorporated, the DOW alarms are firing on the wrong day and apparently doing a call(0) causing the board to reboot on the second try.  I started the tests at 1/1/1971 to avoid the various problems with the first year.

code used:
Code:
#include <Time.h>
#include <TimeAlarms.h>

AlarmID_t morningAlarmID, afternoonAlarmID, eveningAlarmID;
AlarmID_t tuesdayAlarmID, saturdayAlarmID;
char buf[200];

void setup()
{
  Serial.begin(57600);
  Serial.println("Initializing...");
  setTime(0,0,0,1,1,1971);
  morningAlarmID   = Alarm.alarmRepeat(8,30,0, onAlarm);
  afternoonAlarmID = Alarm.alarmRepeat(13,25,0,onAlarm);
  eveningAlarmID   = Alarm.alarmRepeat(17,45,0,onAlarm);
  tuesdayAlarmID   = Alarm.alarmRepeat(dowTuesday,12,31,0,onAlarm);
//  saturdayAlarmID  = Alarm.alarmRepeat(dowSaturday,1,45,0,onAlarm);
  pinMode(13, OUTPUT);     
  Serial.println("Begin test...");
}

void onAlarm()
{
  // alarm callback function
  AlarmId id = Alarm. getTriggeredAlarmId();

  if(id == morningAlarmID) {
    if(hour() != 8 || minute() != 30){
      sprintf(buf,"Morning Alarm Failure: Time %d:%d:%d %d/%d/%d", hour(),minute(),second(),month(),day(),year());
      Serial.println(buf);
    }
  }
  else if (id == afternoonAlarmID) { 
    if(hour() != 13 || minute() != 25){
      sprintf(buf,"Afternoon Alarm Failure: Time %d:%d:%d %d/%d/%d", hour(),minute(),second(),month(),day(),year());
      Serial.println(buf);
    }
  }
  else if (id == eveningAlarmID) { 
    if(hour() != 17 || minute() != 45){
      sprintf(buf,"Evening Alarm Failure: Time %d:%d:%d %d/%d/%d", hour(),minute(),second(),month(),day(),year());
      Serial.println(buf);
    }
  } 
  else if (id == tuesdayAlarmID) { 
    if(hour() != 1 || minute() != 45 || weekday() != dowTuesday){
      sprintf(buf,"Tuesday Alarm Failure: Time %s %d:%d:%d %d/%d/%d", dayStr(day()),hour(),minute(),second(),month(),day(),year());
      Serial.println(buf);
    }
  } 
  else if (id == saturdayAlarmID) { 
    if(hour() != 17 || minute() != 45 || weekday() != dowSaturday){
      sprintf(buf,"Saturday Alarm Failure: Time %s %d:%d:%d %d/%d/%d", dayStr(day()),hour(),minute(),second(),month(),day(),year());
      Serial.println(buf);
    }
  } 
  else { 
    Serial.println("Invalid Alarm ID");
    sprintf(buf,"Time %s %d:%d:%d %d/%d/%d", dayStr(day()),hour(),minute(),second(),month(),day(),year());
    Serial.println(buf);
  }
}

int savedMonth = 0;
int savedHour = 0;

void loop()
{
  if(savedHour != hour()){  //just to let me know it's alive
    savedHour = hour();
    digitalWrite(13, digitalRead(13)==HIGH?LOW:HIGH);   // set the LED on
  }
  if(savedMonth != month()){  // how far it's gotten
    savedMonth = month();
    sprintf(buf,"Time %d:%d:%d %d/%d/%d", hour(),minute(),second(),day(),month(),year());
    Serial.println(buf);
  }

  Alarm.delay(0);
  adjustTime(55);
//  sprintf(buf,"Time %d:%d:%d %d/%d/%d", hour(),minute(),second(),day(),month(),year());
//  Serial.println(buf);
 
}

results:
Code:
Initializing...
Begin test...
Time 0:0:0 1/1/1971
Tuesday Alarm Failure: Time Friday 12:31:18 1/6/1971
Initializing...
Begin test...
Time 0:0:0 1/1/1971
Tuesday Alarm Failure: Time Friday 12:31:18 1/6/1971
Initializing...
Begin test...
Time 0:0:0 1/1/1971
Tuesday Alarm Failure: Time Friday 12:31:18 1/6/1971
Initializing...

The daily alarms seem to be working fine.
730  Community / Bar Sport / Re: Your latest purchase on: June 30, 2011, 04:32:23 pm
Msquare, you are absolutely correct.  Things like microwave turntable motors, defrost timers for freezers and float switches for dishwashers have become easy to find.  Only a few years ago each of these would have cost 20 phone calls and a trip across town to a retailer that would
*** order *** it for you (at a markup).  Last winter I put a fan in my fireplace to blow the heat out.  The manufacturer wanted U$180 for the darn thing and I found one that worked even better with a temperature shut off on ebay for U$35 and it took about 30 minutes to install.

Love the web
731  Community / Bar Sport / Re: Your latest purchase on: June 30, 2011, 03:15:41 pm
I've had the first problem a couple of times, don't seem to have the second one.  You're right, she's a bitch.
732  Using Arduino / Programming Questions / Re: Why is there a delay at the end of void Loop? on: June 30, 2011, 02:42:41 pm
crap, you're right.  I forgot about that darn thing.  BAL put the return address in a register and the went to wherever, then you would BCR or something like it (I forget) to get back.  There were modes and code sections and all kinds of other things that drove programmers nuts trying to do sumthin.

The fortran and cobol compilers of the time sucked too.

We don't know how good we have it these days.
733  Using Arduino / Programming Questions / Re: Why is there a delay at the end of void Loop? on: June 30, 2011, 02:18:18 pm
Quote
Even the lowly PDP8 had "JMS" (JuMp to Subroutine) - even if it was an awkward cuss to use.

Yes, but the IBM360, the flagship computer of the same era, didn't.
734  Community / Bar Sport / Re: Your latest purchase on: June 30, 2011, 01:56:36 pm
As an owner of a mega2560, I'm wondering what makes you call it a 'bitch'.  I have my own personal gripes about the 2560 and would like to know yours as well.  That is, unless 'bitch' has a different meaning in your area.

So, tell me, what has that bitch done that made you mad?
735  Using Arduino / Programming Questions / Re: Why is there a delay at the end of void Loop? on: June 30, 2011, 01:35:33 pm
Oh, good grief.  Almost everyone involved in this discussion is right, and you're arguing about something that will never, ever be decided.

Just a touch of history.  The original languages used didn't have subroutine calls, the machines didn't have a stack, goto was all there was.  People HAD to code using goto.  As time went by, ideas happened and code and machines evolved.  I cut my teeth on an IBM360 and a DEC PDP11/45; one had a stack, the other didn't.  One had something spelled 'call' the other didn't.  Goto was common.

Code written with goto in it was often a problem because there was NOTHING else to help the programmer get done what needed to be done.  So, lousy programmers made a mess of things, just like today with obscure library code and indirect referrences.  Hence the rebellion against goto which software managers took up as an anathema and created 'coding standards' that made people avoid the use of what was once the ONLY flow control method available.  Tons of articles on 'structured programming' touted the 'new' paradigm and it almost became a religion.  Actually from the nature of the various responses, it may actually BE a religion.

Yes, I'm ignoring things like JNZ, jump not zero and JO, jump on overflow because these are just conditional goto statements.

Net, goto is just something that is not worth arguing about in the 21st century with all the other capabilities out there.  If a person wants to use goto, who cares, you don't have to use his code and convincing him what he's doing is somehow wrong isn't going to accomplish much.  Plus, you may be wrong, his method may be better somehow.

The first page of this thread was really useful.  I, for one, didn't know what the actual code was that called setup and loop; that was a valuable part of the discussion.  The timing of the return and call illustrated that hanging inside loop might be useful in time critical situations.  The argument over goto is something that many of us have heard a thousand times and just isn't interesting anymore.

Code it anyway you want to, just use reasonable names and comment the heck out of it.
Pages: 1 ... 47 48 [49] 50 51 ... 64