08-04-2013 01:04 PM
Hi, I'm developing an app that displays data recieved from accelerometer and gyroscope via RS 232 port. Packages arrive 25 times a second, every package is closed by a '#' char which triggers the installed data-recieving function.
I've used sample CVI project (RS232 one) as a 'skeleton' for my app, and it has been working fine until I started tweaking the app to make it more user-friendly (automatic ComPort detection, warning if no data is comming, and such) and I must have somehow broken the most important function - the data is still comming fine, but one i press 'start recieving' the whole application 'freezes' (the displays still display incoming data, but it DOESNT respond to any user-interactions) - it acts as if it was using for loop, instead of even handling to recieve data. When I switch off sensors (so no more incoming data) the app un-freezes (and if I clicked anything when it was still frozen, proceeds to execute it) and then resumes to work as normal (well, sort-of normal).
At first I thought the data-recieving function takes too long to execute, therefore blocking the interface (no time for user-input between data packages), but its not the case - I have commented out (/* */) entire data processing code exept reading com port and displaying test counter, app still freezes.
I've added a LED to the main pannel which is switched on when the installed function starts, and switched off when it exits - since data arrives 25 times a second and eye recognises blinking led as static when it blinks at least 30 times a second I figured it should blink if the data-processing function executes in less than 1/25s - it does NOT blink. IDK if its software/hardware limits (its not a REAL LED, after all) OR if its the data processing function that blocks the interface, after all.
Im not so good with all those panel_handles, perhaps something here is faulty? But then, entire interface works fine until I start recieving data...
Thought it could be too long time out of the com-reading function, but the whole installed callback triggers only when it finds whole data package enclosed with '#' arrived, so timeout shouldnt matter, right?
Maybe something's wrong with port data buffors? Im out of ideas...
Any ideas on how to check, what is the cause of my problem?
Regards, Benji.
08-04-2013 04:27 PM
Solved. Turned out it was com port time out fault after all - I didnt notice I change it to 0.05s in module testing part and apparently callback function clogged entire app waiting for whole data package.