viSci

Can you show us the code?

I have worked with 'experimental' peristaltic pumps using every kind of motor drive (PWM, H-Bridge, Stepper, Servo) and never had a problem as long as you remember to make sure that your analog and digital grounds stay as separate as possible. If you need more isolation then send the PWM through an optocoupler which will break the ground connection entirely.

Just in case anyone did not know the obvious... Yes, a Set Control Value Method does indeed trigger a 'Data Change' Event. Perhaps I am finally starting to understand the xcontrol basics

Does anyone know a way to detect when a Set Control Value Method has been executed on an Xcontrol? I have tried the Display State Change and Data Change Events but they do not seem to trigger on this. Thanks

If you have the DSC toolkit then you can Get Shared Variable List.vi and just give it the process name (either local or remote). Without DSC you need to do it using variable engine properties: http://decibel.ni.com/content/docs/DOC-9523

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.