Neville D

QUOTE (shoneill @ Jun 11 2008, 06:58 AM) Does Ghost4Linux work with other OS's as well? Do you have to run them from a Linux/Unix machine? Neville.

QUOTE (georgekm @ Jun 12 2008, 10:17 AM) Apart from a very snazzy icon, you seem to have done little else! Like I said before use a counter for measuring frequency, not a digital line. Look at the examples on counters in LV and search the NI website for "reading counters" or "reading encoders". There is some info there to clean up signals as well as using quadrature encoders. This is quite critical for a real-world application since, noise is very likely to corrupt your encoder signals, and using these techniques you will count the correct transitions of the encoder pulse (avoid reverse counts), and avoid missing pulses. As to your specific question: you can use an unbundle node on your digital waveform and that should give you: * the Y array of digital data * t0 the start pt * dt the time between successive pts. Then you can do whatever processing you want on the array; though I would imagine you just need to count the number of high values (N) and divide by (dt*N), so I don't really see the need for a "signal processing" VI..? Neville.

Hopefully you mean the software probe used for debugging. If so, the probe updates with data whenever it is available on the wire. If you are getting it every 10 s, then look at the sample rate of your code. Also post it so we can see what you're upto. Neville.

QUOTE (telamon @ Jun 11 2008, 11:22 AM) Don't edit the "complex" VI. Just read the data with this VI in a loop and use an expressVI (File IO>Write to Measurement File) to write data for now, to get you up and running quickly. Should be fairly straightforward even for a newby. Remember posting code of what you've done so far or a screen shot will get you a lot more help. Neville.

What hardware are you using? what is the frequency of interest? Show us your code. I would use a counter channel to measure frequency. Look at examples for counters. Neville.

QUOTE (Don_Corleone @ Jun 6 2008, 04:40 AM) See http://www.catb.org/%7Eesr/faqs/smart-questions.html' rel='nofollow' target="_blank">this Neville.

QUOTE (crelf @ Jun 5 2008, 09:48 AM) Well, if your using Vision you need a vision licence. If your using camera hardware you need an IMAQ licence. God knows if you use Vision Builder you probably need a licence for that too. Along with that the headaches of activation which is troublesome when your customers frequently don't allow internet access on-site. Most annoying is, if you build a utility that uses the IMAQ image display, to be installed as an executable, it doesn't work unless you install some licenced version of IMAQ (or a subset of it). Neville.

QUOTE (Chris Davis @ Jun 5 2008, 05:57 AM) I doubt he's going to need that many licences.. he's probably going to use a single PC to talk to those cameras so he would probably need one licence. But I do wish they would make it easier to use the Vision stuff without all the complicated licencing. Neville.

You need to load the latest version of the NI DAQmx drivers for those VI's to show up. Are you playing with an evaluation or student version of LabVIEW? Neville.

Without seeing your code, I have no idea, but what sample rate are you using? Neville.

Take a look at the Sequence.vi under examples. Acquire a sequence of images, and in a parallel loop, save images to file. Re-use the sequence of image buffers for the next set of acquisitions as each image is saved. Neville.

Coming to this a bit late, but there is also the issue of speed. Using property nodes instead of wires is the slowest approach. Wires (best speed) < Locals < Property Nodes (worst speed) Neville.

I seem to remember something about some dll called "tulip" that allowed NI Visa to talk to Agilent hardware.. this was a long time (10yrs or so) ago.. I think it came from Agilent, but check the NI Knowledgebase about it. I stuck with the NI stuff and was able to get Agilent hardware to work with it. Neville.

QUOTE (george seifert @ May 22 2008, 11:52 AM) Are you reading H/W timed? S/W timed? Are you reading both chans simultanously? Somewhere on the NI website there is an example showing how fast you can go with s/w timed loops and DaqMX, maybe you can go S/W timed and the two reads could then be separated into two loops (provided you don't expect too much accuracy on the timing and are not going too fast). Neville.

QUOTE (george seifert @ May 22 2008, 09:39 AM) Depending on your DAQ board, and the way you set it up: 1 Hardware timed (using the onboard scan clock) Uses a DMA channel(s) to dump data directly into computer memory without Processor intervention 2 Software timed (using a AI read VI in a while or timed loop) Reads the FIFO whenever you ask it to. The more expensive DAQ boards have multiple DMA channels for AI and AO. The multithreaded DAQmx driver is really good for the software timed reads/writes if you go that route. Neville.

QUOTE (george seifert @ May 22 2008, 05:15 AM) Yes its true, since most cards have only 1 FIFO and 1 sample clock, you can't do it. You can sort of do it, by sampling all the channels at the highest rate that you need (in a group) and then have 1 loop or VI that acts as a DAQ server with all the data available, and different clients sampling different channels at required lower rates. Neville.

QUOTE (Yen @ May 21 2008, 09:54 AM) The overhead is required for the packets to be received via TCP-IP and organized together to form the image, so I would guess it doesn't matter how many cameras you have attached, but depends how fast the images are coming through (frame rate). Since your system will be fairly static, you can also boost the performance by defining a ROI (region of interest) so that the camera only sends the pixels in the ROI. This limits the amount of data transfer, the size of LV Vision buffers used and improves overall speed and system response. I personally haven't used a Gig-E camera in a project since we use LV-RT on a PXI system, we are limited to Firewire only. If using a cheaper camera with jpeg output, make sure the image processing works OK with jpeg images before you start. The DCT transform used in the http://en.wikipedia.org/wiki/Compression_artifact' rel='nofollow' target="_blank">JPEG compression algorithm tends to have trouble with straight edges in an image. Let us know how it all works out! Neville.

I think Gig-E is the way to go, considering you can have cable lengths upto 100m (no need for an expensive fibreoptic FireWire extender), can use regular Ethernet hardware, and don't need any special cables. Downsides: 1 Gig-E cameras need externally supplied power 2 Gig-E cameras are not yet supported under LabVIEW-RT (which limits you to LabVIEW and Windows only) 3 5-10% of processor power is used to deal with the Gig-E traffic in acquiring the image before it can be processed. 4 You have to consider network traffic when all of your cameras are firing simultanously or if they share the network with other PC's. I have had good results with Prosilica FireWire cameras; they also manufacture Gig-E cameras They probably will do a volume discount as well. I don't know about "cheap". I doubt your going to be able to get a reasonable industrial camera for less than about $300-$500. And then you have to factor in the cost of the lens (another $100 at the very least). Maybe you can put all the gages on the same physical panel and use a single camera to monitor them all? Also, vision applications always suffer from feature creep; if you buy junky USB cameras, your soon going to have to discard them for something better. Neville.

QUOTE (neB @ May 16 2008, 12:59 PM) Yes. N.

QUOTE (eaolson @ May 16 2008, 11:46 AM) Like Chris pointed out use windraw to window#15 (another esoteric factoid), or else you can use IMAQ RT Video Out under the Vision RT pallet, which essentially does the same thing. Note that not ALL PXI's support this feature. I know the PXI 8187 Controller does (now obsolete), and NI is working on supporting this on a number of the new Dual-core controllers like the 8106. And no, this cool feature does NOT work if you set up a desktop PC as an RT target. It has something to do with a special VESA driver or some such that has to be custom-written for the hardware. Note that you can overlay boxes, lines, circles, ellipses, text etc over an image while displaying it (ie. highlighting a feature of interest for example); text display is limited to a single font type and size only though. (this can be changed, but that is a topic for another day). This is what we use it for: http://lavag.org/old_files/monthly_05_2008/post-2680-1210967791.jpg' target="_blank"> Neville.

QUOTE (Tomi Maila @ May 16 2008, 10:37 AM) You can send images with overlays to the monitor connected to a PXI system running LabVIEW-RT. It is a little known, but very cool feature. Dual-core PXI's don't yet support this feature, but a fix is in the works at NI (a beta driver is currently available if you really need it right away). The front panel of the application could be accessed via VI-Server/TCP-IP/Web browser to adjust params as required. Are you playing back a series of still images? Neville.

Post some code to better understand your problem. Neville.

QUOTE (bmoyer @ May 13 2008, 11:00 AM) A 16bit image that your working with. N.

QUOTE (bmoyer @ May 13 2008, 06:36 AM) Hi Bruce, try reading up Pg 2-2 of the NI http://www.ni.com/pdf/manuals/372916f.pdf' target="_blank">Vision concepts Manual. It has some info on mapping methods.. looks like you will have to pull data out column by column and manually apply a mapping function. This will probably be slow. Can you ignore the least significant bytes ? Can you also upload a 64-bit image as well? N.

Cast the image to RGB, using IMAQ Cast Image use IMAQ ColorUserLookup to manipulate the pixels in the three planes as you want, save the RGB buffer to file as a PNG. Manipulating pixels by extracting out arrays will be slow. it is best to work with the canned IMAQ functions that don't extract data out into LabVIEW, but deal directly with the image buffer(s). Neville.