Developer Portal Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 
    SOLVED

    rStationData : REFERENCE TO Module1StationDataStruct not exported from OES

    rStationData : REFERENCE TO Module1StationDataStruct not exported from OES

    Matyas_Kolcza
    Established Member

    Hi,

    here's the situation: I copied the program from the PLC. On my laptop I have an older version of that same PLC-program. I have to upgrade my old version to be the same as the program on the PLC.I compare them, and found some differencies. Used OES is v4.8.5. The standards are the same.

    Q1: What can I do to not have this Module1.Extension.rStationData REF= DataHandling.StationData.Module1; line in StationUnit.OnApplyParameter exported from the OES into Twincat? A new export from OES does not solve my issue. I also tried with reloading standards, I got the same results.

    old version on left side // version from PLC on the right side

    Matyas_Kolcza_0-1710332375033.png

    Q2: I have 4 OpconDatAccess addons on Module1 level (TypeDataAccessModule1, ResultDataAccessModule1, CgDataAccessModule1, GrrDataAccessModule1). What has to be set in OES to have rStationData : REFERENCE TO Module1StationDataStruct; exported into TypeDataAccessModule1Addon (FB) in Twincat? I have the same problem with all four addons. I can't add that Module1StationDataStruct structure as reference in OES. On Station level the DistributeToModelTree parameter is checked for StationData as shown on the screenshot.

    Matyas_Kolcza_1-1710333126072.png

    Matyas_Kolcza_2-1710333360988.png

    Matyas_Kolcza_5-1710333820873.png

    Matyas_Kolcza_4-1710333479407.png

    Thanks!

    3 REPLIES 3

    MarvinW
    Long-established Member

    Question 1: I'm not familiar with the details of these OES versions, but what probably happened is that the station was done with an older version of OES. In that version the extension didn't recveive the model tree struct references, but in OES4.8.5 they do. If you want to change this then you need to override the default export template. I haven't tested but this feature should be available in OES4.8.5 (I think it was already in OES3).

    To do that, first select a template folder. This has to be done here:

    MarvinW_0-1710393591559.png

    I have only seen the STD used for this but you could also use a folder inside the station.

    Inside this folder you need to put the new template with the same folder structure and name like in your OES installation. The file you want to change is in <Default OES installation path>\OpCon\Templates\_Common\UnitOnApplyParameters.otd. For me the correct path with the standard installation is C:\Program Files (x86)\OpCon\OES V4.8\OpCon\Templates\_Common\UnitOnApplyParameters.otd.

    Copy this file and put it into your template folder, for example when using the path in the screenshot, it needs to go into Std\Templates\_Common\UnitOnApplyParameters.otd.

    Now OES will use this file for export instead of the one in your OES installation folder. So you can modify it and make it skip the extension export. I looked at the file and it's the lines 219 and 226 you want to delete I think (I haven't tested this!)

     

    Question 2: I think this is not possible. Model tree struct variables are only distributed to child units (and their extensions, unless you do Q1 solution) and to chains, but not to add-ons. Just manually add the references in TwinCAT, that's what I would do. Although you don't get much benefit from this over using the global variable directly, judging by the screenshots.

    Just out of curiosity: Is there any OES version that does this export to the add-ons?

    nexidator
    Community Moderator
    Community Moderator

    Both differences have the same reason: A bugfix that came with OES 4.8.3. There is no point in trying to get back to the original code that was downloaded to the PLC. Your new code is better!

    Before the bugfix, every FB was added the rStationData VAR_INPUT (as in Q2). These references were only initialized for the Unit instance and sequence FBs though, so accessing them inside the Extension or add-on FBs would always have caused runtime errors.

    The bugfix removed these reference VAR_INPUTs from all FBs except Unit, Extension and sequences. In OnApplyParameters, the code line (Q1) was added so the reference of the Extension instance is initialized and can be used.

    So, @MarvinW 's answer is technically correct, but I would not recommend doing that!

    Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist