So I have an issue that I hope all you experts can help me solve. I have a program for reading CAN output from a NOx sensor and displaying it on the screen as well as saving to an excel file. I built a second program to control a keysight fieldfox network analyzer using scpi commands through keysights command expert. I was able to combine the two programs and get the output that I want from both the CAN NOx sensors and the fieldfox NA. The problem I am having is when I trigger a scan on the NA the NOx graph pauses, which isn't a big deal, the real issue is that when it starts up again I get a single reading of 0 to the graph. Is there anyway to keep it from pausing the NOx loop when it enters the NA case structure and if not is there anyway to prevent the graph from plotting that 0 point?

It is possible. If you can't get into that Command Expert, it is hard to know what is happening in there. It is possible that it uses some dll's that are set to run in the user interface thread and are killing screen updates. But that is speculation on my part. If you are able to use VISA to communicate and it solves your problem, I would do that. A situation I had. One test stand I build had an inclinometer on it. They provided LabVIEW "drivers". The LabVIEW portion of those drivers were a mess with really bad wiring, redundant code, and numerous issues that looked like a disaster, a good candidate for the Rube Goldberg thread. They did work, and there was nothing complicated about them, so I cleaned up the mess within about a day and elimnated about 80% of the functions on screen. The code was cleaner and still worked. Except I had occasional issues. It ran on an old PC that only had 1 core. The LabVIEW code basically made a call to a .dll which was the actual communication interface to the inclinometer. When starting, the LabVIEW code called the.dll and started a kind of background service. It worked just fine except if I did any major graphic things on the program. If I took a windows and dragged it around the screen, then the code would slow down considerably. I realized the .dll was running in the UI thread, any demands on this ancient PC with only 1 processor for that UI thread (such as rearranging the windows) conflicted with the dll. Eventually the PC was upgraded years later and that might have helped, but my actual solution at the time was I discovered what the communciation protocol was (just basic ASCII commands) and rewrote the driver using pure VISA to directly communicate with the serial port and get rid of the nasty .dll that was in between. Your situation kind of reminds me of that experience I had.

LabVIEW

combining 2 vis

Solved!

I'm glad I could help. Good luck with your app. It may take some extra time, but I think you'll find it worth it and be happier with the results in the end.