jpdrolet

"mec" is French for "guy", that gives some hint about the identity of the anonymous coward.... Good joke Michael, unfortunately I first viewed the thread on the 2nd page where it was already spoiled.

No. The problem must be elsewhere...

Rolf, Somehow I just knew you would reply to this one... I have implemented the code with MoveBlock and it worked perfectly. GigaThanks

I have to interface with a DLL that uses a data buffer asynchronously e.g. the buffer is filled in background after the function returns. In C it looks like this: pBuf =(uint16 *) malloc(size);StartAcquisition(pBuf);while (GetStatus() != DONE);/* start using pBuf here */ I know I can preallocate the data buffer in LabVIEW by initializing an array of the proper size but will the data in the wire output from the CLN be updated? I can't test this actually because I don't have the hardware yet. Alternatively, the DLL has functions to allocate and free buffers but I can't figure how to retrieve data from these pointers . Is there a solution apart from a wrapper DLL?

I want a LabVIEW interface for this! <embed style="width:400px; height:326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=6379146923853181774&hl=en"> </embed>

See this post of info-LabVIEW

Just move the attached wires to the left or right. The arrow will be in the direction of the data flow.

Like Michael said, it is probably a decimal point problem. The device and application probably expect to receive number strings using a point. While forcing the application to use the decimal point (useLocaleDecimalPt=False) is a quick workaround, the user still might prefer to see the comma in the interface. The best way to make your application independant of the local decimal separator is to set the decimal separator in the format strings of the application when communicating with the device. When scanning, formatting strings to/from numbers, prepend all format strings with "%.;" e.g. "%.;%.3f %.2f". To determine what is the decimal separator in use on the machine, convert the number 1 with "%.1f" and check the second character (decimal separator) of the resulting string. To determine the language, an easy way is to convert a date to string with the format %A which returns the full weekday name. Check if the weekday name is in the French set ("dimanche","lundi",...) or English set ("Sunday","Monday",...) (I'm not sure of the capitalisation).

The problem might also arise because after the serial port is init'ed, it can't identify the start bit correctly because of the continuous data stream. Change the program so it replies a finite number of characters after receiving a command. Continuous stream devices are more difficult to interface (they are evil!) because it is harder for both hardware and sofware to synch with the stream.

Globals are evil! Do the loops have the same priority? Do the VIs have the same priority, execution thread, common non-reentrant code? Did it happen before the Spring Equinoxe?

OK I read that it was possible for numeric to be converted to a string input. The world can resume its rotation now.

Is it possible for numeric inputs?

That is a timeout with Windows Explorer issue. When you double click on a VI, Explorer attemps to send a DDE message to the application (LabVIEW). When the attemp fails (it does when the app is not running), it starts the application and retries the DDE message. The above message is issued when the second DDE message fails too. It happens when LabVIEW takes too long to load and enable its DDE server. That error has no consequence since eventually LabVIEW will finish loading and open the VI. You could eventually avoid this error by telling Explorer not to use DDE and open VIs with command line only (Explorer>Tools>Folder Options>File type). Since LabVIEW re-register by default its files associations, you also have to set RegisterExtensions=False in the labview.ini file to avoid re-registering with DDE. That has to be done for all LabVIEW file types...

One possibility is to create a CIN and use its CINAbort functionality. From the PDF "Using External Code in LabVIEW": When you abort a VI, LabVIEW calls the CINAbort routine for every reference to a code resource contained in the VI being aborted.

You can indeed use spreadsheet string to array. Wire a 1D array to the array type input and a comma as delimiter.

It is done automatically. From the Run Method Help: Auto Dispose Ref: If TRUE, the target VI detaches the reference from the main VI. When the target VI finishes executing, LabVIEW automatically disposes the reference, along with the parallel data space. The default is FALSE.

You don't just don't need it, you can't wire it to use the Run method. Wiring the type specifier reserves the VI for Call and you can't Run it. However you can check the connector pane by opening with type specifier, close the refnum. If no error, open a VI refnum for Run method without type specifier.

To use the Run method, don't input a type specifier when you open the reference. You need a type specifier only for calling the VI with the invoke node.

When the user scrolls in a menu it seems that it is in a different window that doesn't belong neither to the VI nor the control. However, you can still monitor the mouse movements using the Mouse Device VIs and figure which item is highlighted. That might not be font independant.

Is that what you want? Download File:post-447-1140837999.vi

I have seen (heard?) echoes on long unconnected RS232 cables (but connected at computer end). It was probably noise pickup between RX and TX. This should not happen when the cable is properly connected to a device. Or maybe there is a short somewhere between RX and TX. Are you running Windows XP? It has some issues with com ports

I think that the Lantronics has drivers to install the Ethernet-serial adapter as a local serial port so you keep using a serial port in your application. However, there was a silly problem that prevent it to work properly since it was parsing the sting output of some command and it didn't work with a non-English OS. Maybe they solve their problem now.

I'm not clear if you want to monitor programmers who edit VIs or users of the application.

The error comes because you must create the semaphore before using it. Call with NEW on the first call. When wrapping refnums in a functional global, I usually test for a valid refnum before returning it. It automatically takes care of initialyzing on first call. You can then get rid of the NEW case.

I also have a loop utility called LoopContinue that determines if the while loop it is enclosed into should continue or not. The different instances communicate with a notifier so many or all parallel loops can be notified to stop simultaneously. For UI VIs it also has an option to open the FP on first iteration, close it on last iteration and terminate the loop when the FP is closed. This utility is intended to be used in any loop in an application that have to run an indefinite time. When the Application Quit input becomes TRUE in one instance, all instances will abort their wait and stop their calling loop. The Continue output, wired to the continuation terminal of the calling loop becomes FALSE. It is used to terminate the application. When the Group Quit input becomes TRUE in one instance, all instances with the same group name will abort their wait and stop their calling loop. It is used to terminate a specific section of the application like a plugin. When the OK|Close input becomes TRUE, only this loop will terminate. When Manage Caller FP input is TRUE, the VI will open the Caller FP on the first iteration, close it at the last iteration and end the calling loop when the user closes the Caller FP. Download File:post-447-1140347475.llb