viSci

Yes, all the methods mentioned do indeed work with cRIO targets. In my system I have 2 9074 targets each with 9144 extension chassis. I am using the scan engine IO Variables which I can read programatically using Data Socket (DS) and then filter and scale then transfer to my version of the Current Value Table (Fancy shift register based storage) and from there the data is written to a proper NSV library which has a binding to a 'mirror' library on the windows side. From there I cannot via the DSC toolkit to my citadel database.

You can also bind one library (say RT target) to a 'mirror' library on another RT or Windows target. LV 8.6 has some nice tools to help you bind entire libraries. You can also programmatically transfer Network Shared Variable data using Datasocket.

The Good News: It is possible to set the initial value of a NSV on an RT target. The Bad News: There does not seem to be anyway to determine when this initial value is available from the SV server. For some reason there an initializing period of time that the PSP client (your RT application) needs to connect to the SV server to obtain the current value of a NSV. You can try looping until the warning message (Warning -1950679027 occurred at an unidentified location Possible reason(s): LabVIEW: (Hex 0x8BBB000D) NI-PSP has not connected to the server yet) goes away but this does not alway guarantee that the next transaction will be good. I think NI should provide a utility that can be called that forces this initialization process to occur.

Here's a little utility to deal with the problem.Download File:post-162-1236702011.zip

I have noticed in LV 8.6.1 that some of my system numeric 'spinner' controls are no longer accepting min, max data range settings in the data entry popup. I can type in a new value and it simply reverts to 0. Once LabVIEW has gotten it into its head to do this then all past and future numeric controls will not allow me to range set. I am guessing that the Numeric Poperties popup has some 'smarts' in it that remembers the last settings and it appears that it is too smart for it own good. Has anyone else seen this problem? Even worse, is that once a control develops this problem I cannot fix it other than deleting.

Cool...I never knew you could get that kind of detailed coordinate information, thanks. I prefer your solution since it does not rely on having to use up the description property of the controls.

Ok, I will try again to explain...If I double click on the text field of the control I want a popup touchscreen keypad to appear. If I click twice rapidly on the up arrow of the control then I do not want to have the keypad popup, but unfortunately the Mods:Double Click property cannot tell the difference by itself. BTW, thanks for your interest in trying to help.

Hi Ton, Perhaps I am not understanding how simple the solution is but I cannot see how to use the native double click to produce the desired result. Take a closer look at my example and notice that it is able to differentiate, on a single numeric control, between a double click and two fast successive value changes.

Here is my solution so far... I have to perform the double click detection myself and interfere with the description property.

I have an Touchscreen HMI that will popup a keypad when a numeric control is double clicked. The problem is that I also want to allow a user to single click the inc/dec arrows with the mouse if it is present. If the single clicks are fast enough they register as an unwanted double click event. I have a single registered mouse down and value changed event for all of the control references in my HMI so I need a generic solution to differentiate between a value change event and a double click. So far I have not been successful. Is it possible within the value change event to disable the double click event or throw away a mouse click?

Ok, thanks for the link to the LV 8.6.1 drivers. Now here is a tougher one...I also need the next rev of the EtherCAT drivers for the 9144 cRIO expansion chassis. I've looked but can only find the 1.0 version that I already have.

Be careful with these LV 8.6.1 installations!!! I foolishly rushed to do this and am getting a niwd4c.dll initialization error in my cRIO RT code. I am guessing that I will need the appropriate NI-DAQ or VISA drivers that will come with the released version of LV 8.6.1. Anybody know were they are hiding?

Your connection as indicated is 2-wire. You need to make sure your instrument and the 9871 are both setup for 2 wire auto mode.

I have a firewire application that does real time 640x480 with alpha blending and it works very well on a ordinary desktop. LV vision is very fast and powerful, you should be able to do lots of cool real-time analysis and effects. Also, keep in mind that you can use any type of firewire camera and do not need the IMAQ frame grabber hardware. Just make sure you have the IEEE 1394 IMAQ drivers. Please, keep us updated on your progress, perhaps we can share some ideas...

This is not your 'fathers' pipe control. It has alot of extra smarts to add connected segments and has some interesting programmatic features.

Does anyone know how this control was created?Download File:post-162-1232549988.ctl

I am using a NSV with buffering to send commands from the host PC to one of 2 cRIO's. The cRIO then uses VI Server to make a Remote Call by Reference to a Return Notifier Proxy which completes the transaction. In my stress testing I have yet to miss a transaction with a roundtrip time of ~50-75ms. It appears that the NSV transaction is very fast with the bulk of the time taken by the Remote Call. BTW, I am caching the Remote Call and NSV Datasocket references.

I am using a NSV with buffering to send commands from the host PC to one of 2 cRIO's. The cRIO then uses VI Server to make a Remote Call by Reference to a Return Notifier Proxy on the PC that completes the transaction. In my stress testing I have yet to miss a transaction with a roundtrip time of ~50-75ms. It appears that the NSV transaction is very fast with the bulk of the time taken by the Remote Call. BTW, I am caching the Remote Call and NSV Datasocket references.

I am trying to optimize my cRIO -> PC remote call performance. Does anyone know what is going on under the hood when a remote call is executed. Here are some things I am wondering about: 1. How is connector data bundled up and converted to a TCP/IP payload 2. What is the structure of the VI Server Protocol 3. What is the threading model of the VI Server 4. What would a transaction timeline look like TIA

I am trying to optimize my cRIO -> PC remote call performance. Does anyone know what is going on under the hood when a remote call is executed. Here are some things I am wondering about: 1. How is connector data bundled up and converted to a TCP/IP payload 2. What is the structure of the VI Server Protocol 3. What is the threading model of the VI Server 4. What would a transaction timeline look like TIA

You should be able to change the scaling of your NSV's deployed on your RT target using the SV property nodes. You will also have the option to keep the change in memory or commit it to the SVE on your target.

Just noticed that all of my post history beyond last month is gone. Is there a way to recover this information?

Here is an example of the code I wrote to do alpha blending

From my cRIO I need to call a vi on a networked PC. I currently have to open a reference to this vi (which is kept in memory for this purpose) then make the call and then close the reference. I was thinking of caching the references but this could be dangerous if the PC restarts in which case I suppose the original references would be invalid. Just wondering if anyone could think of a more clever way to do this to avoid the time penalty of opening the reference. Thanks

I recall that we used to just place such a vi in a the non-executing state of a True/False case structure, but LV seems bent on optimizing out this 'non-running' code. I had to be creative to fool it. Just curious what others have found.