1

Topic: Conjugation of two programming modules

Situation such - it is necessary to an indirect simulator (the automobile traffic) to connect my unit of control (which traffic in a simulator should resolve). And it is necessary, that at start of simulation the unit would be initialized from a file by the necessary user preferences. Correctly I see the approach to the decision of the given problem: - I will organize in dll-ke the static object containing in actually a kernel of the unit of control; - in the designer of object  loading from a file of adjustments and kernel initialization; - I will organize in dll-ke functions,  the interface of operation of a simulator with the unit. In such variant I am am confused with the following: if for loading dll the operating system generally answers how to provide the guaranteed reinitialization of object by new adjustments (after all can happen so that the operating system does not preempt from storage  dll-ku with old object, and at new simulation, starts to use it).

2

Re: Conjugation of two programming modules

Hello, _hum _, you wrote: __> a situation such - it is necessary to an indirect simulator (the automobile traffic) to connect my unit of control (which traffic in a simulator should resolve). And it is necessary, that at start of simulation the unit would be initialized from a file by the necessary user preferences. The simulator is separate EXE, so? And DLL you is not necessary to it in any way, it does not load it. How you want it to push to it? __> correctly I see the approach to the decision of the given problem: __> - I will organize in dll-ke the static object containing in actually a kernel of the unit of control; __> - in the designer of object  loading from a file of adjustments and kernel initialization; Till now all is clear __> - I will organize in dll-ke functions,  the interface of operation of a simulator with the unit. And here it is necessary to specify. What for the interface with an operating simulator (the separate process which is not using these DLL)? __> in such variant I am am confused with the following: If for loading dll operating system DLL anywhere itself generally answers does not boot. It a certain process, and thus not explicitly or implicitly loads a simulator (to which it is not necessary), and your process which loads it and about which you of anything did not tell yet.> how to provide the guaranteed reinitialization of object by new adjustments (after all can happen so that the operating system does not preempt from storage  dll-ku with old object, and at new simulation, starts to use it). If your process DLL loads - can both preempt, and reboot. It seems to me, you not absolutely truly understand principles of functioning of processes and connection DLL. Describe better more in detail the task. You will not interfere with another's process (simulator) so simply and DLL to it will not push (unless , but it is a special song)

3

Re: Conjugation of two programming modules

Hello, Pavel Dvorkin, you wrote: PD> Hello, _hum _, you wrote: __>> a situation such - it is necessary to an indirect simulator (the automobile traffic) to connect my unit of control (which traffic in a simulator should resolve). And it is necessary, that at start of simulation the unit would be initialized from a file by the necessary user preferences. PD> the simulator is separate EXE, so? And DLL you is not necessary to it in any way, it does not load it. How you want it to push to it? Yes, the simulator is separate exe well, I assume that the simulator has a predetermined interface of operation with exterior units. It, for example, does at itself(himself) loading of the library having the predetermined fixed name, and causes from this library of function with in advance predetermined names. Type//simulator side auto hLibrary = LoadLibrary ("external_control_module.dll"); if (hLibrary! = NULL) {auto Func = (int (*) (void)) GetProcAddress (hLibrary, "GetControlValue"); if (Func! = NULL) {int x = ((Func) (x));//<....>};}; PD> If your process DLL loads - can both preempt, and reboot. You about FreeLibrary? If yes, after all it does not oblige an operating system to preempt it absolutely from storage.

4

Re: Conjugation of two programming modules

Hello, _hum _, you wrote: __> correctly I see the approach to the decision of the given problem: depends on interaction model.exe and your plug-in show the signature of methods which need to be implemented in a plug-in the methods which are responsible for creation \removal  logicians, simulation start \stop are especially important. If you them do not see, it is necessary to search more attentively. You can give the reference to a simulator and detailed to dock from it, we look

5

Re: Conjugation of two programming modules

6

Re: Conjugation of two programming modules

Hello, _hum _, you wrote: __> thanks, but I for the present do not know, which simulator will be used, simply I estimate in a head as it generally can be, that in advance  preparations and by that then to spare time __> most likely, any PTV VISSIM. And there, judging by the brochure: the engine causes a plug-in depending on a phase init\create\kill #define DRIVER_COMMAND_INIT 0/* called from VISSIM once at the start of a simulation run *//* values set before: DRIVER_DATA_PATH *//* DRIVER_DATA_TIMESTEP *//* DRIVER_DATA_TIME *//* values got after: DRIVER_DATA_WANTS_SUGGESTION *//* DRIVER_DATA_AUTOMATIC_LANECHANGE */#define DRIVER_COMMAND_CREATE_DRIVER 1/* called from VISSIM once per vehicle entering the network *//* values set before: DRIVER_DATA_VEH_ID *//* DRIVER_DATA_VEH_DESIRED_VELOCITY */#define DRIVER_COMMAND_KILL_DRIVER 2/* called from VISSIM once per vehicle leaving the network *//* value set before: DRIVER_DATA_VEH_ID */#define DRIVER_COMMAND_MOVE_DRIVER 3/* called from VISSIM once per time step during a simulation run *//* values set before: all values *//* (driving behavior data only if *//* DRIVER_DATA_WANTS_SUGGESTION) *//*--------------------------------------------------------------------------*/ DRIVERMODEL_API int DriverModelExecuteCommand (long number);/* Executes the command <number> if that is available in the driver *//* module. Return value is 1 on success, otherwise 0. *//*==========================================================================*/ look, whether such notification messages by what rule an engine suffices you preempts plug-ins - besides it is necessary or to search in docks, or to experiment (  in a plug-in, and then to study)

7

Re: Conjugation of two programming modules

Hello, uzhas, you wrote: U> by what rule the engine preempts plug-ins - besides it is necessary or to search in docks, or to experiment (  in a plug-in, and then to study) there are docks in such spirit: Vissim Signal Controller DLL Interface LK 2016-04-27 This document describes how external controlers can be connected to Vissim through a DLL interface (available since Vissim 4.10) to be used during simulation and/or test runs. Introduction Since Vissim 6, all signal controlers (SCs) are simulated by an external program. If this program file is an *.exe, the old DDE interface is used and one instance of this *.exe is started for each SC using it during a simulation run. If the program file is a *.dll, however, the DLL interface is used. This means that the *.dll is loaded only once for a simulation run and has to handle the controler logic and data for all SCs that it is assigned to. The controler frequency (usually 1/s) defines how many controler time steps (passes through the controler logic) must take place per simulation second. It is set by the external controler during the initialization sequence. The simulation resolution in Vissim (simulation time steps per simulation second) must be a multiple of the controler frequency. Other combinations of values cause run-time errors. (Example: If the simulation resolution is 10 and the controler frequency is 2, Vissim simulates 5 simulation time steps between two passes through the controler logic.) In each controler time step Vissim contacts all controler DLLs at the end of the current simulation time step. First, the current signalization states and detector data of all SCs are passed to the respective DLLs. Second, the DLLs are asked to calculate new desired signal states which are subsequently passed back to Vissim. Depending on parameters set by the controler logic, either these signal states are applied immediately, or transition states (e.g. amber when switching from green to red) are inserted automatically, as defined in the signal group parameters in Vissim. In the next simulation time step the vehicles in Vissim will react on the new signalization. Module structure The source code of a signal controler DLL for Vissim consists of a frame which handles the communication with Vissim and a kernel which contains the actual control strategy. The modules of the frame are made available by PTV in form of A C (++) source code and only sc_dll_main.cpp needs to be adapted for the connection of the kernel. The kernel must exist as A C (++) source code, too. Suitable kernel functions must be called from sc_dll_main.cpp and the kernel can call data access functions from module sc_dll_functions.cpp/.h on its part. The technical details of the DLL communication are transparent for the kernel. (If a controler process with an existing interface (e.g. TCP/IP) is to be connected to Vissim, it is recommended to create a signal control DLL that interfaces between the Vissim data format and the controler data format. In this case the complete handling of the communication between the signal control DLL and the controler process needs to be done in the kernel.) Control flow At the start of a simulation/test run Vissim loads each signal control DLL that is used by at least one SC in the current network. (The DLL is usually located in the same directory as Vissim.exe or in the current data directory.) The subsequent initialization sequence for each SC has two parts: First, Vissim calls the function SC_DLL_ReadDataFiles (). This function has the (up to) two data filenames as parameters that can be entered in the SC dialog box in Vissim. From here

8

Re: Conjugation of two programming modules

uzhas, thanks. It will be necessary to understand, how at them there all is made, and what for they assume usage cpp-shnikov, but, in your opinion, my above described representation, as a whole, is true (that from it to be repelled at analysis dock)?