Michael Aivaliotis

The upload limits have been increased. Jack, can you try posting it here again?

You can talk to a MYSQL database with LabVIEW using the Database connectivity toolkit or other tools floating around. What do you need the PHP for? You don't need this to access database data. Please explain the need for LabVIEW to talk to PHP.

If you just want to distribute data to many readers then another option is using USR globals. This might be easier to work with. Here is an FAQ entry on them: http://forums.lavausergroup.org/index.php?showtopic=273

Why are you using non-latching buttons? Please clarify. What mechanical action are you using?

This statement doesn't make sense. An event structure cannot react to a change in a local variable. Event structures only react to front panel events. It should be ok to use a local variable to pass data, however there is no synchronization. You have no guarantee that the loop has read the old data in the local before new data has become available.

I would say this is a real bug. There seems to be some kind of disconnect between the button value and the updating of the front panel. If you do the following, it seems to work fine.

The LabVIEW scripting Forum is a place to discuss and investigate ways of using LabVIEW to programmatically generate LabVIEW code. In other words you can write a VI that will (when executed) create another VI. You may have seen some of this functionality in use already. NI uses this capability internally in some of their code generation tools. For example, if you right-click on a DaQmx task node you can select an option that builds a code example or a configuration VI. This wizard uses special undocumented features of LabVIEW to do this. VI scripting is a powerful new LabVIEW feature based on existing VI Server technology. Using the scripting API, you can create new VIs, create new front panel and block diagram objects, modify existing front panel and block diagram objects, or inspect existing front panel and block diagram objects. VI scripting allows you to write a VI to programmatically accomplish almost anything you could accomplish in LabVIEW's interactive editor. VI scripting is not advertised or available in the LabVIEW help files that are distributed with LabVIEW. This could be for many reasons. Some of these are: - NI has not finalized the implementation. - The implementation is hard to use and NI wants to make it user friendly. - NI has not decided to make it a publicly available product. - The existing implementation contains many bugs. - NI does not want to burden the support system with issues related to an unreleased product. Because of the previous statements, you are on your own: DO NOT contact NI for support on VI Scripting. DO NOT use these features for released code or applications to your customers. DO NOT count on the implementation to stay the same for future releases of LV. It will change and your code will not be upgradable. And Finally--> Your computer will explode, you will lose all your valuable data and local law enforcement will come knocking on your door. So BE WARNED! Do not blame NI or anyone here at the LAVA Forums for any problems that may arise from using these features. The Details: VI Scripting is exposed to you via methods and properties. To enable these methods and properties, you must add the following line to your labview.ini file. This file is located at: C:\Program Files\National Instruments\LabVIEW 7.1\labview.ini Add the following line: SuperPrivateScriptingFeatureVisible=True After you restart LabVIEW, place a property node down and click on the various properties. You will notice more items in your list. One more thing. To expose the "create object" primitives shown below, you must install VIPM and install the package called: ogmnu_appcontrol_plus *Update* Others have also had success with the following ini entries (don't know what they do): SuperSecretPrivateSpecialStuff=True *Update* Adam Rofer has made some interesting discoveries on some scripting related information. He calls them XNodes. Good work Adam. :thumbup: Here is the website: http://xnodes.lavag.org

Yes, you can do this. See attached image:

Also, don't forget that the entire LabVIEW run-time engine is downloaded and installed if it doesn't already exist. At least, this is my impression. The benefit of using remote panels is the browser interface.

See link: Student Robotics in China

This is a good solution. Another option is to take the output of the ring and use that to index an array of numbers that you want.

See image. This function will do it. What operating system are you running? Why do you ask about Linux and Windows?

By default, if you don't touch the priority settings on the sub-vi's they inherit the settings from the caller. Time-critical priority really only has significant effect in a LV real-time OS. Is this the case?

That's golden. I would have liked to be there to capture the look of that customers face.

Did you also think that the movie "Broken Arrow" was a story about a frustrated LabVIEW programmer battling the forces of evil to get his little Vi to work?... I did. Broken Arrow

Excellent question! It has a surprisingly easy answer. Just open a reference to the main polymorphic VI and using a property node, get the list of Callees. See image.

Ok guys. I have an issue with this implementation with respect to showing new users how to do things. I now understand what you are trying to show Alex but the "proper" conversion of a CSV file to an array would go something like this: Let's not forget that the original question was asking about a CSV (comma separated values) string.

Yes, this is possible. Do you know the old password?

What method were you using before to open the front panel?

Are you using LabVIEW? If not, then you are on the the wrong forums.

A quick search on the NI site came up with this:

I don't mean to correct you Alex but I think you would need to specify a comma for a delimeter, no?

This is PJM's personal palette. Perhaps with a little coaxing, we can get him to submit an openg package with these goodies... I believe the closest thing OpenG has to scripting is the ogmnu_appcontrol_plus package. It can be downloaded with Commander.

Here is a presentation with lots of examples that explains how to use templates with process spawning (multiple VI instances): http://lavausergroup.org/niweek2004/meetin...niweek_2004.zip

Rule number one in my company is: 1. No Global variables Rule number two is: 2. Read rule number one. Anyone caught breaking this rule is reprimanded. Forget globals, remove it from your palette (if you can). The solution you provide is worse! You know how slow your read and writes are gonna be? oh man! Open a reference to the global vi then using property nodes, wholy cow! Very very slow. especially if you have 600 of them. Very bad programming style. Why re-invent the wheel? Read this: What are USR Globals? Spend a day or two and rewrite the global calls to USR globals it's well worth it. Do it behind your bosses back. The program will run better and faster and you will be a hero. Also, if you feel like reading, here: http://forums.lavausergroup.org/index.php?showtopic=652