Log Alarm Only Once

Question

Hi everyone,
I have an interesting issue with logging a 'thermocouple disconnected' alarm as part of a condition monitoring application.
I am logging thermocouple readings at 5 Hz  when a thermocouple becomes disconnected the reading rises to 1372, which is detected and should sound an alarm.  The application builds a string at this time (and publishes to a table) telling the user which thermocouple has disconnected, and any action undertaken (for example, turning the heater off).
I would usually include a snippet, although the code uses property nodes (as the error log code is in another loop) making it pretty much unreadable.
My issue is that the alarm is published on every iteration.  I need to keep checking for other thermocouple failures but disable one which has already occured.  I thought about setting a 'already written' variable in a shift register for each error case but this was getting messy quickly.
Any help (or ideas of a better way to do this!) are appreciated,
Pete
Regards,
Peter D
Solved!
Go to Solution.

Answer 1

egraham wrote:
One method still appears faster and I wonder why this faster method isn't the one we should be using???
Because your method is not the fastest.
Yes, I was sloppy in my code and there was an additional buffer allocation due to the autoindexing branch of the array. If we index inside the inner for loop, we eliminate that extra buffer allocation and speed it up by more than a factor of two. (I did the autoindex for quicker coding and cleaner diagram, because it does not really matter in your application).
Also, don't underestimate the new compiler. For some reason your "delete..insert" does not cause a buffer allocation, something that might not be guaranteed in all cases. (tools...profile...show buffer allocations). It might also well be different on older LabVIEW versions. (I have not tried). It might also be different on different CPUs (My times are quite slow because they were done on a very old Athlon XP).
First, let's make sure we benchmark the right code. We don't do a single replacement as in your benchmark, but there is also an outer shift register where we keep the rotated array. You should also disable debugging, because loops have more debugging overhead, skewing the results.
Attached is a simple draft with 5 code alternatives. Just run and select one algorithm at a time via the enum selector. The time in ms will be graphed. (There are probably some bugs, please verify correct operation).
Loop In Place: Using a loop and the "in place element" structure to rotate rows down.
Loop Original: Using a loop and the proper inner indexing.
Loop_autoindex: Same as (2) but with autoidenxing, causing a second buffer allocation.
Delete_Insert: Your code (delete last, insert new element at the beginning).
Insert_Delete: Basically same as (4) but with operations reversed.
Here are my results: algorithm incremeneted every 40 iterations)
 (1) and (2) are fastest, (3) is slowest, and (4)&(5) are somewhere in the middle, or about half he speed of the first two.
Feel free to find a fster method for the same task. There problaby is......
Also note that the real case has a 2D array of strings, so things might again be slighly different (not tested).
Just some food for thought....
LabVIEW Champion . Do more with less code and in less time .
Attachments:
shift array elements_compare5Algorithm.vi ‏22 KB
ShiftArrayBenchmark.PNG ‏18 KB