Neville D

I don't have any answers to your questions, but in general I find VI Server calls to remote targets a bit flaky. Sometimes they seem to be ignored by the target, generating errors. Especially if you have a bunch of them sequentially. Example: I want to open a remote panel of the top-level VI on an RT target. Trying to query top-level remote VI's name works most of the time (about 75%). At other times it will generate an error (that doesn't mean anything). Anyway, I agree, all your questions are very relevant. Hope there are some answers out there.. Neville.

Read this

In addition to all the other excellent advice that has been posted: If you are driving a relay with a DAQ device, make sure the DAQ device can provide enough current to drive the relay coils. Also put a diode across the relay to prevent back emf from destroying your DAQ. Neville.

QUOTE (george seifert @ Jan 13 2009, 08:19 AM) OK.. well thats progress.. of a sort. My only reason for asking about priorities was that I thought you were NOT supposed to give timed loops the same priority. You need to pick a slightly different value for each one; don't remember where I read that.. anyway, you have got the error with different values as well. Sorry don't have any other helpful suggestions, just that I always found timed loops to have weird issues in the past and have steered clear of them ever since. Neville.

Take a look at this Neville

Are the priorities of all your timed loops set to different values? Neville.

Don't have any specific info for macs, but you could just rename your exe as *.1.exe, *2.exe etc and run them separately. Its a bit of a kludge, but should work for now till you find something better. N.

QUOTE (Vikers @ Jan 6 2009, 02:25 PM) Good! QUOTE (Vikers @ Jan 6 2009, 02:25 PM) Some of the sub VIs are complaining about bad terminals and such. When opening apps developed in 6.0 with 8.2 is it typical to find a few small incompatibilities in the VIs? Are they NI VI's? NI generally does not change their own VI's connector panes. If they are VI's written by your team, then it is possible that from LV version to version there are minor changes in functionality; things like the datalog format or in some cases, an unwired boolean is hidden on the front panel on upgrade and you are warned about it. In each case, read the LV upgrade notes for that LV version carefully. These are well-written and will point out all changes wrt your current and final upgrade version. Just deal with each message in your own context. Ignore it if its trivial, deal with it appropriately if not. Neville.

Get your drivers CD for 8.2.1 and then install support for Traditional DAQ (which is not installed by default with the newer versions). It should have all the traditional DAQ VI's there, and the VI's will open up fine after that. You might also look on the web for it and download from the NI site. N.

There is an app note on NI site somewhere that talks about using a debouncing chip with quadrature encoders (thats the ONLY way you can make it work in the real-world). N.

Hopefully you still have a backup in the previous version. Sometimes when upconverting, some indicators seem to get corrupted and have to be replaced with one from the new version. In the past, I have had to replace the IMAQ image display in all my VI's because the upgrade (frm 8.5.1 to 8.6) and saving to the new version would cause LV to crash on opening the newly saved VI's in a project. Maybe you can figure out by building a simpler part of your main VI and see if that goes smoothly; if not then find out which VI is causing the build to fail. I can't remember how I isolated the IMAQ display as the culprit, but replacing that with a new one caused the VI's to open and build to work. How about toolkit VI's? Have they also been upgraded (if you are using any of them). Look through your project paths and see if any of them are pointing to older versions of VI's in some other folders. Make sure your project isn't referencing any VI's in the 8.2.1/vi.lib Try deleting the build spec and making a fresh one. Another thing: I remember reading somewhere that its recommended to keep the size of the exe down below 10MB. Maybe you can change your build to store VI's in additional llb's instead of within the single large executable. Neville.

Try some of the example programs. If they work, then make sure your code has similar constructs i.e open camera session, wire the camera (IMAQ session) to all other subVI's then close the camera session. When you say "working program" do you mean another LV program or some other camera manufacturers' application? Invalid session ID might occur if you are trying to use a IMAQ session value that has not been opened (or another one exists from before that has not been closed). Post some code, its hard to diagnose otherwise. See this. Neville.

QUOTE (Antoine Châlons @ Dec 19 2008, 07:47 AM) Code runs fine in LV 8.5.1 and 8.6 and under RT as well for both versions with diagram disable. I have a strange bug where one of the IMAQ VI's causes an RT build to fail, so I have diagram disabled that VI (since it is not used currently in the code). Bug has been reported to NI. N.

QUOTE (Ernest Galbrun @ Dec 18 2008, 10:57 AM) This should be fairly easy to do, since most NI boards provide a 5V line you can use for supply, and an Analog Out line you can use for control. If you need 10V supply, use another AO line with output set to 10V constant. I have used a little board put together by some technicians at one of the places I worked in the past. Unfortunately don't remember any other details apart from the above. N.

There are PWM chips out there (I can't remember the P/N) that will modify the duty cycle based on an analog input 0-5V. They are fairly easy to use, and make your software a whole lot simpler. N.

QUOTE (shoneill @ Dec 18 2008, 09:17 AM) You CAN'T use LabVOOP (by value) in LV-RT. You CAN use 3rd Party "by-ref" OOP toolkits with RT. PS. I don't use either in my projects, but I thought I'd throw it out there for you guys to gnaw on.. N.

I've used this module before in the distant past. What Slot0 controller do you have in your chassis? The driver from NI assumed an NI controller if I remember right. Just read up the module info and try to send it simple SCPI command strings first before you try anything more complicated. You should be able to hear a small click as the reed relays inside click on or off. I used an HP GPIB controller, and after some fiddling around was able to make it all work. I had to program the individual registers to get the open/close combinations I needed; can't remember if I used the NI drivers. Neville.

QUOTE (tarek316 @ Dec 15 2008, 12:50 PM) From the documentation, it looks like if its a strict type def it will not update when you write to the Strings Property. Are you sure it even works in development mode? Neville.

QUOTE (jdunham @ Dec 11 2008, 08:14 AM) Under your Project, right-click on the My Computer and enable VI Server from there. Then try the build. Also, just to trouble-shoot Firewall problems, try to access the exe on your desktop host itself and see if that works. Neville.

Read this. N.

QUOTE (Maca @ Nov 23 2008, 04:27 AM) Infact, NI researchers already have working LV code using CUDA on NVIDIA processors for high performance applications but I don't know when they will be officially releasing it. Here is an excerpt (see last para in the link): In addition to the Dell proof of concept, a prototype in which NVIDIA'sCUDA technology enables LabVIEW has been thoroughly benchmarked with impressive computational results. QUOTE (rolfk @ Dec 6 2008, 11:50 AM) However the biggest draw back I do see is the fact that I haven't owned an NVIDIA powered computer in all the time so far. Sort of makes such a solution very narrow scoped in terms of possible deployments Sure, thats how NVIDIA hopes to increase sales..!! BTW MACs use NVIDIA graphics (in addition to INTEL integrated graphics) so potentially this could increase performance on MAC machines in the near future as well. Anyway, I think its a good direction for processor hungry applications like Vision or control. Neville.

QUOTE (JasonXCX @ Dec 5 2008, 11:44 AM) Yes, for PCI daq cards, the ground reference is the PC ground. For ground loop problems, I would always recommend using a DAQ card with isolated inputs. They take away all the headaches of ground loops and high common mode voltages etc. and are well worth the extra cost. Alternately, you can add isolation to PCI DAQ cards with additional NI hardware. Look at the 5B series of NI products. N.

If your asking if the USB DAQ measurements are with respect to the building ground (earth), I think not. If I remember right, the DAQ channels are considered to be isolated from this ground. Which is as it should be, since if you run your laptop off the battery, then where would "ground" be? N.

QUOTE (kondratko @ Dec 4 2008, 07:04 AM) True, the display is a nice additional feature. I have used Omega temperature units in the past with an analog O/P for the temperature (0-10V) so that I had a panel meter with alarming, as well as the ability to read in the analog input into LV via a DAQ line. They were a real @#$!@#% to program though with what looked like a single 3 page manual designed to handle what looked like a hundred different flavours of the meter and 3 programming buttons. I think the 0-55C is probably the storage or operating temperature range of the E-NET device and NOT the measurement range of an attached thermocouple. The type of thermocouple determines the temperature range (i.e J-type, K-type are the two most commonly used). N.

QUOTE (Shazlan @ Dec 3 2008, 03:23 PM) Yes, but you still haven't answered the question: did you try the camera+hub with the camera mfr software utility? This will rule out whether the hub works or not. If hub works then its a MAX (NI) issue. If hub STILL doesn't work then its a hub issue. N.