Using Channel Properties

[EOlsen]

Hello,

 

Have a few questions about using channel properties.

 

If you are using a null protocol, can the timing property be used to hold another value without causing a timing event to take place?

 

Either way if timing is 0, can offset be used to hold some unrelated persistent value?

 

Same with History Interval if history length is set to 0?

 

I'm thinking if I'm not using some of these properties as they were intended, they would be an easy way to hold persistent calibration and set point values.

 

In a conversion could you refer to the variables associated with the current channel? What would be the code to refer to the current channel? Something like this.offset

 

Thanks

[AzeoTech]

You could do that, but it would only persist if the document was saved.  Of course you can trigger saving the document from script, but I find it not the best idea because saving is the most likely time a document will get corrupted, if for example, there is a power failure during the save.  We used to have something called the auto-persist timer which would automatically save the document every so often to keep history around.  But we found that documents would get corrupted over time in situations where power failures occurred often.  You would be much better off holding persistent values in a separate file.  And if you really, really wanted to do it in a channel, I'd probably use the Quick Note and store as a string, that way I could hold a bunch of values in one spot.

 

As for conversions, the only thing you can reference as part of the current channel is the raw value that is about to go into it, and that with the "Value" keyword.  You are, however, the second person to ask this recently, so perhaps we should expand upon the capability.  Maybe you can explain more what you would do with it?  I'm guessing maybe store a cal constant in a channel parameter that is fixed at development time, then apply the same formula with different cal constants based on the channel?

[EOlsen]

In our situation each temperature probe gets calibrated once per year. Sometimes more frequently. Just looking for an easy way to keep the calibration value associated with the channel. So then in a conversion if we could do something like (Value + Calibration) / 4095 * 100.

 

On a display page, user would click on calibrate button, select current channel, view current reading, adjust calibration up or down to make reading match the proper value, save the new calibration value in the channel property. Then when done calibrating all probes, save the document.

 

The other option you mentioned before was creating a class and using ToJson() and saving to disk, but still need a means of knowing in a conversion what the current channel is to access the calibration value.

[AzeoTech]

If you are doing it infrequently as you describe, then your idea is very clean.  Unfortunately with the current architecture, its not too easy for us to change.  But perhaps its time to enhance Conversions.  We'll have to think on it for a few days.  Bug us again next week after we've had time to discuss and ponder it.  I think I'd rather add a field to channels that holds cal constants, then make them (and perhaps the rest of channel parameters) available from conversions.  Hacking random channel parameters to store values doesn't make sense to me.  I'm also thinking we could actually make a command that persists just the channel cal constants, something like channel.saveCals(), and channel.loadCals().  These would take a file name and be saved outside the document, thus both eliminating the concern I already mentioned, and enabling you to create different groups of cal constants.  Just thinking out loud here.

[EOlsen]

For channels it would probably be easy enough to create a function to save persisted values in a .csv file saving the channel name then one or more properties. Then just read it in during start up. We are still working out how we want to handle everything. So not pushing for a change to channels right now. May use the calibration data in conjunction with variables instead of channels. But I'm surprised calibration hasn't been more of a concern for other customers. We certainly need it for all of our analog inputs.

 

If you were going to add a function for saving calibration values, I would suggest making it more generic if possible so it could be used to persist just about any property for any class. Something like saveProp(classname, objproperty) and using the classname and objproperty name to create a file name. Not sure this is any better than using ToJson(), but ToJson() doesn't seem to work with channels.

 

At this point I'd be more interested in seeing you get your new scripting language launched if it is more flexible and capable than the one in DAQFactory now.

[EOlsen]

While you are thinking about this topic here is an idea. Add a numeric field to channels that can hold a single value or an array of values for users that want to extent a channel in some way (like adding calibration factors and set points). It would be up to the user to determine how the extra data was used and and in what order in the array it was stored. This way it could be multipurpose. If you only needed a calibration value, it would contain a single value. If you needed more it would contain an array of values. It would be up to the user to determine what each element in the array held. These would be for values not changing often, but subject to operator change on occasion and wanting to retain the change the next time the program started up. You could add a function that would save these extra values to disk only on the channels for which they were implemented maybe using saving ToJson() only on this property. The disk file would be updated whenever one of these extra values was changed.

 

Each time the program started a start up sequence could be used to copy the "extra" persisted array value to the current value of the channel if the channel was being used to hold something like a set point.

 

You could also add a matching string array property to hold labels for the extra numeric fields if you wanted.

 

Not the most elegant solution, but perhaps not to difficult to implement. Just an idea.

[AzeoTech]

I think we are both on the same page.