LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Deleting channels from task, reconfiguring task

 


@Jeff Bohrer wrote:

Nice looking stuff.

 

Two questions:

1) in timing set-up you are changing the task, why did you not chose to write the task back to the task FGV?  

2) in the run vi, what happens in the error case? and can that cause the task data on the input tunnels of the loops to be disconnected from the real task state?  What happens if you replace w/ SRs?


 

1. If the Task is a reference, then there is no need to write it back into the class properties. It does seem to work this way; however, that may just be by accident. Smiley Surprised

 

2. In the error case, I filter out the timeout error (-200281) and ignore that error. For everything else, I stop the acquisition and report the error back to the main app.

 

Hadn't thought to put SRs in the loop as I have never seen anyone use them for acquisition. Wouldn't hurt to try; if the task wire is a reference, then it doesn't matter if there is an SR or not.

 

I am in the lab with the equipment now. I will put a new build on with the SRs and see what happens.

 

Drew

0 Kudos
Message 21 of 31
(2,802 Views)

 



 

1. If the Task is a reference, then there is no need to write it back into the class properties. It does seem to work this way; however, that may just be by accident. Smiley Surprised

Drew


 

Correct!  So I'm poking around trying to figure out what a task wire is- 

it seems a little like a string- but this snippet proves its not exactly. 

You can wire it to a property node so it must contain a referance (or refer to a referance) but you can't cast it to a more generic so it isn't that either. 

the terminals export string is a Tab Control Page Selector?

 

I'm not sure whats on the wire and what magic happens under the hood.  Its a good thing stuff like this doesn't come up too often its hurting my head

 

odd.png


"Should be" isn't "Is" -Jay
0 Kudos
Message 22 of 31
(2,799 Views)

Tried the SR's in the acq loop; that was bad. Performance of the display and acquisition loops went in the crapper, so it looks like the VISA resource is a reference. I guess it is a special kind of reference since it can be defined with a string instead of a numeric reference number/handle. There is probably some magic under the hood that takes the task ID and ties it to the hardware.

 

So at least we know that the SR's in the acq loop are not required and actually hurt performance, not sure why, but it does.

 

I ran the app for a bit with loading several different channel configurations. I am guessing that I loaded six to ten configuration changes in a half hour and got one hardware reserved error.

 

The good thing was that the customer was having trouble with their hardware so I didn't feel too bad, but they are still giving me a hard time about the error.

 

I poked around the DAQmx dll a bit tonight and found a couple methods that might help. Their names contained ...Delete...Config..., but I am not sure what their prototypes are. I am not very good at writting into the C nodes.

 

I was hoping one of the Knights of NI might drop in by now and give us a hand getting to the bottom of this.

 

Drew

0 Kudos
Message 23 of 31
(2,785 Views)

Drew-

 

I understand what you are doing but it would be hard for me to know exactly what in your code is causing this random reserve error.  I think Jeff was hitting on the issue when he discussed the task-state model.  Read the below description of implicit transitions and refer to the task-state model diagram attached (which is the same one Jeff posted).

 

When a task is created or loaded, it begins in the Unverified state. In this state, you can configure the timing, triggering, and channel attributes/properties of the task.

 

When the task proceeds to the Verified state, the driver will check all of the properties set for then task. If NI-DAQmx finds any problems, it will throw an error and will remain in the Unverified state. If NI-DAQmx finds no invalid values, the task is successfully verified and transitions to the Verified state.

 

The resources a task uses to perform the specified operation are acquired exclusively when the task transitions from the Verified state to the Reserved state. These resources can be clocks or channels on a device, trigger lines on a PXI chassis, or buffer memory in the computer. This transition fails if some task resources are currently reserved by another task. If the task can gain access to all the resources it uses, the task is successfully reserved and transitions to the Reserved state. Otherwise, it remains in the Verified state.

 

NI-DAQmx programs some of the settings for the resources when the task is committed. These settings might be the rate of a clock or the input limits of a channel on a device, the direction of a trigger line on a PXI chassis, or the size of the buffer memory in the computer. Other settings, such as the sample counter, cannot be programmed when the task is committed because they need to be programmed every time the task is started. When a task is committed, it transitions from the Reserved state to the Committed state. In general, the commit transition should not fail. If it does, it is an exceptional condition and the task remains in the Reserved state. If the settings for the resources used by the task are programmed, the task is successfully committed and transitions to the Committed state.

 

When the task begins to perform the specified operation, the task transitions from the Committed state to the Running state. Notice that starting a task does not necessarily start acquiring samples or generating a waveform. You might have specified the timing and triggering attributes/properties such that a sample is not acquired until you call the Read function/VI or a waveform is not generated until a trigger is detected. In general, the start transition does not fail. If it does, it is an exceptional condition, and the task remains in the Committed state. If the task begins to perform the specified operation, the task is successfully started and transitions to the Running state.

 

Implicit Transitions

You implicitly transition the task to a new state when you perform an operation that requires that the task be in a specific state and it is not. If this occurs, the task is implicitly transitioned to the required state and will need to pass through all of the required state transitions until it reaches the destination state. When certain DAQmx functions are executed, they may require an implicit state transition.

 

Querying the value of an attribute/property implicitly verifies the task. This verification is required to return accurate coerced values of attributes/properties. Because the coerced value of a attribute/property often depends on the values of other attributes/properties, the task as a whole must be verified to calculate the value. Because the task might be implicitly verified when you query the value of an attribute/property, NI-DAQmx may return an error specifying that the value of attribute/property is invalid.

 

Calling the Read function/VI implicitly commits the task if the task is not already committed. If the value of the DAQmx Read Auto Start attribute/property is True and the task has not been started, the task also is implicitly started.

 

Calling the Write function/VI commits the task. If the value of the Auto-Start parameter is True, the task also is started.

 

To ensure that the user knows what state the task is currently in, it returns to the state of the task prior to the last operation that resulted in a forward state transition when a task is implicitly transitioned backwards. For example, if the task was in the Verified state and you called the Start Task function/VI to start the task, the task is reserved, committed, and started, transitioning to the Reserved state and to the Committed state before transitioning to the Running state. When you invoke the Stop Task function/VI, the task is not just stopped and transitioned from the Running state to the Committed state. If this were the case, the result is unexpected because the task still has its resources reserved despite the fact that you never explicitly reserved them. Instead, the task is stopped, uncommitted, and unreserved, returning to the Verified state, its state immediately before you performed the last operation that resulted in the state transition, calling the Start Task function/VI.

 

Explicit transitions

Users can also define specific state changes to have better control over their application. These are known as explicit transitions. The main functions in DAQmx will which perform explicit transitions are the DAQmx Control Task VI and the DAQmx Start Task VI. Between these two functions, a user will be able to move to any state.

 

There can be many benefits to explicitly transitioning to each state. The list below highlights a few of the common applications.

 

Verify—If in your application users interactively configure a task by setting various channel, timing, and triggering attributes/properties, explicitly verify the task occasionally to inform the users if they have set an attribute/property to an invalid value.

 

Reserve—If the following is true, explicitly reserve a task: your application contains many different tasks that use the same set of resources, one of these tasks repeatedly performs its operation, and you want to ensure that none of the other tasks acquires these resources after the task begins its sequence of operations.
Reserving the task exclusively acquires the resources that the task uses, ensuring that other tasks cannot acquire these resources. For example, if your application contains two tasks that each perform a sequence of measurements and you want to ensure that each sequence is completed before the other sequence begins, you can explicitly reserve each task before it begins its sequence of measurements.

Commit—If your application performs multiple measurements or generations by repeatedly starting and stopping a task, explicitly commit a task. Committing the task exclusively acquires the resources that the task uses and programs some of the settings for these resources. By explicitly committing the task, these operations are performed once, not each time the task is started, which can considerably decrease the time needed to start your task. For example, if your application repeatedly performs finite, hardware-timed measurements, the time required to start the task can dramatically decrease if you explicitly commit the task before repeatedly performing these measurements. Explicitly committing a task also is required if you need to perform additional read operations of the samples acquired by the task after stopping the task. For more information, refer to Using the Start Task Function/VI

 

Start—If your application repeatedly performs read or write operations, explicitly start a task. Starting the task reserves the resources that the task uses, programs some of the settings for these resources, and begins to perform the specified operation. By explicitly starting the task, these operations are performed once, not each time the read or write operation is performed. This process can considerably decrease the time required to perform each read or write operation. For example, if your application repeatedly performs single-sample, software-timed read operations, the time required for each read operation can dramatically decrease if you explicitly start the task before repeatedly performing these read operations.

 

 

I know this is a wordy reply and I see that all of this has been at least alluded to, but I really feel like a task is in a state that causes the error to occur.  Maybe something in this explanation will pop out at you to indicate why your random error is occurring.

 

Applications Engineering Specialist - Semiconductor Test
National Instruments
Message 24 of 31
(2,769 Views)

Sean!

 

MEGA kudos!  Don't appologize about the length of the reply you stated a lot about DAQmx that can not be directly discovered from the published manuals.  I believe I now understand WHY the task performance took a huge hit in performance when using shift registers. (additional implied state transitions?) And can you shed light on what's on the task wire?  That information may help determine best practice for holding tasks in FGVs.

 

Drew-

Sean is definately onto something here-  is it possible to revise your task FGV into an AE that explicitly handles both forward and backward state transitions?

 

 


"Should be" isn't "Is" -Jay
Message 25 of 31
(2,760 Views)

 


@Jeff Bohrer wrote:

Sean!

 

MEGA kudos!  Don't appologize about the length of the reply you stated a lot about DAQmx that can not be directly discovered from the published manuals.  I believe I now understand WHY the task performance took a huge hit in performance when using shift registers. (additional implied state transitions?) And can you shed light on what's on the task wire?  That information may help determine best practice for holding tasks in FGVs.

 

Drew-

Sean is definately onto something here-  is it possible to revise your task FGV into an AE that explicitly handles both forward and backward state transitions?

 

 


 

Well, I'm not actually using a FGV, it is an accessor node/property node for the lvclass I am using. However, I did re-write the DAQ loop to explicitly transistion the task after the loop exits so that the resources would be released. Although, the error still happens sometimes, which is most confusing.

 

Also, what is AE? (other than applications engineer ;-))

 

I will need to re-read Sean's post again to see if anything pops out. I will definitely be saving the post for furture reference. 

 

Thanks for the input!!

 

Drew

0 Kudos
Message 26 of 31
(2,741 Views)

Also, what is AE? (other than applications engineer ;-))

Action Engine

 

A poor man's methods for a class(es) created by data on a uninitialized Shift register

I've gotten into the habit of thinking of the two interchangably- 

 

I should have said " Can you add methods to your class to explicitly transition states?"


"Should be" isn't "Is" -Jay
0 Kudos
Message 27 of 31
(2,736 Views)

Jeff (and Drew)-

 

I did get some clarification on the task wire: it is a reference to a memory location (if you attach a string indicator, you get a task name, but there is more data sent than the string).  The other main point is the reserve error is actually a legit error.  That is to say, this error only occurs because the program checks the device to see if it is reserved, and if it is, this error is thrown (we all know that some errors aren't this straight forward).  That being said, the device is actually being reserved at some point when another piece of the code is trying to access the device.  Therefore, there is a race condition occurring (parallel code execution issue).  You could try highlight execution (which could of course be a long process), to try and see if this occurs at the same location, and then try messing around with timing to fix the error.  Or, for that matter, speed the code up and see if the errors happen more frequently.  Both these methods could be used to help pinpoint the location.  I hope this will help track down where the error occurs, and good luck!

 

Sean N

Applications Engineering Specialist - Semiconductor Test
National Instruments
Message 28 of 31
(2,724 Views)

Drew-

 

After re-analizing Sean's responses and your snippets I can only offer 1 other suggestion / critique.  Setting "Read all available samples= True" is inconsistant with setting Samples to acquire to any value other than -1 and, with stars aligning and coersion errors calculating the I32,  you may have caught a few implicit state translations by resetting this parameter inside the loop.  A -1 might help and couldn't hurt. 

 

Beyond that I think you'll need to Log every property of the task on error.  I'm thinking a very odd-ball chance of a corner case where some call to nilvaiu.dll is either buggy or corrupt in your DAQmx install.  -

 

Sea story TRUE_ I once "Saved" a DAQmx sub.vi by accident (they are not locked!) after "exploring" the function set-up- you CAN burn yourself!

 

Also, you may want to see if there are known issues with any Hardware or your DAQmx revision.


"Should be" isn't "Is" -Jay
0 Kudos
Message 29 of 31
(2,717 Views)

Sean,

 

I can think of an instance for a possible race condition, but it's a tough one to figure out how to handle.

 

If the user switches between single and continuous mode before the acquisition loop times out, the DAQStop.vi FGV can be reset causing both the continuous and single mode acquisitions to run simultaneously.

 

I will test the Stop DAQ by Ref VI by adding a wait loop to make sure the referenced VI is not in the running state before returning control back to the main application when stopping the acquisition loop to see if this helps. New code is below. I added the loop to check the exec.state of the referenced VI and have a timeout that is 10x the display update rate. (ie. if the update rate is 10Hz, then the timeout is 1 second)

 

StopByRef.png

 

This is the old code:

Old_StopByRef.png

 

I will report back what happened when I have the chance to deploy the code.

 

Drew

Message 30 of 31
(2,716 Views)