jpdrolet

Hi,

I'm trying do something like that, but i only change data information of the DAQ board., its a  control and monitoring system. I'm able to connected several clients but its very slow  because i use a cycle "for" to send information for all clients connected and for the last my clients that delay is big, how can you treat with this question in your code?

but your idea it's fantastic, congratilations :worship:

2053[/snapback]

Paulo,

for each client connection I run an instance of a reentrant VI that handles that connection. These connection handlers run in parallel so when a new message line has to be sent, the "TCP Write" functions all write in parallel for each connection. A slow connection won't slow down other connections like it would happen if you write to all connections in sequence in a for loop.

For the moment, when a new message line is received on one client connection, it is sent to a notification. Other connection handlers wait for this notification and send the message over their own connection. This notifier scheme is not robust enough since messages are lost/overwritten when many messages are notified rapidly, faster than they can be sent over client connection. I'll have to use some queued scheme.

Jean-Pierre

Hi

I was bored tonight so I decided to wire this small Chat Room Client/Server Application. I named it BabVIEW (how silly and not original, I know...).

Users that run the attached client and connect to the server running on my PC will be able to chat live. Well they are supposed to... I didn't test it with multiple clients over the Internet.

Who will have the honor to be the first to connect?

I might post the server code if all goes as expected.

Download File:post-447-1096436681.vi

Hi Didier !

thkx for answer. Is there a way to use the LV In Port VI and Out Port VI or

am I forced to use a driver ?

Philippe

2044[/snapback]

With LabVIEW, I have port programmed a CIO-DAS8 (ISA) and it is quite straightforward (set channel register, start acquisition, poll data ready, read data registers) for single point basic acquisition. Is the 1600 very different from the DAS8?

To use timers and interrupts for timed multichannel acquisition, I think you'll need the low level drivers.

Yes, thanks  :worship:

Oh, the diagram have a grit, too    :thumbup:

Someone said you can enable the grid alignment with a shortcut, is this right?

2033[/snapback]

While moving an object with grid on, hit "g" to toggle the grid.

On a related note, use "a" to toggle wire autorouting on the diagram.

One of the main action scenes shows a round shaped building blowing up. That is actually Toronto City Hall.

1972[/snapback]

You blew your City Hall for a bloody movie?

Gee you really wanted that Hollywood money!

I see many of us use Mozilla Firefox. :thumbup:

here is the last wallpaper I used:

Here is mine.

I still need LV4.1 to support an application.

I don't use LV5.1 anymore.

LV6 is phasing out.

LV7 is my current workhorse.

LV7.1 is still on the CD...

I don't put a full wallpaper. It slows the screen refresh too much...

Yes jpdrolet I agree. A modification that I would recommend to your image is a s follows based on your last statement:

This entire code with the while loop would make up the the LV2 global VI.

1901[/snapback]

What I wanted to emphasize with the previous diagram is that the whole array is not accessed by the calling diagram. It is encapsulated in the LV2 Global. A better illustration is like:

where only a little part of the array is read/modified/written.

Of course you are right Michael, if the operation "increment subset" is used frequently, then it makes sense and it is more efficient to include it as a function of the LV2 Global (attached). This implementation can still cause race conditions. To avoid that, either put all possible operations on the array in cases of the LV2 Global or provide a lock mechanism to prevent simultaneous read/modify/write (like in GOOP).

Download File:post-447-1095907186.vi

Actually, clusters automatically have items added to the end numerically--you have to reorder the control to be an earlier index (which is what I did since I wanted the items grouped together).

Second... I have been reading info on LV2 globals and do not understand how there are less copies of memory made for an LV2 global in comparison to using a global or a global reference that is used to pull the value out through a property node.  When an LV2 global (subVI) is called... isn't a copy of the global created at the output terminal of the subVI?  Is this any different than a copy being created when you read a global variable, or a global-variable-referenced property node to some other control?  Obviously there are other benefits, such as avoiding race conditions, but I'm still trying to figure out what the big advantage is from a memory management perspective.

If I had a large array on the main.vi and accessed the Value property through a global reference, it would create a copy of that array, correct?  And if I simply had the array itself as a global and I read the value directly, LabVIEW would make a copy of it right?  And if I had the array stored in an unitialized shift register that gets passed to the output array terminal of a subVI, there is then a copy that is generated for that too right?  So is there any difference besides the overhead of loading a global in comparison to loading a subVI?

Finally, a note about my use of globals is that their use is typically limited by the execution flow control of my program.  Since program execution is linear, there cannot be a problem with race conditions.

1889[/snapback]

With a huge array held in a LV2 global, there is no advantage of ouputting the whole array to modify it because a copy is being made. Avoid to put the array on any indicator. Look at the attached picture. No copy of the whole array is made, only the elements needed to be modified are replaced.

The idea is to include in the LV2 Global a lot of functions to manipulate the array in place

without having to access/copy the whole array on calling diagrams.

But, after reading your hint about data sources, I realized that the code "makes sense":

1820[/snapback]

Bravo! But which sense!!! :laugh:

I assume there is something else you're not showing us...

1811[/snapback]

Look closely, there is nothing hidden. Check for data sources and wire directions. I found the trick with the lightbulb, I was sure LabVIEW would choke trying to run that.... Since the VI was converted from LV4, I thought there was some error, but it's legit code.

I've found this remarkable counter intuitive piece of code today...

What's wrong with it :question:

Thanks for the lightbulb mode

I forgot about this "Expose Typedef" thing...

Yes Philippe, that is the way to extract the typedef from variant data. While Variant To Flattened String does strip the typedef info, it can still be retrieved by flatteneing the variant itself and getting the subtypedef in the flat data string of the variant.

However, I'd like to know if there is any use that can be made of this typedef info, basically the name of the typedef control VI... I'll need to analyze the type descriptor with typedef info to figure its structure and figure how to detect when it is present or not.

For example of possible usage, when receiving variant data with typdef info, one could extract the control name, open a VI reference. get the directory where it is located and find there Method VIs to operate on the data.

Using "Variant To Flattened String" and "Flattened String To Variant" seem to do just that (remove typedef) by itself or am I missing something ?

PJM

1574[/snapback]

Yes but as commented in Remove Typdef From Variant there was a bug in LabVIEW 6.1 such that Variant to Flattened String did return an invalid type descriptor when used with typedefs. The VI was introduced as a workaround. Typedef information in type descriptors was introduced in LabVIEW 6.1 and this bug was a big disapointment since it did make LabVIEW Data Tools useless on typedef variant.

I did not dig in documentation recently but I think that this typedef information is not yet documented for type descriptors (LV7 is shipped with the same old Application note 154). LabVIEW Data Tools have never been implemented to use that typedef information in variants. The returned type descriptor was invalid anyway.

Now that you have made me look more closely, it seems that the typedef feature was removed in LV7 (type descriptors from Flatten to String and Variant to Flattened String don't include typedef information anymore...). That makes me wonder if that was a feature in LV6.1 or a simply a plain bug. It is from LV6.1 that typdefs are displayed in variants, wire help and that typedef conversion is indicated with a coercion dot. Internally this information is carried in data type and maybe it was just a bug in LV6.1 that made it leaked in type descriptors....

Jean-Pierre

For the specific use of casting control refnums, the function "To More Specific Class" is more appropriate here, providing an error when the typecasting is not appropiate for the control class e.g. typecasting a generic control refum (string) to a specific control refnum (numeric).

Yes but it is static method, I need to do it from control. Your method base at control or constant with existing name, but  I want to set name from control input.

Yes, at runtime.

regards

Mikrobi

1553[/snapback]

If the event name is not known at edit time, how could you create an event case for it, and put code to handle this unknown event :question:

Hey Mikrobi,

You can change the name of the events.  The key is to change the name of the refnum that you are passing into the Register for Events primitive.  However, if you're using the same subvi to pass that reference out that makes it a little tougher, but still possible.

Derek Lewis

1545[/snapback]

To change the dataname of a wire, use the function Typecast or Variant to Data. On the type input, wire an appropriately named control or constant.

I didn't write LabVIEW and I don't know exactly how the guts of it works, but it appears that the Root Loop (a synchronous task handling loop at the very core of LabVIEW) hangs when the pull-down (or Run-Time) menu is in-use, a pop-up menu is in-use, or a dialog (such as the error dialog, file dialog, etc) is open.

By "Instantiate New VIs", I mean:

• Open a VI Reference to a VI on disk that is not already in memory
  
• Open a VI Reference to a reentrant VI, thus creating a new instance
  
• Open a VI Reference to a VI Template on disk, thus creating a new instance
  

The implication of this fact is that one cannot:

• Spawn a process using either the VI Template or Reentrant VI approach
  
• Instantiate Instances of OpenGOOP objects (which use a reentrant VI instance as the data store)
  

This is too, bad since spawning VIs is a very powerful technique.  Is this a problem/bug for the majority of the power-users out there?  IMO, process spawning and GOOP are very important design patterns that my applications cannot live without.

Is there something that I missed and is it possible to get around this issue?

1539[/snapback]

I've noticed that long ago. Open VI Reference is blocked by modal windows maybe because it runs in the UI thread. I think you can add a modal VI to that list.

It is very annoying. The only workaround I see is to create these VIs in a separate instance of LabVIEW/Run-Time App. Or maybe having one application space reseved exclusively for user interface while another does the background stuff.

* surfs searchview.net *

Hum. THAT long ago?

http://messages.info-labview.org/2000/03/10/28.html

I don't know if it is a bug or an intended change, but the path setting "Library Directory" is ignored in LV7 built apps. In LV6, we could set it to the LabVIEW directory and launch unbuilt VIs (with launcher built app) and VIs from vi.lib and user.lib were found where expected.

This doesn't work anymore in LV7. The library directory seems to default to the application directory. We must set vi.lib and user.lib in the search path for the application to find them. However, the load time is much longer then. Workarounds are to put the launcher built app in the LabVIEW directory or copy library VIs in the application directory.

jpdrolet,

Okay, here's where I stand.  I attempted to incorporate many controls and indicators into a decoration, but failed to do so.  I should have know that I cannot customize more than one control at a time.  :headbang:  Maybe there is a way around it, but I have not work enough with customizing controls to do so.  Any ideas?

vince

1508[/snapback]

I mean to customize a single control so it includes the decoration. Then the decoration will follow when the control is moved. See attachment

Download File:post-447-1092956037.vi

James,

Thanks for the Reply, but this is what I meant.  I have some controls that vary in boundaries.  I have enclosed a seperate set of controls & indicators into a decoration.  My question is how can I move all that stuff at runtime?  I can group everything with clusters but that just requires alot of changes to the rest of the code I have.  So, if this is possible it will definite save alot of time

Thanx,

Vince

1503[/snapback]

Customize one of the controls to include the decoration within. The decoraratin will move with the control.

I've noticed that when an EXE is created, it generates an INI file with the same name as the EXE program. 

Now, does this INI file serve some sort of purpose?  I don't write anything to it nor read anything from it, so it appears to me as a useless file,  or does it store information after multiple uses?

If it stores nothing, is there a way to have it NOT generate an ini file?

Forgive me if this question has been asked before.  Most of my labview experience has been in developing for applications where there isn't a need for an EXE version of the VIs.

1485[/snapback]

Application settings are stored in the file. For example, if the VI Server and Web Server are enabled in your application, access list and exported/visible VIs list are stored there.

You can distribute this this configuration file with preset settings for servers and default fonts etc.

Similar to Ctrl-G to browse results of a Find.

Hi,

i want to create an .exe file. I run the application maker as everytime

but now  on a special .vi i don't get an -exe file, only a normal file.

The proberty datatype of all my other .exe files is application. But from

my new file, the datatype ist only file. It is an other icon, too.

But the installer is there. After installing i try to run this file, but

everytime i shoult choose a programm from a list for opening.

What could be the problem?  :headbang:

Sarah

1314[/snapback]

Maybe the Application name in the builder settings doesn't have the .exe extension :question:

Hi Everyone,

I have a question.  Well, I currently have a cluster containing 9 clusters with 3 of the same elements within each cluster.  My question is without using loops, or extracting each cluster element individually.  Is it possible to grab the first two elements of each cluster.  I was trying to use some array manipulations but it did not work as planned.    Any ideas out there? Thanks in advance..

Vince

1273[/snapback]

You can't index a cluster in a loop. You have to transform it into an array. If the 9 subclusters are of the same type, use the function Cluster to Array. It will output an array of 9 clusters of 3 elements.

In a recent Info-LabVIEW thread there was a need for HTML display.

I have wired this SimpleFormatter.vi that accepts tagged (markup text) and display it in a string. With a syntax parser that will wrap keywords with property tags, it can be used for syntax highlight.

It still require some work (to handle the character "<") and has merely been tested with the provided example. The font property also needs to be implemented. Correct syntax is assumed.

I defer panel updates when formatting the string but the string indicator is still drawn twice.

Download File:post-447-1091080666.vi

Download File:post-447-1091080685.vi