How do you get openHistorian to display decimal values? I see there is a multiplier field on the measurements dialog box, but it dose not allow a value less than 1.

The openHistorian displays decimal values by default. The multiplier should be used if you need to scale your input values.

Assuming you are referring to the multiplier field in the openHistorian Manager, there is a longstanding issue with the number validation for input fields. As a sort of side-effect of the way it’s implemented, the validation will strip trailing zeros after a decimal point as well as the trailing decimal point and put the result back into the textbox, making it difficult to type the decimal portion of the number directly into the text box. Copy/paste tends to be the most reliable method for getting the number you want into a number field. Similarly reliable but less intuitive; you can start by typing all the digits for the number without the decimal point, then insert the decimal point in the desired location.

Ok, so I think this is hitting bleeding edge of my knowledge of tags, protocols, and things. I could see decimals on the RTAC magnitude output, so I **assumed** I was sending decimals to openHistorian. After your post I took a wireshark capture of the packets going back and forth and noticed that even though the RTAC magnitude showed decimals, the actual packet values were without, and openHistorian was displaying exactly what the RTAC was sending.

My limited understanding is I have two ways of getting decimals into openHistorian. Switch to floating point in the RTAC, or use a multiplier in the RTAC to convert say 654.7 into 6547 and then using the multiplier inside of openHistorian manager to get that number back down to 654.7. Does that sound about right?

I think the answer to that question depends heavily on your device’s capabilities. You already know that openHistorian can apply a multiplier to the data, but the IEEE C37.118 protocol is also capable of transmitting a “conversion factor” along with the data. This conversion factor is essentially a multiplier that gets applied at the protocol level, so there wouldn’t be any configuration necessary in openHistorian. Additionally, as you surmised, transmitting the data in floating point format is also a viable solution.

Also, before you go crazy with the idea of scaling your values to send as integers, note that the integer format uses 16 bits to store the scaled value, so it supports a maximum range of -32768 to 32767.

Excellent! I appreciate the affirmation & information.