Safety PLCs?

[bkottaras]

IMHO this is not a good approach. I strongly prefer having the safety controller and machine controller as separate devices, to ensure that a proven safety configuration cannot be compromised by changes to the machine program. The only way I'd buy into an integrated controller is if the safety and non-safety functions were clearly separated in software, with access controls in place (i.e. password protection).

The Siemens safety PLCs will require a re-compile if anything (Safety parts or blocks)don't match or seem to have been altered in any way.
In a way it is separate though it resides on the same controller.

 

[ason]

The Siemens safety PLCs will require a re-compile if anything (Safety parts or blocks)don't match or seem to have been altered in any way.
In a way it is separate though it resides on the same controller.

And if you Open a safety program it ask for password
If you don't have it it will be read-only for monitoring.

 

[panic mode]

The Siemens safety PLCs will require a re-compile if anything (Safety parts or blocks)don't match or seem to have been altered in any way.
In a way it is separate though it resides on the same controller.

i don't quite agree. this was very first thing that was mentioned when I was originally trained on S7F and I believed it too. eventually I had project and after finding wiring mistake (also accompanied by programming error) I decided to put it to the test. the controller was S7-317F-PNDP, safety I/O was ET200S, software was Distributed Safety 5.4 and the mentioned mistake was use of normally open contact to monitor contactor (supposed to be normally closed). after wiring was corrected I had to edit safety program to match the change. The input was used in only one of many safety files. So I edited (inverted) affected instructions, saved and downloaded to PLC (normally one should download entire safety program, so that new checksum is generated). Neither software nor PLC complained about downloading incomplete safety solution (single file modified) with not matching checksum. PLC happily accepted it and worked. I pointed this to a fellow programmer working on another machine and then we did same change on that machine (which used same type of processor but was otherwise completely different). same story, S7 was running happily and no fault was generated by controller. no complaint about integrity of the safety program although we both knew that this was not right. we rebooted both machines few times, homed and run numerous cycles, everything was working without complaint. several days later (on a weekend of course), one of the PLCs eventually stopped, and the next day same happened with another. recompiling and downloading safety program fixed the issue.

so S7 does complain if you make change and don't recompile entire safety solution, it just may take several days to determine that (how long it takes to get hurt by machine?)

there are other issues too. one of them is that every now and then download would fail (in two years and 25 machines, each had multiple downloads, i had three times this issue). no big deal, just repeat the download. well not quite, when this thing strikes, you need to wipe out MMC using promer (another little tool I didn't carry everywhere with me). reset procedures described in documentation didn't help, there was no way to get factory default restored without wiping the MMC using prommer. instead of hauling bulky promer, it is more convenient to carry one or two spare MMCs. USB Promer is about $1400, one MMC is about $300 (depends on size).

Also beware that S7300 does only software redundancy:
http://www.plctalk.net/qanda/archive/index.php/t-18043.html

http://support.automation.siemens.c...slib.csinfo&lang=en&objid=1137637&caller=view

one of the really creepy things about S7F is that allows mixing safe and nonsafe I/O even in the parts of safety code that drives safety outputs. all you get is little warning mark next to non-safe contact. so how long until someone is knowingly or unknowingly fixing or bypassing things that affect safety outputs? i can see plenty of cases where muting etc is added afterward. certainly one should have the safety code checked after each such change but n my experince this never happens. only safety review is done when machine is initially installed (because they have to check it), after that it is unwanted expense and everyone goes quiet about it. more over, most PENG guys doing PHSR here don't have a clue about controls side of the machine. they can't even read electrical drawings, not to mention understanding PLC program.

at any rate, i suggest doing some research and base your choices on your consciousness. if you are only looking at small or medium application with not too many I/O I would rather look into Pilz Multi or similar. and i would take any day separate safety solution over mix of safe and standard. if you need bigger one, there are other safety PLCs...

EDIT ------------

forgot to mention separation of safe and non safe functionality. there are standard and safety I/O. but expanding or changing non safe I/O still requires recompiling safety program too.
good luck if you are not the one with access to safety password.

 

[Binaural]

IMHO this is not a good approach. I strongly prefer having the safety controller and machine controller as separate devices, to ensure that a proven safety configuration cannot be compromised by changes to the machine program. The only way I'd buy into an integrated controller is if the safety and non-safety functions were clearly separated in software, with access controls in place (i.e. password protection).

To be honest, it is probably not the right thing for a relatively limited application such as the OPs - safety integrated PLCs tend to have their niche for high-end applications rather than machines and small systems. If the safety arrangements are never likely to change, a small dedicated safety PLC is a better choice for just the reasons you say.

 

[KalleOlsen]

Hi Karsten!

If you like ASi; here is a variant from Pepperl+Fuchs.

http://files.pepperl-fuchs.com/selector_files/navi/productInfo/doct/tdoctb085a_usa.pdf

And another from Bihl+Wiedemann
http://www.bihl-wiedemann.de/cgi-local/byteserver.pl/document/smhoe101.pdf


Kalle

 

[rigicon]

IFM is another

http://www.ifm.com/ifmuk/web/pmain1!3_50.html

 

[BSS@ADPS]

Hi, i`ll will say go for Jokabsafty. I have worked width it
a lot, and have only good thins to say! And one of the
smartest wirerings-systems in the market. (if you ask me)
And a good support here in Denmark as well.

BjarkeSS

 

[PhoenixContact]

Hello all,
As Ason mentioned previously, Phoenix Contact does offer a programmable safety relay called the Trisafe, but to answer a few other questions, there is free demo software available that will allow you to test the product in your application before purchase. There is no licensing necessary and if the Trisafe appears to meet your approval, once a purchase is made, all you have to do is load the demo program to the relay and it will be good to go. Here is the link to the product page-

http://www.phoenixcontact.com/signal-level-matching/31253_49950.htm
Hope this helps.

 

[jstolaruk]

Hi, i`ll will say go for Jokabsafty. I have worked width it
a lot, and have only good thins to say! And one of the
smartest wirerings-systems in the market. (if you ask me)
And a good support here in Denmark as well.

BjarkeSS

I mostly deal with AB's GuardLogix but the Jokab Pluto Safety PLC has worked out well for small applications - inexpensive too if I remember correctly.