Profile-UpLoad-Form-Set64rs: Difference between revisions

From *** My Personal Wiki ***
Jump to navigation Jump to search
Embeddedrf (talk | contribs)
Embeddedrf (talk | contribs)
 
(3 intermediate revisions by the same user not shown)
Line 31: Line 31:
**uploaded to controller
**uploaded to controller
**written into the ProgramMemory table of the database
**written into the ProgramMemory table of the database
<hr>


*CompileProfile > uses this array from Index=1   
*CompileProfile > uses this array from Index=1   
Line 37: Line 41:
** the array that is used for the compiling purpose must be used by the upload routine later > thus it must be persistant
** the array that is used for the compiling purpose must be used by the upload routine later > thus it must be persistant
***Suggestion?: create a different module level array named: mdlCompiledProfileArray
***Suggestion?: create a different module level array named: mdlCompiledProfileArray




Line 46: Line 48:


*DownLoadProfile
*DownLoadProfile
** Puts downloaded values directly into the ProgramMemory table of the database
** Could put downloaded values directly into the ProgramMemory table of the database: right now uses a local ProfileArray


*DeleteProfile  > erases profile entry in ProfileLog table of the database
*DeleteProfile  > erases profile entry in ProfileLog table of the database
**
**does not need intermediate array

Latest revision as of 22:38, 19 March 2010

Software_Design_Notes_-_MultiChannel_Set64rs


Profile Log Operation[edit]

  • DataBase has fields: ProfileName | Start | Stop | ModBusAddress
  • all channels in just 1 database > Why?
    • when user juggles units it is best if the unit diaries follow >
      • rather than changing | folder location | file name the main channel database can just change the entries in the database > this applies for everything!


  • Can be just another TABLE is the ChannelManagement database??? TableName = ProfileUpLoadLog

Other methods of channel diary management[edit]

  • having separate folders forces the following:
    • new folder creation when a channel comes into existence
    • deletion when controller removed
    • change when controller moves addresss



Design Issues[edit]

Use of mdlProfileArray[edit]

  • CONCEPT: Use mdlProfileArray as a scratchpad that can then subsequently be
    • uploaded to controller
    • written into the ProgramMemory table of the database


  • CompileProfile > uses this array from Index=1
    • will not work with mdlProfileArray as is
    • the array that is used for the compiling purpose has to be by nature a scratchpad > user can move it all around and if shared will cause and overwrite!!!
    • the array that is used for the compiling purpose must be used by the upload routine later > thus it must be persistant
      • Suggestion?: create a different module level array named: mdlCompiledProfileArray


  • UploadToController
    • Uses mdlProfileArray to upload to the correct memory locations


  • DownLoadProfile
    • Could put downloaded values directly into the ProgramMemory table of the database: right now uses a local ProfileArray
  • DeleteProfile > erases profile entry in ProfileLog table of the database
    • does not need intermediate array