Michael Aivaliotis

The datalogging capabilities that you talk about are rudimentary but may be useful for something. I just don't know what. :question: I honestly don't know why NI has not dropped this feature since I have never come across anyone who uses it (of course now I will be proven wrong). The type of files created are the same format as your standard datalog files. Datalog files can easily be created by writing a cluster into the file IO functions. How is this different? Go to a brand new VI and create a bunch of controls (booleans, text input etc.). To enable datalogging you have to go to this VI that you want to log data from and go to the Operate>>Data Logging>>Change log file Binding. I bet you didn't notice that before eh? You will be prompted for a file. Enter a filename with any extension. Now go back and edit the values then click the run button. Now go to the Operate>>Data Logging>>Log.. menu. The values of all the front panel controls will be saved as a single record to the file. To retrieve the data you have to place this same VI on the diagram then right-click on it and select "enable database access". A weird file cabinet icon will wrap around the vi and now you can create indicators to retrieve the data from the datalog file. So in essence the entire front panel of your VI becomes the cluster you would otherwise use in your normal datalog file IO VI's. See image:

Hey! I heard that! Actually James, If you look at the sub-vi's that Quixote is using, you will see VISA there. Presently this is the only way to use serial. As far as the coding style your improved re-write is great! Of course it can always be done better...

Or like the Label\Caption relationship. Correct?

Here is a brief tutorial (with pictures) on how to replace the index control in an array. This is useful when you want to provide a user friendly interface to the array control or you want to create custom front panels using the array control as a main component. Right-Click on the border of the control and select Customize from the menu Click on the wrench Icon to break apart the control Click on the index control so it is selected with a dotted line around it. From the menu select customize which will bring up another control editor window for the index cotrol. Now from the right-click menu you can replace the index control with any other numeric object, in this case a slider. Now you just close the control editor window, don't save the control, just say yes to replacing the old index control. The final product.

You should not edit the mnu files directly. Go to your LabVIEW menu and select tools>>Advanced>>Edit Palette Views. This will bring up the palette editor. From this editor you can edit exisitng subpalettes by right-clicking on the nodes or you can create your own mnu file. You can only create custom mnu files in your user.lib subpalette. Once you insert a submenu you will be given a choice to create a new mnu file. I hope this gives you some starting point with mnu files. There is extensive help in the built-in LabVIEW help on this topic.

Are you guys using the built-in ini functions that come with LabVIEW? If you use these config VI's you should never run into compatibility issues because this is handled automatically. I hope you're not creating the path yourself using strings are you?...

You can't build applications or run the Application builder in the Evaluation Version of LabVIEW... Sorry.

It seems that your wish is granted... twice! See this link 1: http://forums.lavausergroup.org/index.php?showtopic=158 See this link 2: LV7.1 Feature: Navigation Window for easily viewing large front panels and block diagrams

You should have no problem doing what you want with LabVIEW. NI has developed a LabVIEW Datalogging and Supervisory Control Module but this only works with LabVIEW version 7.1. I don't think you can buy it for version 6.0 anymore. Here is a description from NI's site. Like I said, you can do all of the above with regular LabVIEW but the add-on module will make your development go much faster.

Hmm, it appears to be a bug that's reproduceable in LV7.0 and LV7.1. Can someone else confirm this? I recreated the same VI in LV6.1 and it behaves as it should. It appears to be some kind of rounding error bug. I found a work-around: 1. Right-click on the control and select representation>SGL 2. Right-click on the control and select representation>DBL. It will work now as expected.

I've moved this post out of the bug-list section because I don't think it's really is a bug. If others disagree I will move it back. I've modified your example VI (LV7.1) and added a fix. I also converted it to LV7.0 for the other folks in this forum. The problem is that when you hide a page in the tab control, that is currently active, LV doesn't know which tab it is suppose to make the active tab. You, as the programmer, must give LV this information by setting the active tab. I've shown this in the code by adding a property node that always forces the first tab to be active. Download File:post-2-1089913388.vi

The LabVIEW run-time installer only contains information for installing components related to running LabVIEW VI's. Hardware communications (like serial) requires different modules that are not included with the "basic" run-time. You can try a little experiment. Create a blank build script. By "blank", I mean do not include ANY vi's. Go right to the Installer tab and configure it as shown in the attached image. Build the app. Run the setup.exe file on the computer that cannot communicate with the serial port or has errors. Does this fix it? If so, then you now have a serial port installer!

You cannot abort a process this way because you have not programmed any modularity in your code. The only way to do this is to put case structures around the bits of code that you need to abort and then make those cases false when you hit stop. For example, if you have three VI's that have to execute and you are executing VI#1 then you can ignore VI#2 and #3. However you cannot abort VI#1 until it has finished executing. If you need this type of control I recommend using state machine architecture and break down your code into smaller chunks that can be controlled better. Here is the FAQ entry: What is a State Machine If you want to do simple start and stop button behavior, look at the attached example (LV70) Download File:post-2-1089822983.vi

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.