Unable to set CO.MemMapEnable

[John_P1]

It seems that once a task is configured for buffered counter output, it becomes impossible to re-configure the task for on-demand counter output:

Attempt 1:

Result:  Conflicting properties error at 2nd start:

Attempt 2 (CO.MemMapEnable is now set to false before starting the 2nd task):

Result:  Internal Error -88700 (yikes!) at 2nd start:

So it seems that in order to reconfigure a task to On-Demand I need to set CO.MemMapEnable to False, but trying to do so results in a non-descriptive "Internal Error".  

For my application, the reason I want to do this is that I have a number of task parameters known during initialization (trigger source, digital filtering, output terminal, counter resource, etc.) and I would have preferred to re-use the same task and avoid re-writing all of the same information repeatedly.  The reason that switching between finite and on-demand pulses is necessary for me is that finite requires at least 2 pulses, when my user may very well only wish to generate a single pulse (but the pulse output is defined at runtime so I have to be able to accomodate switching between single pulse or finite pulses).  

I guess I'll have to clear and re-build my task every time my user wishes to switch between single and multiple pulse generation, but in case there is another workaround (or upcoming bug fix, I'm using DAQmx 9.5.1) that I have overlooked could somebody please let me know.  Assuming this is indeed a bug, I would also be interested in the CAR ID.

Best Regards,

[Kevin_Price]

John,

No specific knowledge but wondering if you came across this, which seems to suggest that you should be able to do what you want, barring a bug.  My only other thought is to explicitly revert the task to the Unverified state as suggested in that link.  I'd have expected that to have happened implicitly when you stopped the task, but maybe it'd help anyway.  Then again if you have to revert all the way back, you may not be left with much advantage over a Clear & reconfig.

-Kevin P

[John_P1]

Hi Kevin,

Thanks for pointing out the link, I actually hadn't seen it before.  Unfortunately though, I still get the same -88700 "internal error" whether or not I unverify the task. Interestingly enough, the error only occurs when using a buffered counter output task (i.e. writing an array of pulse characteristics to the buffer).  Removing the write (so the counter would just re-generate the same set of pulse characteristics) I can switch back to on-demand without issues (with or without unverifying).  This doesn't help me though since my users are specifying arbitrary buffers of counter output pulses so I need to make use of the buffer.

I've actually already implemented a workaround--I just configure two tasks during initialization (a "Finite Pulse Task" and a "Single Pulse Task"), the only difference being one uses implicit timing and the other does not.  When the user wants to output a single pulse I stop and unreserve the finite task, then start the single pulse task with the appropriate high and low times.  When the user wants multiple pulses I stop the single pulse task, set the buffer size for the finite task, and then write my N sample array of pulses to the finite task before starting it.

This works out just fine as a workaround, but it seems that it should be possible to re-use a task handle and change between finite and single pulses.  Regardless, the generic -88700 "internal error" probably wasn't intended to be seen by end users.  If there is a legitimate reason that switching between buffered and single pulses using a single task handle isn't possible then it should probably have a unique (and more specific) error code.

Best Regards,

[Kaitlin-N]

Hi John,

I saw the same error when trying to run the code you posted. However, I'm not seeing any error when I try to outout a single pulse. Here is how I have it set up. I have only currently tested this with a simulated device however, so I can not verify the correct ouput. Let me know if this approach also works with your hardware.

Regards,

[John_P1]

Hi Kaitlin,

Interesting... I get error -200609 when trying to run your code on a real or simulated X Series:

In fact, just this simple case results in error -200609 (the array doesn't show up right for some reason, but it is just a length 1 array with valid frequency and duty cycle):

On a simulated cDAQ chassis (which it looks like you are using based on your screenshot) I don't get any error at all.  Unfortunately though, I don't have a real cDAQ chassis to validate whether or not it works with real hardware.  Anyway, my application requires the X Series rather than a cDAQ chassis so it wouldn't help me either way.

It would be great if X Series devices just supported generating a single pulse in buffered mode so us users don't have to treat 1 pulse as a special case.  If that isn't possible, then it would be desirable to be able to reconfigure a buffered CO task to switch between multiple and single pulses to allow us the means to handle this special case.  If that isn't possible either, then at the very least it would be better if the resulting error gave some indication to the user about what the problem is rather than simply reporting an "Internal Error".

Best Regards,

[Kaitlin-N]

Hey John, 

Can you tell me specifically which hardware you are using?

Thanks,

[John_P1]

I'm using a PCIe-6351 or a PCIe-6320.

Turns out that a simulated USB X Series doesn't return an error either, just PCIe (and probably also PXIe).

Best Regards,

[Kaitlin-N]

Hi John,

So I did some more research on the error -88700 that you were originally getting. There is currently a Corrective Action Request - #371386 for DAQmx stating that if you commit a counter task of any measurement type as buffered, then reconfigure it to be on demand, the second commit will return error -88700. I have added a note of this case to that CAR.

I think for now the best workaround will be creating the second task.

It is strange that a simulated USB X Series doesn't return the error that the PCIe does. I'll have to look into this a bit further to see where the limitation lies. 

Regards,