serial IO using LabVIEW CLFN

[lmd2]

BACKGROUND
I have written LabVIEW wrappers for a DLL device driver. One function of the DLL responds to hardware interrupts and one input to this function is a pointer to a user function (to be called when an interrupt occurrs). Since a LabVIEW CLFN can not accept a pointer to a function I wrote a wrapper DLL which accepts a Dynamic User Event Reference and internally calls PostLVUserEvent(userRec2, &testData);
so far so good.
The PROBLEM:
Another input to the function accepts TYPE which defines the communication protocol. Options are ARINC 429 (an aviation standard), serial 232, serial 485. I tested this originally using ARINC429 and everything runs great. When 232 is selected, immediately upon an interrupt LabVIEW locks up requiring Task Manager to quit LabVIEW, or in somecases powering down the PC. In C code the sample runs fine. The problem (in LV) appears to be in handling the interrupt only when serial is selected. My wrapper DLL includes three header files: #include "extcode.h" #include "hosttype.h" & #include "std429.h"  I have confirmed with the client that their header "std429.h" includes serial IO and serial prototypes (I was hoping that was the issue). Would there be any other #includes necessary (or any other "known quirks") with using LabVIEW to access Serial IO through a DLL?

thanx
lmd2

[lmd2]

Okay, more information: the code seems to be working to a point. The action that we are using to trigger the interrupt is keyboard input from a hyperterminal configured to 9600 baud. The VI runs fine until I type a single letter. At this point the processor gets pegged (Task Manager is open and minimized). Within the event structure I have just an increment (for the time being). Hitting a single letter should trigger a single interrupt and I should see my probbe go from 0 -> 1. Because everything is bogged down (processor pegged) the probe doesn't update for a while but when it does it says over 7K. As I am typing this I just saw another update (I have NOT typed more than 1 letter) the probe now reads 27084

So what should have been a single one time event seems to have latched somehow ON and is continuously firing and using 100% of my processor.

This make sense to anybody?

thanx

lmd2

[lmd2]

don't know if this helps, but the CLFN is configured as reentrant (threadsafe) and the calling convention is stdcall(WINAPI). Could the calling convention be incompatable with RS232?

[G-Money]

Imd2-

          Forgive my ignorance but what does CFLN stand for? I googled it but nothing productive came up. I did find one instance of a handing problem concerning a CFLN and LabVIEW. In that case the problem turned out to be an instance where the CFLN made a call to System32.dll and the minimum size node wasn't filled out so the computer was forced to hang indefinitely. Hope this helps but if not then I will keep looking it for you. Cheers!!

[lmd2]

you appear to have transposed the letters

what I wrote was CLFN which is a Call Library Function Node

it is a way to call a DLL from within LabVIEW

to update this thread, the actual problem appears to be the Event Structure 'latching' on and running endlessly

not sure of the cause yet, but I can reproduce this

screen shots have been sent to NI Support

if we get a resolution I will post it here

thanx

lmd2 

[G-Money]

Imd2-

           Thanks for the update!! I guess I should not post Friday evening after a long week. 🙂 I'm interested in the 'latching' of the event structure so when you get an answer let us know, please. Thanks!!