We just got DIAdem 2018 installed on our server. I already encountered a problem with my old scripts
I used to switch the display format in the channel properties from "Numeric" to "Time" and vice versa. However, I cant do it anymore because the property is read-only. I tried to solve the problem by playing around with all kinds of settings but I did not succeed.
I also tried to solve the problem by script:
Data.Root.ChannelGroups(1).Channels(1).Properties("displaytype").ReadOnly = False
But again, I got the error message "Unable to write read-only property".
On the previous version 2017 I could easily change all the properties without any read-only restrictions. Is it possible that our IT did not install DIAdem in a proper way? Or is it common that these properties are now all read-only?
Thanks for your help
Solved! Go to Solution.
From DIAdem 2018 Release Notes
So potentially switching your code to ChnTimeToNumeric and ChnNumericToTime will be more future prove than switching the option off.
Thanks for the quick response. I should have read the release notes more carefully...
I have the same problem due to the fact that my test files are over 50 days long, so my question is why change this function, which was very easy to use. Now I have to identify the channel name and group and create a small script to run each time I load a file to generate the time formatted channel so I can view the file and see the correct time stamp.
I may have to stick with 2017 for these logs !
First of all, if you're having to manually change the Channel Format to coerce a loaded numeric channel to appear as a datetime channel, then I suggest we improve the DataPlugin you're using so that it does that automatically.
I agree that the ChnFormat() function was a super easy way of toggling a loaded channel's appearance between DBL and DateTime. The reason this was so easy was that the channel array values didn't change when you switched-- the same DBL numbers were used either as-is or were dynamically converted into datetime values in tables and graphs. The problem with this approach is that a DBL used to indicate datetime runs into resolution issues when you want your datetime to be accurate down to, say, a microsecond. For decades DIAdem ignored this problem and kept things simple. Now DIAdem has improved its approach to use a DBL offset for the starting datetime and then all the DBL values in the channel array as the relative elapsed time since that datetime offset. This gives us greater datetime resolution, but it also complicates the process of switching back and forth between numeric display and datetime display. As a result, we need explicit commands to run to do this now. There is currently a toggle switch to enable or disable the extended datetime resolution, but we want to shepherd our customers in the direction of improved datetime resolution, which requires the commands instead of a simple property assignment.
Let me know if you're interested in improving your DataPlugin,
DIAdem Product Support Engineer
I ran into this issue going rom 2015 to 2018, and have tried to use ChnNumericToTime to correct the time, but am getting a time conversion different than the file time. I have recorded in VeriStand the Absolute time which should be referenced to Jan 1, 1904 at 12 AM ("1904-01-01 00:00:00,0000"). I run the following script:
Call ChnCopy("Aliases/Absolute Time","Channel Group/RealTime")
Call ChnNumericToTime("Channel Group/RealTime",TTR("1904-01-01 00:00:00,0000","yyyy-mm-ddd hh:mm:ss,ffff"),False)
The File time (time stamped by Veristand) is 04-18-2019-10-04-07, the time I am getting from the script is Starting at 04/18/2019 11:40:52.05. The date is right, but the time is off by an 1 hour and 36 min and some seconds. I don't understand this offset or how to correct it. I realize that the file time stamp might be a few min different than the Absolute time recorded due to the file being created due to queuing of the data in VeriStand before being sent to the host, but this seems strange. Any help would be much appreciated.
An offset of an hour and 36 minutes is truly odd. Can you post or email me a data file that exhibits this issue?
DIAdem Product Support Engineer