Michael Aivaliotis

I think the best way to debug this would be to probe the path going into the Open/Create/Replace File.vi. If this looks good then another thing to look at is permissions. Are you logged in as an administrator? Sometimes file writing to certain directories are limited to specific user levels. It is strange however that none of the VI's give you errors. You should place the General Error Handler.vi at the end of the file IO chain. This will trap any errors for you.

There is nothing built-in to LabVIEW but check out this post. It can be done by running a custom VI. You can probably put this VI in the project menu to make it more accessible.Clean up all block diagram wires.

Over the years i've gotten accustomed to living with certain rude behaviors in LabVIEW. For example, when you move an object around on the diagram with your mouse, you have to go back and cleanup the mess that LabVIEW left behind. It seems I'm constantly walking around with a virtual pooper scooper of sorts. Here's what I mean. Below you can see a simple VI with a typical assortment of wires attached. This a simple example of the best case scenario - few wires. If I then click and drag the VI to a different position on the diagram, I get multiple overlapping wires. Yes, this is normal behavior but I think it can be done better. The next image is the proffered reaction to my move. As you can see the wires have wrapped themselves to the proper position. Of course this would happen in real time. As you move the VI, you would see the wires wrapping and moving as you drag the mouse. I could best demonstrate with an animation but I am not a computer animator. Also, in combination with this feature, it would be nice if each object (VI, function etc.) had a no-fly zone. What I mean by this is shown in the next image. The red border designates an area where the wires must come straight out of the VI. This means that no other wires can go behind the object or pass near the object's no-fly zone. This would force clean diagrams since it would be impossible to have objects overlapping wires. The next image shows an extreme object movement and how the wires would auto-wrap into position. Also note that the terminal is also an object so would have a no-fly zone as well. Yes, I'm dreaming... I can only hope. :thumbup:

Well what do you know!? You're right! I just did a quick test and confirmed this. Thanks for the warning. I mistakenly assumed that it would behave like the Variant to Data function.

PJM's example works well. Using a variant means that you don't really have to get the datatype correct, however the datatype should be in the same family like numeric or string. Along the same line is this previous post: http://forums.lavausergroup.org/index.php?...=findpost&p=338 To answer your question about re-entrancy. There should be no problem. I assume you know about the feature included with the open VI reference function? This allows you to dynamically call a reentrant VI.

What data-type are the signals? Waveform datatype, arrays or scalars? Which functions do you mean? The Write to Measurement File Express VI's, the write to spreadsheet VI's or the Write File function? The example that Bryan gave you shows using the low level LV primitives (functions). Here are some other examples:

Yes! Thank You Don for the updated version. My goal was to show how the specific property node would be used. The event structure as you show it would be a much better, and preferred, implementation. Thanks for the improvement. :thumbup:

Here is an image of a diagram that performs a dynamic call:

Well, the easiest way to do this would be to use the event structure to handle button presses. When you press a button, a VI would be called and it would pop-up its front panel. The VI's to be called can be just placed on the diagram of the main VI. Follow this link for more info on how to create a pop-up VI: http://forums.lavausergroup.org/index.php?...=findpost&p=255 Once the VI terminates (by pressing a button on the front panel) the front panel will close and you will be returned to the main VI. This method will work but is limited because you can only interact with one screen at a time. You cannot have multiple screens running in parallel. If you want to do this then you need to call the VI's dynamically using VI server. This implementation will allow you to have the main menu VI running while the screens are open. If you need to run a process in parallel, I would suggest using a parallel loop. You can also place this parallel loop inside a subVI (to reduce diagram space) and place the subVI next to your main menu loop which will handle the screen launching.

You do? Where did you get this code? Is it an example for another language? If so, what language? Do you have a programming manual for this instrument? This would list all the commands required to perform interaction with the instrument. Once you know this then it is a breeze to do the rest. GPIB is easier to use than say Serial.First of all, if you want to execute the commands as they are listed in your example you can launch a command prompt interactive terminal and just type in the statements as you list them in your post: SCAN = ibdev (0, 24, NO_SAD, T100ms, 1, 0) This just sets up the GPIB device. T100mS works for my machine, errors when less than 100 uS Yes, this is the timeout value. ibconfig (SCAN, IbcEOT, 0); // Sets EOS bit to 0 Yes the EOS... ibwrt (SCAN, "A00\n", 4); Well the last line is really the command. This tell the scanner to do something "A00\n". Without the manual I don't know really what this does. The 4 means write 4 bytes. Well, you can use the interactive control I mentioned above to test the commands and see if you have device communication. Of course this is not LabVIEW programming but it can give you a comfort feeling to know that your computer can communicate with your device\scanner. What you really want is to get into some LabVIEW code right? Here is all you need to get started. You'll say: "really"? Yes... really.

Well, you can create the semi-circles in a drawing package and import them into the center button. To avoid the overlap issue why not send the center button to the all-back layer? They would then be covered by the surrounding buttons.

The File Dialog function is used to display a dialog. It does not Create, Open or Write a file. The only purpose of the File Dialog function is to give you a "nice" user friendly way of navigating to a file or directory on your computer. It is doing exactly what it's suppose to do. If you wire in a filepath. You are just telling the function what the start directory is, that's all. LabVIEW (by default) prompts you to Save As. This text can be changed by wiring the "prompt" input with your own text.

Correct! And why is this significant? It is nice because the decal is a clickable object which toggles the logic on the boolean. This is great because you can replace it with a custom graphic and use it as an additional part of the control which can be clicked.

To start off, just to clarify. The LAVA Forums are not OpenG. I realize that some OpenG contributors hang-out here but if you want to give praise to OpenG, the best way to do this is to go to the OpenG forums and tell them how much you love them in person. While you're there you can also donate some money : OpenG Website --- OK... About custom controls. Do you know about the control editor? That's the first place to start. There are many ways to access it but the best is to right-click on a front-panel control and select Advanced>>Customize. This will pop-up a window called the control editor. Once your in there you can manipulate all the objects to your hearts content. One thing you have to realize is that each control is composed of many parts. You can manipulate these parts and even replace them with pictures of your own. To see these parts you must click on the icon on the button bar that looks like a wrench. This will cause labview to break apart the control into several components. You will see each element highlited with a white box. If you use your mouse pointer you can click and drag each part of the control and spread it about. So now how do many people create cool controls. Simple, you just hack away at the control using the control editor and replace the parts you want with pictures of your own. The radio button control you mention is actually a slider. Yes! The black dot of the radio button is the slider pointer that has been replced by a black dot. The circles are pictures of circles copied from a dialog button radio control of windows. I hope I gave you an idea of how this is all done. Cheers! :beer: :arrow: Here's a challenge question for you control editor experts out there: Each boolean control has 3 visible parts. The label, caption and boolean text. There is one exception to this, what is it?

Here is an example VI (LV7.0) that shows how to manipulate text in a text box. The focus of this example is the Selection Start + Selection End property. This can be very powerful in performing custom live formatting of front panel text. The trick here is to perform formatting on the text after you highlite the section of interest. The Font property is then used within the same property node. text_hi_lite.vi - Image: Download File:post-19-1088657566.vi

I'm attaching an image that shows a 1000ms (1sec) delay used. Actually, using a sequence structure in this configuration is considered bad form. It is better to use a state machine architecture. If you want more information on state machines then read the FAQ: What is a State Machine?

How about putting the file saving code inside of a loop with a timed delay? If you give a little more description of what you are using already then I can respond with more information.

Are you using locals to achieve this? I don't see any reason that this doesn't work.

I split this post into a seperate thread. For the future please start a new topic thread if you are asking unrelated questions.

I'm not sure I follow you. What is bad policy?

I thought Alex explained it quite nicely but just to clarify I've attached a dead simple method. I think the main idea is to read the previous data and concatinate the new data to the previous data using a end-of-line between the new and old data. Of course there are other logistics issues you have to take care of yourself but the framework should work as shown.

Ok, being the picky bastard that I am, I decided to post a slightly modified version of your example. It is functionally the same however it's slightly improved on code clarity. Feel free to attack my design... The major change is that I stop the top loop by destroying the notifier Refnum. I check for errors on the wait on notification . Any error (such as a bad Refnum) stops the loop. Another change is that I use the timeout output of the same function to determine if there is a new message. This adds a bit of flexibility since you can easily expand this configuration to decode a number of datatypes (not just a Boolean out). So if there is no timeout that means there is something there... decode it. I'm not saying that your version does not work, it works well. I always like to program-in inherent flexibility (no matter how small) to accommodate system expansion.

A late response here but I would recommend that you create a VI that counts a fixed number of transitions (low to high crossing a given threshold). Do this for a certain sample set. Let's say 1000 samples. Then I would compare the count of transitions to the total number of samples collected. If you have fewer transitions for the given samples, you have a problem.

Yes the Conway-Watts book you refer to has some great examples of this. As far as the value of posted suggestions\wishes, we have quite a bit of influence in the direction of future versions of LabVIEW as long as the wishes get posted to the right location: LAVA wish list policy. My opinion is just that, an opinion and does not indicate right or wrong. Keep those opinions and suggestions comming, they are all welcome! :thumbup:

When Dynamic Events were introduced in LV7 I tried so hard to figure out a place for them in my design architectures. I am attaching an implementation where a user defined dynamic event is used to pass data from a dynamically called VI to a main VI caller. I actually used this implementation in a real project. Any comments or suggested improvements are welcome. The code is LV7.0. Download File:post-12-1087954972.llb