orko

QUOTE(Mellberg @ Jul 2 2007, 12:21 AM)

Ok, I understand!

Thank you!

//Mellberg

No problem. Just curious, did this get rid of the original strange behavior you were seeing in the autogrow property?

QUOTE(Mellberg @ Jun 28 2007, 11:14 PM)

Well, correct me if I'm wrong, but I do have to update the left case-structure too to be compliant with LV8.x, don't I? I guess that I in that case need to have NI's bless to be able to reach and be able to use that reference-constant you're mentioning - the SuperPrivateScriptingFeatureVisible=TRUE & SuperSecretPrivateSpecialStuff=TRUE won't help...?

Below is what I did to your BD (added "CaseStructure" to both your constant array and the case selector). As far as the class constant, you can use the "CaseSelector" class as before. I don't see the "CaseStructure" class constant in the list in 8.x, even with the scripting ini settings turned on. It seems to work though just fine like this:

http://forums.lavag.org/index.php?act=attach&type=post&id=6276''>http://forums.lavag.org/index.php?act=attach&type=post&id=6276'>http://forums.lavag.org/index.php?act=attach&type=post&id=6276

QUOTE(phuzionz @ Jun 28 2007, 01:29 PM)

When you start the VI, you can press on the multicolumn, there appears a itemsymbol. But now, How can i prevent that my output array shift's, when i press at the same place.

For example: I press at index 0, itemsymbol appears at index 0, I press again index 0 to eraese that item, now there appaers at index one an item, how an i prevent this?

Two things need to happen:

1) Use "Replace Array Subset" instead of "Insert Into Array" to change(replace) elements without making the array any larger. With the Insert, you were adding an element to the array everytime your event fired.

2) Because "Replace Array Subset" will cause an error if you try to replace an element that doesn't exist yet, you have to initialize your array to the proper size first. This happens to be the same size as the array of ItemNames in the multicolumn listbox.

This is how I got your code to work. Let me know if you need more clarification.

http://forums.lavag.org/index.php?act=attach&type=post&id=6267''>http://forums.lavag.org/index.php?act=attach&type=post&id=6267'>http://forums.lavag.org/index.php?act=attach&type=post&id=6267

QUOTE(tcplomp @ Jun 28 2007, 12:00 PM)

A (new) feature of 8.x is the diagram disable structure

Located in the structures palette.

Ton

Another project specific structure I use frequently is the conditional disable structure, also located in the structures pallete. This one allows you to turn on and off behavior similar to #ifdef's in C by setting a variable in the project manager. An example is one that I use all the time: HARDWARE=TRUE/FALSE :thumbup: Makes development at my desk a much happier experience.

Or another one I see frequently is: DEPLOY=TRUE/FALSE for enabling autoclose behavior or things that you just want to happen after you build the EXE.

QUOTE(Sherif @ Jun 27 2007, 07:54 PM)

This is because when i used factor two to reduce the baud rate I -- at the same time -- doubled the period so they cancel each other and back to the same Problem.

The baud rate of the serial connection has nothing to do with the sampling rate of the analog signal data in this scenario. Since you are converting the samples of the analog signal to raw binary data (ones and zeros), it doesn't matter how fast or slow they get to the receiving end of the serial I/O.

It does however matter what you set as your sampling rate in the "Simulate Signal" VI that is generating your square wave, and making sure that the "binary to digital" sampling rate is set to the same value. This will ensure that the period of the waveform can be correctly translated from the bits received on the read. If you look into the "binary to digital" VI's diagram you will see that it uses this input as the "dt" of the resulting digital waveform (which is the time between each data point (bit) in the waveform), and that it defaults to 1000 uS. Looking at your front panel snapshot you gave us, I can tell that the sample rate of the input analog squarewave is not exactly 1000 uS (it's close, but they need to exactly match for this to work reliably). This isn't the main cause of your double frequency problem however....

There is also another issue that I see happening, now that I look closer at your front panel. You are writing 100 bytes to the serial port, but only getting back 51 bytes of data on your read, which would explain why there is a "double frequency" problem since it looks as if you're missing every other byte of data in the LabVIEW read. I'm not sure why this is happening yet however. Perhaps a simplified test VI that exhibits this problem on your machine could be posted?

One guess I have is that the byte array to string/string to byte array is producing NULL (0x00h) and DEL (0x7Fh) characters, which may be confusing the serial communications.... a quick test on this is to replace the "byte array to string" and "string to byte array" with something that is not going to produce non-printable characters. Like perhaps something like this:

http://forums.lavag.org/index.php?act=attach&type=post&id=6261''>http://forums.lavag.org/index.php?act=attach&type=post&id=6261'>http://forums.lavag.org/index.php?act=attach&type=post&id=6261

This method will produce nice (human readable) hex byte characters separated by commas. (ie: "00,00,7F,7F,...") which are gauranteed not to mess with the serial communications/term characters.

Best of luck!

One thing I noticed is that you are only detecting the "CaseSelector" class. That will work in LV7.x and below, but NI changed the class name to "CaseStructure" in LV8.x. I added that name to your pick list and to the case structure (keeping the "CaseSelector" class in there for backward compatibility) and I'm getting much better results.

QUOTE(John Kelly @ Jun 28 2007, 06:11 AM)

I'm beginning to think my problem is I'm dealing with global variables, so 'items'...variables representing one of the multitude of global variables...show up all over my calling vi. I can't select them all at the same time. I haven't found a way to replace the global variable file with another of the same name.

Ah, I see. In that case to replace all of your global calls in your VI with another version, follow these steps:

1) Open the top level VI that uses the global variables.

2) Open the correct version of the global VI, which has the same name as the global VI that your top level VI is currently calling it's globals from.

3) LabVIEW should prompt you to replace the current VI in memory with the one you just opened, choose "replace".

Voila.

It's very similar to replacing SubVI's on your block diagram, you just don't have the ability to right click the global calls and select "Replace" from there. You must actually open up the globals VI to accomplish the replace in memory.

Hope this helped.

QUOTE(rolfk @ Jun 28 2007, 01:57 AM)

Imagine your tool doing 500 wire modifications and then the user realizes he wants to undo the operation just before he selected your tool. Ouch!!!!!!

Quite true! I've changed the behavior to undo all wire cleanups with a single undo.

QUOTE(Gavin Burnell)

Good point! I've changed this over to just extract wire references from the BD.

Here is the latest version:

http://forums.lavag.org/index.php?act=attach&type=post&id=6257''>http://forums.lavag.org/index.php?act=attach&type=post&id=6257'>http://forums.lavag.org/index.php?act=attach&type=post&id=6257 (LV8.0.1)

UPDATE:

--------

I've fixed the "Clean Up Wires.vi" utility so that it works with Undo and records modifications on the BD (prompts for save). I'm unsure though whether the desired undo behavior would be to undo each wire individually or to undo the whole cleanup in one shot. The current version works on each wire individually.

http://forums.lavag.org/index.php?act=attach&type=post&id=6248 (LV8.0.1)

QUOTE(jpdrolet @ Jun 27 2007, 04:07 PM)

When you open the VI reference, wire 1 to the option input. From the help for Open VI Reference:

I had a feeling I was missing something silly...

Thank you!

QUOTE(rolfk @ Jun 27 2007, 02:24 PM)

Have you tried these?

Rolf Kalbermatter

No I hadn't seen those... I'll give them a shot and see if I can make sense of them ;-) Will they also take care of notifying LV that there was a cosmetic change made to the BD (prompt for save)?

Thanks Rolf!

Alright, this is baffling me.

Pulling an idea from my other post here, I'm trying to figure out how to tell LabVIEW that changes were made to the BD with the "CleanUp Wire" method.

1) I would like the utility in that post to notify LabVIEW that changes were made if it moves any wires, and prompt the user for a save on close. I thought that it would be as simple as to set the BD docmods to something non-zero, but that doesn't appear to work. I even tried to capture the docmod values after a normal "cleanup wire" action and set them to that value, and the asterisk never appears on the title bar Has anyone had any luck with this?

2) It would be very nice to be able to "Undo" the wire cleanup in case the end result isn't ideal. Were is the undo state information stored, and how do I insert my changes into it's "stack"?

http://forums.lavag.org/index.php?act=attach&type=post&id=6245

Thanks for any help.

In LV 7.1, you can do this:

Right click on the subVI in the top level VI and select "Replace" then "Select a VI" and point to the correct location of the desired subVI. As long as the VI that you replace it with has the same name as the one it replaces, LabVIEW will prompt you to replace all calls to it.

Be careful not to open up two VIs at the same time that call two different subVIs with the same name in LV7.x and below. This will cause the second one that is opened to use the subVI that is already in memory (you'll get a notification of this when it happens).

QUOTE(yen @ Jun 26 2007, 12:35 PM)

After more than 750 posts, I think an introduction is in order.

Very nice to meet you, Yen. In keeping with the honesty and candidness of your introduction, http://www.sawf.org/Newsphotos/Hollywood/America_Ferrera_Ugly_Betty.jpg' target="_blank">here is my real identity.

QUOTE(Dirk J. @ Jun 27 2007, 01:01 AM)

that kind of works for me...

the llb now opens in explorer but the 'details' view is not persistent.

but at least it gives me a button to change to details view faster than in IE.

BTW, is this problem IE7 related? Something MS changed to override DDE based file associations with Explorer?

One other thing (that I wasn't sure if it affected this or not) was to change the default folder view settings for all of my folders to detailed view.

I can tell you that this is definitely not IE7 related, since I'm still using IE6 ;-)

I spent some time looking through the registry settings for the LLB classid, but wasn't able to change the view behavior by changing either the DDE settings (tried ViewFolder() and ExploreFolder() in HKEY_CLASSES_ROOT\CLSID\{99F3B825-BDAB-4231-8EDB-5A369C2A2F80}\shell\open\ddeexec) or by changing the open command to point to "%SystemRoot%\Explorer.exe /root,/idlist,%I,%L" in the ascii encoded string at HKEY_CLASSES_ROOT\CLSID\{99F3B825-BDAB-4231-8EDB-5A369C2A2F80}\shell\open\command (it was originally set to Explorer /e).

I'm thinking that perhaps the Explorer switches might be hardcoded into the LVShellExt.dll. If that is the case, then there's nothing us mortals can do.

Personally, I think that it would be ideal to have the view of the LLB files selectable as an option right in the LV Environment options dialog... is there a better suggestion for the wish list?

QUOTE(Sherif @ Jun 26 2007, 05:12 PM)

I already made what you said but still no change anyway thank you for your help

To illustrate the problem more and more

When the analog pulsed signal is converted to digital and sent Over serial Port and then read again on the labview the read signal has half the period of the written wave (i.e double the frequency or double rate)

My only suggestion is that perhaps on the read side, the "binary to digital" conversion is acting on an array of U8 without knowing what the desired sample rate should be of the output digital waveform.

Remember that once the bits are captured and sent along the serial port as a string of data, they are just ones and zeros of the raw data and all the timing information on the original analog waveform is lost.

Perhaps you are going to have to capture the sample rate during the analog to digital conversion in the write code and encode it into the string it writes out to the serial port. Since I think you are intending to control an FPGA board with the serial port I/O directly, you may have to rethink how you're going to extract the timing information from the string that appears on the serial port.

Hope this helps.

QUOTE(Sherif @ Jun 26 2007, 02:29 PM)

OK Thank you Crelf i already tried the loopBack test you suggested but when i write for example Ahmed i received Amd

i don't know why

regards,

sherif farouk (",)

Thank you both JackHamilton & JFM you really helped me to discover where's the problem

but i don't know now why he pulse width of read message is half of the written on the port

do you have any ideas for this behavior...??

thnx in advance

Sherif Farouk (",)

-----------------

Sherif,

The reason you are getting half of the data is because the 16bits per sample is being converted to 8bits by the 8bit array to string.

To fix this, wire up the resolution input to the Analog to Digital conversion VI, which defaults to 16 bits. Then change your Digital to Binary VI to be the "Digital Waveform to Binary U8" instance. This seems to work for me.

http://forums.lavag.org/index.php?act=attach&type=post&id=6237''>http://forums.lavag.org/index.php?act=attach&type=post&id=6237'>http://forums.lavag.org/index.php?act=attach&type=post&id=6237

QUOTE(Dirk J. @ Jun 26 2007, 01:28 AM)

Related to this... LLB's only open using Internet Explorer on my system; I can't get them to open in Windows Explorer, which sucks because IE defaults to "Icon" viewstyle whereas I would rather have "Details".

I actually hacked around this problem because it was irritating me so much. I built a batch file (remember those?) which I defaulted the opening of LLB files to point to.

@echo offExplorer /root,%~f1

Opening up an LLB this way, then changing the view of the window to the details view made all subsequent opens open up in the details mode.

YMMV of course, but I'm hoping for a more elegant solution soon...

Here's a utility that uses scripting in 8.x to perform the cleanup wires using two core VIs located in the "<LabVIEW>\vi.lib\Utility" directory.

Details on those two VIs:

"allVIsInMemory.llb\Get User Application Reference.vi" gets the application reference of the launching VI using the output of the "App.MenuLaunchVI" scripting property node.

"traverseref.llb\TRef Traverse for References.vi" gets all of the object references in the VI to search for wires.

I couldn't get the "scripting tools:Get all Objects.vi" to work in LV 8.2.1. It would gather objects, but probing into it on my system I found that it couldn't find any wires. Not sure why, but Jim Kring pointed out that the traverseref.llb VIs were updated by NI and that one seemed to work fine for me in both LV 8.0.1 and LV8.2.1.

I put the following VI into my <LabVIEW>/project directory in LV 8.0.1 and LV 8.2.1 and it shows up in the "Tools" menu as "Clean Up Wires...". Let me know how this works for you*

http://forums.lavag.org/index.php?act=attach&type=post&id=6235 (LV8.0.1)

*note: I couldn't figure out how to set the docmods so that LabVIEW would know that the VI had changed (hence prompting for a save on close) after this VI executes. Can anyone help me out with that?

QUOTE(AndersBjork @ Jun 25 2007, 10:48 AM)

Thanks very much for your help! I used the same properties before it didn't work, I was quite puzzled why :/

Hmm.. Not sure why that wouldn't work (works fine for me). On a side note, wiring through block diagram objects like that (through Array2's property node to Array3's) violates the left-to-right data flow, and you can't be 100% certain where the connection points are without moving Array2's property node out of the way. Of course, I'm being slightly hypocritical on style guidelines since I didn't wire up the error nodes in my example.

Is it working for you now, or are you still having trouble?

Example (LV8.0.1)

http://forums.lavag.org/index.php?act=attach&type=post&id=6217''>http://forums.lavag.org/index.php?act=attach&type=post&id=6217'>http://forums.lavag.org/index.php?act=attach&type=post&id=6217

QUOTE(Michael_Aivaliotis @ Jun 25 2007, 10:45 AM)

Btw, I really don't like that yellow background on the diagram. It doesn't feel right. Or is it just a side effect of the gif transform?

Hehe... well, it's both actually. The yellow that I have on my BD is a lot lighter, almost white but just enough of a tone to not blind me when I open up my code in a dark environment. I'm one of those that is accustomed to black-lit workspaces. Comes from long hours as a web developer at eAcceleration, where flourescent lighting was an evil demon that drained the lifeforce from you after 18 hours of crunch time coding. I worked in an area that we dubbed "The Dark Side" :ninja:

QUOTE(Ben @ Jun 25 2007, 10:24 AM)

and....

if your cluster have arrays, it will sort them as well.

Tie-breakers use the second element of the cluster and so on....

This had me blinking until I realized you meant "if your cluster have arrays, it will sort by them as well." I couldn't figure out how the sort 1D array was going to sort arrays inside an array of clusters.

That's pretty cool though. I just tried it out and sure enough, with an array as the first element in the cluster, the sort will sort by the array's first element, then second, and so on. Thanks for this tidbit as well!

QUOTE(Michael_Aivaliotis @ Jun 25 2007, 10:16 AM)

you can avoid the search if you just want to sort.

Well...you learn something new every day. I had no idea that "Sort 1D Array" will compare the first element of a cluster when sorting an array of clusters.

Thanks for the tip, Michael! :thumbup:

QUOTE(BOBILLIER @ Jun 25 2007, 09:54 AM)

I want to find the best way to sort (search) array element of cluster by one of the element of this cluster. and obtain a array of index .

I don't know if this is the best way, but off the top of my head here's a way to do what I think you want:

http://forums.lavag.org/index.php?act=attach&type=post&id=6212''>http://forums.lavag.org/index.php?act=attach&type=post&id=6212'>http://forums.lavag.org/index.php?act=attach&type=post&id=6212

QUOTE(AndersBjork @ Jun 25 2007, 08:15 AM)

Yes thats what I meant.

I had a simple while loop with two array controls, two property nodes, a time delay and stop button. For testing, tested several properties by read and write.

Could you post an attachment that illustrates what you've tried (either VI or screenshot of the Block Diagram)? Sometimes a picture really helps define what you're trying to accomplish.

If you're just trying to get an array to change its index that is currently appearing at the upper left corner of the front panel array control, use the "Index Values" property.

http://forums.lavag.org/index.php?act=attach&type=post&id=6210''>http://forums.lavag.org/index.php?act=attach&type=post&id=6210'>http://forums.lavag.org/index.php?act=attach&type=post&id=6210