04-29-2010 02:01 PM
Ben wrote:
I suspect Waldemar will reply... eventually.
Not eventually.
I made some more tests today. And it is reproducible that the "skip" attribute is causing the problem when not set.
"Merge Errors" is used in a lot of places in the code. It could happen that a non-real-time VI will call it and a real-time VI will call it too. It could happen at the same time since we are on a dual core system.
I don't think we have large arrays for ME to process. I don't expect we have more than 6 clusters to merge.
From my second post you can see that memory allocation isn't related to the finished late problem. I traced memory allocation but a change was never in the same or one before or after that iteration as a finished late.
The only thing is the nearly constant time when it happens. This makes me really wonder what's going on behind the scene.
04-29-2010 02:32 PM
How about changing the ME to re-entrant so there is a unique instance used in the code you showed us?
Ben
04-30-2010 11:33 AM
Hi Ben,
I don't like to change ME in that way because it will be overwriten by any Service Pack or Fixpack update. I know all or most of the DAQmx VIs are set as re-entrant.
Today I worked on another story:
The DAQmx task which provides the clock for the timed loop stops suddenly and the timed loop won't run anymore. I don't know if this task interferes with the other tasks on the same PXI-6259 card running in normal priority in another loop.