jdunham

I am specing out a test system and planning to replace the oscilloscopes with NI PXI instrumentation. However, the technician who will be using the fixture wants to be sure he can troubleshoot the devices. He's a bit reluctant to give up the oscilloscopes, and I can't blame him. Will NI's Signal Express make him happy as an add-on to the LabVIEW system which will be needed?

QUOTE (Ton @ Mar 6 2009, 09:01 AM) Fantastic, thanks!

OK, Thanks guys. I got thrown by the built-in comment QUOTE I thought that would mean that the Data Changed event case would get executed, but now it makes sense; you never get anything for free. I had read the wiki page, but if your understanding is broken like mine was, it doesn't point you back in the right direction. I'll add some text if I can figure out what would have helped me. So the underlying issue is that, for the control I'm really working on, any number of things can happen, and I just want to repaint the whole display whenever the data changes or the state changes or any of the auxiliary facade controls change. Where is the best place to put that code such that it's easy to invoke it from various points on the facade block diagram?

OK, so I wrote a very simple (and useless) XControl. All it should do is take a numeric and copy it to a string. From the fresh XControl, the only thing I changed was Facade.vi. I added a Value Changed event for the numeric, which transfers its value to Data Out, and sets Action.Data Changed? = TRUE. I dropped the XControl on a new VI, and changed the numeric. I was expecting the 'Data Change' event to fire right after and update the string value, but the 'Data Change' event never executes. I feel like I'm missing something obvious...

QUOTE (orko @ Mar 5 2009, 10:21 PM) Well remember, all the IMAQ stuff is by-reference (this confused the hell out of me the first time), and images are big and copying is relatively slow, so the whole system is designed never to copy an image unless you force it to. Just about all the functions operate in-place by default. So the idea is that you wire your image to manipulate into the Source input, and leave the Destination unwired, and the routine modifies your source. Sometimes you want to preserve your original image, so you create a second image and wire it into the Dest, and then you have the before and after, but it's pretty rare to need this. QUOTE (orko @ Mar 5 2009, 10:21 PM) So if I'm understanding this correctly... how then would I replace the pixels in the RGB image with the non-masked out pixels in this new Masked image? Man, I know this is a very basic question, but the "ah ha!" switch is not quite closed yet... So the normal thing is to put your original RGB image into Source, and your 16bit image into Mask, and the result should be an altered version of your RGB image with some pixels preserved and others zeroed out. OK, I think what you want is a bit more complex that the normal mask. Let's see... Do I have it right that the only part of the RGB image to preserve is places where the mask is zero, and everywhere else, you want the to keep the grayscale values in the 'mask'? I think you could invert your mask with the IMAQ Compare, and then that is your mask you apply to the RGB image. At that point you should just be able to IMAQ Add that to the grayscale image, since no pixel would be non-zero in both images.

QUOTE (Raymond Tsang @ Mar 5 2009, 12:54 PM) I sent you a PM. If you are interested I can help you get it working with a garden-variety DAQ card. Cheers, Jason

It looks to me like you have your Source and Destination images backwards in the IMAQ Mask function. If you do wire a destination, it will be overwritten by the operation. Since you never put any data into the source, all you see is a copy of the mask in the output. For most of the IMAQ functions, you don't need to wire the Image Dst at all, and you just modify the source image.

Haven't played with IMAQ for a while, but this operation is called a 'Mask', and there are definitely IMAQ routines for that. You may need to make an intermediate mask image in which all of the non-zero pixels are set to 1.

I think most LV developers handle this by not using the STOP functionality. A 'normal' application hides the toolbar (since nothing on the toolbar has meaning to non-LV users), runs when opened, has some LV-implemented buttons for starting the user's tasks, and remains running until the user wants to quit the app, at which time the Exit LabVIEW function should be called. Users shouldn't really be expected to tell the difference between 'running' and 'loaded but not yet running'. It's your job to make sure that the built app never gets into the latter state. Pretty much no other program they will use on the computer has that behavior, so they find it very confusing. It doesn't really require much extra code to accomplish this.

QUOTE (mesmith @ Mar 5 2009, 10:05 AM) I have some wrapper VIs which invoke the SVN command-line client via System Exec.vi. I guess I should open-source them, since they are pretty simple. I'm sure other heavy SVN users have something similar. Jason

QUOTE (dblk22vball @ Mar 5 2009, 08:35 AM) I still think you should look at Subversion. It was designed for source code revision control, but basically it's a system for maintaining a synchronized collection of files. It has a built-in local cache for each client (all useful SCC systems have this) and it only updates sections of a file which need updating.

QUOTE (crelf @ Mar 5 2009, 08:01 AM) Unless it's super-slow, I think Chris is right, just get the files from the network. You can cache them locally so that if the network is down, you can still run a test. If access is slow, you could have a version number in a single file (versioning your test specs is a good idea anyway). Each tester would remember its current version number, check the version number on the network, and then if they are not equal, get the updated files from the network drive. At that point you could just keep the versioning for each specific file. But then you'd have a poor-man's implementation of Subversion [smell the irony?], so you should just convince your IT group to put the real Subversion on the server. In that case you'd just run a simple svn update before executing any test.

QUOTE (LVBeginner @ Mar 4 2009, 11:18 AM) Yeah as soon as I asked, I thought of a half-dozen things I might want to do programmatically over HTTP. In our own app, we do some of this, and we use the ActiveX Object "WinHTTP", which is part of Windows. It handles proxy servers and lots of other stuff and makes a lot more sense than rolling your own. Unfortunately as a "LVBeginner" you probably didn't want to muck with ActiveX right away, but I think it would end up being a better use of your time. There is also some .NET equivalent which is totally different but I don't know anything about that. It might be easier to use.

QUOTE (LVBeginner @ Mar 4 2009, 11:09 AM) By the way, what are you really trying to do? It seems likely that your proxy config only affects port 80, and no one in their right mind writes a program to implement the HTTP protocol in LabVIEW when there are other free programs which do a far better job of browsing the web.

QUOTE (LVBeginner @ Mar 4 2009, 10:55 AM) Well that's good, you've learned that this is not a LabVIEW problem. Is your web browser able to connect? In your web browser's advanced settings, is there a proxy configuration? Presumably if some of these are non-standard, then you have an IT department which can help you more than I can. Good luck.

QUOTE (LVBeginner @ Mar 4 2009, 09:55 AM) Generally the firewall is for incoming connections, unless your IT department is super-restrictive. Nobody can get any work done if they block port 80, so that is usually not going to be filtered out. On the client side (that's you) there is no ability to filter specific programs out. Since that's true, the next thing to do is to open a Windows Command Prompt (Start -> Run -> CMD) 1. ping the server to make sure you can resolve the address (of course sometimes servers disable ping, but www.w3.org does not) 2. telnet to the server and type the your message. I entered "telnet www.w3.org 80" and then I typed in your GET statement, and it spit a bunch of HTML back at me. 3. try the same thing again in LabVIEW. Your program is basically doing the exact same thing as telnet. Be sure to note exactly which VI or function is throwing the error. Note that you may have to install telnet, since that's part of Microsoft's policy of burying all the really useful stuff or not installing it by default. QUOTE (LVBeginner @ Mar 4 2009, 08:47 AM) Now I can't get the TCP Open Connection function to open a connection. I get error 56 which is timeout error. How are you getting a timeout from TCP Open when you have the timeout = -1 (forever)? It seems more likely that you are connecting, but getting a timeout in TCP Read, since you are asking for 100,000 bytes in Standard mode. You may want to try Immediate mode. The help file has more information about TCP Read and its modes.

QUOTE (LVBeginner @ Mar 4 2009, 08:47 AM) Well port 3363 is the VI Server port, which is specific to LabVIEW. It's highly unlikely that www.w3.org would be listening on that port. Try port 80. QUOTE (mesmith @ Mar 4 2009, 09:18 AM) TCP Open Connection won't do a domain name lookup for you and resolve the address - put the IP address of the server in the address box and try again Totally untrue.

Well with Web 2.0 companies getting hundred-million-dollar investments, it's certainly worth the effort of a few blog postings and press releases to jump on the bandwagon.

QUOTE (bsvingen @ Mar 3 2009, 11:52 PM) Daklu's version is a lot more sensible, though he's got a dynamic dispatch input on "Test Data.vi" which is probably not what you'd want. I only make that point because the original code had several VIs with a dynamic dispatch input and a specific child class output, and I think that would almost always be bad news. I didn't quite understand the original posting about the 'pregnant' probes. There are no 'hybrids'. All child classes contain the parent data as well, but you seemed to be talking about a parent class containing the child data. The parent wire can hold a child object, but you won't see the child private data in the probe. Anyway, I recommend adding some different data types to the three child private data classes, and then the probes make more sense. I would also highly recommend upgrading your LabVIEW, since the LVOOP code has a few major bug fixes between 8.2 and 8.6.1 AFAIK.

QUOTE (Raymond Tsang @ Mar 2 2009, 02:55 PM) What about C:\Program Files\National Instruments\LabVIEW 8.6\examples\DAQmx\Counter\Generate Pulse.llb\Gen Dig Pulse Train-Finite-Retriggerable.vi It uses counters instead of DIO, but it might get the job done.

QUOTE (crelf @ Mar 2 2009, 02:24 PM) Well I would think it really is the responsibility of your class to figure out how to transform itself for file reading and writing. This is called Serialization (sorry if you already knew that). If any other code knows how to serialize your data, then you've broken encapsulation because that other code has to know the structure and contents of your object. QUOTE (Cmal @ Mar 2 2009, 02:50 PM) If you have a chessboard object, and its private data includes objects of other classes, then you could simply wire the chessboard object to a datalog file. When you read from the datalog file, it will load all of the data that was saved, including the other classes included in chessboard. Datalog files work really well with classes. I may not have completely understood your question, so let me know if this is what you are looking for. Remember that if your private class data is ever changed, the datalog file functions have to try to figure out how to map the old data into the new data. I would read the "Mutating Data" section of the LabVIEW Help Files before deciding if you want to use the built-in functionality, which seems quite powerful, but also seems like it might not be safe enough for a big multi-developer project in a production environment. I would just write a "Serialize as XML Fragment" method for each class (and the Deserialize method too) and then test the bejeebers out of them, especially if you have to change the data type. Even if you do use the built-in datalog functions, I think you should only call them from methods owned by your class. Then at least if you run into problems, you have a way to track down all the places where it might be happening. Jason

QUOTE (rpscott02 @ Mar 2 2009, 01:44 PM) 1. Right-click on the property node and choose "disconnect from control". 2. Right-click on your control and choose Create -> Reference. This reference can be wired into the disconnected property node. 3. Select the property node (but not the reference) and choose [menu] -> Edit -> Create SubVI... 4. Use the SubVI as needed.

QUOTE (Mark Yedinak @ Feb 27 2009, 01:01 PM) Right. Your code checks the number of bytes right after the write. Note that that Write does not guarantee that those bytes have reached your instrument. In fact all that happens is that the bytes are delivered to the serial hardware driver running under windows, which delivers them to the UART chip attached to your motherboard which puts the bits out on the serial TX pin. Your outbound message is about 20 characters, and it's 10 or 11 bit-times per character, so at 38400, it's going to take 5ms just to send out the message on the TX pin, not including the driver stuff before that (which is probably plenty fast). So then your target device has to receive that data, be sure that it's over, process the command, and send some response. If all of that happens within 25ms, then it's a pretty fast device. No way it is going to be faster than 10ms. So your code checks the number of bytes answering right away, long before the message is even starting to transmit, much less getting a response back. try to add a 100-500ms delay in a sequence structure right between the read and the NumBytesAtPort and see if you get some improvement Good luck.

It looks to me like you are reading back too fast. I don't think you're giving the other unit time to respond. I normally poll the bytes at port until it is non-zero and then read everything there. It's kind of lame that NI doesn't include this in their library. Some instruments can't accept the next command until the first reply is sent out. You don't mention what the symptoms are except that it "doesn't work right" and you say how it should work. Anyway, if you don't feel like adding a polling loop, just add a half-second delay between the write and the read and see if that helps. Good luck.

QUOTE (Antoine Châlons @ Feb 27 2009, 12:17 AM) Great minds http://forums.lavag.org/New-wire-type-the-Null-wire-t13407.html&p=59072#entry59072' target="_blank">think alike!