Choix technologique API de sécurité

Conception / Architecture / Mise en oeuvre
valerypetit
Forcené des structures
Forcené des structures
Messages : 157
Inscription : 24 janv. 2016, 21:47

Re: Choix technologique API de sécurité

Message par valerypetit »

Salut,
J'ai rencontré ABB hier et ai assisté à une conférence sur la sécurité machine animé par un type de Allen-Bradley, c’était pointu mais super intéressant.
niveau matos je n'ai pas encore trouvé mon bonheur,
à mon avis, vu notre environnement il est probable que l'on installe un produit du type répartiteur M12 mais sur une autre marque que pilz vu le prix et la complexité de communication avec l'extérieur (Tableau/Segment/...).

un installateur qui doit intervenir chez nous bientôt propose un S7-1500 avec carte safety sur une installation et du Profisafe...
que veux tu dire il fatu absolument? tu veux dire quel est obligatoire??? ou très fortement conseillé?
Avatar de l’utilisateur
Mantysse
Créateur de langage
Créateur de langage
Messages : 749
Inscription : 20 oct. 2015, 08:17
Localisation : MiP

Re: Choix technologique API de sécurité

Message par Mantysse »

C'est obligatoire!
Sans formation pas d'achat, concrètement sans formation tu a une carte PROFISAFE qui lâche tu es obligé de passer par un intégrateur qui a fait la formation pour l'achat et la mise en place.
"Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément." Nicolas Boileau

L'urgence, c'est fait!
L'impossible, c'est en cours!
Pour les miracles, il faut prévoir un délai!
Avatar de l’utilisateur
JC87
Mi homme - Mi automate
Mi homme - Mi automate
Messages : 1903
Inscription : 20 oct. 2015, 13:00
Localisation : Nouvelle Aquitaine

Re: Choix technologique API de sécurité

Message par JC87 »

Bonjour,

La formation obligatoire c'était vrai au début de la commercialisation de la solution Safety mais tu est sur que c'est encore le cas ? cela dit pour une première affaire la formation me semble indispensable car il y a pas mal de trucs à comprendre. J'ai fais quelques projets avec processeurs safety et c'est vrai que pour une grosse machine ou du moins une machine qui a beaucoup de zones ou de fonctions de sécurité c'est intéressant puisqu'on a à la fois le programme "normal" plus le programme safety dans le même processeur et qu'on peut mixer des cartes d'E/S "normales" avec des safety. Après, avec du 300 c'était quand même assez cher, d'autant plus que le programme safety croque énormément et souvent on est obligé de prendre une cpu de taille supérieure a celle qu'on aurait pris sans safety. C'est peut être plus intéressant financièrement parlant avec du 1500 et peut être plus facile à mettre en œuvre mais là je ne saurai pas le dire je n'ai pas encore testé.

JC
"On veut faire du zéro défaut mais on a zéro bonhomme et zéro budget, et bien à la fin on a zéro résultat..."
Avatar de l’utilisateur
Cyril93
Maître du binaire
Maître du binaire
Messages : 484
Inscription : 29 oct. 2015, 14:22
Localisation : IDF

Re: Choix technologique API de sécurité

Message par Cyril93 »

Salut,

Perso j'ai fait des modifs de bloc safety sur une CPU 317F, sans faire de formation. Et j'ai acheté des modules ET200S 1F-RO sans problème. Heureusement un collègue connaissait parce que c'est pas simple cette histoire.
Avatar de l’utilisateur
Mantysse
Créateur de langage
Créateur de langage
Messages : 749
Inscription : 20 oct. 2015, 08:17
Localisation : MiP

Re: Choix technologique API de sécurité

Message par Mantysse »

Cyril93 a écrit :Salut,

Perso j'ai fait des modifs de bloc safety sur une CPU 317F, sans faire de formation. Et j'ai acheté des modules ET200S 1F-RO sans problème. Heureusement un collègue connaissait parce que c'est pas simple cette histoire.
Oui certainement parce qu'un mec dans ta boite avait fait la formation!
Dans ce genre de cas je sais aussi sortir le pipeau et avoir mon mastos
"Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément." Nicolas Boileau

L'urgence, c'est fait!
L'impossible, c'est en cours!
Pour les miracles, il faut prévoir un délai!
Avatar de l’utilisateur
Mantysse
Créateur de langage
Créateur de langage
Messages : 749
Inscription : 20 oct. 2015, 08:17
Localisation : MiP

Re: Choix technologique API de sécurité

Message par Mantysse »

JC87 a écrit :Bonjour,

La formation obligatoire c'était vrai au début de la commercialisation de la solution Safety mais tu est sur que c'est encore le cas ? cela dit pour une première affaire la formation me semble indispensable car il y a pas mal de trucs à comprendre. J'ai fais quelques projets avec processeurs safety et c'est vrai que pour une grosse machine ou du moins une machine qui a beaucoup de zones ou de fonctions de sécurité c'est intéressant puisqu'on a à la fois le programme "normal" plus le programme safety dans le même processeur et qu'on peut mixer des cartes d'E/S "normales" avec des safety. Après, avec du 300 c'était quand même assez cher, d'autant plus que le programme safety croque énormément et souvent on est obligé de prendre une cpu de taille supérieure a celle qu'on aurait pris sans safety. C'est peut être plus intéressant financièrement parlant avec du 1500 et peut être plus facile à mettre en œuvre mais là je ne saurai pas le dire je n'ai pas encore testé.

JC
Oui c'est toujours le cas, maintenant pour le Safety (je parle bien de safety et pas de profisafe) sur un S7-1200, les distributeurs (du moins certains) poussent pour pouvoir en vendre sans formation, bein oui c'est un manque a gagner pour les distributeur aussi.
"Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément." Nicolas Boileau

L'urgence, c'est fait!
L'impossible, c'est en cours!
Pour les miracles, il faut prévoir un délai!
Avatar de l’utilisateur
fish
Dieu du process
Dieu du process
Messages : 986
Inscription : 20 oct. 2015, 17:44

Re: Choix technologique API de sécurité

Message par fish »

Bonjour,
Mais pourquoi mélanger absolument le safety et le process ?
Puisque c'est cher, qu'il faut une formation, etc, pour quoi ne pas mettre un API standard et un contrôleur de sécu (ce n'est que du paramétrage et non de la programmation) et faire une communication entre les 2 ?
valerypetit
Forcené des structures
Forcené des structures
Messages : 157
Inscription : 24 janv. 2016, 21:47

Re: Choix technologique API de sécurité

Message par valerypetit »

je te suis, perso pour mes projets je préfère séparer les deux.
là c'est du clef en mains.
Après visiblement c'est une boite qui vend en dehors de l'industrie et a tendance à privilégier le contrat de maintenance et la prise de contrôle à distance.
donc plus c'est verrouillé mieux c'est pour eux.
Avatar de l’utilisateur
JC87
Mi homme - Mi automate
Mi homme - Mi automate
Messages : 1903
Inscription : 20 oct. 2015, 13:00
Localisation : Nouvelle Aquitaine

Re: Choix technologique API de sécurité

Message par JC87 »

fish a écrit :Bonjour,
Mais pourquoi mélanger absolument le safety et le process ?
Puisque c'est cher, qu'il faut une formation, etc, pour quoi ne pas mettre un API standard et un contrôleur de sécu (ce n'est que du paramétrage et non de la programmation) et faire une communication entre les 2 ?
Il y a quand même énormément d'avantages a n'avoir qu'un automate (une seul ref a stocker), qu'un programme (un seul logiciel) et aucune com a faire. La formation de toutes les façons, quelques soit la solution safety retenue, a un moment donné il faudra bien en faire une, même minime, sinon c'est prendre le risque de remettre au client une machine qui n'est pas sure avec toutes les conséquences qu'on imagine. Non c'est plus un choix philosophique de tout mettre dans l'automate principal ou garder les sécurité en dehors, chaque cas est différent et ça s’étudie.

JC
"On veut faire du zéro défaut mais on a zéro bonhomme et zéro budget, et bien à la fin on a zéro résultat..."
Avatar de l’utilisateur
Mantysse
Créateur de langage
Créateur de langage
Messages : 749
Inscription : 20 oct. 2015, 08:17
Localisation : MiP

Re: Choix technologique API de sécurité

Message par Mantysse »

JC87 a écrit :
fish a écrit :Bonjour,
Mais pourquoi mélanger absolument le safety et le process ?
Puisque c'est cher, qu'il faut une formation, etc, pour quoi ne pas mettre un API standard et un contrôleur de sécu (ce n'est que du paramétrage et non de la programmation) et faire une communication entre les 2 ?
Il y a quand même énormément d'avantages a n'avoir qu'un automate (une seul ref a stocker), qu'un programme (un seul logiciel) et aucune com a faire. La formation de toutes les façons, quelques soit la solution safety retenue, a un moment donné il faudra bien en faire une, même minime, sinon c'est prendre le risque de remettre au client une machine qui n'est pas sure avec toutes les conséquences qu'on imagine. Non c'est plus un choix philosophique de tout mettre dans l'automate principal ou garder les sécurité en dehors, chaque cas est différent et ça s’étudie.

JC
+1 ça s'étudie, et c'est un peu pour ça que la plupart du temps nous faisons des "machines spéciales" ;)
"Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément." Nicolas Boileau

L'urgence, c'est fait!
L'impossible, c'est en cours!
Pour les miracles, il faut prévoir un délai!
Répondre