LabVIEW
Issue Running Chinese Labview App in the US
Solved!
I have an Labview application written by our Chinese supplier to monitor some equipment. They asked me to install Labview runtime 2013 to run the application. But so far we have not been able to have it work. I would like to know if anyone as ideas that may help.
32 vs 64 bit: Supplier says the app should work on either machine. So far It has not ran on either type. I have tested the app on 3 machines:
- Windows7 pro -64 Bit with LVRTE2013_64bitstd: Application crash at start with message about memory manager.cpp error DAbort 0xF50EFD7B
- Windows10 Pro - 64 bit with LVRTE2016_F64Patchstd-2: Same as above, same error
- Windows7 home -32 Bit with LVRTE2013std: Application seems to start but cannot find some subVI.
1) It would seem that the application is not compatible with 64 bit. But is it because I have the wrong Runtime for a 64 bit application or are the applications sensistive to the bit type?
2) 2013 vs 2016: are the runtime forward compatible meaning I can run an application developed for 2013 with labview 2016 installed? In case of multiple installation does the application automatically find the correct version of the runtime?
3) So far the most encouraging result are with the Widows7-Home version. But the system does not seem to find some subVI. I noticed that Win7 home in the US does not recognize chinese characters. I have strange characters instead. Could this be the issue? and if so how to resolve it since Pro and Ultimate are 64 bits?
or is it possible that the Application is looking for some standard VI that are not in the runtime:
Any advice or comment would be appreciated.
JmarcZ wrote:1) It would seem that the application is not compatible with 64 bit. But is it because I have the wrong Runtime for a 64 bit application or are the applications sensistive to the bit type?
2) 2013 vs 2016: are the runtime forward compatible meaning I can run an application developed for 2013 with labview 2016 installed? In case of multiple installation does the application automatically find the correct version of the runtime?
3) So far the most encouraging result are with the Widows7-Home version. But the system does not seem to find some subVI. I noticed that Win7 home in the US does not recognize chinese characters. I have strange characters instead. Could this be the issue? and if so how to resolve it since Pro and Ultimate are 64 bits?
or is it possible that the Application is looking for some standard VI that are not in the runtime:
Any advice or comment would be appreciated.
1) if the application is compiled with 32-bit LabVIEW, you need the 32-bit rte.
2) same for the run-time engine itself. You need the right version. This might be different for the newest versions btw, but you'll get a message that the correct rte is missing, with a required rte in the message.
3) if vi's are missing, the executable is not build correctly. The weird characters are caused because the os's codepage is incorrect. LabVIEW uses codepage to convert characters to Unicode. So you probably need to configure the os (regional settings) to use Chinese codepage (could be modern or traditional, two different codepages). Or use a utility AppLocale or Locale Emulator (win10, didn't try myself) to start the application with a specific codepage. Not sure if this would make the exe crash if it's wrong though. The vi's seem to be stored with Chinese names. So the wrong cp, might cause some weird conversions that could result in not finding the vi's.
Search LabVIEW like a graph! Great! Thanks for letting us know. Would you mind accepting a solution? It helps other users to see the thread is closed.
@essien wrote:
Add 1: OS language mismatch will lead to "error DAbort 0xF50EFD7B", my example "OS-EN, Program compiled in CN".
That might not be related to the OS language at all. It could be however. Better post in a new thread... Also, crash reports and detailed errors might help.
At first glance, most 0xF50EFD7B errors seem to be related to drivers, such as IMAQ, NI-Scope and others... Details on that might speed up things too.
