Graphs: unlimited channels and multicolumn legend?

Forum Home Forums Development and Integration Graphs: unlimited channels and multicolumn legend?

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #1374
    inpelsainpelsa
    Participant

    Hello,

    I know it could be a bad idea, but at the end it depends on the person who implements it and their hardware performance…

    It would be useful sometimes to show 15-20-50-unlimited? channels on a graph. It could leverage to problems but showing an alert ‘Too much channels shown affects performance’ should leave responsability to the end user.

    Nowadays having a 22″ monitor is common and showing a graph with 20-30 channels at 1920×1600 pixels on it is “”not”” a problem. The only limit I see is the legend who could overtake the display.

    A multicolumn (always balanced or only over 10 channels) legend could help on this. Maybe values are not so readable but it’s up to you and is very useful on comparing several channels!

    bye bye!

    #1376
    MikhailMikhail
    Moderator

    Hello,

    This limit is defined in DiagCnls.aspx. You can change it, I think it should work.
    You right, the possible problems are layout and performance.

    How many channels do you compare in the work proccess?

    #1378
    inpelsainpelsa
    Participant

    Yahooo !!

    About 15 channels by now. but who knows in the future?

    20 channels, 15 days, works perfectly (but with that [show data] function disabled)

    I wonder if you are already using SQL Server lite for objects/channels… why not for data too?

    I’m sure it will be mandatory soon or after for a number of data related reasons.
    Sending several days data together to the graph will make it even faster.

    #1379
    MikhailMikhail
    Moderator

    I wonder if you are already using SQL Server lite for objects/channels… why not for data too?

    Pros of file storage:
    – Performance
    – Works great on systems with low resources, e.g. Raspberry Pi
    – Easy to refactor depending on the project needs
    – No dependencies on 3rd party

    Cons:
    – Unable to write SQL requests
    – Unable to retrieve data using standard tools

    The ideal way is to implement the ability to use different data storage engines.

    #1380
    inpelsainpelsa
    Participant

    On the performance… not sure, maybe it’s faster because you only access sequential data without filtering, grouping… but I’m curious to see a performance benchmark between both solutions. Current databases can get profit of new technologies, and if they are worth, it can make the difference.

    I’m on Arduino, I understand that point, on those platforms it’s a completely different situation and at some point they will use newer technologies.

    There is SQLite for the Pi, but dependencies will be still there.

    That ability is the best, for sure, but I think in 1-2 years will not be needed anymore as said. Just switch to SQL at the right moment 🙂

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.