05-02-2011 06:33 PM
The boolean in the STM Write indicates whether it should ignore the timeout or not.
LabVIEW 2010 did include a number of performance enhancements. I'm not aware of any that specifically target startup time, but some of the general performance improvements may help it. It's also possible that there is an improvement and I just haven't noticed it, I don't write very many Windows apps these days.
This might be a good time to move your question to a general thread, since it's moving pretty far off of STM.
Ryan King, CLA
Senior Systems Engineer
05-03-2011 07:10 AM
On a related note, we are sending a large cluster back and forth, LV on one end and a micro, programed in C, on the other. Is there any tool to convert a cluster definition into a C struct? Right now we have about 20 elements, and it is way too easy for the cluster and the struct to get out of sync.
This comes up again in another system we have where we use ScramNet and have several hundred elements in the cluster/struct.
05-03-2011 09:30 AM
No tools that I'm aware of. Converting clusters to and from structs is always a bit of a pain if they are more than a few simple elements. Here's a couple of ideas:
1. Send each element in the cluster as a separate message. It should be quite easy to write a tool which would automatically generate your meta data based upon a cluster (probably save/load the meta data from a file). You could use the message names to help you identify the struct each belongs to and possibly the order in the struct. The disadvantage of this approach is that it's easier for the elements in the struct to get out of sync (for example if you're using a scan based system, some items in the struct might be from one scan and some from another).
2. Write your own routine to flatten the cluster to a string. This would probably be my preference. You could design the string such that it's easy to unwrap in C and includes all of the information you need to unwrap it (i.e. number of elements, name of each element, data type of each element, etc). In that way you could set it up so that the C code automatically adapts to any changes in the cluster. On the LabVIEW side, you could either change the flattening routine each time you change the cluster or make it dynamic by accessing the cluster elements using VI server (the later would require significantly more processing time). The main drawbacks of this approach as a whole are that it involves some development effort and it will most likely increase your data packet sizes.
Ryan King, CLA
Senior Systems Engineer
05-03-2011 09:45 AM
Another idea would be to create such a tool to create a C data structure definition. Usinge the OpenG lvdata library it is not difficult at all to get a description of the data structure from the LabVIEW typedef array from the old style Flatten function. Then going through that array and writing a C style struct typedef is not such a big problem. Of course if your LabVIEW cluster contains Arrays or Strings, then you have a bigger problem but even that is not really impossible to do, though parsing that Flattened data will be more complicated than just a simple Typecast.
05-03-2011 10:03 AM
There isn't any strings just u_int16_t, int16_t, u_int32_t, int32_t and 32 bit floats. It should be simple.
Then go for it! It sounds like a fun afternoon project
05-03-2011 10:29 AM
05-03-2011 10:39 AM
Sorry for replying to my reply, but I should clarify. I have a C structure, that has a mix of 8,16, 32 bit types currently there are about 300 variables defined. The primary development is on the C side, and LV is doing the monitoring.
What would be great is a way to take the header file that defines the struct and feed that to a program that outputs an appropriate cluster.