labview RT 14.0 Scheduler Assert%3A __1276 Scheduler Assertion Error%3A 80000004

[jnapier]

We have a multithreaded CVI app (~20 threads) running on a PXIe-8135 (4 CPUs).   The application never gets done starting all the threads before blue-screening with the following error:

Scheduler Asser: __1276

Scheduler Assertion Error: 80000004

Interrupt Disabled. Scheduler Enabled.  ....

More details:

System

Chassis 1 PXIe-1085:

    PXIe-8135 Controller

    PXI-6704 (7 of them), initialize properly, thread runs successfully until blue screen

    PXI-8431/8 (8 of these, total of 64 RS422 channels, about 40 being used currently for test), it is during the starting of these threads (one for each board) that it blue screens 

    PXIe-8374 (for using Chassis 2 as an extension of Chassis 1)

Chassis 2 PXIe-1075:

    PXI-8370 (connected to PXIe-8374)

    PXI-6528 (1) threads run fine

    PXI-6529 (4) threads run fine

    NI-8234 (4) not used currently

The scheduler error happens at different times, but always during the starting of the RS422 threads.  Can anybody give a hint as to why the Scheduler Assertion Error occurs, and particularly this specific error?

[kevins33]

Hi,

I have a couple of questions for you.

1) Has this application ever worked?

2) Can you attempt to replicate this issue with less RS422 channels? Basically, is there a maximum number of RS422 channels where the error is received, or if you had only 1 channel being used, would the error still happen?

3) Do you have another PXIe controller that you can try?

4) Did anything change in your system that would have caused the error?

[Bauer_CT]

I have a similar error on my PXI RT application. It worked with two RS485 ports but I tried the full set of 28 and it crashes after less than a minute. I haven't spent the time yet to find out if there's a "sweet spot" with number of com ports that work, but my application requires more like 40 ports when all is said and done. i'm concerned if there's some kind of limit for some reason.

BTW I realize this post is very old. I'm throwing out lines for help here

[jnapier01]

Hi,

I had forgotten about this, and in fact was flailing around so desperately that I didn't see that somebody tried to help me on this board the next day.  We never did have the time to fully characterize the DMA throughput of serial comm data through the backplane as a function of number of channels, bit rates, message rates, and message sizes and we could never get that from NI.  Our funding ran out and we had to admit defeat on that program due to the bad assumption that we could just run a whole bunch of serial channels simultaneously.  A lesson learned was to not always just accept a vendor's assertion that it will work, but you're often stuck doing just that when using proprietary software/hardware instead of building your own.  We found (for another subsequent round of funding for a similar task) that the serial comm protocol needed to be implemented in FPGA's connected to the backplane.  We did use NI hardware/software again (not my choice) and it worked fine.