jpdrolet

I see that Mr mec (a.k.a "one hit wonder"), signed up for a new user account to anonymously spoil a very good joke. :thumbdown:

PS - Excellent work, Michael! Yes, ehhhxcellent. :worship:

"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.

Looks like inteligent people don't deseve a job in Canada.

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>

Years ago I read a posting by either Jim Kring or Jean-Pierre about NI's patent for a 3D bloack diagram.

Does anyone recall this discusion and have any info on this subject?

Ben

BTW: Many times my mother looked at me and told me "Benny, don't ever get old!" Well I did not follow her advise and sometimes remember dreams as if they were memories.

See this post of info-LabVIEW

Hi all,

How can I rotate Feedback Node ?

I mean code with the bootom fedback node looks much more better than the top one.

I realy don't know how I placed the bottom one to my VI. It just happend... (Maybe like other things in LV8.0 ...)

All the Best,

Vladimir

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

Usually this language problem\instrument communication issue is solved by adding the following entry to you executable ini file:

useLocaleDecimalPt=False

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).

thanks for all your help so far, i'm really appreciative!

i played around with the program and was still receiving some junk instead of just the single character. i added in a delay and flush buffer before the bytes at port and receive the correct information. however this error occurs, and i'm not too sure what it means:

Warning 1073676294 occurred at VISA Read in revised_bertserial2.vi

Possible reason(s):

VISA: (Hex 0x3FFF0006) The number of bytes transferred is equal to the requested input count. More data might be available.

i've attached the modified vi. thx guys

the baud rate im using is 57600

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?

If you have a numeric control in a subVI and you wire an enum into it, it will be coerced. My understanding is that David wants the same to happen with a string control.

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

.... This is possible for numeric inputs to sub-vi's. ....

David

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.

OK, "spreadsheet string to array" can't be used since there is no EOL in the data. Another approach is needed.

I'm going to try and brute force this with a for loop, but there seems like there should be an easier way.

-Andrew

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

I think that you wouldn't want to close the process reference in the "spawning" VI, since this could kill the process (since Auto Dispose == TRUE). What I usually do, is pass the reference to the spawned process (via Set Control Value) and let the process (explicitly) close its own reference.

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.

I know that I I don't need to use a specifier to just run a VI dynamically, but I'm using it this way so the error cluster allows me to determine if the opened VI is of the correct type to use as a plug in.

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

Thanks for input on this anomaly.

Actually the echo happens whithout any cable being present on the Comm Port. This is why users think that the cable connection is fine and everything while in-fact they are not even connected. I can find a way to filter the polling characters, but if I can turn echo off then I would go for that

Thanks again

Athony

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 am designing a rather large LIMS (Lab info mgmt sys) for a highly regulated company. we therefor need a high level of security and logging. This would seem like an ideal opportunity to try aspect-like programing in LV.

I know that a full AOP in not reaaly possible in LV, but am wondering what suugestions y'all might have at the back of your heads. Here is mine at least (feel free to chop it to bits before i get all messed up in it):

The basic idea is to create a "run-time aspect server" that will monitor (via vi server) all GUI opens and closes.

- On opens, it would check to make sure the current logged-in user has rights to open that vi and would grey-out any features to which he or she should have no access, alternately aborting (?!) the vi (this should of course never happen).

- On Closes, it would pop-up a (FDA-required) box for the user to describe any changes made, if the vi did actually perform any data changes (ie INSERT, UPDATE or DELETE statements - all data is stored in a dB).

What i want to avoid is having to have all wireworkers on the project have to remember to include a special vi in both the init and close sequences of all their GUIs, but perhaps that is the 'best' solution after all.

michael

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

Hi, the following VI domestrates the LV2G of a semaphore named "test", but the semaphore can't GET .

Is reasonable to use LV2G for semaphore? or something happened here? So strange.

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