viWaitOnEvent timeout after viAsyncWrite bug

[AeroSoul]

Hello again

I have a peculiar problem with visa communication.

The connection is between PC and an FTDI chip that converts USB to RS-232 signals, that are then read by a microcontroller.

The communication can run fine for hours or even days at a time, but then suddenly it drops for no apparent reason.

I tracked the error with NI I/O Trace and found out that error happens when it tries to write a packet.

From what i was able to discern from the log (attached, bug starts at line 35734), error happens when visa tries to write, but then for some reason it times out after about a second and never completes the write. After that the VI running the communication hangs and can not be closed, displaying the message "Resetting VI: SM_USBComm.vi.ACBRProxyCaller.71400030". At this point i need to kill it with Task Manager, because it will not end on it's own.

Tried searching for this bug, but couldn't find any results for it.

Thanks for your help

[AeroSoul]

Well i made a test application that only runs this communication and nothing else.

It worked fine over the whole weekend, no hang-ups no crashing. It seems the problem lies somewhere else, but i have no idea where because the only thing going in or out is data to be sent/received.

[AeroSoul]

Another update:

I made a test app that runs all communication of the device, which is 3 separate USB comms and the error happens.

So the first step is that all the communication VIs are run in the same step with an Open VI reference function (call and forget), at which point they start communicating (each on different COM port) and do so at time intervals of 200ms (set so the error triggers faster, it seems to be affected by comm speed), 1s and 1.5s. 

The error only ever happens on one COM port, the previously posted SM_USBComm VI.

Any ideas what it could be?

[AeroSoul · Accepted solution]

So i think we found the bug.

Running 3 communications and a bunch of calculations at the same time is very CPU intensive and at times it would spike to 100%. 

When that happened the communication stalled and froze, although i'm still not sure why only this particular communication froze and no others, we found a temporary solution.

What needed to be done was setting the Labview CPU priority to HIGH and the crashes stopped. 

EDIT: If you want to programatically set priority and build an executable, follow the steps to second solution here. 

[billko]

I think NI has a LV toolkit that allows you to use your GPU for calculations.

[billko]

Are you doing the calculations in parallel with the communications, or are you hoping that the calculations complete before the communications time out?

[AeroSoul]

When the full application is run, it starts all state machines at once with open vi reference function, set to call and forget (the state machines started are 3 USB communications, DAQ communication, database and a regulator).

The regulator SM is what does the calculations, so they are done in parallel with the USB communication that was giving me trouble. 

All global data is written to and read from Action Engines, so the data to send is there, even if regulator calculations don't complete on time, it's just old data.

What i ended up doing was that instead of starting all the state machines at once i added a 50ms delay between each, so that they don't send/receive packets at the same time. This has helped somewhat, tho they still occasionally sync up, just not all at once. The other thing i did was to set higher CPU priority to this application, which eliminated the bug completely.

This is deemed only temporary solution tho and we are still searching for a better solution.