Neville D

Don't know if this will help, but if you can upgrade to LV 8x, you can automatically add NI components to the installer for your application like MAX, DAQmx etc. will save you the hassle of trying to build a global installer with all these components yourself. And why do you have two different versions of MAX? Just upgrade one to match the other. Also, if you use DAQmx you have the ability to programmatically define channels, so you wouldn't need the virtual channels of the old-style DAQ. You can also convert old-style virtual channels to equivalent objects in DAQmx called "global chans" or something like that (in NI-MAX). Neville.

QUOTE(Thang Nguyen @ Mar 30 2007, 09:59 AM) How about some example code or a quick screen shot? Neville.

QUOTE(Vladimir Drzik @ Mar 29 2007, 08:26 AM) Why dont you make the clone VI's re-entrant and then make the re-entrant VI "open front panel when called". That way all instances will automatically open up at run-time. If you dont want some of them open, just close the window (it wont stop the VI from running). The only issue with this method is that its hard to figure out which instance is which. Neville.

QUOTE(Jon Sweeney @ Mar 22 2007, 06:58 PM) Another thing you could try is to copy over your labview.ini file from your work PC to the home PC.. (backup before hand). There might be some setting in there that is incorrect or different. Neville.

QUOTE(Jon Sweeney @ Mar 22 2007, 09:56 AM) Try playing around with the Palette Loading options under Tools>Options>Controls/Functions Palettes. I have mine set to Load palettes in background. You have to re-start LV after making a change here. Neville.

QUOTE(BenD @ Mar 21 2007, 12:26 PM) First thing to check would be the paths to the plug-in VI's. You might need to double-strip the path for the exe and only single strip to get at the VI in the dev. environment. Put an indicator up on the main VI so you can see what path its using. Neville.

QUOTE(CraigGraham @ Mar 20 2007, 10:41 AM) What are the camera trigger settings when you examine in NI-MAX? I would check there. Maybe its set to "free-run" mode instead of software trigger mode. Try the old-style IMAQ example to see if there is any issue there. I don't have any camera hardware to check at present, but last I played with it, IMAQdx worked fine under LV 7.1, Windoze as well as LV 7.1 RT for Snap and Grab. I have about 8 installs running LV8.2 RT, IMAQdx RT on PXI, with no problems (hardware triggered grab image). Neville.

QUOTE(rkesmodel @ Mar 17 2007, 11:11 AM) Couldn't you just use the Pt. By Pt. function : Mean Pt by Pt.vi ? (under Signal Processing>Pt by Pt> Probability & Statistics>Mean). It seems to be doing the same thing. Neville.

QUOTE(Rick @ Mar 14 2007, 08:54 AM) Rick, My NI Rep told me the new version should be out in about 2 weeks. There are already new versions of NI Vision out on the NI website (Vision 8.2.1), so the LV version should be just around the corner. Neville.

QUOTE(brianafischer @ Mar 9 2007, 05:33 PM) If you already have LV 8.2, debugging re-entrant VI's is a snap. Just double-click on the VI and you can open its front panel, and probe its diagram just like a regular VI.. multiple instances show up as different VI's with a number attached to the name.. Example.vi_1, Example.vi_2 etc. As a matter of style, it is better to use while loops (instead of FOR) with the option of stopping the test on error or user-set Stop. Neville.

QUOTE(yen @ Mar 10 2007, 11:30 AM) No, my first statement was "correct". If you use the pair of provided VI's to first encode and then decode, the output is definitely correct; however if you use another environment (trying to decode) with C, then the color planes appear to be swapped. I'm not exactly certain, but I suspect the issue is the fact that the http://en.wikipedia.org/wiki/JPEG_File_Interchange_Format#Color_Space' target="_blank">JPEG file format does not define the color planes to be used, and the hence the original NI developer of the code was free to interpret the order of the planes as required.. just that interpreting the image in Windoze shows the planes as swapped. The reason for using the JPEG VI's is the built-in compression & flexibility to adjust it up or down depending on file size (transmitting the 12k image takes about 100ms via tcp-ip). I'm not sure how I could use the picture VI's to do the same thing? And, yes, I am using IMAQ and a PXI RT platform for this time-critical image processing application. It's definitely matured a lot since I first started using it around LabVIEW 7. Neville.

Figured it out. I have been using the IMAQ JPEG Encode.vi and IMAQ JPEG Decode.vi from the Developer Zone. There is a "bug" or issue with the Encode, namely that the Red and Blue color planes are swapped, resulting in an image with incorrect color on the receive side, when used with a non-LabVIEW application. However, if you use the JPEG Decode.vi on the receive side, you don't see the problem, since it interprets the color planes correctly. The fix is to swap the Red and Blue planes before using JPEG Encode. Neville.

QUOTE(mermeladeK @ Mar 2 2007, 04:36 AM) Thanks, I will take a look at it shortly.. been out of town and lots to catch up on. Neville.

Hi All, I am using JPEG VI's downloaded from NI, to take a color image and transform to a JPEG string. This string is transmitted via TCP-IP to a VME based computer and my colleague uses C to capture this image. Problem is the image he receives seems to have the colours messed up. It looks blue-ish. I can't seem to be able to upload the JPEG images to LAVA.. Anybody have any ideas? Thanks, Neville.

QUOTE(mermeladeK @ Feb 9 2007, 04:32 AM) Why don't you post the VI's (and data if any) instead of a picture of the BD.. that will save people time in trying to re-build your work just to re-create your error. Neville.

QUOTE(dthomson @ Feb 26 2007, 10:35 AM) Hi guys, I had talked to my sales rep a while back on this.. what you can do is install on all the machines you might need to use it on, then activate the one you are using, and if you are going to switch to another machine then the Licence Mgr has the option to "de-activate" a licence for the time you are not using that machine. Neville.

QUOTE(TiT @ Feb 21 2007, 09:54 AM) Hi Tit, just copy your /LabVIEW/menus folder from one install to the other. That should copy all the pallet setups. (Be sure to backup the old copy first, just in case). Neville.

QUOTE(gustav @ Feb 21 2007, 06:50 AM) Your right.. once the task is started, you can't switch pins mid-stride. Neville.

QUOTE(Val Brown @ Feb 20 2007, 11:46 AM) In my experience the serpdrv was more forgiving of error conditions and seldom generated any errors (even if error conditions existed). This gave the false impression that things were fine. You could try to trap the errors you are getting and either automatically reset the serial port and restart your communication or else try ignoring them to see if you can still communicate. another issue is the output voltages on the USB adapters seldom reach the values as defined by the "recommended standard" (RS-232). It might be a low voltage issue causing the errors, or a floating ground. It might be adding a few delays of 5 or 10 ms in a tight "bytes at port" loop.. it might be incorrect serial port initialization settings.. or another application having access to the particular port (Hyperterminal open?). It might be a missing termination character on your data string. You could try monitoring your serial ports using "portmon" (or was it serialmon ? Just google it) while under use with VISA and with serpdrv. It might be poor design on the software.. without more specific info, (post your code), or more detailed debugging on your side (simplest serial comm that exhibits your problems) its difficult to play "doctor". Neville.

QUOTE(gsussman @ Feb 20 2007, 11:46 AM) Thanks for the tip!! Sometimes you can't see the forest for the trees. I had already modified the utility to backup my RT images. I can use the RT<->RT feature to move over software. You are right, you can't upload the image if the MAC address doesn't match. There is no way to modify this part of the code (behind a p'word protected VI). I suspect it is an anti-piracy feature to prevent copying the LV-RT runtime from a licenced target to an unlicenced target. Neville.

QUOTE(Val Brown @ Feb 19 2007, 05:10 PM) Hi, I have used serial VI's using VISA from LV 6.0.2 all the way through LV 7.1 with PC serial ports as well as USB-Serial adapters on a laptop. Some of the applications involved quite high data rates and ran for days on end (monitoring fuel-cell applications). I have never experienced the kind of instability you are talking about. What version of VISA are you using? There used to be a problem with version 2.6 (or was it 3.0?) but that was fixed ages ago. Like Brian mentioned, even starting LV 7, the "serpdrv" VI's were just wrappers on top of the VISA functions. They had already been "ripped out". So essentially you have been using VISA for a long time. Have you tried 1 A Different PC 2 A different USB adapter 3 A different version of VISA (earlier or later) 4 A different serial cable I don't remember what brand of USB adapter we used, but it was some cheap OTS unit that (thankfully) worked right out of the box. But if you do have issues with your USB adapter try looking to see if NI offers a product. It may not be cheap, but you are guaranteed it will work with VISA/LV. Neville.

QUOTE(Tom Eilers @ Feb 20 2007, 03:12 AM) Sure, I am using LV 8.2. Problem is with each RT as a separate target, you have to build the SAME application again and deploy it again for each separate target. Trying to do all this on the factory floor with a laptop and a wireless connection is quite difficult. It would be nice to have a two-button solution: "Build" followed by "deploy all". Neville.

Hi all, I have multiple RT targets (6). I am deploying the same executable on all 6 of them. Currently, I have the 6 targets set up in my project, and when making a change, I build the exe on one target and copy over the build folder on my desktop to the other six targets build folder. This is to avoid the loooonng wait involved in re-building the same application 5 more times... Then I deploy the exe by right clicking on each target.. a very slow and cumbersome procedure. 1 Is there a way to build and deploy simultaneously onto all 6 targets at once? 2 Is there a way to copy build settings from one target to another? 3 Can the OpenG build tools help with this? Thanks, Neville.

QUOTE(JStoddard @ Feb 16 2007, 11:46 AM) You mean "chart"? Neville.

You need to get the Application Builder, either separately purchased, or if you have one of the LV Pro packages, it is included. It is under Tools>Build Executable. Once you build the exe, you need to install the LabVIEW Runtime Engine, along with your exe on the machine that you want to run your exe on. The RTE needs to be only installed once, after that you can replace your exe or add others, and they should all run fine. Neville.