reads data when i highlight execution

[johnsold · Accepted solution]

Try putting a Wait between the Set OPM Wavelength.vi and the OPM.vi.  You have the two VISA Writes occurring within microseconds of each other.  I think the instrument needs time to reach the wavelength before calling the OPM.vi.  The delay after the DATA? command may also be required.

Lynn 

[GregFreeman]

DOH! Rookie mistake 😞 It works now though, thanks much!

[shanky1023]

I have a Code that gives a string output from a TCP/IP connection... When i run it with Highlight Execution it obviously runs slow but any change in output is updated in the Display..

But when i turn off the Highlight Execution it does not update at all.. Any change in the system is not detected.. I know this Post is pretty old but could anyone take a look into this  issue..

I m attaching the VI...

[RavensFan]

Any reason you have the mode set as "Immediate"? Try removing that constant or set it to its default of Standard. See if that works better.

Something is wrong with your VI's front panel. When I try to Restore the Front Panel window so it isn't maximized, it shoots way off screen to the left and basicall disappears. Do you have some multi-monitor setup? If so, make sure you set your VI's to the primary monitor so that when other people open them, they can see them on screen.

[shanky1023]

Hi..

Ya i am totally sorry about the multi monitor thing.. i just din know it ll be a problem for others...

I shall update you soon with the VI when i go the lab..

I have checked it out with Standard.. it just slows down the VI more cause the Command waits for all the bytes to come in.. Immediate displays immediately.. It works perfectly well in the Highlight Execution mode... every change in the system is output as a new value but the problem is only in the Not Highlighted mode... 

[RavensFan]

Don't you want all of the bytes to come in?  What good is the data you are getting if you don't get all the bytes?

Perhaps the problem is that you have a greedy loop.  You don't have any wait statement in there.  So it will run as fast as the code inside will allow it.  The TCP/IP write will execute very fast.  With the TCP/IP read in immediate mode, it will execute very fast.  The only other things that are happening are the updating of the indicator and the reading of the stop button.  The visual updating of the indicator on the front panel happens in the UI thread and is scheduled when the processor feels it has free time.  If everything else is running superfast, the display won't get updated very often and it will appear to be running slow.  Even other UI things like mouse movement could seem slow or laggy.

[shanky1023]

Ok Now i seem to be getting the point but if i switch to a standard mode it indefinitely waits for all the bytes to come in...

the number of bytes coming in varies sometimes so i gave the maximum and IMMEDIATE option so that as and when it gets bytes it reads..

And how do i make the VI less greedy.. can u suggest me a way and also elaborate on what u mean by including a wait in the VI ?? 

[RavensFan]

I don't really understand the actual definition of the Immediate mode which says "Immediate—Waits until the function receives any bytes from those you specify in bytes to read. Waits the full timeout only if the function receives no bytes. Returns the number of bytes so far. Reports a timeout error if the function receives no bytes."  Sounds to me like it will wait just long enough for the first byte to come in.

What is at the other end of the TCP/IP communication?  You should look at the TCP/IP examples in the example finder.  The basic principle of a communication protocol is that if the number of bytes to read is variable you either read bytes until some sort of termination character comes in to tell you that is the end of the data.  Or you prepend one or more bytes at the beginning of the message to tell how many more bytes there are to read.  So you read the first 4 bytes for example, typecast that to a U32.  Then pass that number into the next TCP/IP read so you now know exactly how many more bytes are left to read.

The Wait function is in the Timing palette.  It is one of the basic LabVIEW functions.  If you are not aware of it then I highly recommend you look at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours

It wouldn't even need to be a long wait.  Even a zero millisecond wait is enough to tell the CPU to go off and do other tasks such as screen and mouse updates.

[shanky1023]

hi ravensfans

thanks for the Wait time suggestion.. also i shall look into the standard and immediate optins once i get into the lab..

I am also going through the manual paralelly 

 I shall get back with my findings as soon as i am in the lab..

Message Edited by shanky1023 on 11-20-2009 11:40 PM

[shanky1023]

Hi Ravens Fans

Now i have worked my way through introducing a Wait in the Loop.. Now the Display updates every second and any updates are accounted for..

Now I just need to get a chart or wave out of the data ouput. I considered converting the output string values to an array and feeding it to a Build Waveform fnction. But i am not able to understand how to build a an array from the outcoming strings as i dont see any option to do this. the tutorial guides on how to go about making waveforms but i cant find much even in LabVIEW help about Data form conversions..

Can you guide me a little.. i am attaching the VI.. now it ll open perfectly for u.. have a look and see how we could make a graphical output