Choix technologique API de sécurité
-
- Forcené des structures
- Messages : 157
- Inscription : 24 janv. 2016, 21:47
Re: Choix technologique API de sécurité
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é?
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é?
Re: Choix technologique API de sécurité
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.
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!
L'urgence, c'est fait!
L'impossible, c'est en cours!
Pour les miracles, il faut prévoir un délai!
- JC87
- Mi homme - Mi automate
- Messages : 1903
- Inscription : 20 oct. 2015, 13:00
- Localisation : Nouvelle Aquitaine
Re: Choix technologique API de sécurité
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
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..."
Re: Choix technologique API de sécurité
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.
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.
Re: Choix technologique API de sécurité
Oui certainement parce qu'un mec dans ta boite avait fait la formation!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.
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!
L'urgence, c'est fait!
L'impossible, c'est en cours!
Pour les miracles, il faut prévoir un délai!
Re: Choix technologique API de sécurité
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.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
"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!
L'urgence, c'est fait!
L'impossible, c'est en cours!
Pour les miracles, il faut prévoir un délai!
Re: Choix technologique API de sécurité
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 ?
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 ?
-
- Forcené des structures
- Messages : 157
- Inscription : 24 janv. 2016, 21:47
Re: Choix technologique API de sécurité
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.
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.
- JC87
- Mi homme - Mi automate
- Messages : 1903
- Inscription : 20 oct. 2015, 13:00
- Localisation : Nouvelle Aquitaine
Re: Choix technologique API de sécurité
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.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 ?
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..."
Re: Choix technologique API de sécurité
+1 ça s'étudie, et c'est un peu pour ça que la plupart du temps nous faisons des "machines spéciales"JC87 a écrit :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.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 ?
JC
"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!
L'urgence, c'est fait!
L'impossible, c'est en cours!
Pour les miracles, il faut prévoir un délai!