jabson

QUOTE (2and4 @ Apr 18 2009, 03:31 PM) Thanks for the example. Your approach is very similar to what I ended up doing but probably would have saved me some time converting everything to the new format.

QUOTE (jdunham @ Apr 17 2009, 11:07 AM) Thanks for the suggestions. Sounds like a clean way to do this so I'll give it a shot. QUOTE (ShaunR @ Apr 17 2009, 12:21 PM) Everyone will have their own methods and solutions to this one. It's an old problem with many equally correct solutions. If you give an example stream and header structure we would probably be able to justify each approach better and you could pick the solution that best fits your preferences. I find, generally, the best option, if possible, is to find the super set of the protocols and choose a display method that can cope with all of them. Thanks for the reply. I hear where you're coming from. In my case, though, It's not just the contents of the fields that have changed but the number of fields. Specifically, the header is 62 bytes in both the original code and the new version. In the original version one of the fields was a 16 byte string used as an instrument ID string. I needed to add some extra timing information in this next revision so I added a U32 field to the header for the new info and shortened the instrument ID string from 16 bytes to 12 bytes (making the header longer had other implications). So now my Labview code needs to have 2 different types of clusters to handle both the old and new data. I was hoping I could just create 2 typedefs and instantiate the correct one but that's not possible. There's probably an easy way to handle this specific case, but in the future this header could grow and have all sorts of new stuff in it. The suggested approach of just using a variant to hold the contents and a case statement to determine how the variant is interpreted seems like a good one. I've never worked with variants before but I guess this is exactly the type of situation they were created for, situations where the exact data type is not known at compile time. dj

Thanks to everyone for the suggestions. They've confirmed my suspicion that there's no way to change the typedef at runtime and given me some ideas to try. What I'm leaning towards now is changing my typedef to be a "cluster of clusters" (each cluster corresponding to a different version of header format), and also containing a version field. The version field will get populated with the version number identifying the format of the data stream and then only the appropriate header cluster within the typedef will get populated with header data. The rest will remain at some default value. Code on the diagram then just needs to check the version field to determine which member of the typedef to read. I'll have to get creative to create the front panel indicator though since I only want to display the correct cluster. That can probably be done with subpanels or a picture control or something. I welcome additional suggestions as well. Thanks again, dj

Greetings, First post to this forum. I have a medium-sized application that is going through it's first major revision. The issue I'm struggling with is something I've encountered before so I thought I'd get some input from others. The application reads in data from an embedded instrument on a serial port. The data stream consists of packets, each packet containing a header and some data. I have a front panel indicator that's a strict typedef'ed cluster representing the packet header (the cluster contains a bunch of string and numeric indicators). So far so good. The issue now is that the structure of the packet header is changing in this next revision. My Labview application needs to be able to handle both the old-style data stream and the new-style data stream. I'd like the application to be able to change the typedef of my indicator to match the correct version of the data stream it's receiving but I don't think that's possible at run-time, is it? A brute force approach is obviously to have two indicators and just show the correct one and hide the other one. I'd like to avoid this, though, because I'm guessing there will be more revisions in the coming months/years and I really don't want to have an ever-increasing number of front-panel objects to handle. It's also a little more complicated since this header cluster gets referenced in the code a lot. Having multiple FP objects to represent the header means having to jump through extra hoops when determining which object to reference. Not impossible but just messy. I'd like to just have one FP cluster whose contents can be changed at run time. It sounds like this might be a good application of the LVOOP stuff but I've never gone down that road and don't have the time to explore it at this point. If anyone has any suggestions besides the brute force approach I'd love to hear them. Thanks, dj