Profile-UpLoad-Form-Set64rs: Difference between revisions
Jump to navigation
Jump to search
Embeddedrf (talk | contribs) |
Embeddedrf (talk | contribs) |
||
| (14 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
== Profile Log Operation == | == Profile Log Operation == | ||
*DataBase has fields: ProfileName | | *DataBase has fields: ProfileName | Start | Stop | ModBusAddress | ||
*all channels in just 1 database > Why? | *all channels in just 1 database > Why? | ||
| Line 11: | Line 11: | ||
*Can be just another TABLE is the ChannelManagement database??? TableName = ProfileUpLoadLog | |||
== Other methods of channel diary management == | == Other methods of channel diary management == | ||
| Line 19: | Line 19: | ||
**deletion when controller removed | **deletion when controller removed | ||
**change when controller moves addresss | **change when controller moves addresss | ||
== Design Issues == | |||
== Use of mdlProfileArray == | |||
*CONCEPT: Use mdlProfileArray as a scratchpad that can then subsequently be | |||
**uploaded to controller | |||
**written into the ProgramMemory table of the database | |||
<hr> | |||
*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 | |||
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!
- when user juggles units it is best if the unit diaries follow >
- 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