Я использую эту иерархию модулей:
Node: {udpApp[0]<->udp<->networkLayer->wlan[0]} and wlan[0]: {CNPCBeacon<->mac<->radio}
Я дал некоторый начальный параметр в ini
файл для udpApp
как :
**.host*.numUdpApps = 2
**.host*.udpApp[0].typename = "UDPBasicApp"**.host*.udpApp[0].chooseDestAddrMode = "perBurst"**.host*.udpApp[0].destAddresses = "gw1"**.host*.udpApp[0].startTime = 1.32s
**.host*.udpApp[0].stopTime = 1.48s
Но во время выполнения я хочу изменить startTime
а также stopTime
за udpAPP[0]
через CNPCBeacon
модуль. Следовательно я изменился CNPCBeacon.cc
как:-
cModule* parentmod = getParentModule();
cModule* grantParentmod = parentmod->getParentModule();
cModule* udpmod;
for (cSubModIterator iter(*grantParentmod); !iter.end(); iter++)
{
//EV<<"get the modulde "<< iter()->getFullName()<<endl;
if (strcmp(iter()->getFullName(), "udpApp[0]") == 0)
{
udpmod = iter();
break;
}
}
cPar& startTime = udpmod->par("startTime");
cPar& stopTime = udpmod->par("stopTime");
И я успешно могу получить значения startTime
а также stopTime
, Однако я хочу изменить эти значения в текущем модуле, что приводит к ошибке с помощью следующего кода:
udpmod->par("startTime").setDoubleValue(4.2);
Кто-нибудь может, пожалуйста, предложить мне способ изменить его во время выполнения.
Объявление вашего параметра как volatile
должен решить вашу проблему. Но для дальнейшего использования я приведу дальнейшее объяснение ниже.
Volatile
по сравнению с нелетучим:
Здесь все зависит от того, как вы хотите использовать этот параметр. В основном через .ini
В файле у вас есть два типа параметров: volatile
а также non-volatile
,
volatile
параметры читаются каждый раз во время вашего бега. Это будет полезно, если вы хотите, чтобы этот параметр генерировался встроенной функцией, например, uniform(0,10)
каждый раз этот изменчивый параметр будет иметь другое значение.
С другой стороны non-volatile
параметры считываются только один, так как они не меняются от запуска к запуску.
С использованием volatile
Параметр type не дает вам полной гибкости, в том смысле, что значение вашего параметра всегда будет находиться в диапазоне, заданном в .ini
Динамическая переменная (параметр) переназначение:
Вместо этого вы можете использовать более надежный подход и переопределять переменную, в которой будет храниться значение из этого параметра модуля каждый раз, когда вам придется это делать.
Например, в вашем случае вы можете сделать следующее:
varHoldingStartTime = par("startTime").doubleValue();
varHoldingStartTime = 4.2;
Таким образом, фактическое значение изменится внутренне, не отражаясь на вашем пробеге.
Исследования параметров:
В качестве альтернативы, если вы хотите, чтобы это изменение параметра было применено к нескольким прогонам, вы можете использовать расширенный встроенный подход, предоставленный OMNeT ++, который позволяет вам выполнять Исследования параметров.
Я объяснил здесь, как работают исследования параметров: https://stackoverflow.com/a/30572095/4786271 а также здесь, как это может быть достигнуто с помощью ограничений и т.д .: https://stackoverflow.com/a/29622426/4786271
Если ни один из предложенных мной подходов не подходит для вашего случая, ответы на этот вопрос в целом могут решить вашу проблему: Как изменить конфигурацию сети при моделировании в OMNeT ++?
РЕДАКТИРОВАТЬ: расширяя ответ, чтобы грубо объяснить handleParameterChange ()
Я не пользовалась handleParameterChange()
раньше, но из того, что я вижу, эта функция обеспечивает сторожевая собака функциональность модуля, который его использует.
Чтобы активировать эту функцию сначала void handleParameterChange(const char *parameterName);
должен быть переопределен.
По сути, это выглядит следующим образом:
Предположим, у нас есть два модуля moduleA
а также moduleB
а также moduleB
имеет параметр parB
, moduleA
изменяет parB
и когда это произойдет, moduleB
реагирует на это изменение на основе поведения, определенного в:
moduleB::handleParameterChange(parB);
Поведение может перечитывать исходное значение для parB
от .ini
и т.п.