LVRT Hung While Deploying

[sword]

hi everyone here!

 

recently i have come to a odd problem with lvrt(ets) and have no idea about how it goes. 

 

My project uses 10 or more dlls which were wrote by third party and had been put into the RT's C:ni-rtstartupdata  folder, and this path had been added to the system find path list. Each of the dlls may have several VI calls(each for different functions in the dll) in the project. And when i try to deploy the whole project, my RT hung with one of it's cpu went to 100% loads.

 

And the odd thing is, when i try to disable one of the dll (means to disable all the vis that call the dll through the "call library function node"), the deploy goes with no error and my application can run as expected except the disabled parts! During the past one week's struggling with this deploy problem, once i can come to a particular configuration (by removing some no use modules in the RT or changing the dll call's  from "run in UI thread" to "run in any thread"), and under this situation ,i can deploy my project to rt, but when i run, a exception string appears on the RT's screen, which says "flushing disk cache" and something like "system error".

 

Here i have two questions:

1,   does the ets os system have a max number of user defined dlls that can exist in memory at the same time?

2,   does anyone come to the "flushing disk cache" error before in the ets system? can you share some experience with me?

 

any suggestions are welcome and will be appreciated.     i am looking forward to your share, many thanks in advance!

[ShaunR]

hi everyone here!

 

recently i have come to a odd problem with lvrt(ets) and have no idea about how it goes. 

 

My project uses 10 or more dlls which were wrote by third party and had been put into the RT's C:ni-rtstartupdata  folder, and this path had been added to the system find path list. Each of the dlls may have several VI calls(each for different functions in the dll) in the project. And when i try to deploy the whole project, my RT hung with one of it's cpu went to 100% loads.

 

And the odd thing is, when i try to disable one of the dll (means to disable all the vis that call the dll through the "call library function node"), the deploy goes with no error and my application can run as expected except the disabled parts! During the past one week's struggling with this deploy problem, once i can come to a particular configuration (by removing some no use modules in the RT or changing the dll call's  from "run in UI thread" to "run in any thread"), and under this situation ,i can deploy my project to rt, but when i run, a exception string appears on the RT's screen, which says "flushing disk cache" and something like "system error".

 

Here i have two questions:

1,   does the ets os system have a max number of user defined dlls that can exist in memory at the same time?

2,   does anyone come to the "flushing disk cache" error before in the ets system? can you share some experience with me?

 

any suggestions are welcome and will be appreciated.     i am looking forward to your share, many thanks in advance!

 

Have you checked the DLLs with the RT DLL Checker?

[sword]

Have you checked the DLLs with the RT DLL Checker?

 

Yes, i have checked all the dlls by using this tool several days ago, and those dlls are reported to be no bad, but some stubs.  And for these 10 dlls(may be more), when i disable any one of them and enable the remaining, then i can deploy my code to RT. 

 

 anyway, many thanks to you~~~

[Rolf Kalbermatter]

Yes, i have checked all the dlls by using this tool several days ago, and those dlls are reported to be no bad, but some stubs.  And for these 10 dlls(may be more), when i disable any one of them and enable the remaining, then i can deploy my code to RT. 

 

 anyway, many thanks to you~~~

 

Those stubs could be the culprit. Your DLLs may in the initialization routine (the code that gets executed automatically when the DLL is loaded into memory) do call some of these stubs expecting certain values or behavior and getting stuck in an endless loop waiting for these to change. Without seeing the DLL source code this is almost impossible to debug though. During the initialization routine of the DLL, even on Windows the system is more or less monopolized for the current process which can result in a very sluggish or even completely locked up system.

 

If you have a chance to look at the source code or talk to the developer of the DLL, make sure they are not doing anything complicated in the DLLMain() function. That is the function called on loading and unloading of the DLL. In fact there are a lot of things you are not allowed to do in there at all, according to MS, one of them is for instance trying to load other DLLs dynamically, as that will have a good chance to lockup your system in a nice deadlock.

[ShaunR]

Yes, i have checked all the dlls by using this tool several days ago, and those dlls are reported to be no bad, but some stubs.  And for these 10 dlls(may be more), when i disable any one of them and enable the remaining, then i can deploy my code to RT. 

 

 anyway, many thanks to you~~~

 

Is it a case that it used to work on the RT platform and doesn't now. Or is it that it works in windows and now you want to use it on the RT platform?

[sword]

Is it a case that it used to work on the RT platform and doesn't now. Or is it that it works in windows and now you want to use it on the RT platform?

 

yes, the whole project source code was converted from labview  2010, and the original copy of 2010 works fine on the same RT configuration, which uses NI PXI 8353 controller. And I have removed some modules that deal with constant current output, and replaced them with NI 4143 modules. (The system has now 3 NI PXI 4143 cards)

 

And I have not test the RT code on my windows system because all the cards can only be seen under RT (A PXI-1045 and a PXI-1065 chassis contains all the NI PXI boards and connect to PXI 8353 controller through MXI lines), and the most strange thing is when i disable one of my dlls (even if i disable the 4143 modules which can be considered as some wrappers around the 4143 dll), system can be deployed and run as expected. So I speculate that there may be some kind of cap on the number of dlls that can run simultaneously.

 

Yesterday I come to this article http://digital.natinst.com/public.nsf/$CXIV/ATTACH-AEEE-7AVNNM/$FILE/readme_RT.html and it says "The maximum number of files you can open on an ETS RT target simultaneously is 256."   I am not sure if the noun "File" here includes dll files. 

 

Best Regards!            

Those stubs could be the culprit. Your DLLs may in the initialization routine (the code that gets executed automatically when the DLL is loaded into memory) do call some of these stubs expecting certain values or behavior and getting stuck in an endless loop waiting for these to change. Without seeing the DLL source code this is almost impossible to debug though. During the initialization routine of the DLL, even on Windows the system is more or less monopolized for the current process which can result in a very sluggish or even completely locked up system.

 

If you have a chance to look at the source code or talk to the developer of the DLL, make sure they are not doing anything complicated in the DLLMain() function. That is the function called on loading and unloading of the DLL. In fact there are a lot of things you are not allowed to do in there at all, according to MS, one of them is for instance trying to load other DLLs dynamically, as that will have a good chance to lockup your system in a nice deadlock.

 

I think i have got some insight from those suggestions! I have ignored the dllMain function completely before!!! Thank you soooooooooo much!!!!

[sword]

Progress updated.

By deleting the SMP support module of the ETS RT, we can finally run our code with all dll calls enabled, all functions have been tested!