Discussion :

[Nico28]

Bonjour,

Je suis à la recherche d'un Contrôle, bibliothèque pour du tracé de signal. Pour le moment j'utilise celui fournit en standard avec VisualStudio mais ce dernier n'est pas top pour du tracé temps réel et surtout lorsqu'il y à énormément de données :
4 systèmes d'axes, tracé sur 24 24 heures à raison de 5 points par secondes. Quand il faut retracer le tout, sur les petites machines à base d'ATOM, souvent cela fini par un Ctrl-Alt-Sup ...

Je recherche quelque chose, payant, mais Runtime free pour la distribution.

Les fonctions dont j'ai besoin :
- Tracé temps-réel (ou en fait pouvoir tracer en même temps que l'acquisition avec un un auto-scrolling)
- Echelle en X en "Temps"
- Echelle en Y avec possibilité d'échelles logarithmiques
- Gestion de zoom.

Je commence par une recherche sur internet avec download des versions "Trial" pour faire des essais, mais si quelqu'un a une idée sur ce qui correspond à mon besoin, je suis preneur (histoire de gagner du temps ...)

Amicalement,

[jopopmk]

Salut,

as-tu essayé de monter ton appli en WPF ?
Il parait que c'est bien plus performant que WinForm (niveau graphique).
Après si t'as rien contre le C++ je pense que tu devrais arriver pas trop difficilement à afficher un point toutes les .2"

Pour une lib dédiée je connais pas, désolé.

[Nico28]

Merci quand même, mais il me fautndu C#-WinForm

[Vincent PETIT]

Salut,
Tu as déjà regardé du côté de Gnuplot ? C'est très puissant.

J'ai une remarque concernant ton projet : en réalité ce qui est temps réel c'est l'acquisition et non l'affichage. Ton acquisition se fait au travers d'un très grand tableau en C# (tableau qui contient les mesures, l'heure, etc...) et l'affichage quant à lui n'est que l'image d'une partie du grand tableau que l'utilisateur souhaite voir. Donc pourquoi rechercher absolument un système d'affichage aussi pointu ?

[clementmarcotte]

Bonjour,

Je ne sais pas si cela permet tout ce que tu veux, mais tu peux regarder du côté de ZedGraph. En principe, il a une license "Open Source".

http://sourceforge.net/projects/zedgraph/

Exemples : http://zedgraph.sourceforge.net/samples.html

Article CodeProject : http://www.codeproject.com/Articles/...ibrary-for-NET

Il est aussi disponible en package NuGet

[adn56]

j'utilise aussi ZedGraph, et oui ils ont raison, l'acquisition doit être découplé de l'affichage
Perso pour ton projet j'aurais un premier soft (un service) qui archive dans une bdd local (type Sqlite) les valeurs lûent via tesp ort d'acquisition.
Puis par la suite tu peux récupérer ce fichier (format CSV par exemple) et tracer les courbes via un autre Wform, voir plus simplement excel
EX : d'un vieux projet avec zed graph (le module d'acquisition est en bas à droite)

bonne prog

[Nico28]

Salut,
Tu as déjà regardé du côté de Gnuplot ? C'est très puissant.

J'ai une remarque concernant ton projet : en réalité ce qui est temps réel c'est l'acquisition et non l'affichage. Ton acquisition se fait au travers d'un très grand tableau en C# (tableau qui contient les mesures, l'heure, etc...) et l'affichage quant à lui n'est que l'image d'une partie du grand tableau que l'utilisateur souhaite voir. Donc pourquoi rechercher absolument un système d'affichage aussi pointu ?

On est entièrement d'accord sur le principe, c'est d'ailleurs cela qui est mis en œuvre.
Pour l'affichage, les opérateurs veulent suivre (au plus près du temps réel) l'évolution du procédé. De plus, ce procédé pouvant se réaliser sur plusieurs jours, il est nécessaire de pouvoir, tout en continuant l'acquisition, pouvoir revenir sur une visualisation du passé ...

Exigences des utilisateurs ...

Mais je vais regardé Gnuplot, je te remercie.

[Nico28]

Bonjour,

Je ne sais pas si cela permet tout ce que tu veux, mais tu peux regarder du côté de ZedGraph. En principe, il a une license "Open Source".

http://sourceforge.net/projects/zedgraph/

Exemples : http://zedgraph.sourceforge.net/samples.html

Article CodeProject : http://www.codeproject.com/Articles/...ibrary-for-NET

Il est aussi disponible en package NuGet

Merci de ta réponse. Il m'avait semblé comprendre que le controle "Chart" intégré à VisualStudio était anciennement ZedGraph !? Je vais retourner voir sur leur lien. Merci à toi.

[Nico28]

Bonjour,

Je ne sais pas si cela permet tout ce que tu veux, mais tu peux regarder du côté de ZedGraph. En principe, il a une license "Open Source".

http://sourceforge.net/projects/zedgraph/

Exemples : http://zedgraph.sourceforge.net/samples.html

Article CodeProject : http://www.codeproject.com/Articles/...ibrary-for-NET

Il est aussi disponible en package NuGet

Merci à toi de ta réponse, mais je suis sur une ligne de production et pas moyen de faire du temps différé. Il y en a bien évidemment, mais là n'est pas le problème. Encore merci, je vais voir du coté de ZedGraph.

[adn56]

Considère bien que ce que nous appelons temps réel et temps différé sont au niveau de la machine (µs) windows n'est pas temps réel par exemple, cela ne veut donc pas dire que tes courbes ne se traceront pas en temps réel au niveau utilisateur de la supervision (la seconde est déjà temps réel pour un humain alors que pour un processeur c'est 10000 fois du temps différé ! tu vois le truc ? je ne sais pas si je suis clair ?

[Vincent PETIT]

Pour l'affichage, les opérateurs veulent suivre (au plus près du temps réel) l'évolution du procédé. De plus, ce procédé pouvant se réaliser sur plusieurs jours, il est nécessaire de pouvoir, tout en continuant l'acquisition, pouvoir revenir sur une visualisation du passé ...

Alors ma réponse n'a sans doute pas été clair et je pense que tu prends le problème du mauvais côté (en fait je le pense pas, j'en suis sur ) Je m'explique :

Comme le dit adn56, l'affichage temps réel que les utilisateurs exigent n'est qu'une illusion, à ta main de développeur, d'un point de vue technique.
Regarde ce schéma


On a un écran avec un logiciel ou une bibliothèque d'affichage graphique.
Et dans le PC un énorme tableau de données qui fait de l'acquisition rapidement et en masse (sur plusieurs jours) avec en bleu des données déjà acquises et en blanc pas encore.

Voilà comment donner à l'utilisateur l'impression d'affichage temps réel.
Tu t'arranges pour afficher à l'écran (graphiquement) un certain nombre de données : ici j'ai pris 1024 données (le carré rouge qui s'appelle "Affichage 1024") mais le but est de remplir un écran de manière lisible et exploitable.
Le scrollbar n'est que l'image de l'endroit, dans dans le tableau, où tu es arrivé. Donc l'endroit où tu es entrain de faire de l'acquisition.

L'utilisateur veut aller dans le passé de l'historique ! Pas de soucis, il appui 1 fois sur le scrollbar pour revenir 1 fois en arrière. Toi de ton côté, tu vois le carré rouge qui s'appelle "Affichage 1024" et bien tu le décales de -1 (tout en conservant sa taille initiale soit 1024) dans le grand tableau de données et tu régénères le graphique.
Si l'utilisateur appui 50 fois sur le scrollbar pour revenir 50 fois en arrière ? Tu décales le carré rouge de -50 (tout en conservant sa taille initiale soit 1024) dans le tableau de données et tu régénères le graphique.

Idem si l'utilisateur va vers l'avant !

Si l'utilisateur veut voir ce qui se passe à l'instant T (le carré blanc où j'ai écris Acquisition en cours) c'est simple, tu décales le carré rouge là où tu fais l'acquisition et régénération du graphique.

En fait, tu n'as qu'a remplir graphiquement l'écran de données lisible/exploitable et une fois que c'est fait, tu surveilles le scrollbar pour voir ce que l'utilisateur veut voir. Autrement dit dans ton grand tableau de données, tu as un plus petit tableau (d'affichage graphique) qui se promène dedans au gré de l'utilisateur et de ce qu'il veut voir. Tu dois avoir un contrôle sur la position du carré rouge dans mon schéma, de l'endroit où tu es entrain de faire l'acquisition dans le grand tableau de données et surveiller le scrollbar réservé à l'utilisateur.

Tu vas me dire "et si l'utilisateur veut un affichage logarithmique donc avec beaucoup plus de données ?"
Aucun problème. Le carré rouge (qui est le tableau d'affichage) s’agrandit pour prendre beaucoup plus de valeur ensuite GNUPLOT (ou autres) passe en mode Log en changeant ces échelles puis régénération du graphique.

Pour faire un zoom ? Il suffit de réduire la taille du carré rouge de mon schéma et régénérer le graphique.

Pour un dézoom (zoom -) ? On agrandit la taille du carré rouge et on régénère le graphique.


Si je comprends bien ton histoire de processeur Atome trop faible pour gérer ton affichage c'est sûrement parce que tu gères une énorme image qui n'a pas lieu d'être.
Je ne sais pas si j'ai été clair car je me rends compte que ce n'est pas évident a expliquer ?

[Pol63]

as-tu essayé de monter ton appli en WPF ?
Il parait que c'est bien plus performant que WinForm (niveau graphique).
Après si t'as rien contre le C++ je pense que tu devrais arriver pas trop difficilement à afficher un point toutes les .2"

faut pas exagérer non plus, faire du tracé en windows forms en temps réel à quelques refresh seconde c'est faisable
quand on trouve des choses lentes en .net c'est que c'est codé avec les pieds, pas que .net est lent

(et même sans dll tierce ca se code facilement ...)

[sinople]

1 point toutes les 5 secondes sur une journée donne 17'280 value journalière.

Ton premier problème est le nombre de pixel de ton écran, pas la performance de .Net ni du contrôle graphique de Microsoft.

Bon maintenant quelques pistes pour t'aider.

Le contrôle graphique de Microsoft possède une série FastLine qui est plus adaptée pour l'affichage de millier de point en offrant un rendu plus rapide.

Tu dois ensuite fenêtrer les valeurs affichée sur le graphique en prenant les dernières (genre 1'000) avec des contrôles pour naviguer dans le temps. Si tu veux une vue plus large (sur la journée), il faut dans ce cas prendre uniquement un point sur X mesure afin de réduire le nombre de mesure avant affichage.

Bref la problèmatique se pose sur la réduction du nombre de mesure transférée de l'acquisition à l'affichage et non pas sur la performance du contrôle.

[phil_tema]

Bonjour,

Tu peux aller voir chez National Instruments, le produit "Measurement Studio", et le composant .NET "ScatterGraph", pour WinForms.
Nécessite Visual Studio.

http://www.ni.com/mstudio/whatis/ui/

C'est pas donné (!) mais c'est TRES puissant (plusieurs axes X, Y, zoom, scrolling, échelle auto, échelles lin/log, annotations...)

Pour info, dans ma boite précédente, on utilisait un activeX (2005) comparable au composant .NET pour afficher des données "temps réel"
dans un oscilloscope (8 canaux, 2000 points/canal, base de temps mini de 10 msec). Ca fonctionne nickel !

Tu peux aller voir aussi du côté de SciChart (que pour WPF je crois)

http://www.scichart.com/features/

@+,
Phil

[Nico28]

En final, j'ai pu résoudre mon problème en utilisant ZedGraph où je trouve que l'on maitrise "mieux" les données affichées.

Merci à tous de votre participation.

Sinon, quelques pistes qui ont été explorées avec le control Chart de Microsoft.
1/ le plus gros de la consommation graphique provient de l'antialiasing, qui peut être partiellement désactivé (mais pas complètement)
2/ l'interpolation à réaliser pour afficher 345 600 valeurs (4 points par secondes en 24 heures, soit 86400 * 4) sur un espace de 1024 colonne de large semble être complètement déporté sur la carte graphique. Si elle a de la moelle, pas de souci; mais si elle est pas costaud et avec de la mémoire partagée avec le processeur, ...