LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Runtime Engine and regional settings

I'm running LV2021SP1 on a PC with a french Windows 10 OS. In LabVIEW I unchecked the "Use localized decimal point" checkbox to use the dot as the decimal point. However after creating an executable I have an issue with the commands sent to a power supply (Keysight N6700),  values like 0.3 are not recognized and the value 0 is sent instead. 

 

My supposition is that the Runtime Engine uses the Windows regional settings ( the decimal separator is a comma with a french OS). I know I can change this setting on a test PC but if somebody change it back the issue will reappear. Can we somehow configure the runtime engine as the development environment to force the use of the dot as the decimal separator?

 

Thanks,

 

Ben

0 Kudos
Message 1 of 5
(494 Views)

@ben64 wrote:

I'm running LV2021SP1 on a PC with a french Windows 10 OS. In LabVIEW I unchecked the "Use localized decimal point" checkbox to use the dot as the decimal point. However after creating an executable I have an issue with the commands sent to a power supply (Keysight N6700),  values like 0.3 are not recognized and the value 0 is sent instead. 

 

My supposition is that the Runtime Engine uses the Windows regional settings ( the decimal separator is a comma with a french OS). I know I can change this setting on a test PC but if somebody change it back the issue will reappear. Can we somehow configure the runtime engine as the development environment to force the use of the dot as the decimal separator?

 

Thanks,

 

Ben


Not sure of the library/API you are using to interface with the Keysight N6700 but perhaps you can use raw bytes instead of strings and then skip part where windows turns your 2Es into 2Cs 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 2 of 5
(456 Views)

All options you can set in the LabVIEW dialog are stored in the according ini file. Your LabVIEW IDE has a LabVIEW.ini file in the same folder as where LabVIEW is installed. You application has its own ini file called <MyApplication>.ini file in the same folder than your <MyApplication>.exe file.

 

The Application Builder supposedly copies some of the entries from your LabVIEW.ini to the build applications ini file and adds that to the build but either you did not include that with your executable or that setting does not get copied over for some reason.

 

Personally I consider it a bug in an instrument driver if it fails on systems that do not use the decimal point. All the string functions that you need to build and parse strings, support a possibility to specify explicitly if the platform specific decimal sign should be used or a decimal point. So if someone writes a driver to work with an instrument, which almost never adapts to your computers locale setting, it should be programmed accordingly to use the decimal point explicitly.

 

 

Rolf Kalbermatter
My Blog
Message 3 of 5
(441 Views)

I have had this issue in the past as well. You can change the decimal separator in Windows as well. Depends which version you are on so a bit of googling is required.

 

This obviously changes it throughout windows

0 Kudos
Message 4 of 5
(417 Views)

Hi,

 

I'm with Rolf about "buggy device drivers": I almost always rework device drivers to work independent from system decimal format settings...

 


@rolfk wrote:

The Application Builder supposedly copies some of the entries from your LabVIEW.ini to the build applications ini file and adds that to the build but either you did not include that with your executable or that setting does not get copied over for some reason.


The AppBuilder just sets some default ini keys in my experience.

When you need specific keys then you should create your own "MyApplication.ini" in your project and use it wie building your application!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 5 of 5
(412 Views)