I'm trying to figure out the best way to merge (or collect) data together from different states in a state machine. If I had multiple states, and each state collected data from an instrument, can I use a shift register and append data, from each state, to the same wire so I can enqueue all of it, at once, to a consumer loop which will write it to a file? Can you append data together between states in a state machine, if yes, how so? Is the "merge signal" function able to do this?
I really appreciate any help, or thoughts!
I would really have to see your code to provide any reasonable response.
But I will say I basically do what you asked all the time. Such as having a state that gets data from instruments, and a sate that displays the data and saves it to disk
But how I do it depends with why I have to, as I usually try to collect data and save it in the same state.
Here is what I have right now. I tried the cluster but you can't wire a cluster to a TDMS write. What I have works well for my application, except I'm trying to figure out how I can add a time stamp into the TDMS file. I thought maybe by collecting the data together differently, I could wire in a get date/time vi and append it to the cluster, or something else, with the rest of the data.
I recognize this code
It doesn't appear that you took anyone's advice about simplifying it at all. It's still full of redundant code Dynamic Data Wires, and way over complicated for what (I think) it does.
Now you are finding it's getting hard to expand and maintain it, huh?
I would throw the whole thing out and start over with a better thought out approach.
I'm not having any problems with it, it does its job fine. I'd like to clean it up but I don't have the time. Really all I'd like to do is add a time stamp to the data, and I think the dynamic data and tdms functions are what's making it difficult. I was exploring other ways of collecting my data together so I could use a get date/time function in one of the states and append it to the data. The time stamp doesn't need to be exact with when each piece of data was collected, it there are a few hundred milliseconds of difference, it really doesn't matter in this application. I was thinking I'd add a time stamp in the "write" state, but I see some changes may need to be made first.
I'm not having any problems with it, it does its job fine.
I think the point here is that you were given several suggestions on how to clean up the code that you chose to ignore. Functionally working code is not the same as good and maintainable code.
Anyway, what you're looking for here is a quick hack to dump into your code and make it work. And yes, there are a few of these, but unless you refactor your code to become maintainable, you will continue to run into more and more situations where you need to hack stuff together to make it work. Eventually this will make your code such a mess that nobody else but you (and maybe not even you) will be able to do fixes or updates in a realistic timeframe. People offering suggestions are doing so because they don't want you to get to that point.
You've already been given the correct answer here, and that is the concept of a master cluster. You pass it in and out of each state using a shift register and often a Linked Input Tunnel. You can then write VIs in each state to access and modify the data in this master cluster.
However, for a hack solution, you could throw together a functional global variable. The how to is starting on page 8 of this presentation. That same presentation contains a few slides on how to use a master cluster like we're suggesting towards the end.
I'm hurt that you think I was looking for a hack :(( lol. I came seeking a legitimate solution. I understand I've got some redundant code to clean up, besides that I'm honestly not sure what's so bad about it (feel free to let me know, I'd love to make it great). Simple state machine, feeds to a consumer loop, doesn't seem like the worst thing ever created.
I'll have to take a look at the presentation, and dig into creating a master cluster. I'm assuming you end up replacing the merge signals with bundles, and bundle all the data together. I'll have to do a little research though. Thanks for the info.
Hi Nadweb, it's very hard to convey tone through forum posts. I think everyone here is generally trying to be helpful, which is why we give our time for free to help others. So don't feel bad, just assume everyone responds with the best of intentions.
If you right-click the TDMS write function and select "Help", you will get more information on what kinds of data are acceptable. Waveform data is acceptable. You can use the "Build Waveform" function and modify t0 to have your timestamp before writing to file. This works just like a cluster, where you only modify the elements (t0) that you wish to change.
I'm sure you're right, everyone is trying to be helpful. I'm still pretty inexperienced with a lot of LabVIEW, but I've been tasked with creating VI's to collect data, so I do the best I can with the little time I have available to actually work on them, and often I don't know when some of the things I write in my code are bad practice, etc.
Thanks for that information! It's good to see what data TDMS can accept. I'm still slightly confused when you say "modify t0 to have your timestamp" I know the build waveform function, and the t0, but don't exactly follow what your saying. Also, if you use a master cluster, do you need to unbundle everything and write them to TDMS separately? It seems TDMS can't accept a cluster?
Appreciate the reply