Feedback connection to ValveUni in Diagram - Control Builder M
Hi,
I've got problem with ValveUni function block used in Diagram.
First (in diagram) I read and move feedback signals from DI/IO module into "Communication Variables":
These feedback signals (from DI/IO) are in "Communication Variables" with 'in' direction but FB1, FB0 input direction is 'in_out' so I receive Error 1765
There is no problem with Out1 signal, because I'm writing into this variable so direction 'out' is ok.
Is there any possibility to solve this problem?
Kind Regards
I've got problem with ValveUni function block used in Diagram.
First (in diagram) I read and move feedback signals from DI/IO module into "Communication Variables":
These feedback signals (from DI/IO) are in "Communication Variables" with 'in' direction but FB1, FB0 input direction is 'in_out' so I receive Error 1765
There is no problem with Out1 signal, because I'm writing into this variable so direction 'out' is ok.
Is there any possibility to solve this problem?
Kind Regards
Asked 10 days ago
Voted best answer
1
The "problem" is that FB0 and FB1 are BI DIRECTIONAL. The "Forced" Status can be written from the function block back into the IO Channel.
In order for this to work, the ValveUni must have Write access to the Inputs - hence the FB0 and FB1 parameters, as well as all Out1 are defined as in_out.
The solution is "Don't use Comm Vars".
The Function Block is designed to be placed in the same Application that owns the IO Channel. The IO Should be declared as either Global to the Application or Local to the POU.
CommVars are not designed as a general solution to replace Global Variables - they are for communicating between Applications. Passing all your IO around as CommVars can create many more problems than it solves - you need to be extremely aware of timing issues, communication delays, scan times, CPU and network loading etc.
In order for this to work, the ValveUni must have Write access to the Inputs - hence the FB0 and FB1 parameters, as well as all Out1 are defined as in_out.
The solution is "Don't use Comm Vars".
The Function Block is designed to be placed in the same Application that owns the IO Channel. The IO Should be declared as either Global to the Application or Local to the POU.
CommVars are not designed as a general solution to replace Global Variables - they are for communicating between Applications. Passing all your IO around as CommVars can create many more problems than it solves - you need to be extremely aware of timing issues, communication delays, scan times, CPU and network loading etc.
Answered 10 days ago
Add new comment