It was needed to read some data in double floating number format for some analyzers in a site. Unfurtunately, Citect Scada program could not read these values. Is there a way to read double floating numbers in Citect Scada program.
It was needed to read some data in double floating number format for some analyzers in a site. Unfurtunately, Citect Scada program could not read these values. Is there a way to read double floating numbers in Citect Scada program.
Of course, it would be best if you requested this as an enhancement to be built into the driver. However, I don't believe any drivers have 64-bit values, so it would probably require an enhancement to the I/O server as well. I'm sure others have requested this as well, but the more people that request it, the more likely it is to happen.
You could modify my code to use arrays instead of string registers to improve performance, which would be more efficient. However, since arrays are not local to functions, can't be passed to functions, and can't be concatenated (like this code does with strings), that would be a problem. You'd have to make sure only one copy of the function runs at a time (see EnterCriticalSection()). You'd also have to rewrite the code to combine all 4 registers into one array instead of working on them separately and concatenating the strings of bits. There are new Array Functions in Citect 2018 (see ArrayCreate()) that create something like an array in memory, treat them as local, and pass them to other functions. However, you access the data through Cicode functions, so I would guess that would be slower than string manipulation for what this code is doing.
You may want to just figure out how many 64-bit registers you have to read, figure out how often you really need to read them (do you really need once per second or would 5 or 30 seconds be sufficient for some values?), and calculate how many times per minute this function will be called. Then you could write a test function to call it that many times per minute and see if it will run that fast and how much CPU it uses. Sometimes we may waste time optimizing code that is theoretically inefficient but in reality runs sufficiently well, which may be the case here...I don't know.