2020-01-19 00:19:18
Je confirme pour les équipements industriels encore en port série j’avais un pc dédié, un vieux IBM hors d’age 
|
Siemens'Adventure !
|
2020-01-19 00:46:22
(2020-01-19 00:14:18)BiduleOhm a écrit : Ben ce que je vois me suffit... je peux déjà te dire que c'est très sommaire et simpliste comme présentation pour de la prog block, j'aurais jamais dit que le soft datait de 2000+, plutôt de début 90s. Donc non seulement c'est très bof dans la catégorie prog block mais en plus, d'une manière générale, la prog block est bien inférieure au code classique, c'est pas pour rien que 99 % des langages (passés et) actuels sont du code et pas du block.
T'as un problème, t'veux un ban ?
2020-01-19 01:00:45
Mouais, ça me dit pas ce qu'il fait exactement ça... Bon à vu de pif j'en rentre facilement le triple ou le quadruple en code classique (et encore, j'utilise une police plutôt grosse) et il est compréhensible à la première lecture. Sans compter que visiblement t'as pas de fonctions donc impossible de réutiliser du code, faut dupliquer... (genre au hasard pour scaler des capteurs de temp tu fais quoi ? tu paramètres entrée par entrée en faisant la même chose à chaque fois ?), y'a juste pas photo, ce langage il suxxx...
Wé non, t'en fais pas pour le secret industriel, je vais pas passer 3 semaines à RE ton truc pour te le voler, je suis pas mazo...
2020-01-19 01:16:47
Perduuuuuuuuuuu ! Ce para était pourtant explicite
 Citation :Pas du tout optimisé pour l'instant, va y avoir du doublons avec les modes mais faut déjà faire un truc qui marche Y'a des fonctions qui permettent de regrouper plusieurs valeurs pour n'en sortir qu'une seule suivant le choix sélectionné donc oui je peux optimiser en évitant des doublons mais je coince sur un point pour le quel j'ai pas encore trouvé de solution. Y'en a aussi pour faire du multiplexage & co mais je me suis pas trop penché la dessus pour l'instant. Concernant les sondes, deux méthodes sont possibles : 1/ La calibration se fait au moment de la prog avec le logiciel de conversion 2/ La calibration peut se faire en créant des points de consigne connectés à l'entrée analogique Pour les offset c'est le même principe que le point 2.
T'as un problème, t'veux un ban ?
2020-01-19 01:23:23
Ah miracle, y'a plus ou moins des fonctions; plus ou moins parce que d'après ta description très peu claire ça a l'air très partiel comme fonctions.
La question est simple: j'ai 10 capteurs identiques, je sais que pour scaler la valeur je dois faire (50 * capteur) + 200 est-ce que je vais devoir écrire ça 10 fois ? ou une seule fois ?
2020-01-19 10:31:43
Haha je m'attendais à cette réponse venant de ta part, mais pour toi ça correspond à quoi une fonction ?
Contrairement à l'arduino où tu peux changer les sondes à la volée directement dans une fonction, ce n'est pas possible avec l'automate car elles sont assignées définitivement à un bloc, ça revient à faire un "Sonde_1 = A1" sauf que à chaque fois elle possède leurs propres paramètres qui sont cependant éditable en fonctionnement à condition d'y crée des consignes, ça revient à stocker des variables. Tu ne peux également pas changer le type de sonde, donc passer l'entrée de PT1000 à 0-10V en fonctionnement. Exemple : 
xworks_sonde.PNG (Taille : 125.36 Ko / Téléchargements : 9)
Dans ce bloc, tu peux par exemple changer en fonctionnement toutes les valeurs avec fond blanc, les grises sont vérouillées mais pour ça il faut soit créer un bloc de consigne par valeurs, soit utiliser un sélecteur mais moins pratique ^^'.
T'as un problème, t'veux un ban ?
2020-01-19 13:34:34
Ben la définition standard: https://fr.wikipedia.org/wiki/Routine_(informatique)
Ok, donc tu dois faire ça 10 fois au lieu d'une, c'est bien ce que je pensais. Rien qu'à cause de ça on peut le qualifier de très mauvais langage.
2020-01-19 16:15:06
Bah voilà tu dis que les fonctions semblent être très partielles mais elles font le job qu'on leur demande donc non ... C'est sûr que c'est
pas les fonctions que tu peux faire toi même, je sais même pas si c'est possible de créer sa propre librairies sur le soft, surement. Je comprend pas ce que tu reproche à ce fait ... Que ce soit sur Arduino ou Siemens tu es obligé de définir des valeurs pour chaque sondes donc on en revient au même, toi tu pars du principe que si tu veux interroger 10 sondes, tu dois le faire avec la même fonction ce qui est logique mais si tu dois mémoriser des valeurs différentes pour chaque sondes, t'es obligé de créer des valeurs et donc on en revient au même fonctionnement que le Siemens, donc où est le soucis ? Dès lors que tu fais plus que lire une valeur sur une sonde, tu est obligé de stocker les valeurs si tu dois les réutiliser plus tard ...
T'as un problème, t'veux un ban ?
2020-01-19 21:52:53
Je parle pas de créer 10 variables, ça c'est normal et facile (et en vrai on peut aussi créer un tableau de 10 cases qui compte comme une seule variable et a un tas d'autres avantages), je parle d'exécuter un truc (un calcul par ex) sur chaque valeur sans avoir à faire 10 fois le code.
Non seulement ça évite de perdre du temps à faire 36 fois les même trucs mais aussi ça évite d'oublier un endroit à modifier si tu veux modifier le truc (i.e. calcul). Histoire d'être plus clair, au lieu de faire ça : https://pastebin.com/a15AWSEz faire ça à la place : https://pastebin.com/081W7kvx 21 lignes à la place de 70, beaucoup plus clair (pas besoin de lire le calcul pour savoir ce qui est fait, le nom de la fonction suffit) et si je dois modifier un un truc j'ai un seul endroit à changer, je risque pas d'en oublier ou de faire des erreurs et avoir des différences entre les capteurs, et surtout, c'est beaucoup plus rapide à coder.
2020-01-19 22:32:36
En terme de vitesse c'est l'inverse, les fonctions sont plus lentes (un appel de fonction c'est ce qu'il y a de plus lourd, suivi d'un test (condition d'un if par ex), et suivi d'une indirection (pointeur par ex), du moins en C, mais c'est très similaire dans tous les langages de toute façon) c'est notamment pour ça qu'on a le mot clé inline en C qui dit au compilo de prendre le contenu de la fonction et de le copier-coller à chaque endroit où est appelée la fonction ce qui permet de virer la fonction et tous ses appels.
Après en général on a pas besoin de se poser de questions, on code propre et si y'a des pb de perf on regarde d'où ça vient et on optimise. Mais souvent les pb de perf viennent d'un algo foireux qu'on a écrit et pas des délais intrinsèques des instructions.
J'ai l'impression que t'as pas saisie un truc Biduleohm, tous les blocs assignés à des capteurs / sorties etc sont UNIQUES, tu t'obstine avec
cette histoire de fonction alors que je sais très bien à quoi ça sert. Dans le cas présent ont définis 1 bloc pour 1 capteur, ce bloc possède ses propres paramètres et basta, il est unique, il n'y a pas besoin d'un recréer un autre ailleurs, c'est de toute façon impossible vis à vis de l'adressage, donc toutes les fonctions qui ont besoin de la valeur de ce capteur sont donc toutes reliées au même bloc, il n'y donc qu'une seule lecture. Cela vaut également pour toutes les entrées digitales et toutes les sorties que ce soit les relais ou analogiques. Par exemple le cas de la sonde qui sert à plusieurs fonctions :
xworks_sonde_2.PNG (Taille : 38.04 Ko / Téléchargements : 7)
Et en version avancée, à savoir plusieurs sondes sélectionnable donc un seul bloc pour les lires comme une fonction le ferait sous arduino & co, tu sélectionne celle que tu veux et hop, ça marche avec le reste aussi.
xworks_sonde_3.PNG (Taille : 58.68 Ko / Téléchargements : 5)
Convaincu ou tu compte continuer à critiquer un logiciel que tu ne connais visiblement pas du tout à la façon qu'un linuxien critique windows ? 
T'as un problème, t'veux un ban ?
2020-01-20 00:04:49
Tu n'as pas compris ce que j'essaie de t'expliquer, et je t'avoue qu'au bout de la 4 ou 5ème fois je suis plutôt soûlé...
Prenons le pb à l'envers: est-ce que tu peux faire exactement la même chose que j'ai fait en code que je vois à quoi a ressemble stp ? (fais juste 3 capteurs parce que 10 tu vas y passer des heures...)
2020-01-20 00:11:11
Pourquoi je devrais pas être saoulé par un mec qui s'obstine à comparer un logiciel graphique et de la programmation en ligne de code ptetre ?
J'ai très bien compris où tu veux en venir et j'ai déjà expliqué comment le faire donc je vais pas relancer la vm encore une fois pour te faire plaisir, tu regarde le poste #106, tu prend le tableau des entrées avec le slope et l'intercept et t'as ta réponse. Bonne nuit
T'as un problème, t'veux un ban ?
2020-01-20 00:16:30
Bon ça répond que partiellement mais au moins j'ai la réponse: t'es obligé de faire ça pour chaque entrée et si tu dois modifier faut modifier entrée par entrée, y'a pas l'équivalent d'une fonction réutilisable. Conclusion c'est super moisi, j'aimerais pas être à la place de ceux qui programment ces automates...
2020-01-20 19:02:26
Sauf que toutes les entrées peuvent être interconnectées au bloc de consigne donc ça revient au même que ta fonction, dans ton cas
c'est un code en dur donc tu ne peux pas le modifier non plus une fois compilé. Conclusion, ton exemple serait donc aussi moisi que le logiciel ?
T'as un problème, t'veux un ban ?
2020-01-20 20:33:11
Je peux très bien prendre les valeurs en paramètre de la fonction au lieu de les mettre en dur (et, oh miracle, j'ai qu'un seul truc à modifier grâce au fait que ce soit une fonction, 30 sec pour faire la modif) ce qui garde l'avantage de ne pas dupliquer le code tout en ayant des valeurs différentes pour chaque capteur si besoin (mais l'exemple était justement dans le cas où y'a plusieurs capteurs identiques.
Je peux même faire des trucs fun du genre avoir des valeurs par défaut tout en ayant la possibilité de passer des valeurs custom pour certains capteurs. Par ailleurs ce ne sont pas des consignes, c'est du scaling borné entre deux limites, c'est juste pour conditionner une mesure brute, pas un algo de thermostat ou autre là où on aurait probablement des consignes différentes selon les capteurs effectivement 
2020-01-20 21:12:51
Ouais enfin même si ta fonction prend des variables, celles que tu va devoir attribuer aux sondes vont devoir être stockées quelque part du
coup tu n'a certes qu'une seule fonction mais que tu va devoir appeler à chaque sondes. Dans mon cas à la place de la fonction j'ai juste à créer une consigne par sonde et le problème est réglé pareil, ma consigne équivaut à la variable que tu va devoir stocker à chaque modification. Je peux également passer non par un multiplexer mais par un démultiplexer, j'ai donc juste à choisir la sonde de destination, saisir la valeur et hop c'est le bloc de la sonde qui l'enregistre, comme ta fonction quoi. ( le démultiplexer fonctionne en inverse, 1 entrée, 8 sorties )
T'as un problème, t'veux un ban ?
2020-01-20 21:31:42
Donc pour toi y'a pas de différence entre écrire quelques chiffres et plusieurs lignes (voir dizaines de lignes) de code ? sans compter que si c'était possible de faire autrement le concept de l'entropie serait à revoir...
"... j'ai juste à créer une consigne par sonde ..." le pb est justement là, tu devrais pouvoir créer une seule consigne que tu réutilises, mais surtout tu devrais pouvoir grouper les blocs dans une entité quelconque et pouvoir la réutiliser, parce que devoir refaire un bloc c'est passable, mais devoir refaire tout un algo d'une dizaine de blocs ou plus c'est une autre histoire... (pour info regarde comment marchent les nodes dans Davinci Resolve, c'est exactement ce que tu peux faire pour éviter d'avoir à faire les choses 36x). Arf, donc ils ont implémenté le concept pour les valeurs mais pas pour l'algo, tout l'inverse de ce qu'il fallait
2020-01-20 21:38:42
Tu sais je te parle de fonction que j'ai découvert en cherchant ... Y'en a encore pleins qui servent à je ne sais quoi
Après créer autant de consigne que de sondes n'est pas optimisé oui, d'où la solution du démultiplexer qui ne requiert que 2 blocs en plus pour 8 sondes, pas un drame en soit quoi.
T'as un problème, t'veux un ban ?
|
|
« Sujet précédent | Sujet suivant »
|
