LabVIEW
Array to typedef cluster (is too slow)
@EMCCi wrote:
Ok, so reading what you have answered me, it seems that the big part of the waste is in updating the data by reference in a loop. I didn't know that write values by reference was slow... I'm doing it by first time.
Then, as Benoit said, I should first build the cluster with the "analog data", and then write this cluster once in the typdef cluster by reference? Like this?
But the problems is how to build this cluster from the 2D array in an easy way?
Even better would be to send this cluster out of the VI through an indicator and connect it to the Front panel Indicator directly, and skip the reference.
(I see McDuff basically said the same)
/Y
If you want it fast, avoid variant conversion. And of course 'value' property nodes.
This will not automatically adapt to cluster changes, but you'd probably get a broken wire in most cases. And it will be fast...
I'd consider avoiding the conversion, but there's not enough information to propose something.
Search LabVIEW like a graph!
@EMCCi wrote:
paul.ross: We do instrumentation of very big machinery. 57 is the number of different variables measured in this case. This is string array has been already processed programatically, and now has only the clean values of the variables. For example {"650.00", "On", 12, "Ready", "102.50", "Primary", etc.}
Putting variables in a cluster might not be the best choice. Nothing wrong with 57 (or 500 or 5000) variables. But not in a cluster.
You'd usually want a solution where you use either an array or a (variant attribute) set. This allows access to individual variables by either a type def'd enum or by string.
The array can often be based on floats, as it stores (most) integers, Booleans and floats well. If you require strings, you have to either make separate buffers, or store flexible data. That can be variants, the raw strings or flattened data strings. Then you can convert when you read the values.
@EMCCi wrote:
mcduff: In every loop iteration, I have to save the value in a different cluster element. In your example I can only save in one cluster element for each data type. If I have 2 doubles I won't be able to save them in different cluster elements. It will help if I upload the VI?
This would be soo much easier if you had some solution based on an array or set...
wiebe@CARYA wrote:
If you want it fast, avoid variant conversion. And of course 'value' property nodes.
This will not automatically adapt to cluster changes, but you'd probably get a broken wire in most cases. And it will be fast...
I'd consider avoiding the conversion, but there's not enough information to propose something.
Wouldn't it be faster to just use Index Array and individual conversions instead of Array to Spreadsheet and Extract from string?
/Y
@Yamaeda wrote:
wiebe@CARYA wrote:
If you want it fast, avoid variant conversion. And of course 'value' property nodes.
This will not automatically adapt to cluster changes, but you'd probably get a broken wire in most cases. And it will be fast...
I'd consider avoiding the conversion, but there's not enough information to propose something.
Wouldn't it be faster to just use Index Array and individual conversions instead of Array to Spreadsheet and Extract from string?
/Y
Maybe. I'm not going to test it 
. This will be faster then variant conversion\value properties. Your suggestion would be (arguably) more complex, but if even more speed is needed, it would be worth a try.
My guess is that array of string comes from a string to begin with. Not sure, but if so that Array To Spreadsheet String won't be needed of course.
I don't think a cluster is right for this to begin with.
@EMCCi wrote:
paul.ross: We do instrumentation of very big machinery. 57 is the number of different variables measured in this case. This is string array has been already processed programatically, and now has only the clean values of the variables. For example {"650.00", "On", 12, "Ready", "102.50", "Primary", etc.}
Very big is of course all relative. What to say about an application that processes around 14000 internal variables, with around 1000 external IO points from all kind of devices like EtherCAT, Modbus, RS-485, several TCP/IP devices and DAQmx?
But yes that application is nowhere updating a single control through value properties!
Yamaheda & wiebe@CARYA: I build a cluster because this data is send by mobile network. Doing it like this I can adjust the data type for each variable, which is necessary to save mobile data. I was searching a way to do what you both are proposing but in a for loop, making it easier to program and scale in the future. But seems like this solution do not exist, so I will do it like this.
rolfk: It's not a competition 
I have understood in this project that updating controls through value properties is not a good idea.
Anyone has the solution to index through a cluster to update the values without using references?
Thanks for your time and responses,
EMCCi
