Siemens - best way to layout AI

DLMUK

Member
Join Date
Jun 2013
Location
Southampton
Posts
311
Hi,

I have a new project using Siemens ET200 distributed I/O, I have 40 channels of 4-20mA inputs in total.

I need to build in a calibration function for each one, at the moment I have a standard "Calibration" FB which I use in all my projects. I normally call an instance of the FB for each input from OB1 as I normally only have a couple of AI.

Is this the best way to do it for 40 channels of I/O? It just seems a bit cluttered to call the FB 40 times in OB1.

Would you put the call for each input in a separate FC and then call that from OB1?

Thanks,
 
Last edited:
Or a separate BF so all the FBS use a multi instance DB instead of needing a DB for all 40 FBS. Some people are against multi instance though.
 
I'm curious, why? It de-clutters things so nicely!

I have seen some companies go as far as stating FBs are not allowed, only FCs and DBs.

I believe it is due to lack of knowledge of Siemens, and if people go crazy with nesting multi instance it can be a pain.

Updating deeply nested multi instance FBs can be time consuming and tedious, I've seen people mess up entire projects while trying FBs.
 
Usually the OB1's would have only calls to FC's and all the "work" would be done there. This would give a high level detail of the call sequence that can be handy in large projects.

I like the multi instance FB idea, but I would chose it only if it was simple to add new analog IO to it. It's nice, but if you're not going to be able to do it while running, you may be better off to have separate FB's inside an FC.

Potentially... you could put the information from each instance DB into an UDT and have an array of these in a normal DB. You'd then pass a pointer to the FB to work on those values. But this is easier said than done, particularly if you don't work with pointers much.
 
Just use multiple instance. This is exactly what it is for (*).
Setup an FB that takes care of all the analog channels you think you will ever use, plus some extra just to be sure. Memory is cheap.

I dont agree with the "time-consuming and tedious". Once setup with enough available channels in the "parent" FB, it is easy to add, remove or change channels.

*: There are other cases where one should not use multiple-instance, since it does indeed lock you into the FB declaration that has been setup. But for this case it is a no-brainer. Just my opinion.
 
I agree this is a perfect application for multi instance.

It is possible the application I worked with was just very poorly programmed.

I have
Had to change a motion block that was a multi instance in a fixture block that was a multi instance in a cell block.

So after I made my change and updated all the motion blocks I had to update the instance call for the fixture, then update the instance for the cell.

Personally I wouldn't have nested the multi instance FBs as they were. Or maybe there is an easier way to update them all at once that I don't know about.
 
I would do this with your FB-block (Calibrate) and making multi instance calls to it from one FB
All FB's DB-blocks would be at one DB block. (multi instance)

You can locate also "spare" multi intances to DB beforehand.
Then you only need to change these spare names afterwards.
(You can go online after you have renamed spare and copy DB (multi instance) to offline. That way you have same timestamp version at online and offline, but you don't need to download DB or FB blocks actually to CPU. CPU have only memory areas (old S7 CPU)

Multi-instancing let you still also make separate DB blocks for calibrate blocks afterwards, if you don't want modify working FB and DB blocks

Also calling one FC where you have 40FB's makes more sense than locvating all to OB1.
But then you would have also 40 different DB-blocks for calibrate.
 
Last edited:
The problem with FBs and Instance-DBs is that you cannot change the declaration-part on a running machine or plant. There are ways to do it, but it takes a bit of effort and is not for the uninitiated.
Basically you can change code freely, but you cannot change the declaration part.

So the down-to-earth way to do it is to create the FBs and IDBs (multiinstance or not) with spare data in the declaration so that you can use the spare data for when you have to make modifications online.
 
I have
Had to change a motion block that was a multi instance in a fixture block that was a multi instance in a cell block.

So after I made my change and updated all the motion blocks I had to update the instance call for the fixture, then update the instance for the cell.
QUOTE]

There is a function called "check block consistency" which can handle this for you pretty fast.
 

Similar Topics

Hello everyone, I've been doing projects with Siemens and Rockwell PLC's for a couple of years now, and some softwares really helped me alot in...
Replies
10
Views
2,566
Any manufacture recommendation for remote I/O for Siemens PLC.
Replies
10
Views
2,872
Hello, I'm used to using Allen Bradley RIO options for putting filed IO out in the field and running my safety back to it. Of course I have to...
Replies
5
Views
2,794
I've been doing PLC programming for about 15 years now but all of my experience has been with Allen-Bradley PLC's. A few months ago I started a...
Replies
5
Views
3,111
Hi All, I'm in the process of learning Siemens: 1) Using TIA Portal V14. 2) Working on a S7-1200. There are chances that I also use the S7-1500...
Replies
15
Views
10,588
Back
Top Bottom