09-20-2016 09:24 PM
Why did you make your loop background black making it hard to view the diagram?
I have never seen problems where a 50 msec wait took 100's to 1000 msec. Are you sure that is where the extra delay is occuriring? Is there even a need to wait 50 msec if there are no bytes at the port? Suppose you change it to 10?
How many processors does your CPU have? I remember more delays due to Windows moving in older LabVIEW VI's when they were running on a single processor CPU and not seeing problems on multi-processor CPU's like any PC manufactured in the last 10 years or so.
One thing you could try is to right click on the VISA Read and set it to synchronous mode instead of asynchronous mode. It will take the watch off the icon on the read node. I don't know whether that would help, or actually hurt. But it is worth an experiment.
You said your C program is without a GUI. What if you did that with your LabVIEW program as well? There are instrucitons available on NI's website to tell you how to turn a LabVIEW app into a Windows service.
Are there any parts of your code using property nodes?
09-21-2016 05:04 AM - edited 09-21-2016 05:06 AM
Your issue almost certainly has nothing to do with the code snippet that you've posted and is 99% more likely to have to do with things going on elsewhere in your code.
At a guess, I would imagine that you have problems around the UI thread/root loop and/or problems with the OS as others have said. Things like property nodes, drawing to the UI etc. all have to happen in the same thread so it could be that you have a lot of thread switching going on. What does your UI look like, how often are you updating it? This is especially applicable if you're noticing it is worse when you move/drag the window around as this forces a redraw.
What sort of CPU usage are you seeing when your application is running and what type of CPU have you got?
Try to isolate your important serial communications from anything to do with the UI so that it isn't necessary to thread switch to the UI thread.
09-21-2016 05:09 AM
Another suspect is the concatination of strings. If there is an actual structure to the messages coming in, it is much better to try to use a state machine (for binary data) or the termination character (for ASCII data) instead of using the Bytes At Port and concatinating the strings together. Doing so will reduce memory allocations (which can become slow). If you give us some idea of how that parsing VI is working, we could help you refactor to eliminate that Bytes At Port.
09-21-2016 10:56 AM
@bdwhaley wrote:Hello - this is a follow up post from a previous topic some of you may have already addressed, but I realize that I didn't lay out the situation well enough and I want to start fresh.
This seems heavily redacted, for example I would expect the string to be wired across in the other case. What else is missing? (And no, I cannot take code serious that has glaring background colors.)
Does the C code really do the same polling for bytes or is it more reasonable and utilizes the presence of termination characters.
You said you changed the priority. Did you configure it to run in any specific thread?
Why do you read the "port" terminal with every iteration of the loop? Can it change during execution of the loop? If not, it belongs before the loop.
What does the parser subVI do? How does the C program do this part? What are the execution settings of that subVI? I assume that it trims the accumulated string. How does it communicate with the main code?
How does the loop terminate normally?
09-21-2016 11:53 AM - edited 09-21-2016 12:17 PM
At 115k baud with a 100ms response time and a 50ms wait ???
The hole architekture seems questionable to me. A producer/consumer ??
How is the RS232 in the OS configured? (buffer, response/signaling, priority?) Do you exactly know what the C program is doing?
Not all aspects of the RS232 are covered by VISA*. (Learned that while using a rs232 for a CAN like protokol with restrict ACK timings)
*) well about 15a ago 😉 , but even then it wasn't a problem to log 115kbaud data at 4 ports simultaniously ... producer/consumer! and the RS232s (nonUSB) run in parallel in 4 loops in 4 subvis called by vi-server ...
What is the parser doing? Can we see some raw data?
I would expect that the I/O control inside the loop is taken outside by the compiler??
10-21-2016 10:27 AM
Don't laugh, but the solution was extremely simple, remember the pauses mainly occured when moving, closing, opening the LabVIEW GUI.
It took over 3 weeks to figure this out:
Performance options, Choose the "Adjust for Best Performance" option. I can't believe this.
As to why I put my diagram background as dark as one of you posted, it's because after programming over 20,000 hours of labview in 20 years time (many of those hours on CRT), my eyes are fried and I am not able to look at a white screen more than a few minutes without experiencing severe discomfort. Maybe that blue LED light coming through has caused this. Don't know. Also can't handle fourescent lighting very well.
Thanks for all your comments, Bradley
10-21-2016 10:32 AM
@bdwhaley wrote:Don't laugh, but the solution was extremely simple, remember the pauses mainly occured when moving, closing, opening the LabVIEW GUI.
It took over 3 weeks to figure this out:
Performance options, Choose the "Adjust for Best Performance" option. I can't believe this.
As to why I put my diagram background as dark as one of you posted, it's because after programming over 20,000 hours of labview in 20 years time (many of those hours on CRT), my eyes are fried and I am not able to look at a white screen more than a few minutes without experiencing severe discomfort. Maybe that blue LED light coming through has caused this. Don't know. Also can't handle fourescent lighting very well.
Thanks for all your comments, Bradley
Don't forget to mark your post as the solution! That it is your own post that was the solution doesn't disqualify you from marking it. 😉
10-21-2016 10:44 AM
As much as I would appreciate the credit, I don't deserve it. Please UNmark my comment as a soultion. 🙂
10-22-2016 12:21 PM
OH NO!
to be brutally late to the party- you could have probably fixed the issue by simply disabling the AERO themes for Windows.