Software/Daqmx corruption/hardware fault?

[Voila1]

Hi all

I have a test system that has recently started throwing -200297 errors. The system is about 2 years old and has not had these issues before this week. If the pc is restarted the error disappears for a bit before returning (its not consistent).

I have been through the help guides/existing forum posts for that error and checked the daqmx settings and I seem to have avoided all the normal issues that cause that (its a finite number of samples, follows the 10% rule etc). Just to be on the safe side I reduced the number of samples taken down to 1000 (from 100k) and still got the same issue.

I had a look through NI MAX and that threw up an error (attached) so I reset the config database as per the help article. That again has temporarily fixed the issue (after reboot it's fine for a bit then the issue returns).

I have done a self test and a reset on the pci card and both return with no issues.

I have also done a full software repair on the installed labview components through the package manager which has also not fixed the issue.

I have attached the VI in question (FYI rate is 2Mhz, number of samples is 100k), a couple of screen shots of the NI Max issue

Question(s) I have is,

Is this a fault with a card?

Or a fault with the code?

Or am I in need of a full reinstall? 

Any advice would be much appreciated!

V

[AeroSoul]

Did you by any chance update windows last week?

[Kevin_Price]

Are you sure you aren't *really* talking about a -200279 (buffer overflow) error?

The code is about as simple as it gets, I don't see any problems there.  Really, a finite acquisition should never *try* to deliver more data than the buffer is sized for, and I don't ever remember hearing of a -200279 error on a finite acquisition task.

Are you calling the attached vi repeatedly in a tight loop?  Sometimes errors come up when you try to reconfigure a task too soon after clearing one that used the same hardware resources.  It'd be better to configure once, hang onto the task refnum, and then just start and stop the task repeatedly, waiting until program exit to clear the task.

If it's a problem with the device, it'd be a pretty weird one to manifest itself this way.   If the stuff above about repeated calls don't apply, I guess I'd try removing and then re-installing DAQmx.

-Kevin P

[Kevin_Price]

Additional thought:  are you also *really* sure that the error is thrown in the code you posted?   Or are there any other DAQ tasks in your app that might possibly be responsible?   Just making sure...

-Kevin P

[mcduff]

A couple of things to try:

1. From your screen shot it looks like something is wrong with MAX. I don't see any test panels or anything else beside refresh. Maybe reinstall DAQmx? This should be a last resort as it is a PITA. See screen shot below of what MAX shows me.
2. Instead of taking 3 million points, take 3,000,320. This assumes your disk sector size is 512. DAQmx works better when the number of points is an even multiple of the disk sector size.

[Voila1]

Thanks everyone for your ideas.

@AeroSoul  good point, I will need to go check its certainly possible as the updates are automated by the IT department.

@Kevin_Price I am pretty sure, its used for a basic current measurement so its only executed 3 times (none of which are looped). Does your coment about reconfiguring the same hardware too fast apply to all daqmx tasks on a specific card? As there is some digital tasks that happen beforehand. I have not found any other issues with finite measurement loops either. I have the full dev system on that pc, so i did check. with trace execution on. 

@mcduff Ye, if you refresh the ni max configuration then reboot they all return (until it fails again). Ye the labview install process in general is a pita, which is why i am here looking for alternatives! 

Cheers

V

[Kevin_Price]

1. Please confirm the specific error code.  Is it the fairly unusual -200297 you first reported, or is it the pretty common -200279 that I responded about after making an auto-correct assumption?

2. A problem that only shows up intermittently suggests some kind of timing / race condition.  Depending on which error, it could mean contention for DAQmx resources or it could mean contention for CPU, or several other possibilities.

3. The code you posted does *NOT* inherently look to me like it should be able to cause *either* of those error codes by itself.  There'd have to be something else getting in the way.  That's why I speculated about calling it repeatedly in a tight loop.  I've known such things to result in DAQmx errors.

    But this is mainly guesswork without a more thorough understanding of *all* the code.  (P.S.  While I recommend you post it all, I'm not promising to give it a thorough examination myself.  I generally skip past threads when zipped up projects approach 1 MB.)

-Kevin P

[Voila1]

Sorry, yes you are correct it is the 279 one (fat fingers/not enough coffee on my part) see attached screenshot

I would have thought multiple competing tasks would give a different error like 50103? I suppose there could be a small memory leak, the code uses variables a lot, and some slow down/change in the pc has now caused it to become an issue.

To make things a bit easier, I have attached a zip folder with all the vis involved (i have not included any vi/global which does not contain a daqmx task somewhere). I can upload more if you need, I just didn't want to overload people with files. The sections of interest are in the LTS FTR MK2.vi in the "test" event case then sections 2 and 3 of the state machine.

[GerdW]

Hi Voila,

---

@Voila1 wrote:

To make things a bit easier, I have attached a zip folder with all the vis involved (i have not included any vi/global which does not contain a daqmx task somewhere). I can upload more if you need, I just didn't want to overload people with files. The sections of interest are in the LTS FTR MK2.vi in the "test" event case then sections 2 and 3 of the state machine.

---

Lots of missing files: VIs, globals, project …

But from what I see I think you should restart the whole project from scratch!

• Way too much local variables! And using "value" property nodes to replace locals is also wrong…
• When you need a statemachine then you should use shift registers to hold state data!
• Wrong usage of an event structure: never have "long lasting" code inside an event!
• Wrong usage of DAQmx: why do you need to create and kill tasks all the time?
• Cleanup: when Autocleanup improves your code then you made something wrong…
• when setting up a statemachine you should use an (typedefined) enum to determine the states, not just integer values…
• Why use two string indicators "message"/"message2" when one indicator with be sufficient too?
• Using the "History.Version" property will not work correctly in an executable!
• …

You really should design your application first before starting to code!

(I would not use any Renishaw software after seeing these VIs… 😉 )

[Voila1]

I know there are lots of missing files including the project. That was deliberate as I didn't want to waste anyone's time digging through of stuff that's not useful/relevant (as per the message where I posted it!). If you need more vis I can add them but I would rather not, the quality doesn't get any better.

As for your other points, I am fully aware its rubbish code (which is why I didn't post it in the first place 😉). It is old, inherited code and yes I am definitely going to throw it in the bin and start again when I have the time.

The question is: is there something in that lump of code that is going to cause the error I am seeing? 

If there is, then its going to get pushed to the top of the pile. If not, well it can wait.

Its a good thing you can't get any labview software from them then isnt it 😉 (also how do you edit/delete posts? 😅)