When configuring a Campbell PakBus data source, you have the option to enable or disable automatic parameter configuration. Either choice can result in complex outcomes which may not be initially obvious, so we will cover this in detail over two separate articles:
- Part 1 explains how this choice affects series-to-parameter mappings and parameter creation during the initial connection to the device. It also covers the effects of changing to manual configuration and editing the series-to-parameter mappings.
- Part 2 focuses on what happens when the logger program changes after a data source has already been configured based on the original program.
Lets assume our data source has already been configured using automatic parameter configuration. The logger program at the time contained one table, Logs
, which defined the following 6 fields:
Batt_Volt
Rain_Accum
Temp
Flow
Latitude
Longitude
These fields result in the following series-to-parameter mappings:
And we end up with the following automatically created parameters in the workspaces tree:
So far, this has just been revision of what we learned in part 1. However, what happens when the logger program is changed? Let's make the following 3 changes to the logger program:
- Remove the
Batt_Volt
field - Rename the
Temp
field toTemperature
- Add a new field,
Height
Note that the table name has not been changed, it is still Logs
.
If the data source has automatic parameter configuration enabled, what happens when a connection is made between eagle.io and the logger for the first time after the logger program has changed? The documentation says the following 3 actions will occur:
- Field names common between the old and new program will maintain existing parameter assignment
- Field names absent from the new program will cause assigned parameters to be disabled (greyed out)
- Field names newly defined will be associated with new parameters
Based on this, we would expect our program changes to have the following results:
- The 4 field names which are unchanged between the old and new program will maintain their existing series-to-parameter mappings, and the corresponding parameters will be unaffected
- The
Batt_Volt
field which is absent in the new program will be absent in the series-to-parameter mappings, and the correspondingBatt-Volt
parameter will be greyed-out in the workspaces tree - The
Temp
field which was renamed in the new program will be absent in the series-to-parameter mappings, and the correspondingTemp
parameter will be greyed-out in the workspaces tree - The
Temperature
field which is newly defined in the new program will be mapped to a newly createdTemperature
parameter - The
Height
field which is newly defined in the new program will be mapped to a newly createdHeight
parameter
Let's confirm our expectations by disabling automatic parameter configuration so that we can see the series-to-parameter mappings:
As expected, the 6 series-to-parameter mappings are based directly on the 6 fields in the most recent logger program. To confirm what has happened to the parameters, lets look at the workspaces tree:
As expected, there are two new parameters, Height
and Temperature
. And two parameters, Batt-Volt
and Temp
, have been greyed-out to indicate they are no longer associated with any series.
This demonstrate the sort of changes that happen during automatic parameter configuration, but are they the changes we actually wanted to happen? For example, if the field name that changed from Temp
to Temperature
in the logger program still represents the same series of data from the same sensor, then we now have a problem: all the data from that temperature sensor acquired into eagle.io before the logger program changed is represented by the greyed-out parameter Temp
, while all new data that is acquired after the logger program changed will be represented by the new parameter Temperature
. Since this split in the data probably isn't desirable, we can go back into the series configuration and change the mapping of the series so that it is once again associated with the old Temp
parameter:
After making this change, we can now see that the old Temp
parameter is once again active, while the new Temperature
parameter is inactive:
As a final step, we can delete the Temperature
parameter, as it won't be needed any longer. We could optionally delete the Batt-Volt
parameter if we have no further need of the historical voltage data that it still represents. The workspaces tree will now only contain active parameters which are all associated with the fields of the current logger program:
It's very important to note that the continuity of identically-named fields between old and new logger programs is only possible if the table name also stays the same. For example, if the new program had changed the name of the table from Logs
to SensorLogs
, then all existing parameters would be disabled, and all fields in the SensorLogs
table would result in new parameters.
In summary, it's important to have an understanding of what changes will occur if you change the logger program while automatic parameter configuration is enabled. If not all changes are desirable, you can still alter the configuration as required afterwards. If you suspect most changes will not be desirable, or if you just want full control over any changes, you can disable automatic parameter configuration before changing the logger program. You will then have the responsibility of making any necessary changes manually.
Comments
0 comments
Article is closed for comments.