ENH: Thermocouple Pragmas and Generalization

[ZLLentz]

FB_ThermoCouple actually supports both thermocouples and RTDs, but the semantics need to be generalized a bit. This PR deprecates the old FB and makes a new FB_TempSensor with the following pragma changes:

• STC is no longer baked into the PV name
• fTemp has EGU and PREC pragmas
• Boolean fields now all have proper ONAM and ZNAM

Some advice needed: what's the best way to make PREC a configurable field? As it is now it is hard-coded, but if I leave PREC un-pragmad then I expect that a user's outer PREC macro will fill in to the boolean fields as well... Not desired behavior. Is there a way to limit which records the user's outer pragma propagate down to?

[klauer]

Some advice needed: what's the best way to make PREC a configurable field? As it is now it is hard-coded, but if I leave PREC un-pragmad then I expect that a user's outer PREC macro will fill in to the boolean fields as well... Not desired behavior. Is there a way to limit which records the user's outer pragma propagate down to?

I missed these on my first pass, sorry - you can fill in just the precision using a different syntax (see the flight rules https://confluence.slac.stanford.edu/display/PCDS/Beckhoff+Flight+Rules ). But I'm not sure you can have multiple pytmc pragmas in a row, as you'd want the pv prefix to be broadcast to all members and not the precision.

Perhaps we just shrug at the PLC level and pass the buck to EPICS. Turn on autosave for the PREC field, and require a one-time setup step in EPICS.

[ZLLentz]

I'm going to make the two changes discussed above:

1. Add deprecation warning using the warning pragma
2. Add default "bad" values to unlinked error variables

[ZLLentz]

@slacAWallace I see you pushed a div by zero fix via github. I'll check to make sure the lib still builds in TwinCAT later. I think the indentations are messed up now.

However, is this the correct way to handle this? Or should this lib have implicit zero div checking?

[ZLLentz]

Also, I'm not convinced that this needs to set a reasonable temperature on zero div because it is the user's mistake to change the scale to zero. There is no case where you want to change this during program execution. There is also no case where the correct value is something other than 10 or 100 as far as I know.

[ZLLentz]

What I'm trying to say is, it's improper to push like this to an open and approved PR. An additional change that needs additional discussion should be treated as second PR.

[ZLLentz]

Ok I want to wrap this up... I made this PR because the pragmas 100% needed to be fixed for some of Maggie's components and it has become too many other things. Also a release was just made and I missed it which makes me extremely sad.

[klauer]

Let's remove the previous commit and make a new tag. It's not too late.

[ZLLentz]

I'm going to fix the spacing and change the default temp to something clearly wrong like absolute zero

[ZLLentz]

Another thought: it may have been better to have a multiplier instead of a divisor, then the default would be 0.1 and there is no possibility of a div by zero

[ZLLentz]

Actually yeah, that would be way more elegant. Any objections to inverting the input parameter?

[klauer]

No real objections given the two scale factors you've shown.

[ZLLentz]

The fResolution parameter is exactly the Resolution parameter from docs like https://www.beckhoff.com/EL3314/, and now there is no zero div handling needed.