Tricky variable connection within same application in diagram mode
I've spent so many hours trying to figure it out now... So it´s time to ask you guys :)
Situation:
Control Builder 6
My application consists of two diagram where the first (1) does the data processing from the AI835 I/O:s and the second (2) diagram only does hardware monitoring.
I´ve understand that I can´t readily use declared and I/O-connected variables in diagram (1) also in (2). I´ve tried with communication variables but since they can´t be connected to I/O-channels I really don´t know how to use the channels from the I/O:s in multiple diagrams.
The reason for this is that want (must) have a rather extensive fault monitoring and I wish to have a seperate diagram for this. It just takes so many pages to hade everything in one diagram.
So, this is the signal flow;
Raw measurements from AI835 channels -> declared variabels in diagram (1) -> calculations being made -> a new variable is created and copied into an access-variable for OPC communication.
So far so good.
The same very variables (using RealIO and error masking) on the I/O should also be used in diagram (2) for the hardware supervision. But how do I reach it there? I would like to "pick" the .Status flag of the RealIO and use it in FB_ChannelError to create outputs.
Any help is higly appreciated.
//Mikael
Situation:
Control Builder 6
My application consists of two diagram where the first (1) does the data processing from the AI835 I/O:s and the second (2) diagram only does hardware monitoring.
I´ve understand that I can´t readily use declared and I/O-connected variables in diagram (1) also in (2). I´ve tried with communication variables but since they can´t be connected to I/O-channels I really don´t know how to use the channels from the I/O:s in multiple diagrams.
The reason for this is that want (must) have a rather extensive fault monitoring and I wish to have a seperate diagram for this. It just takes so many pages to hade everything in one diagram.
So, this is the signal flow;
Raw measurements from AI835 channels -> declared variabels in diagram (1) -> calculations being made -> a new variable is created and copied into an access-variable for OPC communication.
So far so good.
The same very variables (using RealIO and error masking) on the I/O should also be used in diagram (2) for the hardware supervision. But how do I reach it there? I would like to "pick" the .Status flag of the RealIO and use it in FB_ChannelError to create outputs.
Any help is higly appreciated.
//Mikael
Asked 6 months ago
Voted best answer
3
There isn't a "nice" way to do this with Control Diagrams. Basically, the I/O channels can only go to One Diagram, and copying IO channels to other diagrams creates exactly the kind of issues you're hitting.
To Cut down on the complexity of Diagrams, you're better to create multiple Diagram Types and embed those into your base Diagram. So in your case you could perhaps do all the diagnostics in a "Diagnostics" type and all the Signal Processing in a "Signal Processing" type and then just embed 2 Diagrams into the "Application". Connect all the I/O channels using "Ports" on the diagram types.
Ultimately, problems like this are why I still have a personal preference for programming everything in good old FBD in the base POU programs.
A couple of other notes ....
- AVOID Access variables. Access variables are not for "OPC Communication" - they're for Peer-To-Peer communications using MMS to Controllers or a local HMI panel. They impose additional communications load on the CPU and they're extremely difficult to cross reference and search properly. The OPC Server already has access to everything.
- For peer-to-peer communications in version 5.1 and above always use Communication Variables". You can search, trace and cross reference properly. Note that again, peer to peer comms uses CPU load, so don't define things you don't need.
- Copying "RealIO" and "BoolIO" datatypes is a problem because they are Bi-Directional. The "Forced" bit of a RealIO DataType is WRITTEN back to an Input Channel, and READ from an output Channel. If you Copy "Real_Input_1" to "Real_Input_2" then you just broke the ability to Set "Forced" on Real_Input_2 and send that back to the "Forced" input on the Hardware Channel. This is why ABB recommend "Control Connections"
To Cut down on the complexity of Diagrams, you're better to create multiple Diagram Types and embed those into your base Diagram. So in your case you could perhaps do all the diagnostics in a "Diagnostics" type and all the Signal Processing in a "Signal Processing" type and then just embed 2 Diagrams into the "Application". Connect all the I/O channels using "Ports" on the diagram types.
Ultimately, problems like this are why I still have a personal preference for programming everything in good old FBD in the base POU programs.
A couple of other notes ....
- AVOID Access variables. Access variables are not for "OPC Communication" - they're for Peer-To-Peer communications using MMS to Controllers or a local HMI panel. They impose additional communications load on the CPU and they're extremely difficult to cross reference and search properly. The OPC Server already has access to everything.
- For peer-to-peer communications in version 5.1 and above always use Communication Variables". You can search, trace and cross reference properly. Note that again, peer to peer comms uses CPU load, so don't define things you don't need.
- Copying "RealIO" and "BoolIO" datatypes is a problem because they are Bi-Directional. The "Forced" bit of a RealIO DataType is WRITTEN back to an Input Channel, and READ from an output Channel. If you Copy "Real_Input_1" to "Real_Input_2" then you just broke the ability to Set "Forced" on Real_Input_2 and send that back to the "Forced" input on the Hardware Channel. This is why ABB recommend "Control Connections"
Answered 6 months ago
Answers
2
I think it is against the idea of Diagrams (FD) to use I/O Signals in multiple places, better is to have all "code" for one functional loop in one place, and you can structure code in multiple levels with Diagram Types instead.
Anyway, you can do it with Communication Variables, not directly connected to I/O but just insert a move block in your first Diagram to copy the Status (or, even less nice, the whole RealIO) to a Communication Variable "out" and the same Communication Variable can be defined as "in" in your second Diagram. Note that Diagrams are not code sorted, you have to sort manually so that Diagram 1 (status out) is to be executed before Diagram 2 (status in).
I didn't understand your last part with the outputs, Communication Variables send data only in one direction so you would need another one to send something back to Diagram 1 if you wanted to do that, and you get one cycle delay in that value...
Anyway, you can do it with Communication Variables, not directly connected to I/O but just insert a move block in your first Diagram to copy the Status (or, even less nice, the whole RealIO) to a Communication Variable "out" and the same Communication Variable can be defined as "in" in your second Diagram. Note that Diagrams are not code sorted, you have to sort manually so that Diagram 1 (status out) is to be executed before Diagram 2 (status in).
I didn't understand your last part with the outputs, Communication Variables send data only in one direction so you would need another one to send something back to Diagram 1 if you wanted to do that, and you get one cycle delay in that value...
by Mikael Rank: 1587 on 1/28/2020 2:06:22 AM | Like (0) | Report
I should add that I´ve tried to find an answer similiar to my questions on the forum before asking :)
by german.perez Rank: 3474 on 1/28/2020 3:48:34 AM | Like (0) | Report
Have you tried to declare variables in Global Variables list?
by Mikael Rank: 1587 on 1/28/2020 3:52:38 AM | Like (0) | Report
Should this be done also in Diagram programming? I thought that don´t work or shouldn´t be used?
by german.perez Rank: 3474 on 1/28/2020 4:13:18 AM | Like (0) | Report
There are different types of variables in Compact Control Builder for storing and
computing values (local, global, communication, and access variables), where the
local variables are the most frequently used in Control Builder. They always belong
to the local code inside a function block, control module, diagram, or a program.
The I/O data types should preferably be placed as variables
or global variables in the application editor, so that they can be read and written
from the application.
by Rob Lyon Rank: 2 on 1/29/2020 12:38:06 AM | Like (0) | Report
Somewhat disappointingly -You can't connect "Global" Variables to Control Diagrams. Go Figure :\
Add new comment