X axis time is not working on waveform chart

[msiwk]

After I hit run, my waveform chart collects data, but only updates the time once. After that, the time is static. In the picture, it would show the 11:14 AM time and then stay there until I stopped the program. I know data keeps coming in since the display on the side of the chart keeps updating. I'm not sure why the chart wouldn't update the time. 

I've attached the main VI (Motor Acquisition Program) and all subVIs.

[James.M]

Uhhh, wow. You have 6 queues going in to the same subVI. FYI, there has got to be a better way to do that. Bundle all of the data in to one cluster and send it through one queue, since you're sending it all every iterations of the loop anyways.

Unfortunately, it looks like that subVI and a couple of the other subVIs are the ones we need to help since that's where the waveforms are created fro the graph. Please attach those subVIs as well.

[msiwk]

Yeah I'll be sure to change the queue thing, thanks. I thought all the VIs were in the zip. Are you missing all the subVIs?

[James.M]

I am missing a whole bunch of Controls and a whole bunch of Untitled VIs. Maybe you attached a previous version of the main VI that didn't have the right naming saved? You can open your main VI and click File > Save As > Duplicate Hierarchy to include everything.

[msiwk]

Ok now are they attached? I did the Duplicate Hierarchy so hopefully they are. Please let me know.

[James.M]

Yeah, that worked.

Sooooo, Im seeing waveforms being written to the queues and these waveforms have up-to-date t0 values, but then I probe the dequeue values and they have the very first t0 value from when the program started... I'm not sure what could cause that.

I would suggest cleaning up your application a bit to fix the queue functionality. You only need one queue to send all of the data from the producer loop to the consumer loop.

While you're at it, I would suggest cleaning up your diagram and consolidating. A lot of your inputs can be put in as an array and/or a cluster of data. All of those inputs and outputs of that one subVI make it incredibly hard to read.

[msiwk]

Ok I'll fix the queues as soon as I can and let you know if that worked. Also, yes, I realize the VI is pretty messy, but a lot of those inputs are needed on the front panels, so I can't get rid of the inputs, but at least I can clean up the wires with arrays as you said. Believe it or not, I will be needing 25 times the present amount of inputs in the future, so I'm a little concerned about space. Do you have any sugguestions for this future problem? My current setup is reading data from two motors with one daq. Eventually I will have 25 daqs to read data from 50 motors. My inital plan is to simply copy ands paste the while loop that I currently have for each daq which seems to be a bad idea (but the only idea I have so far).

[James.M]

That is an incredibly bad idea, yes. For scaleability you want to use subVIs and a great architecture to make sure it's scalable. Arrays are your friend when it comes to scaleability.

[msiwk]

Ok I fixed the queue thing (haven't cleaned up the wires yet) to just use one, but I'm still getting a frozen timestamp on the chart. I'll keep troubleshooting, but let me know if you have more ideas as to how to fix this.

As to the scaleability, I'll start thinking about how I can use arrays here, but as far as great architecture, I'm not sure what you mean. Do you mean specifically, producer/consumer, state machine, etc. or simply a good layout?

[James.M]

There are a few great architectures that developers use on a regular basis. The main two are the Simple State Machine and Queued Message Handler. You probably want to look in to the Queued Message Handler. LabVIEW ships with a template that you can use.

Please attach your new code now that you're cleaned up the queue functionality.