In CoDesys V3 how can you uses the I/O Mapping tab when FB uses AT %I or %Q? The FB is defined as follows:
FUNCTION_BLOCKnetaccVAR_INPUT
  aState   AT%I*:UINT;
  RxControl  AT%Q*:DWORD;
  RxData   AT%Q*:DWORD;END_VARVAR_OUTPUT
  TxControl  AT%I*:DWORD;
  TxData   AT%I*:DWORD;END_VAR
I can get it to compile if create a GVL with VAR_CONFIG as follows:
VAR_CONFIG
  GVL.MY_AXIS.netacc.aStateAT%MW0:UINT;
  GVL.MY_AXIS.netacc.RxControlAT%QD0:UDINT;
  GVL.MY_AXIS.netacc.RxDataAT%QD1:UDINT;
  GVL.MY_AXIS.PLCopenRx2AT%QD2:UDINT;
  GVL.MY_AXIS.PLCopenRx1AT%QD3:UDINT; Â
 Â
  GVL.MY_AXIS.netacc.TxControlAT%ID0:UDINT;
  GVL.MY_AXIS.netacc.TxDataAT%ID1:UDINT;
   GVL.MY_AXIS.PLCopenTx2AT%ID2:UDINT;
  GVL.MY_AXIS.PLCopenTx1AT%ID3:UDINT;END_VAR
I would like to us the CoDeSys I/O Mapping so if the fixed I/O address shift because of hardware changes the VAR_CONFIG does not require updates. When I try to use the I/O Mapping tab I get the following compile errors shown in the picture below
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-04-09
Originally created by: scott_cunningham
You cannot use AT declarations for input or output variables of POUs - per the CoDeSys help files.
Closest workaround for you is to change your ins and outs to pointers:
FUNCTION_BLOCKnetaccVAR_INPUT  paState  :POINTERTOUINT;  pRxControl:POINTERTODWORD;  pRxData  :POINTERTODWORD;END_VARVAR_OUTPUT  pTxControl:POINTERTODWORD;  pTxData  :POINTERTODWORD;END_VAR
And then create the Fb_init() method this way:
METHODFb_init:BOOLVAR_INPUT  bInitRetains:BOOL;//Initializationoftheretainvariables(requiredbyFb_init)  bInCopyCode:BOOL;//Instancemovedintocopycode(requiredbyFb_init)  aStatePtr  :POINTERTOUINT;//hardwareaddresstouse  RxControlPtr:POINTERTODWORD;//hardwareaddresstouse  RxDataPtr  :POINTERTODWORD;//hardwareaddresstouse  TxControlPtr:POINTERTODWORD;//hardwareaddresstouse  TxDataPtr  :POINTERTODWORD;//hardwareaddresstouseEND_VARpaState:=aStatePtr;pRxControl:=RxControlPtr;...pTxData:=TxDataPtr;
Then when you declare your FB instance, you need to include your assignments (or you get a compile error):
Now Inst1 Ins and Outs point to the hardware address you desire. In your code, you need to dereference your pointers (like this example for a counter):
pCounter:=pCounter^+1;
Another workaround that I prefer, but it does add some variables to memory space:
Define some generic arrays (e.g. DigIn[0]..DigIn[15]) and map them at the CoDeSys I/O mapping. Then in my code I add one POU (program) called HardwareMapping where I map my local variables that have meaning. The advantage is I have one program where all of the code to real world connections are made.
In CoDesys V3 how can you uses the I/O Mapping tab when FB uses AT %I or %Q? The FB is defined as follows:
I can get it to compile if create a GVL with VAR_CONFIG as follows:
I would like to us the CoDeSys I/O Mapping so if the fixed I/O address shift because of hardware changes the VAR_CONFIG does not require updates. When I try to use the I/O Mapping tab I get the following compile errors shown in the picture below
Originally created by: scott_cunningham
You cannot use AT declarations for input or output variables of POUs - per the CoDeSys help files.
Closest workaround for you is to change your ins and outs to pointers:
And then create the Fb_init() method this way:
Then when you declare your FB instance, you need to include your assignments (or you get a compile error):
Now Inst1 Ins and Outs point to the hardware address you desire. In your code, you need to dereference your pointers (like this example for a counter):
Another workaround that I prefer, but it does add some variables to memory space:
Define some generic arrays (e.g. DigIn[0]..DigIn[15]) and map them at the CoDeSys I/O mapping. Then in my code I add one POU (program) called HardwareMapping where I map my local variables that have meaning. The advantage is I have one program where all of the code to real world connections are made.
Works with Drive1 as a FB instance or a structure.
NOTE: This solution can add one scan latency (FBs don't see the value until the next scan) - some applications maybe can't tolerate this.
Related
Talk.ru: 2
Talk.ru: 3
Talk.ru: 5