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

Increasing Timeout and resolving Type Mismatch in Data Storage App

Increasing Timeout and resolving Type Mismatch in Data Storage App

TY14
New Poster

I am currently working on an app that should be able to do the following:
It should be able to store data over a user-selected period of time.
- You need to specify the node you want to save.
- You need to specify the mount point of the USB device.
- The period you want (in seconds).
- And the interval at which a value should be saved during that period.

So far, it works quite well, however, I keep getting the following error message in the node:
Method failed - Error: 408
DL_TIMEOUT
original error: DL_TIMEOUT
and
Method failed - Error: 400
DL_TYPE_MISMATCH
Can't read type Information

Despite the error messages, the saving function works, but then the app crashes and has to be restarted.
My specific question is how I can increase the timeout and why I am getting a mismatch error.
Below you will find the important files.

And a few screenshots of what I have already tried:

Screenshot (46).pnghere you can see the mismatch error

Screenshot (47).pngtimeout error

Screenshot (45).pngbut if i chose 2 seconds for period it works

Screenshot (43).png

I guees the reason is in node: types/webserver/settings
the default is at 3000 ms, is there a possibilty to change the default?

Screenshot (44).pngi also tried to change the value in callable-timeout settings

Screenshot (48).pngIn the logbook you can see that my code works in manipulating the timeout; it says: Timeout value for the method sdk/usb/history successfully changed at 24000 ms
I tried to set the timeout based on the period and interval

Screenshot (8).pngand finally you can see that it somehow worked

Maybe someone with similar problems could help me out. 
Thanks in advance 

 



 





4 REPLIES 4

Sgilk
Contributor

@TY14 ,

It seems that the type mismatch error only happens when you save certain datalayer nodes? There is a lot of casting happening here, so it could very well be those operations.

        if "history" in address:
            root = InertialValue3.GetRootAs(buffer, 0)
            try:
                node = root.Node()
                mount = root.Mount()
                period = root.Period()
                interval = root.Interval()

                if isinstance(node, bytes):
                    node = node.decode('utf-8')
                if isinstance(mount, bytes):
                    mount = mount.decode('utf-8')

                # Sicherstellen, dass period und interval Ganzzahlen sind
                if not isinstance(period, int):
                    period = int(period)
                if not isinstance(interval, int):
                    interval = int(interval)

                # Timeout-Wert berechnen
                timeout_value = 1000 * period * interval

                # Setzen des Timeouts für die Methode
                result = self._provider.set_timeout_node(self._providerNode, timeout_value)

                if result == Result.OK:
                    print(f"Timeout-Wert für Methode {self._nodeAddress} erfolgreich auf {timeout_value} ms gesetzt")
                else:
                    print(f"Fehler beim Setzen des Timeout-Werts für Methode {self._nodeAddress}: {result}")
                    cb(Result.FAILED, None)
                    return


            except (ValueError, TypeError) as e:
                print(f"Error while decoding values: {e}", flush=True)
                cb(Result.TYPE_MISMATCH, None)
                return
        

I don't have a good guess on the DL_TIMEOUT problem besides overflowing some type maximum.

I would suggest deploying this app with a remote target and debugging. Set breakpoints on the TYPE_MISMATCH and DL_TIMEOUT errors to catch them as they are thrown.

All right, thanks for the input.
I thought it might be the casting, but when I take it out I get a fatal error

tiramisu
Member

@TY14 ,

I think your problem is that you're answering the request in an synchronous way blocking the provider. So the provider can't send keepalives back to the broker/client. When a client gets no keepalive or answer after 3 seconds it will asume that the request is dead and return a timeout.

timeout_handling.png

A solution is to do it in an asynchronous way:

  • Have a worker thread for doing the "hard" work.
  • In the on...-Method forward the request to the worker thread and return without calling the callback
  • In the worker thread do the work and after finishing call the callback with the result.

So the provider thread is not blocked and can send keepalives back to the client/webserver. You as a implementer of a provider can modify the timeout values:

2024-08-01_08h14_40.png

2024-08-01_08h16_11.png

Thanks for the comprehensive explanation.
But I somehow figured out how to increase the timeout value in the data layer

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