FlexLogger Automation in LabVIEW is so good, it has basically replaced our workflow of developing FlexLogger Plug-Ins. I can't recommend it enough to folks currently developing Plug-Ins.
I have some lessons learned after several real world implementations and would like to suggest some improvements, in priority order.
- "Get" functions for channel configuration info (alarms, limits, scaling, excitation, etc) are desperately needed. Alarms, limits, and scaling are the most critical. (We are currently parsing the .cfg file that FlexLogger saves to disk with the project, but this is less than ideal and only updates when the FlexLogger project is saved)
- "Get Names" needs an additional filter criteria to include only physical channels (those being generated by a cDAQ, PXI, etc) . If any System Channel (Performance, Filter, Variable, etc) is present in the outputted Channel Names Array, it will cause subsequent calls of "Get Values" to fail.
- "Get Values", when called with an array of Channel Names, shouldn't error out if only a single channel is invalid. It should return as much valid data as possible and any invalid channel should come back as a NaN or zero in that index.
- The other "Get XXX" functions ("Get Data Rates", "Get Enabled", etc) need to allow arrays just like "Get Values". And again, a single invalid channel should not error out the whole function.
Items 2 through 4 are all related to reducing the number of calls to the Automation server. Passing large chunks of data in a single call rather than performing an individual call for each channel shows a boost in performance. I could probably get by for most projects with only two array enabled "Get" functions: "Get Values" and "Get Full Configuration" (returning an array of clusters including data rate, enabled, alarms, limits, etc) and handle all the rest in LabVIEW.
Hope that feedback is useful. I'm happy to discuss further if desired. Thanks for such a truly useful addition with this LabVIEW Automation package!
