viSci

Yes I may have to try using the ini approach... I had assumed that since I can set the Srvr.Port when running from the project that it should work from an exe as well. The help for the property indicates that it should work in the runtime. BTW, the advantage for me in dynamically setting the VI Server port is that I will have multiple instances of the same exe running on one computer and would prefer to have the port number generated automatically (As Rolfk pointed out to me, you can use the Create TCP listener vi to generate an unused port number and then just close that TCP port and use it for the VI Server).

I have been beating my head against the wall for 2 weeks over this issue and so far I cannot get an answer to this question and its import. Basically I have found that I cannot set the app class property Srvr.Port within a LV2009 executable. The property node executes without error but I have verified that the VI Server Port is not being set and thus always remains at the default of 3363. Any insight would be greatly appreciated, thanks.

I have an LV2009 app that sets it own Service Name. It works when run from the development environment and I can verify that the NI Service Locator has captured the new registration. If I build my app into an exe then the ServiceName property has no effect and the intended Service Name does not get registered. Any Ideas? Thanks.

Could you please tell me where in the Init code the saved display data is retrieved from disk? Is that something built into the xControl infrastructure or does the user have to provide that intelligence. Is there a certain data structure that has to be created within the Display State typedef to make this work. I simply placed my data elements flat into the cluster but it does not seem to automatically save it.

Well I have the Tag version working but cannot seem to get your method to work. I believe you meant to have me use the Display State cluster instead of the Container State. I added the 'Convert State for Save' ability but am not sure what I need to do to the Init ability to retrieve the information and get it back to my controls. I have a Display State Change event where I transfer the Dispaly State In to my controls but the data appears to be empty.

Just thought I would post this in case others have wondered how to get each instance of an xControl to preserve edit time settings such as scale ranges, control labels, etc. I had hoped that it would be as simple as making the changes on each instance then doing a 'make current values default' and saving the top level vi. Alas, it does not work that way with xControls. However you can stash away all your setting in xControl container Tags. Within any Facade case, grap a Container State Refnum and utilize the Tag.Get and Set methods to store anything you want within the container instance. All the tag info remains unique for each xControl instance and the aggregate gets saved within the top level vi.

Lets say you have a numeric control set to the value of 1. If you set the key focus you will see that the text field in the control becomes hightlighted. If you repeatedly press the up arrow on the control you will notice the value incrementing 1,2,3..8,9,10, and then jump to 20,30,40 etc. If you use the up arrow on the keyboard then it will increment by one throughout the range. I am inclined to consider the nonuniform incrementing to be a bug since in my case it is undesirable and even hazardous since it can cause a system control value (gas pressure for example) to unexpectedly jump up in value. The solution I found is to use the NumText.SelStart and End properties to force the whole numeric field to remain selected and then the value will increment uniformly.

Is there any way to automated the process of installing right click user menu items into a set of controls and indicators? I thought it could be done with VI Scripting but have not found anything yet. Anybody have a suggestion? Ok, just figured out that you can use the event structure to catch a right click activation event which contains a menu reference property. From there you can install your custom menu items and then catch them right away in other event cases if clicked on.

Whoops, I guess I did not read the opening statement very carefully... Global VI's not Globals. Well I do still need to clean up access to my globals anyway! When we are talking about globals are we referring to old style 'free' globals or project based shared variables? Shared variables are always part of a project and thus have access scope protection which is helpful. I use NSV's alot (I have 100's of them in my cRIO application) mostly are used to to bind IOV's upward to the PC HMI. But I also use them for interprocess signaling and as command response FIFO's. I suppose I should do a better job of encapsulating their access in classes, thanks alot for giving me more work to do

Try converting all inputs (level) and outputs pump speed to %, there are egu to % and % to egu vi's for this purpose. also make sure you understand if you are forward or reverse acting. In other words, what is ther relationshiop between input and output. If it is reverse acting then make you PID k gain negative.

In both LV2009 and LV 8.6.1 I have experienced a type of invisible project corruption that results in damage to etherCAT scan engine access to Digital Output resources. Image a working cRIO 9074 with a 9144 expansion chassis that has been working perfectly for an extended period of time. A change is made to source code, compiled and deployed to the target. Something goes wrong with the deployment and both the project explorer and the cRIO crash hard. The cRIO has to be manually rebooted and LV on the development machine has to be terminated and restarted. After restarting and redeploying again, everything is working fine except that Digital Outputs are not generating a voltage change on the cRIO 9076 module that resides in the 9144 expansion chassis. In the Distributed System Manager, digital outputs on the 9076 are forced but no electrical signal change is observed. All other modules are working normally. cRIO is then reformated and project is redeployed but the problem persists. Swap out a new 9144 and 9076 module, still the problem persists. Open a new project and add cRIO target and finally the outputs start working again. Open the original project, remove the cRIO target, add cRIO target, redeploy and then all is well. What is the lesson learned? Apparently, there was nothing wrong with the hardware or the source code or configuration within the project yet something 'invisible' had become corrupted in the project. The problem is that there is no way to validate the project to see if something has gone wrong internally. Also no errors were generated. Has anyone experienced anything like this?

Just an aside that LV2009 exe build properties now includes the option to autodeploy NSV libraries upon application startup.

The current version of the PID toolkit for LV 2009 is not much different from the original dating back to the 1990's when it was first written by Gary Johnson. It is very clever and highly convoluted and would be difficult to use in an RT application. I am thinking of ways to decouple the PID core from the autotuning procedure. My first thought is to use NSV references to tap into the PID PV,SP,Output and PID parameters. This way the autotune client software could run on any PC and would be consistant with the PID Real-Time Function Block. Would like to hear from other who have thought about this, particularly anyone from the NI systems group who may already be planning this.

Yes, actually I am doing exactly that. Unfortunately, the alias names returned are identical for the 2 adapters in my PC.

I have a PC that is connected to a mxi based pxi chassis that contains a pxi-6682 GPS timing module. The pxi-6682 has a ethernet adapter that appears to the PC as a second ethernet adapter card. The problem is that if I poll labview for a list of adapters by name, both the 6682 and local adapter have inherited the same name (the network computer name). Thus there does not seem to be a way to get to the actual adapter names (which are different) allowing me to find the IP address being used by VI Server. So my question is: 1. Is there a way to find the IP address of the VI Server 2. Is there a way to get the actual assigned name of each ethenet adapter card Thanks for your help.

Anybody know if there will be a 2009 update for the cRIO EtherCAT drivers? It is not on the NI-RIO drivers install or the 2009 device drivers DVD set. It seems like it would be better for it to be included with the NI-RIO drivers.

Any word on when these will appear?

The SOLA UPS comes with a windows based monitoring utility called upsmon but I am using it with a cRIO which needs to monitor the state and battery level of the UPS.

Thanks, portmon is awesome! I now have a transcript of the communications protocol which unfortunately is binary but am working on decoding it presently.

Anyone every seen one of these puppies? So far I cannot make any headway and will probably need a com port sniffer to pull it off...

Actually it would have been nice if execution highlighting revealed the hidden code, but it did not do so in my case.

Nice utility, thanks François.

I am not able to get the structuresFadeToDiagramBeneath ini to do anything. Could someone confirm that this works?

Greetings one and all, As my first post on the new LAVA site I would like to offer a public service announcement to help others avoid the difficulty I have gone through the past 4 hours. Up until today I found the Auto Grow feature to be annoying and disabled it. But lo and behold it was 2 subvi's hidden in a diagram disable structure that were causing my problem. It occurred to me that this is a nasty pitfall of graphical programming that has always existed prior to Auto Grow. So do yourself a favor and leave Auto Grow Enabled! Perhaps in the future structures could have a simple indication if any objects are outside of its visual boundary.

http://zone.ni.com/reference/en-XX/help/37...eate_bound_var/