Dahnuguy
There is nothing sacrosanct about the numbering of an FC. If you write an FC and name it FC100, it will work just as well if you rename it to FC200, or FC327 ... Now clearly the reverse of this is that we could each write two utterly different functions and name them both FC666. Which one is the real FC666, mine or yours?
For the matter of Siemens having produced two separate libraries of functions, each one happening to contain an FC105, I don't think they expected users to simply grab the first thing they saw with FC105 written on it and ram it in to their own project without checking what it does.
Now a further layer of abstraction is the 'symbolic' name given to an FC (or any other program element). I might call my FC666 "Humidity" and you might call yours "Valve Ctrl". If I change the symbolic name of mine to "Speed" that doesn't change what the block does. So ultimately I could have an FCxxx with a certain amount of code in it, and complete freedom to give it whatever number and symbolic name I wish.
Some software designers and coders will have their own or their company's conventions about numbering and naming FCs, FBs, and DBs. But as a very general rule of thumb most users in the Siemens community will tend to stick with specific numbers as originally allocated by Siemens in their libraries. So usually when you talk to someone about an FB41 you would expect it to be a PID control block. Why 41? Who knows - lost in the mists swirling around (inside?) Siemens Bavarian design offices.
My guess is that if you had an FC105 with a given symbolic name in your project, and then dragged or copied a different FC105 with a different symbolic name in to your project, the 'newer' name would overwrite the older. If you need to use the same FC105 in multiple locations to deal with multiple different operations, then just use it. But remember, it is a 'function' - it does just one thing. It has no concept of being assigned to or attached to another entity like a plant device or sensor. FC105 is just an operation like a 'plus' or 'divide by'. What is unique to each occurrence in the program is the actual parameters you apply. That's where you should be assigning a symbolic name to the input variable to identify what it is that's being scaled.
I'm not specifically defending Siemens here. But don't confuse being different for being worse.
Ken
There is nothing sacrosanct about the numbering of an FC. If you write an FC and name it FC100, it will work just as well if you rename it to FC200, or FC327 ... Now clearly the reverse of this is that we could each write two utterly different functions and name them both FC666. Which one is the real FC666, mine or yours?
For the matter of Siemens having produced two separate libraries of functions, each one happening to contain an FC105, I don't think they expected users to simply grab the first thing they saw with FC105 written on it and ram it in to their own project without checking what it does.
Now a further layer of abstraction is the 'symbolic' name given to an FC (or any other program element). I might call my FC666 "Humidity" and you might call yours "Valve Ctrl". If I change the symbolic name of mine to "Speed" that doesn't change what the block does. So ultimately I could have an FCxxx with a certain amount of code in it, and complete freedom to give it whatever number and symbolic name I wish.
Some software designers and coders will have their own or their company's conventions about numbering and naming FCs, FBs, and DBs. But as a very general rule of thumb most users in the Siemens community will tend to stick with specific numbers as originally allocated by Siemens in their libraries. So usually when you talk to someone about an FB41 you would expect it to be a PID control block. Why 41? Who knows - lost in the mists swirling around (inside?) Siemens Bavarian design offices.
My guess is that if you had an FC105 with a given symbolic name in your project, and then dragged or copied a different FC105 with a different symbolic name in to your project, the 'newer' name would overwrite the older. If you need to use the same FC105 in multiple locations to deal with multiple different operations, then just use it. But remember, it is a 'function' - it does just one thing. It has no concept of being assigned to or attached to another entity like a plant device or sensor. FC105 is just an operation like a 'plus' or 'divide by'. What is unique to each occurrence in the program is the actual parameters you apply. That's where you should be assigning a symbolic name to the input variable to identify what it is that's being scaled.
I'm not specifically defending Siemens here. But don't confuse being different for being worse.
Ken