JackHamilton

I saw the same thing when I installed my Vision 7.1. It gets worse! When I complied the application and ran it (on the development machine) it got a dialog stating: "This is an unlicensed Version of Vision 7.1,...would you like to connect to the internet and obtain a license?" So apparently it can license an exe built application? huh? Welcome to the world of the NI License manager - where licensing is MORE important than the application running. As vision 7.0 is pretty much the same as 7.1 - I uninstalled Vision 7.1. Regards Jack Hamilton

I've seen that too. :headbang: My working around is add spaces AFTER the desired text and be SURE to put a period ( . ) at the end - the cursor ignores trailing spaces. Most people don't even notice the period floating off the to far right. Also, by default the first letter of the cursor test is slighty cut-off - I put a space before the text to fix that (you don't need a leading period) Regards Jack Hamilton

A recent info-LabVIEW post asked about detecting the 'final' value of a control knob or slider. The problem with the new event structure is it is TOO efficient at catching all the change events for the control - but what you really want is only the 'final' value selected by the user. "Mouse Up" event does not always work reliably - as th use may slide the mouse off the control prior to releasing the mouse button. I've coded up an example using this detection scheme with Queue messaging between two loops a GUI and processing Loop. The jpg diagram shot is a simpler version only showing how the algo is wired to the shift registers. Enjoy and Regards Jack Hamilton Download File:post-37-1108576177.vi

Looking at your code this is one Queue no-no. You NEED to put timeouts for the ENQUE functions! Yes, timeouts when inserting items in the queues. Years ago I had a program that would stop working after some time. I traced the problem to an enque that was trying to pass data to a full queue - as the delay was set to infinite the function waited forever, never generating those useful error messages. Also, I sound like a broken iPod - NEVER put naked queue functions on the diagram! - if you used a wrapped funtion around all the queue sends - you'd only have one place to look for debug. "Too busy working on other new applications" - I've been there, a word of advice - 'Take the time in every new project to 1. Learning something new. 2. Improve you code architecture - write some routine that you can REUSE in other applcations.' I know -'every application if different' - yes they are and no they are not. I've got routines now that I wrote years ago that I drop into new projects - taking days of development time down to minutes. It took me a long time of scrambling to keep outputting code to realize there has to be a better way. Regards Jack Hamiilton

Jeff, I use queue message clusters that contain variants quite a bit and don't have too much problem keeping track of the prototypes for each specific command. The main reason is I employ a fucntional architecture. I don't put naked queue's on the diagram! I construct a messaging function that is a communication MATCH to the module it's design to communicate with. As I use a match control and communications module - they internally maintain exactly what the prototype is of the queue message cluster and variant. This internal constuct is known as "Private Data" within the function. When you coding up you top level function - you should not care nor have to manage the prototypes for the messaging. I only thing you have to wiring into the function is the parameter to modify. Using a variant input is not good - you're just cause the top level code to manage the message prototypes - which can cause potential problems. As a default you can have as inputs to the comm function, a numeric array and a string array - thus you can input a single value or multilple values. However, my function inputs are more specific to the actual module it controls. Regards Jack Hamilton

Becktho Can you post a snapshot of the diagram that's receives the queue? I'm very familiar with queues and have not see this problem. You are aware that upon creating a new queue - you must flush the queue? LabVIEW retains the queue in memory - even after a destroy. (Another mind-reading feature of LabVIEW) thus, you must flush the queue upon creation - or the previous queue and any messages inside will come back like a ghost from the grave. This issue is only when in the development environment. Regards Jack Hamilton

I leapted with both feet into recoding an *working* application to DAQmx and an M Series card. The old code was using an 6023E and traditional DAQ performing 'Re-trigged continuous acquisition'. The REASON for the change was with the E Series and traditional DAQ - the CPU consumption was 100%. We purchased an 6022 M Series card and recoded the retriggered acquisition with DAQmx. Preliminary capability code proved the M series card performance to be exceptional. CPU usage for a comparable task was about 40%. When we started to code up ways of configuring the DAQmx task and propagate the data out of the DAQmx loop to other modules via Queues or Notifiers numerous odd behaviors occurred. As our application 'images' the data acquired - we noticed that we were quite consistently - but erratically missing data. After nearly a week of looking at the DAQ triggering (thinking the acquisition was missing the trigger) the elimination of that as the cause - make us look elsewhere. On a wild shot, I added some debug code to the queue messaging that sends the data out of the DAQmx timed loop to and receiving module. We discovered that the Queue was simply missing data! Even though display probes show the data faithfully entering the "Enqueue Message" function - the data simply did not show up at the other side!. The 'pending to receive' always showed some number much smaller than the total allowed queue stack size. Further, during debug I hastily dropped an Intensity graph in the receiving loop to display the contents of the accumulated data buffer which is a 2D array. The intensity graph performance is very slow, but the queue buffering should have decoupled that problem to the capacity of the buffer and given us about 1 minute of buffer time. What happen was the DAQmx timed loop - slowed it acquisition to the rate at which the intensity graph updated! Trying to understand this, I dropped Case statements into the receiving code to: disable writing to the intensity graph, and/or added a Msec delay timer to 'emulate' a long delay in the receiving loop. By removing the graph update and adding even huge delays to code worked as expected: The DAQmx loop ran at this own rate -the queue buffer stacked up. BUT when the intensity graph updated was added - The SENDing DAQmx loop execution time slowed!!!!! NI tech support is still trying to believe my claims. In the interim my solution was to remove the "Timed loop" with a simple While Loop for the DAQmx task. This seemed to reduce the problem to occurring in the 1%. The strangeness does not end there. As we have about 20 existing systems out there running 6023 E series card, we decided to try the new DAQmx code on the E board. In my code I have only to select the 'Dev2 from the control and rerun the VI. The 6023E card performance - Based on CPU usage was much better than the M Series???? It was about 11% compared to 40% for the M. That said I not lambasting NI. DAQmx is new the M Series cards are new. I don't expect perfection out-of-the-shoot. My post is simply a warning to others. As I ate about 2 months of consulting time, because of these bizarre problems - with functions in LabVIEW that I have come to trust. ie. Queues and Notifiers. I am quite impressed with the DAQmx performance. I wish there was a 'real' example of the Timed loop. I had to grope for a day or two to create a timed loop link to an actual DAQ card event timer. The examples don't use hardware at all. Regards Jack Hamilton

I rarely used "naked Queue" calls in my applications. I've very successufully used the following architecture for queue messaging: 1. The queue message is a cluster consisting of the following elements: A. Enum (Strict Type Def) this is the "Command" of the message. Typically this refers to the actual state of the state machine the queue is communicating to. B. A variant: This is the catch all datatype handler. C. *optional* U8 numeric that signifies the 'priority' of the message or the sender ID. D. *optional* Message timestamp (timestamp datatype) C. *optional* Error cluster. I ALWAYS write a wrapper around the Queue which serves as the "SEND MESSAGE" function. The Enum is the "Function Call" the variant is the data. The error output can actually be the error returned from the sub-code commanded by the queue. (if you code the sub-VI to return any errors after a queue command is received. It's just too easy to forget what the queue prototypes are after a few weeks away from the code. Also, the concept of applying Object oriented programming describes the concept of "Public" and "Private" Data. Once you've created the queue - do you really need make it's reference avaliable throughout all the code? Having ONE and ONLY ONE Send function - allows you to debug your code much easier. I have dropped File I/O in them at times to log all the messages and who's sending them. This has also given me the added benifit of creating command user/tracing and macros!. The Send Message function uses USRs to hold the queue reference. It's also a great place to retain documentation about what commands do what - and what eactly the datatypes are for each particular message. I've even in some cases had mulitp inputs of specific datatypes for specific for each command. What you want to create is a Sub-VI module that receives and process the queue commands - and a message sender that is 'mate' for that module. The two routines work as a match pair. This way you only have to make these two function 'know' exactly what the variant contains for each command. I often have very different datatypes in the variant based on a paticular command, it can be a string, cluster or array. I only have to assure that the sending module & receive module match. Typically, I create 2 communication queues, one sends commands and the other receives responses. This allows my "Send Message" function to also support getting data back from the module. Like errors, current configuration, data, etc. Although it's more complex - it handles nearly all instances of messaging. Regards Jack Hamilton

Question: Does code saved in 7.1.1 open in 7.1 without errors? (Incorrect, earlier version???) Jack

Hey a Chart with "Sweep" option enabled shows the previous trace until it's replaced by the new data point-by-point. This is a quicker way...

Download File:post-37-1103031218.viNishit, [Pronunced 'Nis -hit' right?] You need to use messaging to propogate the UDP data to other loops. Notifiers would be best as they support one message ->many receivers. Looking at your example code - that won't work because the wire between the VI's will enforce standard LabVIEW execution rules which are: The first VI will execute till completion - then pass data (via the wire) to the next routine etc. Wire connection in LabVIEW enforces exection order. Your final code will contain many loops; one the UDP -> notifier send. Then the other loops will wait on the notifcation data or user options. You can include a User Interface loop with a LabVIEW event structure and use the notifiers to pass commands to the various display loops (for configuration purposes) Give that a try. BTY: UDP is not a 'reliable protocol' so it can lose data if network traffic gets high. Attached is a quick VI showing this messaging and a snapshot of the diagram Regards Jack

Mike, I looked *fairly thoroughly* thru the DAQmx channel and task property nodes and did not see a instance where I can change the device. I ended-up hand coding all this with string tools - pretty sloppy as SOME tasks, like counter/timing required a "/" prefix before the 'Dev1" specification - or else you get an error when trying to create the channel. I'm starting to see some DAQmx weirdness...and have been talking to NI support about this.

I am trying to programmatically create DAQmx tasks/channel names. The problem is the new DAQmx task channel handles includes the Device name "Dev1/ai0". I simply want to change the assigned Device for a already specified channel - You apparently can treat DAQ tasks/channels as strings and use string parsing to replace/update the channel content - but there are several problems. 1. The DAQmx channel are specific to the hardware type - ie. Analog, DIO and counter/timers have different prototypes. So the output of the string parser - has to be a string. It seems to work - I do see a coersion node at the string/channel connector. 2. The syntax for the Channel declaration is different! for analog it's "Dev1/aio" BUT for Timing the syntax is preceded by a "/" : "/Dev1/ctrOInternalClock". So creating a VI to replace/update the "Dev" part of the channel is nearly impossible as I don't know a way to interrogate if the input channel is an analog, DIO or counter/timer type. I don't think NI really though much about this...

I think NI forum hosts should consult their attorneys before making such statements. I don't understand the application of the word 'illegal' in the censor statement. Unless Express VI's are patented and they are referring to patent infrigement. If that's the case - you can't use the world 'illegal' because it's not illegal to disclose a patented technique - all anyone would have to do is look up the patent - To get a patent you have to dislose the details of your technology/technique which is then published in the public record. Perhaps they are confused with proprietary and patented... If the information is proprietary - then publishing such information would be 'illegal' only if the party disclosing the information had entered in and violated a disclosure agreement with NI. As the forum itself is hosted by NI - it can't violate it's own proprietary agreements. I don't think either is the case. I think there is a kinder/gentler wording NI can use to say that certain information is outside of the Developer topic and leave it a that.

I'm not understanding why you have two loops accesing the same hardware that can only be controlled synchroniously? How are you handing access to the single resource (serial port). You should only have one loop controlling all read/write activity of the serial port. This way you don't interrupt a read when a write request comes along. Normally, you should not see much of a delay other than that attributed by the baud rate. It will be difficult to debug problems if two loops are competing for the same resource - how do you know a write preceeds a read for requested data? Some more detail - or a snapshot of the code would be great.

Mike, I came across a solution for this in the NI knowledgebase - Using the Vision Builder first perform a color extraction of the RED pane of the image - then all other functions will work. Jack

The waveform returned from the AI VI is a 2D array - use the "Index Array" function to strip off just the '0' element and save that to disc. See Example code:

Megan, A quick way to save the data in segement files without coding it all - is to use the NI "LabVIEW Measurement File". In the configuration - "Save to series of Files" settings you can set the file to be segmented by size, data, time etc. Regards Jack

Don't take my poke the wrong way - I've learned a few things overs the years consulting. One is the magic word you can use with clients "No". Sometimes, clients and consultants think we carry some magic bag of tricks and can whip up bug-free solution to a complex problem in no-time. The reality is sometimes the solution is very simple and direct. It's like having a flat tire - the solution is to 'Get out and fix it' no amount of button pushing on the dashboard is going to solve it. I too like to keep a poker face when pitched a problem - sometimes it's better to run for the hills. I'm glad you found a solution.. Regards Mr. Hamilton (Jack)

If the load cell is read via analog data - then a DAQ card can 'scan' 4 channels at a very high rate and return data reads for all 4 channels at once. You can do this with a single AI read in a single loop. There are numerous examples with LabVIEW for multi-channel analog reading. If the reads are acquire via serial port - then you'll need 4 seperate loops or one serial comm loop that polls 4 channels sequencially. More details about 'how' the measurement is physically connected to the computer would be helpful...

I would recommend a 'packet' format so telemetry is emitted in bursts. Using \r\n termination is good to know where a packet ends - you should consider unique characters or a fixed packet length to know where a packet begins. Fixed length is better - even if you have to padd with zeros. Then you configure the serial port get 2x the packet size with the proper termination. This way you'll get a full packet. Sound like a nice project! you should include a GPS!

Hmm, I should say this...but what the heck. I did put an Easter Egg in some software once :ninja: - basically it would display a dialog box that "All parts would Pass Testing". Lucky for me to enable it - you had to press a key sequence - then press another Ctrl+key to get the dialog. (It was only a dialog - it did not effect the test ;-#) The enable sequence disabled after the Easter Egg dialog display. Well I got lucky because we showed ONE person at the plant and in about 2 weeks I was asked point blank by the Project Manager "If I put an Easter Egg in the test code". Keep in mind this was released code which was not for comercial use. The person who watched only knew the final key sequence - not the enable. They could not ever get the dialog again. (Because QC wanted to take a look at it ). As I was the only one who knew the enable sequence.."No sir! I replied". The lesson learned was - make sure access to the egg is somewhat complex - the first idiot you show will show everybody in the plant and your goose is cooked!

Megan, Likely the problem is the file write is taking too long and delaying the analog read. You need to decouple the acquisition & file save into 2 seperate loops. I've done this and it will work great. Use a Queue to send the acquistion data to the save loop. This will allow the acquisition loop to output data to the queue - without getting backed up by the save time. This is known as a "Producer/Consumer loop" it looks likes this: Shown below:Let me know if you need to more help.

Cis, That is called a "Splashscreen" (which most users find irrating -(this is why I use them alot)) You do this in LabVIEW by first calling the 'Splash' routine first which then calls the main code. I have an example of a splash screen vi on my www.labuseful.com website - enjoy!

Hmm it was the correct size but corrupted - the link is now revised to a new zip. This is a windows WinZip file.