‎02-19-2021 07:29 AM
Hi
I'm in test phase of my project and encountered lots ACBRProxyCaller errors.
My project is composed of one clone module and his front panel is displayed in a sub-panel of the tester vi. My main cloned module is a bit fat, but most of the time it runs correctly.
I have tested it for one night without any errors. But if I try to do something on my computer like loading other programs or make some web searches, sometimes I obtain randoms error ACBRProxyCaller from randoms sources in my program. The source of error can become from any sub-vi in my module. I don't think than the problem became from DQMHor of my program structure but more from LV (I use LV2018). After few searches on the web, the origin of this kind of error are not very clear, but like ACBR = Asynchronous Call By Reference, I suspect the cloning management. Have you ever encountered this kind of errors? Have you any suggestions to avoid this? I'm afraid because in the end, I need to run 25 clones modules at the same time, and if I start to have a problem just with one, what about 25...
‎02-19-2021 10:37 AM
Can you post screenshots of the errors that you're seeing?
‎02-19-2021 12:06 PM
Hi Eric,
We have seen applications launching thousands of cloneable modules in parallel with no issues.
Posting a video or code may help us help you.
Regards,
Fab
‎02-22-2021 04:33 AM
Hi Darren and Fabiola
Here a kind of error:
The Sub-Vi referenced in the error is a simple TCP connection like this:
I have inlining it to try to solve errors but without success. Before the inlining transformation, I have to try to debug it to find the source of error, but sometimes it appears just after TCP Connect, or after TCP Send or TCP Read. I have detected ACBRProxyCaller in one other sub-vi, but the most of time it appears in the TCP sub-vi. I suspect than error is linked to a time response of the system. Like I said before, I don't think it's about DQMH but from LV and perhaps from my PC who is a bit old.
‎02-22-2021 07:24 AM
That error has nothing to do with DQMH:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Lz2SAE&l=en-US
The reason you're seeing the ACBRProxyCaller text in the error message is because, as of DQMH 5.0, DQMH Main VIs are launched via Async Call By Ref (the 'ACBR' in the VI name), so VI names are going to be reported in the way you're seeing in the error message... that text is simply the standard call chain reporting from the TCP functions. If you were using a previous DQMH release (DQMH 4.2 and earlier), you would see the same error message, just without the ACBRProxyCaller text, since in earlier DQMH releases, the DQMH Main VI was launched via a different mechanism (the 'Run VI' method).
‎02-22-2021 11:58 AM
Thanks, Darren
I don't see the error structure message and I agree with you, it's not a DQMH problem.
I will investigate around TCP server.
But like you can see below it's can arrive from send and received with lost time Code error 1.
Do you think than add dedicate inner TCP port in place of 0 (ask windows to define port) can improve that.
‎02-22-2021 12:46 PM
I'm not familiar enough with your application's TCP usage to be able to offer specific suggestions. I would say that in the past, I've found it helpful to have a DQMH module that manages the TCP connection, and a helper loop with a state machine is used to close and re-open the TCP connection any time a connection error has occurred.
‎02-22-2021 12:53 PM
It's exactly what I have made.