How to use Unicode characters with TestStand?

[Mark_Ireton]

I'm trying to implement the use of Greek characters such as mu and omega for units. I enabled multi-byte support in the station options and attempted to paste some characters in. I was able to paste the mu character (μ) and import it from Excel with PropertyLoader. However, I have not had any luck with omega (Ω). I found the HTML codes for these characters on a web page (http://www.hclrss.demon.co.uk/unicode/) so I could use those codes for HTML reports, but that won't work for database logging, nor does it display the characters correctly for the operator interface. The operator interface is not a major problem, but the database must have the correct characters for customer reports. Anyone know how to do this? D
oes database logging support Unicode for stored procedure calls to Oracle?

[Elaine_R.]

Hello Mark -

At this time TestStand has no unicode support. The multi-byte support that we do offer is based on the Windows architecture that handles Asian language fonts. It really isn't meant to provide a bridge for unicode values in TestStand. Certainly, your Operator Interface environment will have its own support level for unicode, i.e. at this time neither LabWindows/CVI version 6.0 nor LabVIEW 6.1 officially support unicode characters. This is why you will see that the units defined in the TestStand enumerators are all text-based values.

I have run a quick test here, probably similar to what you were doing on your end, and I am uncertain if you will get the database behavior you want from TestStand. The database logging steps and API all use basic char sty
le strings to communicate to the driver. Even though you are reading in a good value from Excel, TestStand is interpreting the character as the nearest ASCII equivalent, i.e. "Ω" will be stored and sent to the database as "O". If you have a stored proceedure in Oracle that is calling on some TestStand variable or property string as an input, then it is doubtful you will get correct transmission of the values to the database. If your stored proceedure could call into a spreadsheet directly, you would probably have better luck.

Regards,

Elaine R.
National Instruments
http://www.ni.com/ask