How hard would it be to include an Offset value for SQL tags? I’ve run into a situation where we’ve been collecting a lot of temperature data directly from a Opto remote I/O brain and now production wants to be able to offset the temperature value to account for probe variation. I can’t do it in the controller since it’s just I/O and changing it to a calculated tag means dumping all of the previous history and starting over with a different tag. If there was an Offset parameter on the SQL tag I could just change that and there would be no issues. Just a thought!
That’d be easy enough to add, I suppose… but would you expect it offset all past history data as well? Or would it simply be a value added on to the raw value? And would it be applied in reverse to writes?
I’m imagining just another field on the Numeric Options panel, and it would be a value that would be applied after scaling, and would work like scaling, that is, counter applied when writes occur.
No, I was imagining that it would just add/subtract from the raw value. I don’t think I’d want that to happen…
Interesting… I didn’t even think about that but I would think it should otherwise it would be pretty confusing when someone entered a value in and it reads back a different value.
This is exactly what I was thinking as well. You’re the man, Colby!
Ha, you should probably wait til I put it in first…
But yeah, shouldn’t be a problem. I’ll try to get it in for the 7.3.2 release.
How is this different from scaling?
Well… you’re right. And I had the same thought, but the problem is, it doesn’t currently work like that. For a simple offset, you would want low==high, but with different values for raw and scaled. Unfortunately, right now, when the ratio is 1:1, the scaling is turned off.
So really, we’re probably just talking about bug with scaling system that should be fixed.
That’s fine, I’m for that. But is that something that you can change from a client? I don’t see the raw and scaled values as bindable properties under the SQL tag. It looks like you can only change them from the designer or is there another way that I’m not seeing?
In theory you could write to the scale parameter fields, but I don’t know how intuitive it would be. I’m going back and forth- having a simple offset field in addition to making the scaling work correctly wouldn’t be that big of a deal, and if I did that, I could make it a writable property that didn’t cause the tag to be reloaded, as writing to the scale parameters would do. Also, there’s the issue that if you were to do it with scaling, you would need to write to two fields, and that probably wouldn’t be atomic (for what it’s worth… probably not a huge deal).
I’ll have to think about it a little more.
Well, if they’re external SQLTags you can easily write a bit a code and screen to handle it. Extending the tag configuration screen would be where I would start. [quote=Colby.Clegg]Also, there’s the issue that if you were to do it with scaling, you would need to write to two fields, and that probably wouldn’t be atomic[/quote] Write both fields and then update the configchange time.
Of course if this are internal tags, that would require a module.
Yeah, they are all internal tags. Let me know what you come up with, Colby. Thanks for at least looking into it
Actually, what I had in mind was that you could use something like:
You can write to most tag properties this way (even if they’re not shown in the tree… the tree only shows things it thinks you would want to bind to).
The properties involved in scaling are: RawLow, RawHigh, ScaledLow, ScaledHigh
And, ScaleMode (0=off, 1=linear, 2=square root)
To follow up: for 7.3.2, the scaling feature has been fixed to allow for simple offsets, if low==high. I still think there’s room for a separate setting, but since this technically allows for what you want to do, it’s all that we did for this release.
Yeah, I noticed that in the release notes for 7.3.2. I just upgraded our servers to 7.3.2 today so I’ll play with it this week if I get a chance. Thanks, Colby!
I finally got around to using this and it works good. Not as easy as just binding to an offset property, but not too bad at all. Thank you, sir!