JackHamilton

Well that's an interesting question. LabVIEW can cast labVIEW data and cluster as XML and read them back. As XML is an 'open tag' architecture. LabVIEW will only support it's own XML tags. You can write a custom XML imported for labVIEW - as XML is just a string - you can look for special tags - extract them an converted them to numeric, strings, arrays etc via traditional LabVIEW methods. There is nothing really magic about XML - just think of it as a kind of ASCII text data/storage file. Regards Jack Hamilton

I discoverd this bug after a few hours of checking and rechecking a peak detection algo - using cursors to display the 'found' peaks in a graph. However, my algo was find points just before or after the peaks... :headbang: Well my algo was correct - I was chasing a bug in the graph cursor XY position property. As bewildering as the properties are there is a property under cursors a cluster called "Cursor.Position" who's elements are X,Y. I was wiring the data to that property only to find that although I input the X value of 0.0476 (in units of time - it's a waveform graph) LabVIEW was putting the cursor on the 0.477 index !?!?!. It can't be a rounding issue the number I input is much closer to the proper value then the one the graph choose on its own... Even reading back the Cursor properties immediately after setting it - showed it simply ignored my input value and choose the next X axis point over. However, there is ANOTHER property called "Index" expressed as integer for the X axis - wiring the index there - DOES cause the cursor to actually locate to the desired point. This is one of those times where a stupidly simple 'cute' features burns time like an x-wife on her spouses VISA card. Sheeze!!! Jack Hamilton

This is a very clever trick with some sample VI's on how to encode a live IMAQ image to a jpg string which allows you to send the image via TCP/IP. I've done this and get about 11fps via intranet. This is from the NI web site - but it's so neat, that I am posting it here for posterity. What I also did for performance was to scale the image to 1/2 before encoding to make the image size even smaller. Enjoy! Jack Hamilton TRANSFERRING IMAGES WITH DATASOCKET (TCP/IP) Problem: I am trying to send an image over a DataSocket connection in LabVIEW and the reading (client) VI is not able to display the received image. What can I do to correctly send the image? Solution: One key consideration in sending an image over DataSocket is that it is not really an image being transferred but a pointer to the image. This is why the client program in the transfer is unable to display a received image. A good way of getting around this is to flatten the image using the Flatten to String.vi and send the bit string over the DataSocket Write. On the receiving end, the string must be unflattened with the Unflatten from String.vi before being displayed in the image indicator. In this way, all the data is sent across the DataSocket connection rather than just a pointer. See the attached DSReader and DSWriter examples which demonstrate this. A related situation that may pose a limitation is trying to send grabbed images (continuous stream of images) over DataSocket. Sending the flattened data and trying to maintain a good fps (frames per second) rate can be difficult. Another approach is to apply some form of compression to the image. A lot of time can be cut off of the process by compressing the image into JPEG format, sending the data, and then uncompressing the JPEG into the image. Included below is a link that has an example program that demonstrates this. It utilizes a TCP/IP transfer method instead of the DataSocket, but the concept is the same. Download File:post-37-1113494557.vi Download File:post-37-1113494559.vi

Robert, I've had as many at 10 loops running at once. Most were performing discrete I/O. Analog wfm output, Analog input, DIO and counter/timer functions. I try to make each loop totally queue driven and completely 'detangle' control and display updates so each loop is actually a Sub-VI. This way I can choose the execution priority for each loop. I've attached a diagram snapshot of what this looks like. The flat sequences are to control the start-up sequenceing, some DAQ config functions can collide with each other. Some of the VIs are programs I've written some years ago like Queue driven RS-232 or TCP/IP. Regards Jack Hamilton

Dan, I know now the "Build wfm" is the function to use - I would challenge as to why "Wfm Attribute" would not be the most likely candiate? One could argue the t0 timestamp is an attribute of the wfm? That said - that was not my initial Bug report - your code even reveals the bug! Look at the start timestamp of the Array subset it starts the same time as the original wfm - even though its wire to extract the sub-set 10msec from the start!. I've posted this to the NI disucssion forums - and they come to the conclusion - its a bug!. You have to take the t0 - offset to and input that to get the subset start index to be correct. Thanks for your input on this. I miss the meetings too! Jack Hamilton

The index wavefore VI has two modes for indexing the wfm. 1. By index of point 2. "Relative Time" With Relative Time - you have to specific the time location to index - the bug is this must be ABSOLUTE TIME, meaning you can't wire 0.001msec - you have to take the T0 value and Add 0.001msec as the index value. :thumbdown: This does not at all correlate with the ring text stating indexing by "Relative Time" it's Asbolute time. Nag by Jack Hamilton The wabbit hole goes deeper, sample wfms don't have valid timestamps! See example code. Download File:post-37-1112650773.vi

Ouch!, That's too far back for me to save. 6i queues were different then... :thumbdown: The diagram is a state machine - so it won't print out well. Hmmm....

You can use the hard drive serial number and/or the MAC address of the network interface as a way to locking code to specific hardware/computer. There are some vi to read this in LabVIEW. Some on my web site. www.labuseful.com Jack Hamilton

But wait it gets much, much worse.... A few weeks later some of the Vision OCR functions would not work and other vision quirkyness occured. I turned out the installing of vision 7.1 and uninstall - corrupted the vision dlls. I had to completely uninstall all of LabVIEW and reinstall everything to get things back in working order!! Regards Jack Hamilton

Walter, I'm scratching cobwebs here, but I ran into a similar problem with LabVIEW and VB via TCP/IP - it turned out the 'lingo' is flipped between LabVIEW and the 'rest' of the world. Meaning try running the 'server' software on the LabVIEW side and the 'SERVER" software on the Linux side or vice versa. Yes, I know odd, but it discovered the problem when I have both my LabVIEW Client and server testing running with the VB app - and the reply from VB popped up in the 'wrong' window'! Regards Jack Hamilton

Kidd, Irene He has a very nice tookit called iVision - it's free or you pay a small fee. I just played with it today and it worked great - looks like it will support more than one camera. Also, it will save you lots of groping over the next few days...! find it at: http://www.geocities.com/irene_he/IVision.html regards Jack Hamilton

JP Sorry for coming in late on this. I've been using DAQmx awhile and am still new to it! Looking at your code - you've hit the marks - only comment - do you really want to 'start' the tasks immediately after configuration? I don't know your overall code, if it's a queue state machine. I do the DAQmx "Start" in the acquire state. Be wary of odd performance problems using Timed loops and DAQmx... Regards Jack Hamilton

The way to do this is to write a single routine who's job in life is to set the DO port lines.The way to control this 'function' (Vi) is by using messaging... I've uploaded an example program that is pretty near what you want. Regards Jack Hamilton Download File:post-37-1112162564.llb

MAH, The NEMA GPS Standard is a serial comm message that the GPS outputs like a heartbeat. Many "USB" GPS systems actually are USB to serial converters. To test this out - see if when you plug in the USB GPS - you get another Comm port showing in NI-MAX. If you DO NOT see this 'extra' serial port in MAX then they are doing something else... :ninja: It can be a royal pain the ###### to try to tiki to their DLL, or Active-X. You may want to look at buying a simple NEMA compliant serial GPS system, in lieu to dinking with this. You should re-search for "LabVIEW friendly GPSs" - or put up a post on info-LabVIEW. I never have more problems than trying to link software <-> software! :headbang: Regards Jack Hamilton

You can do this with graph cursors and some "Nan" array tricks. I've coded up a little demo - which you can download....Kinda fun . The example is written in LV 7.1.1. Regards Jack Hamilton Download File:post-37-1112162498.vi

Kid, Looking at your code - you've wired the same "uniqueName" into the active-X control . This would appear to want a unique name - so I would change it to something different than the other camera name. Other than that - that should work. Regards Jack Hamilton

If I read correctly, You want more than one program on the computer to access the same resource? i.e. the GPIB port? If that is so, what you really need is a single VI that controls the GPIB port, It would work like a train conductor. Other programs would send data and read responses via queues to the program. I've done this with RS-232 and had as many as 200 different VI's accessing the same serial port. I sat down and wrote that about 5 years ago - now I plop it on the diagram and voila! I have instant RS-232, I've likely saved myself 100's hours of programming time, by doing this once - and correctly. This may seem overwhelming difficult, but if you deconstruct it mentally, it's quite simple: Q1: What is the necessary data needed to send a data over GPIB? A1: The 'GPIB Address', the data in string format, A flag that this/if command gets a response, the response timeout in msec. Okay with those answers: It does not matter what data is actually being sent to where - the data types are the same and nearly any scenario can be covered. So in our GPIB Communication State Machine: we would need the following functions/states INIT, CONFIG,SEND, RECEIVE, SPOLL,QUIT INIT = runs at startup, creates the GPIB message queue acquires the GPIB card resource CONFIG = configures the GPIB device, termination, Dev number etc. SEND = Sends data to the GPIB port RECEIVE = performs a GPIB read SPOLL = performs a manuall GPIB Serial Poll QUIT = terminates the module We have a incoming Queue message that is a cluster that contains the following controls: 0. GPIB Command: INIT, CONFIG,SEND, RECEIVE, SPOLL,QUIT 1. GPIB Address string 2. GPIB Message (Data or command) 3. 0/1 response returned by instrument 4. Response timeout wait in msec (ignored if 3=0) 5. GPIB Termination (device specific) Now we have to add some more logic to this - so step mentally back.... The GPIB conductor - needs to know 'who' send the message so the response can be sent back. This can be done by adding a numeric value to the Queue message - you can assign each calling program a unique number. The conductor - will simply take the number and rebroadcast it with any response it receives. The receivers will know their own ID and process its own message. There are some complexities, for instance some GPIB instruments require checking stats registers after a command is sent, that easily handled - if you employ the concept of 'Public and Private Data'. To our GPIB conductor - he does not care what the command is, checking an instrument status register still involves sending a command string and reading a response, so our conductor does not really have to change the way he works to handle this. So how do you handle sending a instrument command, than then requires a second status check? Answer: You send two consecutive messages to the conductor. Your code that's written to handle that specific GPIB device - should have the logic and smarts coded in it to deal with that specific device. Don't contanimate the GPIB conductor code to handle odd exceptions - it will make it too complex. Also, you'll be able to use this code in other projects. One big advantage of code reuse - is you can perfect that code over time and have a very reliable library in your pocket. Regards Jack Hamilton

I am using the Rainbow 6.1x drivers in LabVIEW 7.1.1 with no problems. Although this thread is old, the topic remains of interest, I do check these old posts (when I remember ;-)) Regards Jack Hamilton

Yes , (but it depends! ) If you are using the NEW IMAQ Image display indicator - you can; via the property node = change the size of the live window. I've attached in VI that shows how to do this. You need to have LV 7.1 & Vision 7.0 Regards Jack Hamilton Download File:post-37-1109534409.vi

Rav, The term for what you want is called a "Splash screen". Like the graphic you see when you load LabVIEW. Attached is an example VI on how to do this with VI server. Regards Jack Hamilton Download File:post-37-1109533798.llb

Hayden, Look in the LabVIEW Examples : Search for "Binary" From that hit list open "Cont acq to file (binary).vi" also open "Display Acq'd File (binary).vi" - as this is the reader function. That example is about 90% of what you want to do. Although the diagram is cluttered - wrap a CASE Statement around the bin file write hooked up to your "record" button. Make sure in the False case you wire thru the File reference. That should work just fine. Plop a graph in the loop to view the data. If your speed and points are low - the graph & file I/O should keep up. Otherwise - you'll need to goto a multi loop architecture - one loop acquiring the data & saving - the other displaying the data. If you need more help - let me know. Jack Hamilton

You're thinking a la Excel? Well there is not a property node control for the MCLB to do this. You can acheive this 'effect' by simply taking the data table and removing the desired column of data and re-populate the MCLB. You only need to remove the selected column array when routing it to the listbox - you can keep the 'full' table in memory in your code. Jack Hamilton

Karthas, I need some more detail, but I can comment that computers are very fast and you can change your coding module to perform the control or 2 or 4 channels at the same time, in a round-robbin fashion. I've controlled 16 PID channels in one loop - typically, most physical evetns do not change on the msec range and the computer has plenty of time to monitor several things at once. Some details on what is going on in those loops would be helpful. Regards Jack Hamilton

Search the discussion forum here for "Encryption" you'll find some posts on this topic. one of which is mine. In general: Encryption wrappers don't work with LabVIEW as it's interpeted code. I've used the Rainbow Sentenial Pro key - they work well. I've done the whole 9-yards with them. Encrypted Algo's, demo counters and application installers that included encryption key functionality. I'd suggest you include the encryption key calls in your LabVIEW functions. Don't wrap all of test stand (besides you can't!) It only takes about 20msec to call the key and run queries to it. I've done key calls with every GUI keypress. That said it took me about a month total to wrap my head around: 1. How the key works 2. The developler interface software for the key (create algo's, burn keys) 3. Developing an encryption scheme 4. Coding the scheme 5. Redeveloping the scheme, recoding again ;-) 5. Mucking about with how to actually install the key drivers w/labview 6. Testing the key so it all works, when and how it should. 7. I had to totally rewrite the LabVIEW Drivers from Sentenial - they okay for rough & tumble on how to talk to the key. I'm in the phase now to writing a "License Manager'" with the option to enable a "Demo/evaluation" key to a full licensed version. Encryption protection is a huge industry and you'l find the documentation can be daunting. Also the documation is not clear - it's not suppost to be - as the security companies knows hackers read it too. ;-) I'd be happy to give pointers, or consult with you on that. It's not a trivial thing to slam in the code last minute. As I started learning more about the software protection - I've found it's not easy to come up with schemes that protect your software that are also easy to use, manage and are robust. You don't want your software shutting down on a client because the Windows date is off, or theres no internet connection. Regards Jack Hamilton

I will caution that multiple control stacking such as the picture control is cute - but will be problematic on complex GUI's. The picture control was a good way to create the "Hover button" effect. I'm not a big fan of Dynamic Events - mainly because I never had sleepless nights wishing they existed ;-). (however, I'm just not one of those who jumps on the latests thing - until it's been kicked around a bit) As I get older, It's becoming clear to me that readabiliy of the code is very important. More important than a clever method that may obscure the intent of the code. Anyone who's tried to pick up or be part of the project with lots of VI Server calls knows the potential issues with this. I chuckle abit at the shock of implementing a Pre-6i solution to polling buttons, my gosh that's all we had back then! Regards Jack Hamilton