Dylan, ·· A few thoughts for you to ponder.· You have a block of code in Main which is presumably part of your initialization routines, but in it you do the following:
Main:
' ------ user parameters -----
'select the first motor by default (0,1,2) = (W,X,Y)
motor_select = 0
'all motors are disabled by default
motor_enable(0) = 0
motor_enable(0) = 0
motor_enable(0) = 0
'setup the test tube index: all start at 0
tube_num(0) = 0
tube_num(0) = 0
tube_num(0) = 0
'setup initial dt values for each motor, in minutes
dt(0) = 1
dt(1) = 1
dt(2) = 1
Notice that you're assigning the same array elements three times in a row for the first two groups.· The dt(x) group is fine.
Something else to keep in mind is that all those DEBUG statements take time (and program space) especially at slower baud rates.
I've also never tried to terminate input of the remaining bytes of the DS1302 as you have done so I don't know what effect it will have.· Normally I have used a temp variable in each position which I didn't need the data (day, month, year, etc.) but you removed the variables and are still doing a burst transfer which wants the whole thing at once.· Just some stuff to consider.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Chris Savage Parallax Tech Support csavage@parallax.com
'get the number of minutes since start from each clock
minOfDay(0) = hrs.NIB1(0) * 10 + hrs.NIB0(0) * 6 + mins.NIB1(0) * 10 + mins.NIB0(0)
minOfDay(1) = hrs.NIB1(1) * 10 + hrs.NIB0(1) * 6 + mins.NIB1(1) * 10 + mins.NIB0(1)
minOfDay(2) = hrs.NIB1(2) * 10 + hrs.NIB0(2) * 6 + mins.NIB1(2) * 10 + mins.NIB0(2)
You are not getting what you are expecting, I think.
--- mins.NIB0(1) refers to mins.NIB1, *not* to the minutes nibble in array variable mins(1)
That is because the Stamp thinks it is addressing an array of nibbles, and mins.NIB1 is the one that follows mins.NIB0 in memory.
The first one, where the index is (0) is be fine, because the index zero is self reference. But the index 1 or 2 won't work, because of the nibble array stuff.
I'm not sure how that explains the problem you are seeing, but it is definitely wrong. I expect it has to do with the order in which the program variables are defined.
They are getting mixed up with the array syntax. You are thinking something like
mins(1).NIB0,
but that is not allowable Stamp syntax.
One way to correct this would be to use what we call implicit arrays. Hmmm. Maybe not get into that. Here is a simple fix that uses a different way to extract the nibbles from the bytes:
-- The three clock chips will gradually drift with respect to one another, because they have three separate crystals. After a few months they might be seconds or even minutes apart and off from real time, depending on the extremes of temperature this system experiences. Is relative or real time drift an issue?
-- The above code could have problems every time the number of minutes elapsed hits 1440 and rolls back to zero. For example, suppose the user has selected a period of 13 minutes, which does not divide 1440 evenly. It will work fine 110 times, until the elapsed time arrives at 1430. After 1439 comes zero, and in your code there is no action when minOfDay()=0, so the next action comes when it equals 13. So there is an interval of 9+13=22 minutes instead of 13 minutes. Is that an issue? The easiest way for you to deal with that is to extend the clock read and calculation to include days.
In some of our data logging systems, there are actions that are supposed to occur at specific dates and times to the minute. I have found that the most straightforward way to deal with that is to keep a double precision variable that holds the number of minutes since midnight on 1/1/2001. All of the event dates and times are converted to the same linear scale, which makes comparing the values more straightforward, despite the large numbers and math. Time calculations can be kind of mind twisting.
Yikes. It looks like putting off dinner to write more code has lead to some foolish errors:
1. bad code:
Should look like:
'all motors are disabled by default
motor_enable(0) = 0
motor_enable(1) = 0
motor_enable(2) = 0
'setup the test tube index: all start at 0
tube_num(0) = 0
tube_num(1) = 0
tube_num(2) = 0
Tihs brings up the question, if a variable is not given an initial value, does it automatically start from 0 ?
2. debug statements: are you refering to the SEROUT commands to the LCD ? i plan on removing all of the DEBUG commands. Also, My serial LC dcan also communicate at 19200 baud -- can the BS2 handle this speed as well ?
3. about talking to the RTC : I was trying to save register space be removing some unsed variables. Perhaps it would be best to work with the RTC in the correct way, and try and save register space by the elimination of some other variables. I know that I am probably writing a lot of this code as if it were a high level scripting language, and I wouldn't be surprised if there are some instances of wasted program space/ register space. Any comments on this?
I think this makes sense to me -- essentially what the .NIB{0.1} operator is doing, but with division. I think that this should work fine.
1. Time drift: shouldn't be an issue, as this unit will only be "on" for at most 1 week.
2. dealing with midnight boundary: yes, i think that this might be an issue... as the device may be on, without time resets for more than 24 hours.
The bug introduced by "skipping" the 0th minute of a day was introduced as a way to get around the fact that the following code :
'check: motor enabled? motor flag = 0? seconds = 00? 0th minOfDay != 0?
IF motor_enable(0) = 1 AND motor_flag(0) = 0 AND secs(0) = $00 THEN GOSUB m0
will evaluate to TRUE on the 0th minute of the day -- meaning that the motor will be advanced when the machine is first turned on.
Perhaps a different approach to this might be better: i.e. a flag telling the main loop that the device has just been turned on, and skip the first "false" increment at 0th minute of the day.
I would like to mention a couple things about the operation:
1. the motors are diabled by default when the device is powered on- as not all three motors are always needed. Once a motor is enabled, its timer is reset to 00:00:00 and then countdown until the next motor advance is started.
2. if at any time a motor is disabled, then motor advances for that motor are ignored- once this motor is re-enabled, its timer is again reset to 00:00:00 and the countdown starts again.
The idea is that we need to be able to operate each motor independently of the others, and that not all 30 positions in the test tube rack will be used at any one time. See image:
·· All variables are initialized to zero at startup, so if you're never re-initializing then the code is redundant.· I wasn't looking for that, just the fact that it was being re-assigned.· If you'll be removing the DEBUG statements that's great and you should suddenly see a small boost in performance as each line of text is being sent as 9600 bps, along with your LCD code this can slow response time down.· Moving the LCD baud up to 19200 should help.·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Chris Savage Parallax Tech Support csavage@parallax.com
I have removed all of the debug statements and most of the useless output to the LCD. As you suggested, changing the baud rate to 19200 sped things up a bit.
However, we still have two outstanding issues with this project:
1. dealing with total time intervals > 24 hours , and dealing with the 0th hour of the day.
I think that this can be partialy fixed by starting the clock at 1am, so that the following statement is not evalusated are TRUE when the unit is first turned on:
'check: motor enabled? motor flag = 0? seconds = 00? 0th minOfDay != 0?
IF motor_enable(0) = 1 AND motor_flag(0) = 0 AND secs(0) = $00 THEN GOSUB m0
...however, I think that this might involve adjusting the "phase parameter accordingly":
phase = 1 '??
motor_flag(0) = minOfDay(0) + 1440 + phase // dt(0) MAX 1 ' = 0 when it is time to advance motor 1, =1 otherwise
2. the second issue is preventing the motor from incrementing more than once per TRUE evaluation of :
'check: motor enabled? motor flag = 0? seconds = 00? 0th minOfDay != 0?
IF motor_enable(0) = 1 AND motor_flag(0) = 0 AND secs(0) = $00 THEN GOSUB m0
right now, the program is running through the main loop about 6 times per second -- which means that the above code is evaluated to TRUE 6 times per every one time that it should be evaluated to TRUE. We are nearly out of variable space, but perhaps a BIT variable could be used to "flag" the above code to only run once.... just not sure how to implement it.
·· As for the second issue you can easily stop it from making multiple triggers using a flag that is set and then cleared once the values are no longer equal.· This tactic is used all the time in loops, especially in clock systems so that the alarm isn't re-triggered in certain situations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Chris Savage Parallax Tech Support csavage@parallax.com
When I want something to happen once and only once, I use logic that detects the *transition* from (condition not true) to (condition true). That is, don't simply base the action on (condition true), which is what your program does now, and as you have observed, the condition might be true several times in a row before it again becomes (condition not true). But the transition from no to yes happens only once, and that is what should trigger the motor action.
Here is what the trigger statement should look like:
IF motorEnable(0) AND motorTime(0) THEN GOSUB m0 ' where one condition embodies preferences and the other alarm times
To do this, you have variables set up as follows. This is going to use implicit arrays, which are more flexible than explicit ones. I think you have several arrays in the program that
don't really need to be arrays. For example, it seems to me there is no need to keep the real time variables as in arrays. Those should reduce down to a single-bit arrays for motor and alarm flags.
The following also rolls day of month into the time calculation, so it is good to go for 31 days running, and that way you can dispose of the phase variable. There are 44640 minutes in a 31-day month, so it fits in one word variable for the math.
motorEnableFlags VAR Nib ' overall enable set by user preference
motorEnable VAR motorEnableFlags.bit0 ' alias bit 0: array addressable as motorEnable(0), motorEnable(1) etc.
motorTimeFlags VAR Nib ' flag goes to =1 only when it is time to turn on the motor and stays =1 for only one time through the loop
motorTime VAR motorTimeFlags.bit0 ' alias bit 0: array addressable as motorTime(0) etc.
timeFlags VAR nib ' for a state machine, past state
timeFlag VAR timeFlags.bit0 ' array addresable as timeFlag(0), timeFlag(1) etc.
Julian VAR word ' temporary variable to hold minute of month 0 to 44639, and calculation, this variable is disposible after use.
timeBit VAR bit ' for calculation, also temporary disposible after use
SHIFTIN DataIO0, Clock, LSBPRE, [noparse][[/noparse]secs, mins, hrs, day, day] ' time, read day, trash day of week.
Julian = (day *1440) + (hrs.NIB1 * 10 + hrs.NIB0 * 6 + mins.NIB1 * 10 + mins.NIB0) ' minute of month
Julian = Julian // dt(0) ' reduced to modulo dt()
timeBit = ~(Julian MAX 1) ' = 1 when it is time to advance motor 0, note that ~ inverts 0 to 1 (NOT)
motorTime(0) = timeFlag(0) ^ timeBit & timeBit ' this is the bottom line transition for the motor time
timeFlag(0) = timeBit ' this bit is the only thing that needs to be saved about the state of the clock
IF motorEnable(0) AND motorTime(0) THEN GOSUB m0 ' happens only if motor is selected on, and time has made an alarm transition.
The program needs to go through the above routine for each RTC/motor combination.
The motorTime(0) bit starts off equal to zero, so the motors start off idle. Then when the time selected by dt(0) rolls around, motorTime(0) goes high for only one and only one time through the loop. The logic involving timeBit and past state timeFlag(0) enforces that, with operations involving ^ and & (the bitwise XOR and AND operators).
Wow. thanks again Tracy for the great comments and ideas... I was starting to think that I had the "trigger" issue resolved before I saw your post, but was still worried about dealing with dt and day of month values which are larger than 255 ... there isn't much room for two Word(3) variables.
I will give your sample code a try this afternoon and report back with the results. One quick question though: with your example is it possible to address all three RTC units, or am i now limited to using just one?
the only reason that i ask, is that the three motors will not be operating from the same "time base" i.e. each one of them will be started and stopped at various times throughout the day based on soil property-induced changes in the movement of solution through the soil columns...
having some problems implementing your suggested code. here are my questions by section:
motorEnableFlags VAR Nib ' overall enable set by user preference
motorEnable VAR motorEnableFlags.BIT0 ' alias bit 0: array addressable as motorEnable(0), motorEnable(1) etc.
motorTimeFlags VAR Nib ' flag goes to =1 only when it is time to turn on the motor and stays =1 for only one time through the loop
motorTime VAR motorTimeFlags.BIT0 ' alias bit 0: array addressable as motorTime(0) etc.
timeFlags VAR Nib ' for a state machine, past state
timeFlag VAR timeFlags.BIT0 ' array addresable as timeFlag(0), timeFlag(1) etc.
Julian VAR Word ' temporary variable to hold minute of month 0 to 44639, and calculation, this variable is disposible after use.
timeBit VAR Bit ' for calculation, also temporary disposible after use
do these variable definitions need to be included in the main loop: i.e. do they need to be reset with each run of the main loop?
HIGH rtc(0) ' Select DS1302
SHIFTOUT DataIO, Clock, LSBFIRST, [noparse][[/noparse]RdBurst]
SHIFTIN DataIO, Clock, LSBPRE, [noparse][[/noparse]secs, mins, hrs, day, day] ' time, read day, trash day of week.
LOW rtc(0) ' Deselect DS1302
i added the HIGH, LOW, and SHIFTOUT statements here to make the RTC work... not sure if you ommited them on purpose...
Julian = (day *1440) + (hrs.NIB1 * 10 + hrs.NIB0 * 6 + mins.NIB1 * 10 + mins.NIB0) ' minute of month
Julian = Julian // dt(0) ' reduced to modulo dt()
timeBit = ~(Julian MAX 1) ' = 1 when it is time to advance motor 0, note that ~ inverts 0 to 1 (NOT)
motorTime(0) = timeFlag(0) ^ timeBit & timeBit ' this is the bottom line transition for the motor time
timeFlag(0) = timeBit ' this bit is the only thing that needs to be saved about the state of the clock
IF motorEnable(0) AND motorTime(0) THEN GOSUB m0 ' happens only if motor is selected on, and time has made an alarm transition.
the above code doesn't _seem_ to be doing anything... unless the dt value is greater than 1 minute..
I have attached a partly working program, but i think that my implementation is not quite correct.
Any ideas, clarification would be great! thanks again,
I haven't looked at your program listing in detail to see what else is going on.
Have I got this straight?
-- The intervals are quantized in units of minutes and stored in variables dt(0), dt(1) and dt(2).
-- There is a bit that enables or disables each motor, stored in motorEnable(0) motorenable(1) and motorEnable(2).
The motor is enabled or disabled by the end user. The associated RTC is reset to zero and strarts counting elapsed
time when a motor becomes enabled.
-- There is a bit that becomes 1 when the time comes for a motor action, one for each motor, motorTime(0),
motorTime(1) and motorTime(2). Those bits become 1 for only one pass through the loop when the time comes,
so the motor action will be taken once and only once when the motor is enabled at multiples of interval dt().
For example, if motors 0 is enabled for 10 minute intervals stardting at noon and motor 1 is enabled for 3 minute
intervals starting at 14:05, then motor 0 will take one step at 12:10, 12:20, 12:30,... and so on, and motor 1 will do so at
14:08, 14:11, 14:14... and so on.
-- There is one more set of 3 bits, timeFlag(0), timeFlag(1) and timeFlag(2) that hold on to the past state of the
time bits and allow the state machine to detect transitions.
The code I am suggesting is the state machine. The code runs every time through the loop, and outputs the
motorTimeFlags that go into deciding whether to move a motor or not. It should reduce the number of variables
required.
This won't work as written for dt() = 1 minute, because the flag is always 1, and it needs to have a cycle, like 010101.. for a 2 minute dt,
or 000100010001....., for a 4 minute dt, etc.. Only works for dt() = 2,3,.... Do you need the option of a 1 minute dt()?
' untested snippet
dt VAR Word(3) ' to allow for dt()>255
dataIO CON 0 ' use the first bit of your contiguous RTC dataIO pins here
' -- ask if you don't understand what I mean, dataIO on p0,p1,p2
rtc CON 3 ' ditto, rtc on p3,p4, p5
motorEnableFlags VAR Nib ' overall enable set by user preference
motorEnable VAR motorEnableFlags.bit0 ' alias bit 0: array addressable as motorEnable(0), motorEnable(1) etc.
motorTimeFlags VAR Nib ' flag goes to =1 only when it is time to turn on the motor and stays =1 for only one time through the loop
motorTime VAR motorTimeFlags.bit0 ' alias bit 0: array addressable as motorTime(0) etc.
timeFlags VAR nib ' for a state machine, past state
timeFlag VAR timeFlags.bit0 ' array addresable as timeFlag(0), timeFlag(1) etc.
Julian VAR word ' temporary variable to hold minute of month 0 to 44639, and calculation, this variable is disposible after use.
timeBit VAR bit ' for calculation, also temporary disposible after use
FOR idx = 0 TO 2
HIGH rtc+idx ' Select DS1302
SHIFTOUT DataIO+idx, Clock, LSBFIRST, [noparse][[/noparse]RdBurst] ' use the individual dataIO() pin.
SHIFTIN DataIO+idx, Clock, LSBPRE, [noparse][[/noparse]secs, mins, hrs, day, day]
' time, read day, trash day-of-week.
LOW rtc+idx ' Deselect DS1302
Julian = (day *1440) + (hrs.NIB1 * 10 + hrs.NIB0 * 6 + mins.NIB1 * 10 + mins.NIB0) ' elapsed minutes
DEBUG DEC Julian, TAB
Julian = Julian // dt(idx) ' reduced to modulo dt()
DEBUG DEC Julian,TAB
timeBit = Julian MAX 1 ' = 0 when dt() minutes have passed
motorTime(idx) = timeFlag(idx) ^ timeBit & timeFlag(idx) ' transition time
DEBUG BIN1 motorTime(idx),TAB
timeFlag(idx) = timeBit ' save current state of the clock
NEXT
DEBUG CR
IF motorEnable(0) AND motorTime(0) THEN GOSUB m0
IF motorEnable(1) AND motorTime(1) THEN GOSUB m1
IF motorEnable(2) AND motorTime(2) THEN GOSUB m2
Great! your last post helped me to understand what is going on. We do not need time intervals of less than 2 minutes, so we wont have to address the issues related to that...
I have successfully integrated your state machine approach to our project, and it works! In fact it works nearly perfectly.
There are two small glitches that seem to occur randomly.
1. while the unit is running, and motors are "enabled", increasing the motor increment interval (dt) will *sometimes* cause the motor to increment even if the defined time interval has _not_ yet elapsed. I can't seem to be able to get this to happen on a regular basis, but it has happened a couple times. Possibly realted to this fact, if a motor has been disabled and its timer has been running, enabling this motor will sometimes cause it to advance immediately.
I think that this might have to do with the fact that all RTC units are set when the device is powered on.
'run at power-on time
gosub Init_RTC
attached is the full program listing
Init_RTC:
FOR idx = 0 TO 2
reg = CWPr ' Initialize DS1302
ioByte = WPr0 ' Clear Write Protect
GOSUB RTC_Out
GOSUB Set_Time
NEXT
PAUSE 5
RETURN
RTC_Out:
HIGH rtc+idx ' Select DS1302
SHIFTOUT DataIO, Clock, LSBFIRST, [noparse][[/noparse]reg, ioByte]
LOW rtc+idx ' Deselect DS1302
RETURN
Set_Time:
day = $00
hrs = $00 ' DS1302 Burst Write
mins = $00
secs = $00
HIGH rtc+idx ' Select DS1302
SHIFTOUT DataIO, Clock, LSBFIRST, [noparse][[/noparse]WrBurst]
SHIFTOUT DataIO, Clock, LSBFIRST, [noparse][[/noparse]secs, mins, hrs,date, month, day, year, 0]
LOW rtc+idx ' Deselect DS1302
RETURN
2. the other slight problem is that at seemingly random long time intervals ( > 3 hours) a motor will magically disable itself, i.e. motorEnable(0) will go from 1 -> 0 .
This should only happen if that motor is selected, and a button is pressed. Could electrical noise or the like be causing pins to think that they have changed from LOW to HIGH ? I recall hearing that a small value capacitor can be used to mitgate these type of problems.
Any thoughts on these issues?
PS we are actively testing this device with real samples -- with mostly excellent results!
With regard to problem 1, are you resetting the associated elapsed time clock to zero when you reset dt()? You have to do that, otherwise the next activation could happen anytime from one minute to dt mintues later.
For number 2, I have no idea. Coulld be a program error. If everything rezeros at once, it could be a processor reset.. You'll have to dig for that one.
Congrats on the excellent results!! What is your sampler sampling?
it is usually only one motor that will go from being enabled to disabled - and only if it is "selected" - other motors are not affected. I will try and collect more information on this -- as I am not the person using this device - just the one stuck with building it. [noparse]:)[/noparse]
problem #1:
when we reset an RTC unit before changing its associated dt value, everything works as expected. I am curious as to why adding time to a dt value can cause the motor to increment prematurely.... It only happens sometimes -- that is the strange part.
Comments
·· A few thoughts for you to ponder.· You have a block of code in Main which is presumably part of your initialization routines, but in it you do the following:
Notice that you're assigning the same array elements three times in a row for the first two groups.· The dt(x) group is fine.
Something else to keep in mind is that all those DEBUG statements take time (and program space) especially at slower baud rates.
I've also never tried to terminate input of the remaining bytes of the DS1302 as you have done so I don't know what effect it will have.· Normally I have used a temp variable in each position which I didn't need the data (day, month, year, etc.) but you removed the variables and are still doing a burst transfer which wants the whole thing at once.· Just some stuff to consider.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
There is a problem with expressions of this form:
You are not getting what you are expecting, I think.
--- mins.NIB0(1) refers to mins.NIB1, *not* to the minutes nibble in array variable mins(1)
That is because the Stamp thinks it is addressing an array of nibbles, and mins.NIB1 is the one that follows mins.NIB0 in memory.
The first one, where the index is (0) is be fine, because the index zero is self reference. But the index 1 or 2 won't work, because of the nibble array stuff.
I'm not sure how that explains the problem you are seeing, but it is definitely wrong. I expect it has to do with the order in which the program variables are defined.
They are getting mixed up with the array syntax. You are thinking something like
mins(1).NIB0,
but that is not allowable Stamp syntax.
One way to correct this would be to use what we call implicit arrays. Hmmm. Maybe not get into that. Here is a simple fix that uses a different way to extract the nibbles from the bytes:
Other notes:
-- The three clock chips will gradually drift with respect to one another, because they have three separate crystals. After a few months they might be seconds or even minutes apart and off from real time, depending on the extremes of temperature this system experiences. Is relative or real time drift an issue?
-- The above code could have problems every time the number of minutes elapsed hits 1440 and rolls back to zero. For example, suppose the user has selected a period of 13 minutes, which does not divide 1440 evenly. It will work fine 110 times, until the elapsed time arrives at 1430. After 1439 comes zero, and in your code there is no action when minOfDay()=0, so the next action comes when it equals 13. So there is an interval of 9+13=22 minutes instead of 13 minutes. Is that an issue? The easiest way for you to deal with that is to extend the clock read and calculation to include days.
In some of our data logging systems, there are actions that are supposed to occur at specific dates and times to the minute. I have found that the most straightforward way to deal with that is to keep a double precision variable that holds the number of minutes since midnight on 1/1/2001. All of the event dates and times are converted to the same linear scale, which makes comparing the values more straightforward, despite the large numbers and math. Time calculations can be kind of mind twisting.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Nice project!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
Yikes. It looks like putting off dinner to write more code has lead to some foolish errors:
1. bad code:
Should look like:
Tihs brings up the question, if a variable is not given an initial value, does it automatically start from 0 ?
2. debug statements: are you refering to the SEROUT commands to the LCD ? i plan on removing all of the DEBUG commands. Also, My serial LC dcan also communicate at 19200 baud -- can the BS2 handle this speed as well ?
3. about talking to the RTC : I was trying to save register space be removing some unsed variables. Perhaps it would be best to work with the RTC in the correct way, and try and save register space by the elimination of some other variables. I know that I am probably writing a lot of this code as if it were a high level scripting language, and I wouldn't be surprised if there are some instances of wasted program space/ register space. Any comments on this?
Thanks again for your input,
Dylan
Good points... about the first block of code:
I tried this method after getting syntax errors when using the syntax:
Looking at your suggested alternative:
I think this makes sense to me -- essentially what the .NIB{0.1} operator is doing, but with division. I think that this should work fine.
1. Time drift: shouldn't be an issue, as this unit will only be "on" for at most 1 week.
2. dealing with midnight boundary: yes, i think that this might be an issue... as the device may be on, without time resets for more than 24 hours.
The bug introduced by "skipping" the 0th minute of a day was introduced as a way to get around the fact that the following code :
'check: motor enabled? motor flag = 0? seconds = 00? 0th minOfDay != 0? IF motor_enable(0) = 1 AND motor_flag(0) = 0 AND secs(0) = $00 THEN GOSUB m0will evaluate to TRUE on the 0th minute of the day -- meaning that the motor will be advanced when the machine is first turned on.
Perhaps a different approach to this might be better: i.e. a flag telling the main loop that the device has just been turned on, and skip the first "false" increment at 0th minute of the day.
I would like to mention a couple things about the operation:
1. the motors are diabled by default when the device is powered on- as not all three motors are always needed. Once a motor is enabled, its timer is reset to 00:00:00 and then countdown until the next motor advance is started.
2. if at any time a motor is disabled, then motor advances for that motor are ignored- once this motor is re-enabled, its timer is again reset to 00:00:00 and the countdown starts again.
The idea is that we need to be able to operate each motor independently of the others, and that not all 30 positions in the test tube rack will be used at any one time. See image:
·· All variables are initialized to zero at startup, so if you're never re-initializing then the code is redundant.· I wasn't looking for that, just the fact that it was being re-assigned.· If you'll be removing the DEBUG statements that's great and you should suddenly see a small boost in performance as each line of text is being sent as 9600 bps, along with your LCD code this can slow response time down.· Moving the LCD baud up to 19200 should help.·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
I have removed all of the debug statements and most of the useless output to the LCD. As you suggested, changing the baud rate to 19200 sped things up a bit.
However, we still have two outstanding issues with this project:
1. dealing with total time intervals > 24 hours , and dealing with the 0th hour of the day.
I think that this can be partialy fixed by starting the clock at 1am, so that the following statement is not evalusated are TRUE when the unit is first turned on:
'check: motor enabled? motor flag = 0? seconds = 00? 0th minOfDay != 0? IF motor_enable(0) = 1 AND motor_flag(0) = 0 AND secs(0) = $00 THEN GOSUB m0...however, I think that this might involve adjusting the "phase parameter accordingly":
2. the second issue is preventing the motor from incrementing more than once per TRUE evaluation of :
'check: motor enabled? motor flag = 0? seconds = 00? 0th minOfDay != 0? IF motor_enable(0) = 1 AND motor_flag(0) = 0 AND secs(0) = $00 THEN GOSUB m0right now, the program is running through the main loop about 6 times per second -- which means that the above code is evaluated to TRUE 6 times per every one time that it should be evaluated to TRUE. We are nearly out of variable space, but perhaps a BIT variable could be used to "flag" the above code to only run once.... just not sure how to implement it.
attached is the latest version of the program.
thanks again!
Dylan
·· As for the second issue you can easily stop it from making multiple triggers using a flag that is set and then cleared once the values are no longer equal.· This tactic is used all the time in loops, especially in clock systems so that the alarm isn't re-triggered in certain situations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
When I want something to happen once and only once, I use logic that detects the *transition* from (condition not true) to (condition true). That is, don't simply base the action on (condition true), which is what your program does now, and as you have observed, the condition might be true several times in a row before it again becomes (condition not true). But the transition from no to yes happens only once, and that is what should trigger the motor action.
Here is what the trigger statement should look like:
IF motorEnable(0) AND motorTime(0) THEN GOSUB m0 ' where one condition embodies preferences and the other alarm times
To do this, you have variables set up as follows. This is going to use implicit arrays, which are more flexible than explicit ones. I think you have several arrays in the program that
don't really need to be arrays. For example, it seems to me there is no need to keep the real time variables as in arrays. Those should reduce down to a single-bit arrays for motor and alarm flags.
The following also rolls day of month into the time calculation, so it is good to go for 31 days running, and that way you can dispose of the phase variable. There are 44640 minutes in a 31-day month, so it fits in one word variable for the math.
The program needs to go through the above routine for each RTC/motor combination.
The motorTime(0) bit starts off equal to zero, so the motors start off idle. Then when the time selected by dt(0) rolls around, motorTime(0) goes high for only one and only one time through the loop. The logic involving timeBit and past state timeFlag(0) enforces that, with operations involving ^ and & (the bitwise XOR and AND operators).
I hope that helps a bit, or two bits worth.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I will give your sample code a try this afternoon and report back with the results. One quick question though: with your example is it possible to address all three RTC units, or am i now limited to using just one?
the only reason that i ask, is that the three motors will not be operating from the same "time base" i.e. each one of them will be started and stopped at various times throughout the day based on soil property-induced changes in the movement of solution through the soil columns...
thanks.
having some problems implementing your suggested code. here are my questions by section:
do these variable definitions need to be included in the main loop: i.e. do they need to be reset with each run of the main loop?
i added the HIGH, LOW, and SHIFTOUT statements here to make the RTC work... not sure if you ommited them on purpose...
the above code doesn't _seem_ to be doing anything... unless the dt value is greater than 1 minute..
I have attached a partly working program, but i think that my implementation is not quite correct.
Any ideas, clarification would be great! thanks again,
Dylan
I haven't looked at your program listing in detail to see what else is going on.
Have I got this straight?
-- The intervals are quantized in units of minutes and stored in variables dt(0), dt(1) and dt(2).
-- There is a bit that enables or disables each motor, stored in motorEnable(0) motorenable(1) and motorEnable(2).
The motor is enabled or disabled by the end user. The associated RTC is reset to zero and strarts counting elapsed
time when a motor becomes enabled.
-- There is a bit that becomes 1 when the time comes for a motor action, one for each motor, motorTime(0),
motorTime(1) and motorTime(2). Those bits become 1 for only one pass through the loop when the time comes,
so the motor action will be taken once and only once when the motor is enabled at multiples of interval dt().
For example, if motors 0 is enabled for 10 minute intervals stardting at noon and motor 1 is enabled for 3 minute
intervals starting at 14:05, then motor 0 will take one step at 12:10, 12:20, 12:30,... and so on, and motor 1 will do so at
14:08, 14:11, 14:14... and so on.
-- There is one more set of 3 bits, timeFlag(0), timeFlag(1) and timeFlag(2) that hold on to the past state of the
time bits and allow the state machine to detect transitions.
The code I am suggesting is the state machine. The code runs every time through the loop, and outputs the
motorTimeFlags that go into deciding whether to move a motor or not. It should reduce the number of variables
required.
This won't work as written for dt() = 1 minute, because the flag is always 1, and it needs to have a cycle, like 010101.. for a 2 minute dt,
or 000100010001....., for a 4 minute dt, etc.. Only works for dt() = 2,3,.... Do you need the option of a 1 minute dt()?
' untested snippet dt VAR Word(3) ' to allow for dt()>255 dataIO CON 0 ' use the first bit of your contiguous RTC dataIO pins here ' -- ask if you don't understand what I mean, dataIO on p0,p1,p2 rtc CON 3 ' ditto, rtc on p3,p4, p5 motorEnableFlags VAR Nib ' overall enable set by user preference motorEnable VAR motorEnableFlags.bit0 ' alias bit 0: array addressable as motorEnable(0), motorEnable(1) etc. motorTimeFlags VAR Nib ' flag goes to =1 only when it is time to turn on the motor and stays =1 for only one time through the loop motorTime VAR motorTimeFlags.bit0 ' alias bit 0: array addressable as motorTime(0) etc. timeFlags VAR nib ' for a state machine, past state timeFlag VAR timeFlags.bit0 ' array addresable as timeFlag(0), timeFlag(1) etc. Julian VAR word ' temporary variable to hold minute of month 0 to 44639, and calculation, this variable is disposible after use. timeBit VAR bit ' for calculation, also temporary disposible after use FOR idx = 0 TO 2 HIGH rtc+idx ' Select DS1302 SHIFTOUT DataIO+idx, Clock, LSBFIRST, [noparse][[/noparse]RdBurst] ' use the individual dataIO() pin. SHIFTIN DataIO+idx, Clock, LSBPRE, [noparse][[/noparse]secs, mins, hrs, day, day] ' time, read day, trash day-of-week. LOW rtc+idx ' Deselect DS1302 Julian = (day *1440) + (hrs.NIB1 * 10 + hrs.NIB0 * 6 + mins.NIB1 * 10 + mins.NIB0) ' elapsed minutes DEBUG DEC Julian, TAB Julian = Julian // dt(idx) ' reduced to modulo dt() DEBUG DEC Julian,TAB timeBit = Julian MAX 1 ' = 0 when dt() minutes have passed motorTime(idx) = timeFlag(idx) ^ timeBit & timeFlag(idx) ' transition time DEBUG BIN1 motorTime(idx),TAB timeFlag(idx) = timeBit ' save current state of the clock NEXT DEBUG CR IF motorEnable(0) AND motorTime(0) THEN GOSUB m0 IF motorEnable(1) AND motorTime(1) THEN GOSUB m1 IF motorEnable(2) AND motorTime(2) THEN GOSUB m2▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Great! your last post helped me to understand what is going on. We do not need time intervals of less than 2 minutes, so we wont have to address the issues related to that...
I have successfully integrated your state machine approach to our project, and it works! In fact it works nearly perfectly.
There are two small glitches that seem to occur randomly.
1. while the unit is running, and motors are "enabled", increasing the motor increment interval (dt) will *sometimes* cause the motor to increment even if the defined time interval has _not_ yet elapsed. I can't seem to be able to get this to happen on a regular basis, but it has happened a couple times. Possibly realted to this fact, if a motor has been disabled and its timer has been running, enabling this motor will sometimes cause it to advance immediately.
I think that this might have to do with the fact that all RTC units are set when the device is powered on.
'run at power-on time gosub Init_RTC attached is the full program listing Init_RTC: FOR idx = 0 TO 2 reg = CWPr ' Initialize DS1302 ioByte = WPr0 ' Clear Write Protect GOSUB RTC_Out GOSUB Set_Time NEXT PAUSE 5 RETURN RTC_Out: HIGH rtc+idx ' Select DS1302 SHIFTOUT DataIO, Clock, LSBFIRST, [noparse][[/noparse]reg, ioByte] LOW rtc+idx ' Deselect DS1302 RETURN Set_Time: day = $00 hrs = $00 ' DS1302 Burst Write mins = $00 secs = $00 HIGH rtc+idx ' Select DS1302 SHIFTOUT DataIO, Clock, LSBFIRST, [noparse][[/noparse]WrBurst] SHIFTOUT DataIO, Clock, LSBFIRST, [noparse][[/noparse]secs, mins, hrs,date, month, day, year, 0] LOW rtc+idx ' Deselect DS1302 RETURN2. the other slight problem is that at seemingly random long time intervals ( > 3 hours) a motor will magically disable itself, i.e. motorEnable(0) will go from 1 -> 0 .
This should only happen if that motor is selected, and a button is pressed. Could electrical noise or the like be causing pins to think that they have changed from LOW to HIGH ? I recall hearing that a small value capacitor can be used to mitgate these type of problems.
Any thoughts on these issues?
PS we are actively testing this device with real samples -- with mostly excellent results!
Thanks again,
Dylan
For number 2, I have no idea. Coulld be a program error. If everything rezeros at once, it could be a processor reset.. You'll have to dig for that one.
Congrats on the excellent results!! What is your sampler sampling?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I will start with problem #2:
it is usually only one motor that will go from being enabled to disabled - and only if it is "selected" - other motors are not affected. I will try and collect more information on this -- as I am not the person using this device - just the one stuck with building it. [noparse]:)[/noparse]
problem #1:
when we reset an RTC unit before changing its associated dt value, everything works as expected. I am curious as to why adding time to a dt value can cause the motor to increment prematurely.... It only happens sometimes -- that is the strange part.
thanks for the ideas,
Dylan