Good morning, ··· The file attached is a "Working" model for the following:
1) Global Varibals for the Timers are capable of being programmed ··· from either location via an "RF" Link.
2) Countdown via all three timers are now being Displayed on the ··· LCD. Once the count terminates the screen is Cleared and the ··· current Values of all the Timers are displayed on the screen.
3) Output to the Quenching station Motor is operable and comes on ··· when any of the Timers start counting and turnes off when the ··· Count is finished.
·· I am working on the last step of the process now which is to transmit ·· the Timers values to the remote Prop via the "RF" Link. This is so the ·· Remote Prop will show the count decremented on it's screen as well as ··the Prop at the Quenching station where the Motor is located.
·· Note: Would like to say a special Thank You to stevenmess2004 & stefanL38. ·· I could not have gotton this far so quick without their patience and well ·· documented examples.
The "updated" attached file includes the following:
1) I have included the methods to display the countdown ··· on the Remote Prop "Office Prop" via "RF". I can view the countdown on Timers ··· 1,2 & 3 depending on which Limit switch was thrown. The only ···problem I am having is when I make Limit switch - 1·at the Quenching Station ··· The display on the Office Prop shows 1 & 2 counting down. When I Make ··· Limit switch - 2, The display shows 2 & 3 counting down. When I make ··· Limit switch - 3, only Timer - 3 is counting down "as wanted" on the Office Prop. ··· I presume that now may be a good time to incorperate the "Locks". It appears ··· that everything is operating correctly except fo this. ···almost there stevenmess2004 & stefanL38 ··· ··· If you guys see where the problem is let me know, I believe that this is the ··· very last step in the process. After that I will concentrate on just cleaning ··· things up and studying what you guys have taught me so I can code more ··· efficiently.
··· I am going to take a video of the system operating and send it to you guys, ··· You need to see "our" system working :>)
if Count_4 < 10 'If Timer_1 value is less than "10"
data.dec(0)
data.dec(0)
data.dec(Count_4)
if Count_4 < 100 'If Timer_1 value is less than "100"
data.dec(0)
data.dec(Count_4)
if Count_4 < 256 'If Timer_1 value is less than "100"
data.dec(Count_4)
sends one leading 0 as soon as you are under 100 and then the value
and as soon as you are under 10 it is sending 2 leading 0 and value and then
the second condition is still true and it is sended again
This means yuo are sending the value two times
you should change your code to the following:
if Count_4 < 100 'If Timer_1 value is less than "100" send a leading 0 for first digit
data.dec(0)
if Count_4 < 10 'If Timer_1 value is less than "10" send a leading 0 for second digit
data.dec(0)
data.dec(Count_4)
if you go under 100 ONE additional leading zero is needed
if you go under 10 a SECOND leading zero is needed (the first zero comes from the condition if Count_4 < 100
which is still true and that makes in summary two leading zeros
and after the (eventual) needed leading zeros send the value itself only ONCE UNCONDITIONAL
now your code has three independend running methods
two of them are writing on the LCD at the same rows and columms
inputs via the keypad are working this way:
The last input counts: if somebody starts typing the three values at the office-prop
and somebody else starts typing on the quenchstation-prop,
the values of that man that types in the last digit, becomes valid
and the other is overwritten.
Do you want to have it this way? Or do you intend it another way?
best regards
Stefan
Post Edited (StefanL38) : 3/22/2008 10:45:21 PM GMT
Thank You guys, I will try this tommorow when I get back to work. The project is acomplishing about 98% of what I need it to do
as this is the last Major issue that I have as far as functions are concerned. I know that I have alot of cleaning up and streamlining to do but its really exciting for me to see it working to this point. This is a major step in our control system for the future...
I appreciate your help,
JMLStamp2p
Hello Guys,
Note: See attached "Spin" File for the latest code.
I have replaced my code as suggested by "stevenmess2004" in his latest post.
Everything is working correctly except for one small issue. When I make the
Limit switch at the Quenching Station prop location its LCD starts decrementing the
count, as does·the Remote office Prop·which shows·the count decrementing as it
should·in the correct format but stops when it reach's "1". I would like for it to show
the original value that it started decrementing from which should be "TValue_1". I
have been away from the code for a few days so I'm have to get the sequences back
in my Head :>)
I will be working at getting this last·small error straightened out and will be working
on incorperating the "Locks" for the next couple of days. If anyone has any
suggestions on how to fix this please post a· sample code fragment.
Thank You to stevenmess2004 for your last code fragment suggestion which
straightened out the LCD readout on the Remote "Office" Prop.
waitcnt(80_000_000 + cnt) 'if you change this to waitcnt(clkfreq+cnt) it will automatically adjust itself if you change the clock frequency say by using a 6MHz crystal
'Wait "1" second.
and here
Waitcnt(160_000_000 + cnt) 'change to waitcnt(clkfreq*2+cnt)
Now if I understand you want the original value of seconds to be displayed when the countdown finishes. All you need to do is add in some code after the repeat loop to send the value of seconds to the LCD. So add something like this
data_LCD.tx(254)
data_LCD.tx(71)
data_LCD.tx(10)
data_LCD.tx(3)
data_LCD.dec(Count_4)
'Print current value of Count_4 to the LCD. at location
'Col-18, Row-2.
(I just took this from the repeat look so it may need fixing) after this code in Output_4 (and the other output methods)
i have thought about the things that should work parallel in your application.
if you REALLY NEED everything to work parallel this will mean quites an effort for managing this without messing up the datastreams coming in and sended out by each prop
for example: somebody starts typing in new timervalues at the quenchstation. At the same time somebody starts to type in new timervalues in the office
Let's say at the quenchstation the typing is finished first. Then it will send out the values. These values first get to the receivebuffer of fullduplex-serial of the officeprop.
If you want to display on the LCD as soon as they arrive while you are typing in new values on the officeprop this causes difficulties. Because you want to have a
instant feedback on the LCD as you type one digit. The lockmechanism has locked the display for others than RxStr. So PUB Received_Data waits until it is unlocked.
You finish typing in and the officeprop sends out HIS Timervalues. After that sending to the LCD becomes unlocked. The PUB Received_Data gets the timervalues of the quenchprop and shows them on the display
and oops ! now you have different values in the two props !
So their has to be a priority or a second lock if one prop is in "type-in-timer-values-mode"
One easy solution could be to lock keypad-typing as long as a countdown is running or the other prop
has already startet keypad-typing. This would make it secure that the data is processed in a sequential way.
Here i need a very detailed description what HAS TO BE REALLY parallel.
If really EVERYTHING should be parallel the solution could be to define areas on the LCD that are strictly only for ONE purpose.
one area for keypad-typing-feedback
one area for countdown is running and its actual values
one area for preset timervalues
then it could work this way:
defining a LCD-Buffer of 4x20=80 bytes
the different methods like RxStr, received_data etc. write only into THEIR particular bufferarea
then there is another method that updates the content of the LCD by reading the complete buffer
and which is the ONLY ONE which sends data to the LCD.
I think the data that is send out to the other prop needs a header that marks what kind of data it is:
actual countdown-values or a new set of timer-values
Still there will be the need of a lock-mechanism that only one method is sending out data to the other prop
at one time to avoid datacollision / mixing up the datastreams. Or to have a sendbuffer too.
The different methods write to the sendbuffer to their PARTICULAR place and there is only ONE method that reads the sendbuffer
and sends out the complete data all the time.
Then the only thing that could happen, is, that - for a short moment - the data could be half old half new because
one method has not yet finished write to the buffer. With the next sending it will be completed.
Maybe the display could have a row-columm with titel design:
First row has collums for preset-value, actual-value, Keypad-typing-feedback
in the 2nd 3rd, 4th-row there are the values itself
best regards
Stefan
Post Edited (StefanL38) : 3/28/2008 12:20:23 PM GMT
SteFanL38,
your suggestion to "lock keypad-typing as long as a countdown is running" solution would work best as far as
running interferance between Props. The chance of two people operating the Keypads at the same time would be almost impossible
the way things work around here and if someone see the LCD counting down they could simply wait until it is finished "for now" :>)
stevenmess2004,
Got this working as I was typing this reply :>), simply transmitted the values of the RD_Array at the end of LCD_Reset Method. This is
probally not the most "code" efficient way of doing it but seems simple to me at this point :>)
Thanks again to the both of you for your help, I am learning alot real fast because of your kindness.
Sincerely,
JMLStamp2p.
To stevenmess2004 & StefanL38, The "2" Props are now operating as wanted.
They both show the Timer values in the correct manner on both ends as needed and also
show the decrementing values when counting down on both LCD's !
Each one can program the others Timer varibles remotely and operate the Contacts as
needed for the Quench Station Pump Control.
Give yourselves a hand, You deserve it :>)
Great Job Guys,
JMLStamp2p
Comments
Thank You for the file, I am off work today but will load your code tommorow and make comments to how I
understand it.
Best Regards,
JMLStamp2p
··· The file attached is a "Working" model for the following:
1) Global Varibals for the Timers are capable of being programmed
··· from either location via an "RF" Link.
2) Countdown via all three timers are now being Displayed on the
··· LCD. Once the count terminates the screen is Cleared and the
··· current Values of all the Timers are displayed on the screen.
3) Output to the Quenching station Motor is operable and comes on
··· when any of the Timers start counting and turnes off when the
··· Count is finished.
·· I am working on the last step of the process now which is to transmit
·· the Timers values to the remote Prop via the "RF" Link. This is so the
·· Remote Prop will show the count decremented on it's screen as well as
· ·the Prop at the Quenching station where the Motor is located.
·· Note: Would like to say a special Thank You to stevenmess2004 & stefanL38.
·· I could not have gotton this far so quick without their patience and well
·· documented examples.
·· Regards,
·· JMLStamp2p
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
The "updated" attached file includes the following:
1) I have included the methods to display the countdown
··· on the Remote Prop "Office Prop" via "RF". I can view the countdown on Timers
··· 1,2 & 3 depending on which Limit switch was thrown. The only
·· ·problem I am having is when I make Limit switch - 1·at the Quenching Station
··· The display on the Office Prop shows 1 & 2 counting down. When I Make
··· Limit switch - 2, The display shows 2 & 3 counting down. When I make
··· Limit switch - 3, only Timer - 3 is counting down "as wanted" on the Office Prop.
··· I presume that now may be a good time to incorperate the "Locks". It appears
··· that everything is operating correctly except fo this.
·· ·almost there stevenmess2004 & stefanL38
···
··· If you guys see where the problem is let me know, I believe that this is the
··· very last step in the process. After that I will concentrate on just cleaning
··· things up and studying what you guys have taught me so I can code more
··· efficiently.
··· I am going to take a video of the system operating and send it to you guys,
··· You need to see "our" system working :>)
····JMLStamp2p
i think i got it
your code
if Count_4 < 10 'If Timer_1 value is less than "10" data.dec(0) data.dec(0) data.dec(Count_4) if Count_4 < 100 'If Timer_1 value is less than "100" data.dec(0) data.dec(Count_4) if Count_4 < 256 'If Timer_1 value is less than "100" data.dec(Count_4)sends one leading 0 as soon as you are under 100 and then the value
and as soon as you are under 10 it is sending 2 leading 0 and value and then
the second condition is still true and it is sended again
This means yuo are sending the value two times
you should change your code to the following:
if Count_4 < 100 'If Timer_1 value is less than "100" send a leading 0 for first digit data.dec(0) if Count_4 < 10 'If Timer_1 value is less than "10" send a leading 0 for second digit data.dec(0) data.dec(Count_4)if you go under 100 ONE additional leading zero is needed
if you go under 10 a SECOND leading zero is needed (the first zero comes from the condition if Count_4 < 100
which is still true and that makes in summary two leading zeros
and after the (eventual) needed leading zeros send the value itself only ONCE UNCONDITIONAL
now your code has three independend running methods
two of them are writing on the LCD at the same rows and columms
inputs via the keypad are working this way:
The last input counts: if somebody starts typing the three values at the office-prop
and somebody else starts typing on the quenchstation-prop,
the values of that man that types in the last digit, becomes valid
and the other is overwritten.
Do you want to have it this way? Or do you intend it another way?
best regards
Stefan
Post Edited (StefanL38) : 3/22/2008 10:45:21 PM GMT
as this is the last Major issue that I have as far as functions are concerned. I know that I have alot of cleaning up and streamlining to do but its really exciting for me to see it working to this point. This is a major step in our control system for the future...
I appreciate your help,
JMLStamp2p
Note: See attached "Spin" File for the latest code.
I have replaced my code as suggested by "stevenmess2004" in his latest post.
Everything is working correctly except for one small issue. When I make the
Limit switch at the Quenching Station prop location its LCD starts decrementing the
count, as does·the Remote office Prop·which shows·the count decrementing as it
should·in the correct format but stops when it reach's "1". I would like for it to show
the original value that it started decrementing from which should be "TValue_1". I
have been away from the code for a few days so I'm have to get the sequences back
in my Head :>)
I will be working at getting this last·small error straightened out and will be working
on incorperating the "Locks" for the next couple of days. If anyone has any
suggestions on how to fix this please post a· sample code fragment.
Thank You to stevenmess2004 for your last code fragment suggestion which
straightened out the LCD readout on the Remote "Office" Prop.
JMLStamp2p
waitcnt(80_000_000 + cnt) 'if you change this to waitcnt(clkfreq+cnt) it will automatically adjust itself if you change the clock frequency say by using a 6MHz crystal 'Wait "1" second.and here
Now if I understand you want the original value of seconds to be displayed when the countdown finishes. All you need to do is add in some code after the repeat loop to send the value of seconds to the LCD. So add something like this
data_LCD.tx(254) data_LCD.tx(71) data_LCD.tx(10) data_LCD.tx(3) data_LCD.dec(Count_4) 'Print current value of Count_4 to the LCD. at location 'Col-18, Row-2.(I just took this from the repeat look so it may need fixing) after this code in Output_4 (and the other output methods)
data_LCD.tx(254) data_LCD.tx(88) 'Clear the LCD. data_LCD.tx(254) data_LCD.tx(71) data_LCD.tx(2) data_LCD.tx(1) data_LCD.str(string("Timer_1 Finished"))Hope this helps.
i have thought about the things that should work parallel in your application.
if you REALLY NEED everything to work parallel this will mean quites an effort for managing this without messing up the datastreams coming in and sended out by each prop
for example: somebody starts typing in new timervalues at the quenchstation. At the same time somebody starts to type in new timervalues in the office
Let's say at the quenchstation the typing is finished first. Then it will send out the values. These values first get to the receivebuffer of fullduplex-serial of the officeprop.
If you want to display on the LCD as soon as they arrive while you are typing in new values on the officeprop this causes difficulties. Because you want to have a
instant feedback on the LCD as you type one digit. The lockmechanism has locked the display for others than RxStr. So PUB Received_Data waits until it is unlocked.
You finish typing in and the officeprop sends out HIS Timervalues. After that sending to the LCD becomes unlocked. The PUB Received_Data gets the timervalues of the quenchprop and shows them on the display
and oops ! now you have different values in the two props !
So their has to be a priority or a second lock if one prop is in "type-in-timer-values-mode"
One easy solution could be to lock keypad-typing as long as a countdown is running or the other prop
has already startet keypad-typing. This would make it secure that the data is processed in a sequential way.
Here i need a very detailed description what HAS TO BE REALLY parallel.
If really EVERYTHING should be parallel the solution could be to define areas on the LCD that are strictly only for ONE purpose.
one area for keypad-typing-feedback
one area for countdown is running and its actual values
one area for preset timervalues
then it could work this way:
defining a LCD-Buffer of 4x20=80 bytes
the different methods like RxStr, received_data etc. write only into THEIR particular bufferarea
then there is another method that updates the content of the LCD by reading the complete buffer
and which is the ONLY ONE which sends data to the LCD.
I think the data that is send out to the other prop needs a header that marks what kind of data it is:
actual countdown-values or a new set of timer-values
Still there will be the need of a lock-mechanism that only one method is sending out data to the other prop
at one time to avoid datacollision / mixing up the datastreams. Or to have a sendbuffer too.
The different methods write to the sendbuffer to their PARTICULAR place and there is only ONE method that reads the sendbuffer
and sends out the complete data all the time.
Then the only thing that could happen, is, that - for a short moment - the data could be half old half new because
one method has not yet finished write to the buffer. With the next sending it will be completed.
Maybe the display could have a row-columm with titel design:
First row has collums for preset-value, actual-value, Keypad-typing-feedback
in the 2nd 3rd, 4th-row there are the values itself
best regards
Stefan
Post Edited (StefanL38) : 3/28/2008 12:20:23 PM GMT
SteFanL38,
your suggestion to "lock keypad-typing as long as a countdown is running" solution would work best as far as
running interferance between Props. The chance of two people operating the Keypads at the same time would be almost impossible
the way things work around here and if someone see the LCD counting down they could simply wait until it is finished "for now" :>)
stevenmess2004,
Got this working as I was typing this reply :>), simply transmitted the values of the RD_Array at the end of LCD_Reset Method. This is
probally not the most "code" efficient way of doing it but seems simple to me at this point :>)
Thanks again to the both of you for your help, I am learning alot real fast because of your kindness.
Sincerely,
JMLStamp2p.
data.dec(RD_Array[noparse][[/noparse]0])
data.dec(RD_Array)
data.dec(RD_Array) 'TValue_1
data.dec(RD_Array)
data.dec(RD_Array)
data.dec(RD_Array) 'TValue_2
data.dec(RD_Array[noparse][[/noparse]6])
data.dec(RD_Array[noparse][[/noparse]7])
data.dec(RD_Array[noparse][[/noparse]8]) 'TValue_3