Log In
Register
Forum
Topic RSS
2:42, EET
November 21, 2020
Offline
Hello,
i am very new with Android Studio and Prosys OPC UA SDK, so maybe the question is not difficult.
During the debugging i have the message: “Source code does not match the bytecode”.
Is it something normal with Prosys OPC UA SDK library?
Thanks!
10:14, EET
April 3, 2012
Offline
Hi,
IF you are using a source edition of the SDK (i.e. edition that contains source codes of the SDK in addition to the binary), note that the binary jar distributed within those are the same as with binary-only editions, thus the jar is obfuscated, thus any “Source attachement” functionality wont work out-of-the-box. Basically in these cases you would have to compile a separate “debug jar” from the sources.
If that was not the case, it is probably related to android studio. With a short googling, I could find this: https://stackoverflow.com/questions/39990752/source-code-does-not-match-the-bytecode-when-debugging-on-a-device, though it is somewhat old post.
P.S.
Also note that if you have an non-source edition, you basically cannot debug the SDK internal parts (unless running on a dev tool that shows bytecode-level operations etc.), I have not personally used Android Studio in a while, thus in theory this error message could be just from not having the sources at all.
P.S.2
Please check that the class the debugger currently on is a com.prosysopc.ua (or subpackages) packaged class, or that the stacktrace of the Thread (typically you can see this from somewhere) contained one. If not then that has nothing to do with our SDK.
19:19, EET
November 21, 2020
Offline
Thank you for reply!
You are right, i use a source edition of the SDK. So during debugging i have the message as in the subject of this post.
In general after SDK update I have problem with connection to the PLC (Siemens S7-1500) -everything works very slowly. That’s why i started debugging to find where the problem is.
I did everything what is written in: https://www.prosysopc.com/blog/developing-opc-ua-for-android/
I use prosys-opc-ua-sdk-client-4.4.2-1266.jar.
Prosys OPC UA app client works without any problem – it is very fast. Other client works also fine.
My app was working better before update (although it was always quite slow). Now it takes 90 seconds to connect to the server (PLC).
During this time i can see in the debug windows as below:
11/23 12:11:57: Launching ‘app’ on Pixel 2 API 28.
App restart successful without requiring a re-install.
$ adb shell am start -n “com.nissisample.project.myapplication/com.nissisample.project.smarttool.MainActivity” -a android.intent.action.MAIN -c android.intent.category.LAUNCHER -D
Waiting for application to come online: com.nissisample.project.myapplication.test | com.nissisample.project.myapplication
Waiting for application to come online: com.nissisample.project.myapplication.test | com.nissisample.project.myapplication
Connected to process 27161 on device ‘Pixel_2_API_28 [emulator-5554]’.
Waiting for application to come online: com.nissisample.project.myapplication.test | com.nissisample.project.myapplication
Connecting to com.nissisample.project.myapplication
Connected to the target VM, address: ‘localhost:61936’, transport: ‘socket’
Capturing and displaying logcat messages from application. This behavior can be disabled in the “Logcat output” section of the “Debugger” settings page.
I/t.myapplicatio: Not late-enabling -Xcheck:jni (already on)
W/t.myapplicatio: Unexpected CPU variant for X86 using defaults: x86
W/ActivityThread: Application com.nissisample.project.myapplication is waiting for the debugger on port 8100…
I/System.out: Sending WAIT chunk
I/System.out: Debugger has connected
waiting for debugger to settle…
I/chatty: uid=10086(com.nissisample.project.myapplication) identical 1 line
I/System.out: waiting for debugger to settle…
I/System.out: waiting for debugger to settle…
I/chatty: uid=10086(com.nissisample.project.myapplication) identical 3 lines
I/System.out: waiting for debugger to settle…
I/System.out: waiting for debugger to settle…
I/System.out: debugger has settled (1409)
W/t.myapplicatio: Accessing hidden method Landroid/view/View;->computeFitSystemWindows(Landroid/graphics/Rect;Landroid/graphics/Rect;)Z (light greylist, reflection)
Accessing hidden method Landroid/view/ViewGroup;->makeOptionalFitsSystemWindows()V (light greylist, reflection)
D/OpenGLRenderer: Skia GL Pipeline
D/HostConnection: HostConnection::get() New Host Connection established 0xddc19920, tid 27195
D/HostConnection: HostComposition ext ANDROID_EMU_CHECKSUM_HELPER_v1 ANDROID_EMU_native_sync_v2 ANDROID_EMU_native_sync_v3 ANDROID_EMU_native_sync_v4 ANDROID_EMU_dma_v1 ANDROID_EMU_YUV420_888_to_NV21 ANDROID_EMU_YUV_Cache ANDROID_EMU_async_unmap_buffer GL_OES_EGL_image_external_essl3 GL_OES_vertex_array_object GL_KHR_texture_compression_astc_ldr ANDROID_EMU_host_side_tracing ANDROID_EMU_gles_max_version_3_0
I/ConfigStore: android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasWideColorDisplay retrieved: 0
android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasHDRDisplay retrieved: 0
I/OpenGLRenderer: Initialized EGL, version 1.4
D/OpenGLRenderer: Swap behavior 1
W/OpenGLRenderer: Failed to choose config with EGL_SWAP_BEHAVIOR_PRESERVED, retrying without…
D/OpenGLRenderer: Swap behavior 0
D/eglCodecCommon: setVertexArrayObject: set vao to 0 (0) 0 0
D/EGL_emulation: eglCreateContext: 0xe57ff0a0: maj 3 min 0 rcv 3
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
D/HostConnection: createUnique: call
HostConnection::get() New Host Connection established 0xddc19f60, tid 27195
D/HostConnection: HostComposition ext ANDROID_EMU_CHECKSUM_HELPER_v1 ANDROID_EMU_native_sync_v2 ANDROID_EMU_native_sync_v3 ANDROID_EMU_native_sync_v4 ANDROID_EMU_dma_v1 ANDROID_EMU_YUV420_888_to_NV21 ANDROID_EMU_YUV_Cache ANDROID_EMU_async_unmap_buffer GL_OES_EGL_image_external_essl3 GL_OES_vertex_array_object GL_KHR_texture_compression_astc_ldr ANDROID_EMU_host_side_tracing ANDROID_EMU_gles_max_version_3_0
E/eglCodecCommon: GoldfishAddressSpaceHostMemoryAllocator: ioctl_ping failed for device_type=5, ret=-1
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
D/eglCodecCommon: setVertexArrayObject: set vao to 0 (0) 3 2
W/ActivityThread: handleWindowVisibility: no activity for token android.os.BinderProxy@3421c51
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
W/ActivityThread: handleWindowVisibility: no activity for token android.os.BinderProxy@e16f55e
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
I/chatty: uid=10086(com.nissisample.project.myapplication) RenderThread identical 7 lines
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
W/t.myapplicatio: Verification of java.lang.String com.nissisample.project.smarttool.SimpleClient.readData(java.lang.String) took 305.520ms
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
W/System.err: log4j:WARN No appenders could be found for logger (com.prosysopc.ua.UaApplication).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
W/t.myapplicatio: Verification of void com.prosysopc.ua.types.opcua.client.ClientInformationModel.() took 472.180ms
I/t.myapplicatio: Background concurrent copying GC freed 66025(4MB) AllocSpace objects, 13(320KB) LOS objects, 27% free, 16MB/22MB, paused 1.077ms total 110.029ms
I/t.myapplicatio: Background concurrent copying GC freed 113024(5MB) AllocSpace objects, 1(60KB) LOS objects, 24% free, 18MB/24MB, paused 515us total 101.049ms
I/t.myapplicatio: Background concurrent copying GC freed 125051(6MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 18MB/24MB, paused 551us total 100.186ms
I/t.myapplicatio: Background concurrent copying GC freed 149756(8MB) AllocSpace objects, 0(0B) LOS objects, 23% free, 20MB/26MB, paused 1.220ms total 116.660ms
I/t.myapplicatio: Background concurrent copying GC freed 140112(8MB) AllocSpace objects, 0(0B) LOS objects, 23% free, 20MB/26MB, paused 1.704ms total 106.956ms
I/t.myapplicatio: Background concurrent copying GC freed 119438(6MB) AllocSpace objects, 0(0B) LOS objects, 20% free, 23MB/29MB, paused 588us total 108.079ms
I/t.myapplicatio: Background concurrent copying GC freed 150121(8MB) AllocSpace objects, 0(0B) LOS objects, 21% free, 22MB/28MB, paused 789us total 107.144ms
I/t.myapplicatio: Background concurrent copying GC freed 151044(8MB) AllocSpace objects, 0(0B) LOS objects, 19% free, 24MB/30MB, paused 556us total 163.681ms
I/t.myapplicatio: Background concurrent copying GC freed 190613(11MB) AllocSpace objects, 0(0B) LOS objects, 19% free, 24MB/30MB, paused 532us total 107.223ms
I/t.myapplicatio: Background concurrent copying GC freed 170189(7MB) AllocSpace objects, 0(0B) LOS objects, 20% free, 23MB/29MB, paused 600us total 191.531ms
I/t.myapplicatio: Background concurrent copying GC freed 205632(9MB) AllocSpace objects, 0(0B) LOS objects, 20% free, 22MB/28MB, paused 529us total 112.111ms
I/t.myapplicatio: Background concurrent copying GC freed 176993(8MB) AllocSpace objects, 0(0B) LOS objects, 21% free, 21MB/27MB, paused 556us total 101.729ms
I/t.myapplicatio: Background concurrent copying GC freed 145497(7MB) AllocSpace objects, 0(0B) LOS objects, 19% free, 25MB/31MB, paused 433us total 128.478ms
I/t.myapplicatio: Waiting for a blocking GC ProfileSaver
I/t.myapplicatio: WaitForGcToComplete blocked ProfileSaver on HeapTrim for 18.135ms
I/t.myapplicatio: Background concurrent copying GC freed 160424(9MB) AllocSpace objects, 0(0B) LOS objects, 27% free, 16MB/22MB, paused 5.877ms total 69.118ms
I/t.myapplicatio: Background concurrent copying GC freed 171958(9MB) AllocSpace objects, 0(0B) LOS objects, 27% free, 15MB/21MB, paused 8.316ms total 67.569ms
I/t.myapplicatio: Background concurrent copying GC freed 190978(10MB) AllocSpace objects, 0(0B) LOS objects, 25% free, 17MB/23MB, paused 717us total 145.066ms
I/t.myapplicatio: Background concurrent copying GC freed 162765(9MB) AllocSpace objects, 0(0B) LOS objects, 26% free, 16MB/22MB, paused 1.865ms total 100.834ms
I/t.myapplicatio: Background concurrent copying GC freed 120432(7MB) AllocSpace objects, 0(0B) LOS objects, 27% free, 15MB/21MB, paused 8.547ms total 69.953ms
I/t.myapplicatio: Background concurrent copying GC freed 144903(8MB) AllocSpace objects, 0(0B) LOS objects, 25% free, 17MB/23MB, paused 536us total 110.993ms
I/t.myapplicatio: Background concurrent copying GC freed 154529(9MB) AllocSpace objects, 0(0B) LOS objects, 25% free, 17MB/23MB, paused 664us total 126.094ms
I/t.myapplicatio: Background concurrent copying GC freed 177946(10MB) AllocSpace objects, 0(0B) LOS objects, 26% free, 16MB/22MB, paused 589us total 123.029ms
I/t.myapplicatio: Background concurrent copying GC freed 136090(7MB) AllocSpace objects, 0(0B) LOS objects, 27% free, 15MB/21MB, paused 5.447ms total 70.488ms
I/t.myapplicatio: Background concurrent copying GC freed 161717(8MB) AllocSpace objects, 0(0B) LOS objects, 27% free, 15MB/21MB, paused 6.461ms total 64.225ms
I/t.myapplicatio: Background concurrent copying GC freed 163729(9MB) AllocSpace objects, 0(0B) LOS objects, 23% free, 20MB/26MB, paused 567us total 174.438ms
I/t.myapplicatio: Background concurrent copying GC freed 174988(10MB) AllocSpace objects, 0(0B) LOS objects, 24% free, 18MB/24MB, paused 1.220ms total 122.704ms
I/t.myapplicatio: Background concurrent copying GC freed 143071(7MB) AllocSpace objects, 0(0B) LOS objects, 23% free, 19MB/25MB, paused 545us total 126.943ms
D/uri_uri: http://opcfoundation.org/UA/DI/
D/value: Connected
D/sss: Connected
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
D/EGL_emulation: eglMakeCurrent: 0xe57ff0a0: ver 3 0 (tinfo 0xdca0bde0)
14:52, EET
April 3, 2012
Offline
Hi,
That blog post is from 2012. OPC UA and thus our SDK has changed a lot during the last 8 years (or well, a lot of things have been added to OPC UA, the “core” is like still the same depending on how you look at it).
What version of the SDK did you use before?
But in general, the way the current release and few versions before that worked is that they read all types from the server during connect. Depending on things, it might actually be faster, but in some cases it can be slower as well. We have done some tests with our office S7-1500, but my current understanding is that it cannot accept and process data fast enough and thus it is slower. The S7-1500 also tends to use a lot of custom Structures, thus there are more types to read. Also it uses lower so called OperationLimits, it usually can just accept 1000 operations at once.
What duration for the connection would be considered as acceptable by you?
However, IF you have used any UaNodes or custom Structure reading/writing, any AddressSpace.getNode operation should be considerable faster now. They previously did do a sequential Read/Browse to get the types (since they are also UaNodes in our design), and it effectively did read about 100 or so nodes recursively one-by-one, which is slow. And if you have really old SDK before, it probably didn’t also support custom Structures (without our codegen tool at least).
It is possible to disable the so called TypeDictionary initialization, which will basically revert to the old design, though note that then you cannot basically decode custom structures and if you make any getNode calls or basically operate on UaNodes, it will have to fetch the nodes (and that works the same way as previously at that point).
You must call:
UaClient.setInitTypeDictionaryOnConnect(false) and UaClient.setInitTypeDictionaryAutoUsage(false) before connecting. Note that if you do not set the autousage to false, then on first encounter with a custom Structure it will do the initialization, which might be problematic, if it takes so long that you would want to disable it in the first place.
Also it should be noted that this is somewhat of an ongoing issue, and our current implementation is sort of best-effort balance that should work within all situations with the OPC UA 1.04 new DataTypeDefinition Attribute (this requires a separate long post, so I’ll only make it if needed). Doing the things as part of the connection in my opinion is mostly the only solution as I think SDK should not “block the channel” sort of after the connect method returns.
13:20, EET
November 21, 2020
Offline
Hello,
Thank you for the information. This really helped me a lot!
First of all i reduced number of tags available on OPC UA Server (PLC) so the connection time is reduced to 35 seconds form 90 seconds.
Then I used UaClient.setInitTypeDictionaryOnConnect(false) and UaClient.setInitTypeDictionaryAutoUsage(false) so the connection time is just 2 seconds.
When i read the value of the tags then it is also very fast. I do not take all the nodes from the server. I just read the specific defined tags from the PLC.
Everything works fast now.
Thank you for the support.
15:31, EET
April 3, 2012
Offline
Ok, good. As long as you do not “touch” any UaNode based API within the SDK and do not want to read/write custom Structure types that will work.
Hopefully in the long run we could deduce need for that automatically, but that might be … complicated.
And we might need some intermediate strategies, but basically the way DataTypeDefinition could manifest in a server is without “encoding nodes” (since the definition itself also has a “default encoding nodeid”. OPC UA uses encoding nodeids instead of the DataType NodeIds direction for Structures (I would say partially due to historical reasons, though in reality that probably never can change in a binary-compatible way, since the very servicerequests UA consists of are also sort of Structures themselves).
IF however it would be known that 1) The server supports DataTypeDefinitions, for ALL custom Structures and 2) It has HasEncoding references from each custom structure DataType node to the encoding nodes (thus it can be reversed by a client easily via Browses and Reads), it might be possible to do this part in a lazy way. Though that would basically have to be given to the SDK as a parameter, it cannot really be known beforehand that I can see. Also due to the bulk-nature of the requests, it is well not exactly same, but close to ask the data of e.g. 100 of nodes vs. just one, if you then find out that the Structure DataType happened to have a field of a custom Structure type, and then you have do basically do that recursively, which is slower network-wise than to do them upfront.
Thus in the worst case, an encounter with a custom encoding id means _every_ Structure DataType must be checked. And since we basically need to sort of do that anyway for the old DataTypeDictionary system (pre 1.04-way of knowing the Structure metadata needed to encode/decode their binary representation), it sort of made sense to do it like this. But it will still probably need more work..
Also based on https://forum.prosysopc.com/forum/opc-ua-java-sdk/inittypedictionaryonconnect-performance/ there could also be some bugs, not sure yet.
Most Users Ever Online: 1919
Currently Online:
40 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 727
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1529
Posts: 6471
Newest Members:
kourtneyquisenbe, ellis87832073466, zkxwilliemae, gabriellabachus, Deakin, KTP25Zof, Wojciech Kubala, efrennowell431, wilfredostuart, caitlynfajardoModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1032, Jimmy Ni: 26, Matti Siponen: 349, Lusetti: 0
Administrators: admin: 1
