viSci

Has anyone else noticed a significant increase in variant attribute performance in LV2009SP1 from LV8.6.1? In the past I had been using VA's for Current Value Table Implementations but reverted to using simple numeric arrays in LV8.6 since the array based implementation seemed to be faster. Now in LV2009SP1 the opposite is true by a wide margin (40%).

I think the new PSP is very efficient. Read the white paper on the subject, it gives you pretty accurate performance characterizations.

Well, other than NSV binding, there does not appear to be a direct RT based OPC solution. It is interesting to note the Wind River does offer a VxWorks OPC driver so any RT target such as cRIO should be able to theoretically work. Another possibility might be to see if the OPC data is available as ModBus over TCPIP, Profibus or even Ethernet/IP for such devices as AB PLC's.

Here is some information on the subject... http://forums.ni.com/ni/board/message?board.id=170&message.id=446048&requireLogin=False

Here is some info on the CJC in a 9211 http://digital.ni.com/public.nsf/allkb/E6DFDA7F1AA16C1C86257599006D4A0A I believe if you are using the scan engine then the autozero and CJC are done for you automatically.

Hello All, I was wondering if anyone has any of the missing LVx posts that include the vi's and basic examples of its use. I am trying to put together a LVUG presentation on the general topic of messaging frameworks and would like to include LVx as well as some of the other interesting methods such as active vi's, event bus, etc. Thanks

NI has been experimenting with RT based infrastructures to allow remote managed RT test sequences. Veristand is a case in point. You might want to check out the Multi Process Engine Reference Design from NI http://zone.ni.com/devzone/cda/epd/p/id/6136 or Reference design for Real Time Test http://zone.ni.com/devzone/cda/tut/p/id/9883 You could probably extend the 'command server' to include transfer of task vi updates.

PID is based on Proportional control so it expects your output to work with a 0-100% range, in your case it would have to be PWM and you will need to setup a timer to control the pulse width. Also remember to scale all of your inputs and outputs to % full scale.

Just found out from NI R&D that the problem is repeatable and is caused by attempting the customize the digital numeric on a slider control. The vi will run once but thereafter will be corrupted. A CAR has been filed.

Just a little memo to all who responded (none actually) that I sent in my corrupted vi to an AE at NI and within 24 hours he got it to R&D where they were able to repair the self inflicted damage. I would really like to know what kind of tools they are wielding. The big lesson learned is that the damage could have been much worse and that was a big wake up call to get tortoiseSVN in place. Now I will do a daily revision of my source code and a backup of the SVN repository. Thanks NI for your help and quick response.

Hello all, I have a rather dire situation in which a top level vi that was being run from the project was corrupted. If I try to open it I get the dreaded error code 3 - could not load from panel. I had been running the vi for several hours and then stopped it normally. I then tried to do a build and it failed. I was late to pick up my son so I did not read all of the details of the error message but rather as I do every night did a backup. This morning I find that the vi is corrupted, the backup now is corrupted and the last exe has been wiped out since the build failed. The vi looks ok from the file size so I have some hope that NI might have tool to analyze the problem and fix it. Does anyone have any comforting words of hope to share?

Hey Norm, If your giving them out I'll take one, thanks.

I use a form of remote messaging that uses buffered network shared variables as queues to pass commands into any process whether it is on the same machine or not. Included in the message is a return notification so that the client process can flexibly block until the remote command has been completed. Included in the notifier is an optional completion response. In my case, my instrumentation is running on a cRIO and the client apps run on a PC.

Hi Scott, I am very impressed with your diagnostic skills. Thank you very much for your help!

Ahhhaaa!!!! Here is what I have discovered: The exe code works fine if and only if the LV2009 development is not open. Somehow the presence of the development environment is preventing a separate VI Server Instance to function correctly!?! Could you please try this on your end? Thanks for your help. In more detail what I see is the the exe standalone will set and read the Port to lets say 4369. If I have the LV DE open first and then open and run the exe the port will get set to 4369 but will be read as 3363 (the default LV port)

I actually used your code snippet. The verification comes later in the code when I attempt to read the assigned port number and use it as part of a remote messaging scheme. It is there when I read the Srvr.Port property that I verify that is not the value the was set previously. It has reverted back to the default of 3363. So far the only technique that works is setting the port number in the exe's ini file. I am curious to know how you are verifying that your code is working correctly.

Yes, that is what I am doing but unfortunately it does not work in LV2009

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.