coordinating multiple programs

[pflash50]

I'm developing a number of studies that run on several charts at the same time and talk to each other via global variables and a dll for some big history arrays.

For the most part these things are working well, but there are some intermittent problems that I'd like to solve. These seem to be timing related - IOW they depend on whether or not chart one loads and runs its copy of the indicator program before or after chart five runs its copy, etc.

Q1) Is there a way to enforce the order in which things like this will communicate with your data servers?
Q2) Is there a way to make programs execute one at a time during the load phase?
Q3) Is there a way to get an efs program to start over if it reaches a particular point in its processing and finds that some required global or external data is not yet ready?

I have experimented with the "reloadEFS()" function, but it seems to prevent any other efs programs from operating while it "reloads" and therefore ends up running in an endless loop that eventually times out and closes eSignal. If I use a counter or a flag to limit the number of passes through the loop, then it doesn't do any good because, again, reload seems to block other programs as it reloads repeatedly, until it is done.

Q4) The timing problems seem OS sensitive, also. On an 800Mhz P2 with 256 MB and W2000 and a T1 Internet they are rarely a problem.

But on a 1.1 Ghz Celeron with 128 MB and WXP and a 28.8 dialup Internet they are severe. Same code, same layout.

Q5) Tips, tricks, suggestions?

[Doji3333]

My Answers...

Q1) Is there a way to enforce the order in which things like this will communicate with your data servers?

- not that I'm aware of. You would have to do this with LOGICAL variables (GLOBAL). These would control the actions of your systems

Q2) Is there a way to make programs execute one at a time during the load phase?

- not that I'm aware of. Again, GLOBAL LOGICAL Variables could accomplish this.

Q3) Is there a way to get an efs program to start over if it reaches a particular point in its processing and finds that some required global or external data is not yet ready?

- Yes, using conditions (and or LOGICAL GLOBAL VARIABLES), you could get a single (or multiple) efs files to reload.

Q4) The timing problems seem OS sensitive, also. On an 800Mhz P2 with 256 MB and W2000 and a T1 Internet they are rarely a problem.

- 28.8 dialup?? What the heck is that doing on your system. Are both computers in the same location?? If so, invest in a ROUTER and get them sharing the t1 connection.

If they are in different locations, then find another solution for the 28.8 dialup. It is no wonder you are having SYNC issues with EFS on that connection. I don't even know if esignal supports that type of connection??

If you can, get something that will feed the data faster to your system. Remember, your system is only as good as it's weakest link - which in this case is probably the 28.8 connection speed.

But on a 1.1 Ghz Celeron with 128 MB and WXP and a 28.8 dialup Internet they are severe. Same code, same layout.

Q5) Tips, tricks, suggestions?

-- Use logical variables to control your system.

Hint... Set one file (the master file - like the "MCP" - from the movie TRON). This MCP (Master Control Program) will control all the others..

Within this MCP, let it establish the necessary control variables for the other files (including "RELOAD" logical variables for each of the individual files).

This would normally be accomplished by having both a CONTROL global variable and a RESPONSE global variable. For example..

setGlobalValue( "RELOADEFS1", true ); // trigger to reload EFS #1

When the MSC sets this to true, the EFS #1 will recognize it and do the following...

if (getCurrentBarIndex() == 0) {

if (getGlobalValue( "RELOADEFS1" ) == true) {
setGlobalValue( "RELOADEFS1", false ); // reset the control value.
//-------------------- You could also place this into the preMain() function to indicate the EFS has been reloaded.
setGlobalValue( "RELOADEDEFS1", true ); // set the response value
reloadEFS();
}

}

Now, within your MCP, you would check for these changes....

if (getCurrentBarIndex() == 0) {

if (getGlobalValue( "RELOADEDEFS1" ) == true) {
setGlobalValue( "RELOADEDEFS1", false ); // reset the response value. EFS #1 has been reloaded.
}

}

I hope this is making sense. Basically you need to create a control system for everything you are running. You could even have the MCP RELOAD everything is needs when it is started - that way everything is reloaded the instant the MCP has finished loading.

Another, possibly smarter, way to handle this is with arrays of objects. You could create an array of objects for each EFS you are using. This way, you can simply create a routine to update the array of objects - and thus the global variables - for each EFS. This might be more complex than you need, but would provide for easy integration of additional EFS files in the future.

B

[pflash50]

Doji3333,

I'm using one global flag (per symbol) with multiple values to control my programs, and like I said it works intermittently.

I plan to do some experiments with your approach to see what the differences are.

Do you actually use this approach, or is this theory?

My dial up machine is at a different location. I've found that I can sometimes find problems easier on it than on the faster connected machines. For less extreme activities it isn't even noticeably slower.

And I have another machine (1.8 GHz Celeron, 640 MB, DSL Internet and WXP) that also has timing problems, hence my guess that it might be OS sensitive. But I'm not really sure.

[rcameron]

I have created in a way what Brad has suggested in his last paragraph, where each chart that loads sets a global value which can be instanced as many times as you like and an array is attached to that global value which can be worked on by any called function drilled down to as many levels as you like. All you do is pass the global value to the called script so that it then can access the array in question. There are no timing problems at all.

For example I have built a number what I call function engines with a library of related functions (Moving Averages, Ranges, Pivots, Price formulations, etc...) which can be called from any efs on any chart, and those values then also can be passed to other charts of lower/higher time frames to allow further processing. All you are doing is passing one global variable around concerning the initiating chart whilst the array can be worked on at different levels without conflict.

You can see some of these points explained in the following thread:-

http://forum.esignalcentral.com/showthread.php?s=&threadid=5464

Robert

BTW this is why I am looking into DLL coding as I feel performance could be greatly enhanced over regular efs scripting. Of course I do not know if I will come up against the problem you have experienced but I do not believe so seeing how things have worked so far.

[pflash50]

Originally posted by rcameron
I have created in a way what Brad has suggested in his last paragraph, where each chart that loads sets a global value which can be instanced as many times as you like and an array is attached to that global value which can be worked on by any called function drilled down to as many levels as you like. All you do is pass the global value to the called script so that it then can access the array in question. There are no timing problems at all.

For example I have built a number what I call function engines with a library of related functions (Moving Averages, Ranges, Pivots, Price formulations, etc...) which can be called from any efs on any chart, and those values then also can be passed to other charts of lower/higher time frames to allow further processing. All you are doing is passing one global variable around concerning the initiating chart whilst the array can be worked on at different levels without conflict.

You can see some of these points explained in the following thread:-

http://forum.esignalcentral.com/showthread.php?s=&threadid=5464

Robert

BTW this is why I am looking into DLL coding as I feel performance could be greatly enhanced over regular efs scripting. Of course I do not know if I will come up against the problem you have experienced but I do not believe so seeing how things have worked so far.

Hmmm. I'm having no problems using symbols like "ES #F" as part of my GlobalValue variable names.

I do things like

symbol = getSymbol();
CmdFlagName = symbol + ".CmdFlag";
setGlobalValue(CmdFlagName, "reload");

...

CmdFlagValue = getGlobalValue("ES #F.CmdFlag");
if(CmdFlagValue == "reload"){
...
}


all the time.

But I didn't look over your code in detail, so maybe this isn't what you are talking about?

????

Performance enhancement is also another reason for me to explore DLLs. Looks promissing so far.

One thing I'm particularly interested in exploring is the use of an external debugger via DLL. I've noticed that if your internal debug output grows much beyond a thousand line or so it can actually stop eSignal. If you poke it enough times (click on various windows) it will eventually start moving again.

Delete the debugPrintln statements and the program works just fine.