Toggle Button and Functions - House Automation Start Questions

1. I use OBs for automation projects all the time.  I use FBs for automation projects all the time.  For me (but probably not many legacy Step7 -> TIA Portal converts), the difference for me is whether the subsystem is optional or mandatory.  Optional: OBs.  Mandatory: FBs/FCs from OB1_Main.

2. Create an FB for a generic toggle and call it each time it is needed.  

AutoGen_2666347

Hi, I am creating a project for college which uses PLC to create a House Automation using only I/O.

I have a few questions that i don´t understand much about the programming logic.

1 - I m creating FB for each division (Kitchen, Bedroom, ...) for a better organization and only use the OB to call those in the start. My question is if this way is correct or should i use an OB/division instead?

2- May be related to the 1st. I created a toggle button in a FC and i call it in the FB of the division every time i need to use for a light or something that i want to use toggle function. The problem is that in the 1st FB it works perfectly but then in the 2nd, 3rd,.. division it doesnt work. Dont FC are used for program that is complex and it is used multiple times at multiple diferent times?

 I created this function in a FC, does anyone know a better logic for Toggle or if there is a Block in a library?

Then i call it inside a FB and only need to introduce the Memory Input (Will be by software only) and use 3 Memories for each toggle (its a lot that is way i am trying to find a shorter way of creating a Toggle) and the Output (light in this case)

And in the end i call the FB of the kitchen in the Main Block
Project tree of what i have.

Sry for the big questions and thank you in advance

With a Siemens HMI and PLC, you only need 1 tag for toggle and NO FB.  It can all be done strictly in the HMI.

AutoGen_2666347

Okay, but if i use Toggles as FB i create a problem of having more than 50 Data Blocks, because most of my automation projects are lights On/Off. In that way it will use less space if i just copy the toggle Button code and paste it every time i need.

Is there any toogle fuction that doesnt require 3 additional tags and an M Neg for it to work? Doesnt Siemens has a fuction for that already, the same way it has a S/R fuiction pre defined?

2 - I still dont understand the difference in using OB's for each division or FB's for each division. I only want to create a division with Data so it can retain its tags.

You can search these forums for specific solutions.

One example might be: HMI Push Button Round G (Set Bit While Key Pressed) - 202626 - Industry Support Siemens 

AutoGen_2666347

Hm, i see.
So i just need to use and input and output direct and do the toggle of the input in HMI, is that it?

I suspect a bad understanding is brewing here.

It is true that the HMI can handle the toggling of a bit. The "InvertBit" or "InvertBitInTag" is good for that. Using an HMI for light switching seems to be the wrong solution for the application. Local push buttons in each room seems more likely. What follows assumes local buttons.

-------------- PART 1
Home automation may need to have that button do several tasks. Toggle off/on may just be one such function. Press and hold may be another function. An FB that handles the multi functional behaviour would make sense. 

Assume the FB is called "fbPressFn". That FB could be called repeatedly with its own DB (formally called an instance). Or the FB could be called as a multi-instance within a parent FB. Then the instance of the FB is a tag in the STAT declaration. The data type would be "fbPressFn", where you would normally see Bool / Int / ..

Try it: drag the "fbPressFn" in the code. A dialog comes up to create an instance. Review which choices are presented. Test them all to see the result.

What follows at an advance level is that you can create an array of instances. Such example would be:

instPressFn: Array [1..50] of "fbPressFn"; // 50 instances of button control

-------------- PART 2
You may only want the simple case where a light is toggled on or off. It is possible to mass process bits. For example MD20 could represent 32 toggle actions. The same ideas processing only one bit toggle is viable for BYTE / WORD / DWORD / LWORD processing.

-------------- PART 3
The use of multiple OBs is not as complicated as it seems. Creating a new "Program Cycle" OB would create a secondary "OB1" which is used just like the original OB1 is used.

Is the picture coloured in a bit more for you now? What are your thoughts?

Ahh, my mistake not understanding the real question.

I suppose it also depends on whether the existing wall switches are standard Up/Down toggles, or Decora push-button, or Decora Dimming, and whether there is local feedback for dim levels, and whether any of these wall switches are "smart" - like wifi, zigbee, zwave, matter, thread, and so on.

If this is new construction, what wall swtiches have been decided upon?  Are they simply sending digital inputs to a PLC, and then you are creating logic to properly respond to each switch input and turn on the appropriate device(s) at the appropriate dim level and so on?

Simple toggling in that situation is exactly as @qwazee describes so well above in the prior reply.

Use of "instance" or multi-instance FB DB(s) with a generic switch handling FB.

Might I add, you really should investigate "Presence sensing" input devices which can provide input(s) stating how many people are in a space and where they are, as well as where they are going - and if you want, how fast they are going.

You can use that along with scheduling information to automatically turn on task lighting in the kitchen around routine activities like preparing breakfast, lunch, dinner, popcorn for movie time and the like.

Setting a scene capability is also a must.  You know, coordinating outputs depending on the type of action requested - whether from a voice command, or some scene controlling button or switch.

You can save yourself a lot of time and money by investigating the use of HomeAssistant, but that's not nearly as fun, nor as reliable as a PLC.