Jump to content

Neville D

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Neville D

  1. QUOTE (amila @ May 8 2009, 02:08 PM) Build the arrays any way you want. Run through the arrays with a FOR loop and discard any pts that you don't want.
  2. QUOTE (amila @ May 8 2009, 05:52 AM) Well, just check first if you have 2 or 4 edges. Use a case structure to selectively build the arrays based on each case (with the build arrays inside). Or Make a cluster for each edge: {Pt1[x,y], Pt2[x,y], Mid-pt[x,y]} and output the cluster at every iteration where an edge is found. Then you have an array of clusters with the solutions inside. N.
  3. QUOTE (Götz Becker @ May 8 2009, 01:20 AM) Couple of comments: 1) I get the deployment errors as well (when there is a built exe set to run on startup and it is stopped, OR when the ini file specifies some startup exe that is not there). But I generally hit OK on the error, and then click on the RUN arrow again, this time it runs fine. No need to reboot, or restart LV. Its annoying, but I can live with it. 2) I have a quad-core desktop as RT target, connected over Gigabit Ethernet to my development PC (quad-core Windows desktop 2GB). I suspect your laptops are 100MB/s slowing down the deployment considerably. Also laptops in general seem to be MUCH slower in development mode than a desktop. When visiting customers, I use my dual-core 2GB laptop and its definitely slower to open the project/open the VI/download the project/build and executable. Probably due to slower hard drives and slower ethernet on the laptop. 3) I find that if I open the VI's I want to debug and set probes on them, then deploy, things go smoother. 4) What version are you using prior to LV-RT 7 and targets like cFP, CVS etc, deploy/build was quite painful but with the newer versions (and with fast targets with lots of onboard memory) things are a lot better. QUOTE (Götz Becker @ May 8 2009, 01:20 AM) Using probes often leads to a local LV crash which means loading everthing again (opening the project alone takes about 2 minutes with SCC disabled). Memory leaks usually not a problem and if we suspect something we log the CPU/Mem status over night in a TDMS file. Our PXI targets are 8106/8130/8108/8110 and the development machines are all dualcore notebooks. Hmm.. what kind of probes? I use custom probes (consuming lots of memory) of arrays of complicated structures, as well as image display probes (custom and standard), and various flavours of history probes with seldom a crash. How much memory do you have on your targets? I have 2GB on my quad-core RT (ETS), and 512MB on an older PXI-RT 8187 and they both generally run fine, but of course everything is slower on the single-core 8187. Do you have very high sample-rates or thread starvation issues on the RT? Maybe its too busy and can't deal with the debugging updates, I dunno. I usually add one of these into the main loop to get an idea of CPU loads: And throw in a plot on the main VI so I can look at the front panel with VIServer: Neville.
  4. There is no way (that I know of) that you can manually select an annular triangular ROI manually over an image display in LV Vision in a single easy step. You can select a circle, oval, annulus (tire shape) rectangle, rotated rectangle. You can select the triangle itself by using the Polygon Tool (don't use the Closed Free hand Tool, the adjoing lines won't be straight). You can write code so that the user first selects the outer triangle, then selects the inner triangle, and you form the resultant ROI as {Outer-Inner}. N.
  5. Maybe you can build an express VI? those can be resized and are meant to be functions you build for others to re-use. N.
  6. QUOTE (jdunham @ May 7 2009, 11:04 AM) I'm assuming you know about using the compound arithmetic primitive and using "negate" on an input (changing multiply to divide and add to negate)? Its not "simple" but pretty flexible (any number of adds/subtracts in any order).. http://lavag.org/old_files/monthly_05_2009/post-2680-1241723903.jpg' target="_blank"> N.
  7. QUOTE (Karin @ May 7 2009, 12:00 PM) You can save the avi on the compact flash memory on the CVS and ftp the file later (programmatically or manually). QUOTE (Karin @ May 7 2009, 12:00 PM) How can I (through the LAN) get a boolean output from the the CVS and triggier a Digital out port on the the C-RIO? I have tried using a global variable and run the vi's on the each devices, without any result. Did you know that the CVS also has digital lines that you can control? Maybe you don't need to communicate to the cRIO at all. Global variables are valid for all the code on a particular platform. Try using shared variables. Look at examples. They are easy to setup and are a first step to communicating between different NI hardware or between NI hardware and a PC (running LV code). Neville.
  8. Your question is not very clear.. do you wan to select it manually, or want to detect it programmatically?
  9. QUOTE (neBulus @ May 7 2009, 09:51 AM) Yes, and you can monitor memory usage using the Real-Time System Manager found under Tools>RealTime Module>Syst Manager, though when the remote system tends to run out of memory, one of the first things it does it stop communicating with the System Manager.. but you can trend the memory increasing if there is a memory leak of some sort. Neville.
  10. I'm not clear what your trying to achieve. Are you processing the images on the PC? If the camera is connected to the CVS, you cannot use it directly with code on your PC. Process the image on the CVS and transmit the result to the host (PC). You can however, run code on your PC that is pointed to the CVS. i.e in your Project folder, if there is code under your CVS target, you can open and run the code in the development environment. This mode is for debug and will be slow for the CVS since in general they have very little memory (128MB max I think?). If you just want to display the image, connect a 1280x1024 monitor to the CVS, overlay graphical (lines/circles etc.) or text information on the image and display this on the remote monitor. If you want to use the data from the CVS, you have to set up a mechanism to acquire the image and transmit it (or the result) to the PC via any number of communication mechanisms: shared variables/TCP-IP/UDP/FTP. Look at examples for these. Neville.
  11. My guess is about 30% more time. In general its quite easy. Develop the application for windows, try to minimise use of property nodes & too much UI flim-flam (pop-up config windows, subpanel VI's and such), and you can port the exact same application to RT with a minimum of fuss. I have a vision application that started out windows-based and then was ported to RT. If you have a target with lots of memory (like a PXI controller) then it becomes easy to run the code directly on it for debugging (in development mode) without needing to build executables. Also, you need to add additional code to log errors/state transitions etc. for debug, and specific code to check file paths for development mode and executables, but then I would assume you already did when you developed the windows version . Neville.
  12. What NI components have you added to your installer? Try building an installer with no additional NI components. Then add NI components one at time to see which one of them is causing a problem. Sometimes adding installers for components that need a runtime NI licence like Vision components for example, might cause problems (but it does generally work). Have you built an executable for your code already (this needs to be done before you build the installer). If all else fails, make a new build spec (leave the old one) and try afresh. Neville.
  13. QUOTE (Roger Munford @ Apr 22 2009, 02:18 PM) Roger, I seem to remember when I was using SCXI modules that the calibration (gain and offset measured across an internal accurate resistor usually) were re-adjusted depending on the modules used. So you would have to check for your specific hardware. Call NI. I was measuring very lo voltage values from a current shunt on an isolated channel and needed the mV values to be as accurate as possible. For the modules I was using, the gain and offset was corrected at start of the DAQ task. If you kept the task running (for 3 months) then it would NOT be corrected in between. If you restarted, then it would be corrected. However with the old DAQ (not DAQmx) there was a way to manually force the re-calibration when required, but this of course obstructs your data stream while it goes and does its thing. Also with newer modules R-series (or is it S-series?) the calibration is no longer two point but a series of pts with a second order curve fit. So its best to check with NI on your specific hardware. Also, once you have the calibration parameters and using Raw mode, you should be able to duplicate the values coming out of the DAQ device when using calibrated mode. Neville.
  14. I would also look at similar instrument drivers from the same manufacturer as a good starting point to modify. Many instrument classes from the same manufacturers share commands and have similar structures. So try to find a driver of a similar instrument, try it out and go from there. Neville.
  15. The LabVIEW driver will usually have the most commonly used commands. For something not in the driver, you will have to write it yourself. Check the SCPI commands in the manual for your instrument to automate the command(s), make a copy of some basic command VI that you already have in the driver, then modify it with the new command strings. Shouldn't take you more than 30 mins to an hour to have something working. Neville.
  16. QUOTE (ShaunR @ Apr 13 2009, 12:32 PM) True, but you are paying for the ruggedness and ease of use of the platform (hot pluggable modules etc.) if your application demands it, then its worth it. I have used Fieldpoint to develop a Hydrogen fueling station for fuel cell industrial vehicles. It worked flawlessly even at 1 degC (parking lot outside in fall). QUOTE (ShaunR @ Apr 13 2009, 12:32 PM) DO NOT GO WIRELESS!!!! (especially if you are in an industrial environment) unless you really have to. There aren't many pro's but shedloads of cons.Wires don't drop connections and interference is rife in the 2.4GHZ band. Also solid structures (like walls, cabinets and even people) attenuate the signal immensely. Just search the net for problems people have getting a signal from one side of their house to another let alone 200m!. Again, your mileage may vary but I regularly use wireless connectivity to view camera output for alignment and calibration in a vision application in a saw-mill. The distance to wireless node is about 50m through lots of steel walls with no problems. I get about 9 frames/s but thats good enough for my application. This is using a regular laptop with 802.11g with commercial OTS networking hardware (nothing fancy, custom or expensive). I guess the ultimate choice of hardware depends on needs as well as budget. Neville.
  17. QUOTE (postformac @ Apr 11 2009, 09:50 AM) Check "Hide Trailing zeros" in the menu shown above in another post. Neville.
  18. QUOTE (flarn2006 @ Apr 10 2009, 04:20 PM) I'm not sure what those are, but if you want to monitor performance parameters like Processor usage etc. there are already VI's on NI's website that use .NET calls to achieve this. http://zone.ni.com/devzone/cda/epd/p/id/5405' target="_blank">Performance Monitor Neville.
  19. QUOTE (hfettig @ Apr 10 2009, 08:56 PM) For the remote DAQ devices if you want ruggedness & a nice DIN-Rail mountable form factor, you could go with compactFieldPoint, which is not fast and has a lot of useful features like onboard datalogging to compactFlash, range of processor options etc, and of course programable and running LV-RT. If you don't care about ruggedness or form factor, you could use a regular PC in ETS mode with PCI NI DAQ cards, and running LV-RT. You will need to check that the ethernet chipsets are supported for ETS mode, and that your DAQ cards will run on LV-RT (some older ones don't) but apart from the initial headaches of selecting and setting it up, it will run just as well as any NI LV-RT target. This has the advantage of being very fast, fairly cheap (you need an LV-RT runtime licence) and equipped with Gig-E support as well. If you want to go really fancy, you might use the new NI wireless DAQ modules..? Neville.
  20. The OpenG array toolkit has a VI that can sort 2-d arrays (of any datatype) as well. You will need the most-excellent VIPM from JKI to download the toolkit. N.
  21. QUOTE (crelf @ Apr 8 2009, 10:16 AM) True Chris, but it doesn't address his question of how to install software updates on remote targets like cRIO's. Currently it can only be done through NI-MAX>Remote Targets>Software> and then selecting the software version to update. N.
  22. QUOTE (manojba @ Apr 7 2009, 11:18 PM) Ultimately you have to evaluate whether the user will actually go to those lengths just to use your evaluation software longterm. Imagine having a production test system and having to manipulate the system date every two weeks just to use some software messing up other applications like databases, spreadsheets etc..! What is it you are writing that is going to enthuse your users to cheat on paying you? N.
  23. QUOTE (Matthew Zaleski @ Apr 8 2009, 07:53 AM) Yes, we have exactly the same concerns with our PXI-RT installs at customer sites. I would contact JR.Andrews AT ni.com. He and his team have been working on the System Replication tool to work out these issues (duplicating MAX functionality programmatically). They have plans for improvements, but emailing him your concerns will sure get the ball rolling faster. N.
  24. Its probably corrupted. llbs can sometimes be corrupted. There is no way to retrieve the VI's inside. Go back to a previously saved backup if you have any. Moral of the story: it is better to use folders than llb's. There is no reason nowadays to use an llb. In the bad old days of Win 3.1, the llb's allowed you to name your VI's longer than the 8.3 file naming convention, but that is not the case any longer. You can right-click on an llb and convert to a folder of VI's (I think). Sorry! N.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.