[inpelsa]

Right, much better.
Seems everything works perfectly with both except clicking Admin that returns 404 error

[inpelsa]

On my lenovo a820 with a forged ROM it doesn’t work at all.

Web is shown but without views list. No views… no graph…

4.4.2 with vMS V rom

Juat as a note in case it happens with other devices, not worth to debug.

[inpelsa]

too early to give a good opinion (through is quite useable and fast), too many things not JET implemented.

JET => YET

Unless you are going to implement it too fast 🙂

[inpelsa]

I tried several times to link image, after 5 minutes i leaved it out, anyway you got it.

Leave the task for the queue,it’s time to make link reliable!!

[inpelsa]

http://s32.postimg.org/9fkw5rf5h/.jpg

Yes, there are limits. Any way to avoid those Normal ?

• This reply was modified 9 years, 2 months ago by inpelsa.
• This reply was modified 9 years, 2 months ago by inpelsa.
• This reply was modified 9 years, 2 months ago by inpelsa.

[inpelsa]

Hehehehe… I already understood that column…

Event appears and checkbox is NOT checked!

[inpelsa]

Just one doubt more…

As nothing is 100% reliable and this test-wireless link even less… I get some events displayed as: Normal after a loss of link (maybe 3 times a day, but with 100 channels…)

Is there any option to avoid/ignore NORMAL events caused by a communication error?

Thanks!

[inpelsa]

Yes, but even without cache and that amount of data… it can be plotted quite fast.

The problem is AppendDiagDataTable(diagData) (does somebody use it?) and receiving data day per day: after removing that function everything works much better.

just try it, send 30 days data to the graph and you will see it plotted in a second as it does when de-zooming.

[inpelsa]

Sure, here you have:

It’s and old SCADA system called Freelance (1990) we use here.
It generates all graphs instantly (5 channels, 3 weeks of data, samples every 5 seconds) but most probably it will use some kind of grouping when zooming out.

I will take a look to the Schneider Electric IGSS demo but not sure it keeps data for so long time.

[inpelsa]

Well, I didn’t see understood it before…

                    AppendDiagData(diagData);
                    AppendDiagDataTable(diagData);

That second whole function is just to show the data table when you press the “show data” button.

I don’t usually need it, I will comment that function. Now it takes just 20 seconds instead of 1:30.

Anyway, implementing those improvements will make it much faster 🙂

[inpelsa]

My 2 cents to speed you up:

What makes it slow is not graph drawing: is javascript populating HTML-Table data for the 2nd and following days.

Example: graph 30 days 10 channels takes 1:30 on my computer

– Querying each data day takes 0.5 seconds: 1 data query of 30 days will save ~15 seconds, but as this will send data table already created it will show inmediatelly at server’s costs.

If sending full graph data is too complex I see those improvements:

On DIAG.JS, function AppendDiagDataTable(diagData) :

        var rows = table.children(":first").children("tr"); // tbody, tr
        if (rows.length == diagData.DiagCnt + 1) {
            var rowTime = rows.eq(0); // время
	    var buffertest ="";
	    console.log(GetNowDT() + " mark loop 1 IN " + diagData.PtCnt);
            for (var j = 0; j < diagData.PtCnt; j++) {
		buffertest=buffertest + $("<td>").text(Diag.TimeToStr(diagData.DiagTimeArr[j], TableTimeOptions));
            }
	    console.log(GetNowDT() + " mark loop 1 OUT " );
            rowTime.append(buffertest);
	    console.log(GetNowDT() + " mark loop 1 after append ");

	    buffertest ="";
	    console.log(GetNowDT() + " mark loop 2 IN " + diagData.DiagCnt);
            for (var i = 0; i < diagData.DiagCnt; i++) {
                var rowVal = rows.eq(i + 1); // значения
                var trend = diagData.DiagDataArr[i].TrendDataArr;

                for (var j = 0; j < diagData.PtCnt; j++) {
                    var dataItem = trend[j];
		    buffertest=buffertest + $("<td>")
                        .css("color", dataItem[Diag.ColorInd])
                        .append($("<div>").text(dataItem[Diag.DisplayValInd]));
                }
            }
	    console.log(GetNowDT() + " mark loop 2 OUT " );
            rowVal.append(buffertest);
	    console.log(GetNowDT() + " mark loop 2 after append ");
	    buffertest ="";

        }

– If you use a buffer instead of .append each loop you save ~15 seconds

– Loop 1 takes about 15 seconds (adds time data?)
– Loop 2 takes about 45 seconds (sets value data and color to text data when you scroll over graph?)

I will try to remove Loop 2 to be able to work.

Maybe creating data table in a different way/technology or optimizing functions used inside loops will improve it enough.

Bye!

[inpelsa]

btw…

> May be the bottle neck is drawing these points.
After having the whole data, if you zoom and reset zoom, all 30 day points are drawn inmediatelly so it’s not about drawing.

It could be some math (search for max, min, graph resize).

I do not expect to have that full featured graph, but a Report with some graphs, some channels and only 4 days of data… takes some time.

This is a basic performance feature it should already have: Maybe not for the 1 day 1 channel free graph version, but for the multi-day multi-channel PAID version it should.

Please, take a look to it.

Thanks,

[inpelsa]

It’s easily reproduible (and thus maybe easily fixable) but I understand your point.

Any expected date for the new web app?

[inpelsa]

Mmm… true… is true.

I thought it was the output status.

thanks!

[inpelsa]

Mikhail, did you find the bug about memory usage?

[Author]

Posts