1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Odd characters in temperatures showing in Phoebus |
From: | "Leblanc, Gregory via Tech-talk" <tech-talk at aps.anl.gov> |
To: | "Kasemir, Kay" <kasemirk at ornl.gov> |
Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Tue, 5 Oct 2021 15:36:11 +0000 |
Sorry, I’ve failed to link to the working git repo for my mess: https://github.com/gregoryleblanc/CsHeater The file in question is: https://github.com/gregoryleblanc/CsHeater/blob/main/CsHeaterApp/Db/Watlow_PM_Monitor.template I don’t have a head on the Pi running the softIoc, but I do have another linux box here. I’ll get CSS installed and see what it says. I can probably also get debugging info from the windows version, although the console output is very
noisy. Greg From: Kasemir, Kay <kasemirk at ornl.gov> Hi: If I understand correctly, you do have the UTF-8 0xc2b0 in the EPICS database file, good. caget on Linux also shows that as a degree sign. Can you run CSS on Linux to see what comes up in the GUI? It's possible that it all works on Linux because UTF-8 tends to be the default there. On Windows we might be missing something in the CSS code to select UTF-8, so we end up with some other default and thus the characters are not correctly mapped. -Kay From: Leblanc, Gregory <leblanc at ohio.edu> Looking at Watlow_PM_Monitor.template in Notepad++ with the HEX editor installed, I see that it is already showing 0xC2 0xB0 (screenshot attached).
When I look at the Windows ANSI (windows-1252) code page, I see that 0xC2 is for Latin Capital letter A with circumflex, and 0xB0 is degree sign. So that explains why I’m seeing the double characters in Phoebus, though not what to do
about it. Next I tried running “> caget -d CTRL_DOUBLE SP_Cesium:Oven_Heater:ProcessValue1 > bad.txt That command always shows the strange character, regardless of what is displayed on the console. When I open that file in notepad++, I get the strange T character. When I look at the hex dump, it shows the “┬”
character is encoded as 0x2c 0x25. It also shows a “░” character with an encoding of 0x91 0x25. ‘file bad.txt’ from WSL reports: bad.txt: Little-endian UTF-16 Unicode text, with CRLF line terminators I don’t seem to get the strange character encoding when I run caget from linux, which would make sense if it’s somehow related to the windows codepage. Greg From: Kasemir, Kay <kasemirk at ornl.gov>
Well, try to use some type of hex editor to edit the database file and make it field(EGU, "xxxx") and for the xxxx you need to get 0xC2 0xB0 in there, because that's the UTF-8 for the degree symbol, http://www.unicode-symbol.com/u/00B0.html Or simply use field(EGU, "C") or field(EGU, "Deg C") ;-) From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Leblanc, Gregory via Tech-talk
<tech-talk at aps.anl.gov> Well, that gives me some interesting results. Full dump at:
https://pastebin.com/4iqDBfem TL;DR: > caget -d CTRL_DOUBLE SP_Cesium:Oven_Heater:ProcessValue1 Units:
┬░ > ssh elsewhere & return > caget -d CTRL_DOUBLE SP_Cesium:Oven_Heater:ProcessValue1 Units: ° Same behavior using PowerShell and command prompt. I don’t see any change to $OutputEncoding before or after the ssh command, nor does manually setting $OutputEncoding = [System.Text.Encoding]::UTF8 make any difference. Chcp reports
the same active code page before and after ssh (437), so that doesn’t seem to be the right direction. I don’t have hexdump on windows, yet.
Greg From: Kasemir, Kay <kasemirk at ornl.gov>
> caget SP_Cesium:Oven_Heater:ProcessValue1 SP_Cesium:Oven_Heater:ProcessValue1 22.855 Try caget -d CTRL_DOUBLE SP_Cesium:Oven_Heater:ProcessValue1 and note the 'Units'. Also try caget -d CTRL_DOUBLESP_Cesium:Oven_Heater:ProcessValue1 | hexdump -c to see exactly what characters follow the "Units:"... Fundamentally, phoebus will allow UTF-8 encoded text for the units. -Kay |