I have a feature request to Fidelity streaming.
Currently the 1-min bar is added only when the bar has a volume.
If it is streaming, the strategy gets executed only when the bar has a volume.
I have a strategy which I want to generate a signal in that situation.
Could you consider steaming no volume bar (open/close/high/low price should be the closed price from the previously traded bar) so that the strategy gets executed every single bar?

Sorry but being a 3rd party, we (MS123 LLC) can not help with Fidelity data. With data requests and/or problems, please call Fidelity directly.

QUOTE:
Could you consider steaming no volume bar (open/close/high/low price should be the closed price from the previously traded bar) so that the strategy gets executed every single bar?

Other providers do have this option, but I'm afraid you'll meet plenty of resistance from the architect of Wealth-Lab. Nonetheless, it never hurts to ask.

Eugene, does the IQFeed provider have this option?

Based on what I saw in its source code, it doesn't appear that our IQFeed provider imposes such restriction. If volume is missing in an otherwise valid streaming quote that can be successfully parsed, it will still be added.

I can perfectly understand why the architect or the engineers would be against adding the option.
Probably their implementation of generating the bar is based on the trade closed at the bar.
If they have to generate a bar that doesn't have a trade, they will need a new code to synthesize a trade.

But I believe it perfectly makes sense for a strategy getting an executing at very single bar regardless of the volume.
In fact, currently I cannot automate it in my strategy but I have to observe it in person and manually close the position etc...

I know that you're very capable of implementing work arounds - like run a strategy using a symbol that you know will update every minute, like QQQ or SPY. When you synch secondary symbols to the primary you'll get "repeated" bars as described in the WealthScript Programming Guide > DataSeries > Accessing Secondary Symbols > Secondary Series Synchronization. You can detect which bar actually has zero volume because it will have the same time stamp as the previous bar.

Or, you can create another Bars object that shows the symbol just the way you want it, like this:

CODE:
Please log in to see this code.

You code looks very promising to work around the issue.
However, I still hesitate using an external symbol in streaming strategies due to the external symbol issues I reported in the past as below.
#18548 - WLP5.5 : GetExternalSymbol raises exception when Streaming
#18663 - Streaming pairs strategy (external bar data gets out of sync)

I guess these two issues are still present in WLP6.3.
How about WLP6.4?
Are the new Fidelity streaming changes by any chance fixing these issues?

18548 - this exception is by design in order to prevent Wealth-Lab from crashing. It only should happen when initializing a chart at the precise moment a streaming update arrives. Truth is, I can't even remember the last time I've seen it occur.

18663 - All secondary symbols are requested by a synchronous call to the static provider... and unfortunately this won't change in the arhitecture in the foreseeable future.

A workaround that should work is to stream the secondary symbol in another strategy window and write/retreive the DataSeries to/from global memory (after a small Sleep delay). Alternatively, 6.4 S. Monitor updates occur with much less delay - usually less than 3 or 4 seconds (but more for higher intervals like 30 minutes). It won't help with the secondary synch directly, but you can probably use it for the global mem scheme.

On second thought, this is going to be much complicated than it sounds.

Imagine a streaming window executing a strategy at 1-min interval.

If the primary symbol at the bar doesn't have a trade, the streaming window won't even get an execution, therefore not even getting a chance to retrieve the secondary symbol.

Now you have a second streaming window in which you retrieve the bar data for the primary streaming window as its secondary symbol. The primary streaming window cannot access it via the global memory as the primary window won't even get an execution. So that you have to handle it in the secondary streaming window but the secondary bar data is out of sync.

There doesn't seem a good way to handle the zero volume bar in real-time basis.

Say you're operating 2 Fidelity streaming windows (not the S. Monitor).
A - has "the strategy" that operates on a secondary symbol, and,
B - writes its data to global mem

If you put even just a 1 second delay in A, you would be practically guaranteed (in theory) that B will have written its info to global mem by the end of the 1 second. If B didn't update for that bar, then it's a zero volume bar! Isn't this what you need to detect?

This works for Fidelity streaming windows because the chart will "close" the interval when first of two things occur:
1. A tick is received that belongs in the next interval, or,
2. The "heartbeat" determines the interval has ended.

But, if no trade occurred in an interval, then nothing happens.

As long as B writes the data to global mem and A always uses it instead of the delayed secondary symbol, it seems to work. Although the 1 second or whatever delay could be still considerable cost.

QUOTE:
18548 - this exception is by design in order to prevent Wealth-Lab from crashing. It only should happen when initializing a chart at the precise moment a streaming update arrives. Truth is, I can't even remember the last time I've seen it occur.

This is essential for this work around to work. I don't know if it has ever been fixed as I have a work around to prevent it from occurring. Any possibility if it was ever fixed in the current or previous version?

Do you have a procedure that causes the exception? Maybe we're talking about different conditions.

I think we are talking about the same thing as described in ticket #18548.

The supposition (3 years ago) was that the change in version 5.5 (or 5.4?) - to prevent Wealth-Lab from crashing when an interval update occurs while a script was executing - is the source of the exception. If this is correct, either you get the exception or Wealth-Lab crashes. Given the choices, we're probably going to stick with raising the exception.

However, maybe the supposition was not correct. In the ticket you indicated this is the setup to cause the exception:

Streaming window A : symbol is FAS and uses FAZ as an external symbol
Streaming window B : symbol is FAZ and uses FAS as an external symbol

Is it enough to run 2 windows with this statement to cause the exception?

CODE:
Please log in to see this code.

If not, what are all the conditions?

Yes, that should be enough to cause the exception.

There must be something else to it. I've been running this for several hours (6.3 for a baseline) and have not seen an exception.


4pm ET - not even one.
(We've gotta get this server off of central time!)