LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

combining 2 vis

Solved!
Go to solution

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?

0 Kudos
Message 1 of 13
(4,215 Views)

Can you attach your VI?

 

There is no way we can tell from your description how you combined your VI's.

Message 2 of 13
(4,208 Views)

It sounds like there is a waiting for data happening in the NA code that is keeping your loop from iterating and causing the CAN part to have to wait for the next iteration.  Hard to say for sure without seeing some code.  But make sure you have each intrument in its own loop so that one will not affect the other.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 13
(4,192 Views)

I'm attaching the VI. It may be difficult for anyone to run because it requires one metric buttload of plugins but maybe one of you can tell me how wrong I am doing things. A word of warning: I am a complete amatuer with labview, I've used it quite extensivly but I'm sure I'm doing some things really wrong. Any help would be greatly appreciated. Thanks.

0 Kudos
Message 4 of 13
(4,122 Views)

And to clarify a bit, the program does work. It addresses the VNA correctly via command expert and the data is reflected correctly in the output file. The only real issue is that the graph freezes while the VNA loop executes and the CAN data gives a single reading of 0 for all values which then make my graph look horrible. Almost as if it exits the CAN containing loop for a split second and then resumes right where it left off. I'd like to find a way to stop it from exiting that loop but would also be okay with simply not plotting the zero value and just living with the graph freezing.

0 Kudos
Message 5 of 13
(4,110 Views)

First suggestion.  Be careful with your front panel.  I've got two big monitors, but the frontpanel was blown up larger than my primary monitor with the title bar off the top of the screen.  Somehow I managed to get to edges and was able to resize it so that I could see it.  But then I noticed you have your front panel somehow set to resize itself with the size of the panel.  So resizing it just distorts everything on the screen.  Rebuild the front panel so it doesn't do that.

 

Now looking at your code, I was first expecting to see some problems with the two parts of the code that were combined being dependent on each other.  But I didn't see that.

 

I think you will need to use the troubleshooting tools available to you such as probes.  You say you think a loop could be exiting and restarting.  Put a probe on a wire after that loop to see if that actually happens.  I see a case structure that seems to reinitialize graphs.  But a probe on a wire to see if that ever executes that case of the structure.  Without seeing the subVI's, I can't tell if any of them are going into loops that could be causing the hold-ups.  The fact the FieldFox loop is based on an ExpressVI kind of scares me.

 

Also put probes on any error wires.  It is possible that for one device, it generates an error if you don't service it often enough.  Perhaps a buffer overflows.  And when some functions get an error, perhaps instead of returning the expected data, it will return default data such as a zero on a numeric, or an empty array.  Probing wires should show how things are behaving.  The highlight execution tool can slow the operation down so you can see how the data is flowing.  But it may not work for you since it slows down all the code.  Since you are dealing with DAQ devices and instruments, they won't behave the same if you slow down the code.  So you'll just have to rely on probes.

 

A couple of tips about your diagram.:

  • You use the value property node way too much.  Sometimes you don't need it at all because you have an unused terminal for the control.  (See ROI Start and ROI End)  Even if you do need to get a control value in more than one location (assuming you aren't going to have race condition problems), you'd be better off using a local variable and not a property node.
  • Learn about auto-indexing.  In one loop, you feed an array in and use an index array wired up with the i terminal to get an individual value.  Just use an auto-indexing tunnel.
  • No need to add a 1 to a wire.  The numeric palette as the increment function which increases the value by 1 without needing to wire up an add functiona and 1 constant.
Message 6 of 13
(4,100 Views)

Thanks so much for all your input. As I said I'm an extreme amatuer and most likely wasn't following the best practices I'm sure you know about. I'll implement some of the changes you suggested and see if I can troubleshoot based on your advice. I really appreciate you taking the time and I'll continue to post my progress.

0 Kudos
Message 7 of 13
(4,093 Views)

So I have followed your suggestions, replaced property nodes with local variables looked at a few different probes and I still can't stop the freezing issue. The final measure I took was put a random number generator in each loop with an indicator for each on the front panel. I noticed that when I initiate anything that has to go through keysights command expert all of the random number generators stop until command expert has finished. Do you think its possible that the error is happening within command expert where I can't get to it. If I communicate with the VNA as a VISA device and feed it SCPI commands manually I don't see the same issue. Do you believe this could be the issue or am I just grasping at straws. Thanks again for all your feedback.

0 Kudos
Message 8 of 13
(4,059 Views)
Solution
Accepted by topic author FreeRangeOrganicBabies

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.

Message 9 of 13
(4,047 Views)

Thanks again for your input. I cannot get into command expert. Command expert is actually a windows program that runs seperatly from the labview program and needs to be installed on each machine after building the LV executable. Given that everything in labview stops while communicating through it I'm inclined to think I have to go the VISA route. I've been able to run a few simple commands sending SCPI commands as plain text over VISA. I guess I'm off on the long road of rebuilding with VISA. I can't thank you enough for your help. I was at wits end without the experience to know better. Have a great day!

0 Kudos
Message 10 of 13
(4,017 Views)