04-24-2013 01:05 PM
Rhys,
You still do not have a true state machine. All you have done is replace the stacked sequence structure with a while loop and a case structure. Your looging loop is more like a state machine because the next state is chosen based on values within the current state.
Timing: Your VI is still complicated enough that estimating the exact timing of the writes to file is not straightforward.
- Each of the DAQ loops has a 1 ms Wait. If everything else in the loop runs faster, the Waits may run in parallel but it is not guaranteed. With the DAQ sampling rates set at 1000 samples per second, you might have to wait for a sample to be available. You also have 1 ms timeouts on the Dequeue functions in the logging loop. With all these things competing for the same millisecond, it seems likely that 2 ms cycle times could occur.
You are using the Available Samples ... property node but not taking advantage of the data. What if there are 2 or more samples available? Your code will never catch up. Reading all available samples might be a better choice. Since you seem to only be logging the data, why not read data a few times per second or less and write bigger chunks to the file each time. Your hard drive would probably like it better, too.
You only check Dequeue Timed out on two of the queues. What happens if the voltage task is turned off?
The Data Table loop only runs 4 times per second. The way the DAQ loops run, the Data Table will only see 4 samples per channel per second, not the 1000 that the DAQ acquires. Is that what you want? You have not posted the Data Table.vi so I cannot tell what it does. If peaks and troughs can occur on time scales of milliseconds, you may miss them.
Lynn
04-24-2013 02:57 PM
Lynn,
So when you say, state machine, should I have a loop within my 'run' case, which is a state machine, doing something like this:
state 1 = Read Data
state 2 = Write to file
With the state machine looping continuously between these states?
The dequeue timeout is just something that I was playing with because i was getting more time data in the file than measured data.
So i could delay my read loops to 200mS etc, but read all the available samples each time, and log to file at the same rate?
The reason i have delayed the data table loop to 250mS is to stop the values in the table fluctuating so quickly, so that they are possible to read. It might be better if I put the peak and trough VI in the read loops so that they catch all potential peaks and troughs and then pass the data using a queue to the data table loop.
I am out of the office currently but I will attach the Data Table.vi when I return.
Rhys
04-24-2013 03:14 PM - edited 04-24-2013 03:18 PM
@Rhys_CKTC wrote:
Hi Guy's, Thanks for your help so far.
To be honest I havent gone down the route of using the template, I opened it up and found it quite difficult to modify it towards my VI.
Many Thanks,
Rhys
That is unfortunate. Perhaps I should have been a bit more elaborate discussing the new feature.
It Appears that NI thought to include some really amazing things in the feature! See that "More Information" bold text? It gets you right to here
Of course that template help suggests you read this which goes into much more detail about the Queued Message Handler Template and how to modify it.
Both of them contain this link:
Those links take you here or Here
Where the actual developer of the template will walk you though using the template you chose!
Really, this feature might just start hurting my Forum Post count.
04-24-2013 03:48 PM
Rhys,
What I envision is making the outer while loop and the large case structure into the state machine. Split the 'run' case into multiple states such as Read Data, Process Data for Table, Write to File, and perhaps others. The inner loops would all go away. The loop with the event structure woule probably be a separate parallel loop. That would convert the program to a standard Producer/Consumer (events) design pattern.
If you do not mind hurting Jeff's post count too much, follow his advice and read up on the new features. You could probably start from scratch with that sample project and get a good result in about the same time it would take you to modify what you have now.
Is there any reason why you cannot put all the measurements into a single DAQ task? You are sampling and reading at the same rate. When you have the Thermocouple or Voltage tasks diasbled, simpy discard the data for those channels. You would use Read N Channels, N Samples and get a 2D array.
Lynn
04-27-2013 05:57 AM
Hi Guys!
So I have taken your advice and attempted to use the sample project that you suggested. At the mo I'm getting an error with regards to the DAQ Channels. Lynn, i took your advice of putting all the measurements into one task, I concatenated each task into a string (In the initialize channels State of outer SM). But something within the VI does not like it. Was wondering if you could have a look at this?
Rhys
04-27-2013 07:37 AM
Hello,
be careful when you use a while loop in labview VI, because according to the documention of the function(labview Help), the instruction execute at least once before testing its conditions of réitérartion.
Alexandre,
04-27-2013 12:36 PM
Alexandre,
I do not understand the relevance of your comment. There is no probleem with the termination condition in Rhys' most recent code.
Rhys,
Nice. I do not have DAQmx and many of your subVIs are not included, so I cannot tell what the problem might be. What errors do you get? Simply stating that the VI "does not like it" is not very helpful in troubleshooting.
Your Strain Channel Setup SUB.vi has way too much duplicated code. If you ever need to change anything in there, it will be a big job to make sure each change is correctly made in 16 places. Create an Add Channel to Task subVI. Place it in a for loop with autoindexing of the arrays. That block diagram which was about 4 screens in area now fits on < 1/4 of a screen. Also make the Strain Gauge 1 cluster into a typedef. Then any changes only need be made to the typedef and they will propagate throughout the code.
Lynn
04-29-2013 01:27 AM
Sorry I was a bit vague with that. See the attached PNG which shows the error I get. Let me know if you want to see any of the subVI's to troubleshoot this problem. Would there be a problem with passing the task to the next state using a shift register?
Thanks for the advice with the masses of repeated code I have! Deffinately something i need to change.
Thanks,
Rhys.
04-29-2013 11:08 AM
OK, the PNG didnt attach on the last post.
Should attach now,
Also, another PNG show's how I concatenate the tasks into a single DAQmx task. Is it correct to do it this way?
Rhys.
04-29-2013 11:23 AM
@Rhys_CKTC wrote:
OK, the PNG didnt attach on the last post.
Should attach now,
Also, another PNG show's how I concatenate the tasks into a single DAQmx task. Is it correct to do it this way?
Rhys.
No. You need to use the Create Virtual Channel VI (in the DAQmx palette) to add channels to a task.