I'm a retired client server developer with experience in an event driven system with large database behind it. Alot of work with SQL Server back end, and some Oracle. Mostly large systems: corporate, financial applications.
I'm not an experienced C# developer, but can knock out some simple Ninja strategies and indicators.
I also am a Chart Trader / Futures... I look for visual patterns and trade those, on the chart. I don't use the DOM.
I am wanting to use a Strategy to enhance / extend my manual Chart Trader trading, not a Strategy to run by itself. I want to see the orders the Strategy submits, and be able to exit them with Chart Trader.
Ninja Archtecture
I am frustrated with the Ninja design where if there is a strategy on the chart, you cannot see the active orders on that chart, because Chart Trader cannot be active on a chart with a strategy. And, since Chart Trader is not active you cannot close (on the chart) any orders or active positions on that chart.
The software developer inside resists the Ninja architecture what requires that the indicator is instantiated inside a strategy and use exposed variables, et cetera as a method of communication between the two. It seems this requires that the strategy constantly is polling the indicator for changes in status or signal.
I would much rather have the Strategy and Indicator be decoupled, with a method of communication between them.
Here is my idea, perhaps it is not feasible, but if it was it would work for my purposes, and could build a foundation for others to expand upon, in many wonderful and exciting ways. For example, to have an indicator send a signal to your trading buddy's computer half way across the world.
I don't have the expertise to code this, but for sure could use code stubs and bring them into my code.
For a local machine, the idea is to have a strategy running in the strategy analyzer and the indicator running on a chart with chart trader.
I WOULD HAVE THE STRATEGY SUBMIT AN ATM ORDER, AND THUS AN ORDER OR POSITION COULD BE EXITED WITH CHART TRADER WITHOUT MESSING UP THE STRATEGY, AS THE STRATEGY IS ONLY USED TO SUBMIT THE ORDER, NOT TO MANAGE THE TRADE.
A method of communication is established. perhaps TCP on 127.0.0.1 or Named Pipes.
The indicator sends signals through this communication link to the Strategy. For example, Buy Limit at 102.45
Once there was a trade in play, the Strategy would not act on any other signals.
Perhaps there are other ways for the Indicator to communicate with the Strategy. I don't know if it is possible in NinjaTrader for an indicator trigger events (methods) in a decoupled strategy, and pass data during that trigger.
However, TCP would allow a much broader application, across a LAN or WAN.
I do have some questions about the overhead of a TCP Listener, et cetera, and whether this would actually work.
This example is very basic and simple and uses ATM strategies. It is also possible to send stop and target levels and let the strategy do the money management, and then manage the trade in the charttrader etc.
The following user says Thank You to terratec for this post:
(1) Generate an automated strategy via the SuperDOM (set ATM parameters such as profit targets, stop loss, breakeven stop and trailing stop
(2) Save the strategy under a name, such as Test_Strategy
(3) Code an automated strategy via the strategy editor. Use AtmStrategyCreate() to enter orders. For more details please see NinjaTrader help file. Save that strategy.
(4) Connect NinjaTrader to a data feed.
(5) Add the strategy to a NinjaTrader chart and activate it. As it is an ATM strategy the execution will not be shown on the chart. You can minimize that chart, as it is only needed to start the strategy.
(6) Open another chart with the chart trader, and you will see the position and stop and profit orders that have been created by the automated strategy.
(7) Now you can manually manage the orders that were submitted by the strategy.
You can write custom buttons on chart trader that cause an indicator to pass an order to a strategy. When the order is filled it triggers an ATM strategy to handle stops, trailing stops , targets, breakevens etc.
You can drag the stops and targets around , NinjaTrader will keep track of everything and you can still use the NinjaTrader Close button to close everything out.
I'm just a simple man trading a simple plan.
My daddy always said, "Every day above ground is a good day!"
First I am not a programmer. I have my concepts and pick some code that could work for me, and then I am changing it my way. So I can not explain much. I am just solving the problems.
In the mentioned thread there are following posts about a bit of StrategyGlobal....
As you see in the example above, I send an order command with the instrument name, the ATM strategy name and the timeframe. You can add whatever you want to say to the strategy like SLprice target1, target2, BE yes/no, move SL ... You just have to tell the strategy what she has to listen for...
You don't need that. You have to start a strategy for each instrument. Then you can switch in the indicator chart timeframes and instruments. (As long as you send those facts with your commands).
If you have more than one indicator chart, then you have to take care that the declaration public class StrategyGlobal {public static string command = ""; does only exist once.
Don't know. My indicaor is always on and then I start the strategy. But it sounds logic that the indi should run first.
You could also run
public class StrategyGlobal {
public static string command = "";
as a standalone indicator or perhaps outside strategy/indicator.
I have to think about what could cause which problem...
Thank you...lots to study, it looks like. Will dig into LOM examples it this week.
From a conceptual level:
In my mind I don't see the need to have a parent-child tightly coupled relationship between the Signal Generator and the Trade …
In your Strategy put this code:
public class TradeManagerGlobal {
public static string command = "";
}
...
if ( TradeManagerGlobal.command.Contains("BuyLimit")) ) {
... Parse the string
... Execute commands
TradeManagerGlobal.command=""; // Clear the command, or send back results
}
I also add a 1 second wake up timer to my strategy to insure that the strategy execute any command within 1 second of a button press on the chart.
And of course the strategy can communicate any results back to the strategy using the same TradeManagerGlobal.command string, or different similarly defined string variable. Anything can communicate with that strategy, even a chart for a different instrument, if desired. The trade targets also appear on all charts for that instrument, and can be also managed manually.
The following user says Thank You to monpere for this post:
public class MyIndicator_Global
{
public static string Instrument = "";
public static string LongShort = "";
public static double Price = 0;
public static string ATM_Name = "My ATM";
}
This way I do not have to parse a string in the Strategy.
In the strategy I make sure the Instrument matches the Global Instrument from the Indicator
If I have more than one indicator with a global, each indicator can have its own global public name
Since this is intended to augment manual trading, it is unlikely that I would have a bunch of these running...
@vantojo
thanks for feedback
I see an advantage in splitting the data on the indicator side.
When I parse prices from different instruments then I have to deal with different length. ES 5618 / 6E 12302 (4 or 5 digits). And sometimes an instrument is in the zone where it flips from 4 to 5 and back from 5 to 4 digits. Such things do complicate my life, but I can live with them.
On the other hand when sending all information with one click, I am confident that everything is on the way.
Do you see other advantages?
@monpere and the rest of the world
Do you see any advantages/disadvantages with this way?
@monpere
Sometimes it is a bit difficult to understand me as I am German thinking and writing...
We send one string with all the stuff we need. In the strategy we pick the substrings from that string to create the order and the order management stuff etc. It is all sent by one click.
public static string command = "";
vantojo does use for each thing an own variable and therefore does not have to pick substrings etc.
public static string Instrument = "";
public static string LongShort = "";
public static double Price = 0;
public static string ATM_Name = "My ATM";
I know what I (we?) do. His way could make some things easier or riskier or more CPU consuming or whatever. I am thinking about it (as I am always curious) and would like to have some inputs. Like chances with this way, risks etc.
I send one string to the strategy, and let the strategy parse it and figure out what to do with the command. The more parsing logic in the strategy, the more flexible I find it personally. I parse all strings using REGEX which is pretty powerful for string manipulation. You also only need to run 1 strategy per instrument, because the strategy compares the instrument in the command string to the instrument it is running, in order to consume or ignore the command. These are a sample of some of the command strings I generally send to the strategy.
I am finding the structure I posted to be adequate for my purposes to communicate trade signals from indicator to a strategy. I am not using this for anything other than sending the initial trade signal.
public class MyIndicator_Global
{
public static string Instrument = "";
public static string LongShort = "";
public static double Price = 0;
public static string ATM_Name = "My ATM";
}
Not being a C# guy, this is simple for me. And, personally, I don't like to parse strings much. I prefer to pass data in fixed structures.
With this, I can have several charts open, each with a different instrument, and then the same number of matching strategies running (in Strategy Analyzer), and the signals are not getting confused.
The first thing the strategy does is to see if the MyIndicator_Global.Instrument == Instrument.MasterInstrument.Name
If it matches then we have a signal for the strategy instrument, if not then the script returns. When there is a signal, the strategy processes it then immediately clears the global area so another indicator can write into it.
The disadvantage is that there is just one global communication area shared by multiple instruments. The only time there could be a conflict is if in the almost exact same moment two indicators write a signal into the common area. Unlikely but possible. In this case the first signal would be lost. (Or not, one would need to understand the code execution threading inside Ninja).
I would not write this type of code if it were being used to land a probe on Mars... :-)
My first preference was to have the indicator trigger an event in the matching strategy. This is what my longer term plans are, when I get time. Then there is a direct link between the indicator and the strategy.
This is pretty much what I do. I also have one communication variable since I trade manually, and there would never be an instance where I would manually enter 2 trades at the exact same moment in time. This is pretty much a direct link into the strategy since the variable you call global is a memory structure accessible by both indicator and strategy. I've had this code working for years, no issues, it is pretty robust.
If you want to have multiple indicators and strategies talking at the same time, you would have to turn the message communication structure into a list queue, and every indicator and strategy will put and scan the queue for their own messages. That way there is no collision of messages.
For a constant (feedback) dataflow like actual account size, risk position value, AvgPrice, filled Quantity etc. it has also some advantages with this structure. But can also be done the other way.
By the way... The constant bidirectional flow has the side effect that you don't need to care about wakeup the strategy.
The communication structure is there, you just have to use it. My strategy reports back all sorts of info, like trade status, if the strategy is running, or paused, what account is it running under, equity, etc. The most important thing to me is that the indicator periodically polls the strategy and asks it are you alive?, to which the strategy better answer yes I am! Nothing frustrates me more then seeing a great trade but am unable to get in because the strategy was not alive for some reason. As a scalper those few seconds trying to fgure out what's going on, will cost me a trade.
I have noticed at times the Ninja strategy (in the strategy tab) shows as active but it is not really....the OnBarUpdate appears not to be entered even though there is lots of price action. Is this what you are referring to?
Sometimes a strategy just stops responding, or is slow, or is in some startup mode, or I may have paused or stopped the strategy during the day and forgot to turn it back on, etc. The indicator periodically polls the strategy, and puts a status on the chart saying if the strategy is alive or not, so I know just by glancing at the chart that my strategy is running, paused or down.
The following user says Thank You to monpere for this post:
I also use a feedback function that shows me running/paused. That’s the visual part.
I did two things to solve the problem:
Leaving OnBarUpdate empty. Instead I use OnMarketData (and OnOrderUpdate, OnExecution). This way the strategy is much busier (and faster) and always ready. It is not that much CPU consuming as only a very little part of the code is active when I have no order or position. Most of the code is only active when a command or execution is on the way.
I did outsource every variable that does make any sense for both indicator and strategy to the global section. This way they always have something to chat (and keep themselves awake and ready. This brings the two parts – in a conceptual sense - closer together.
Off-topic: I did outsource the globals to a separate indicator that is always running in the background. All the problems like what to start first or errors when using multiple strategies or the (unwanted) reset of variables by changing time-frame, instrument etc. are gone.
The following user says Thank You to terratec for this post:
