viSci

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.

As many know, LV will autoupdate a typedef'd combo box control but not a diagram constant.

There is a very interesting and useful class of applications that would greatly benefit

from the use of typedef'd combo box constants that autoupdate. Consider the use of Current Valve Tables

in distributed systems. The CVT's are actually a form of keyed memory that is used to

store data values that can be dynamically created, updated and read. NI's System Group has a

version of the CVT that uses block diagram strings as variable names. This approach is cumbersome

in that if a name is changed you have to find all instances on the diagram and change

them manually. Also you have to cut and paste them in the first place. Another possibility is typedef'd enum's which will autoupdate

on the diagram, but unfortunately the enum datatype cannot be passed into subvi's without converting to a variant or string. It is also rather inefficient if your CVT is large

and you have 100's of variable names that would have to be passed around inside of the enum constant attributes.

An alternative and elegant solution is the use of typedef'd combobox constants that will autoupdate. I would like to argue that the change in behavior is really only a

development environment change, not really a fundamental change to the underlying wire type characteristics as it has been argued by NI.

The constant itself already has an attribute that links it to the typedef, so why inhibit the autoupdating?

Any Comments?

The problem with Get Strings from Enum__ogtk.vi is that it is way too slow to be used in a CVT implementation on an embedded target.

I agree that a smaller version of the format into string would be nice and could be called enum->string.

One thing I noticed when first trying to debug my remote VI Server calls is that each target within a project has individual VI Server configurations. Furthermore, you can have

multiple VI SERVERS at a single IP address only differentiated by the 'Service Name'. I also found out that you can remotely call reentrant vi's but it turns out I did not need that feature.