orko

QUOTE(67nate @ Jul 2 2007, 06:53 AM) I think that you are looking for the "Hex String to Number" vi that is located in the String/Number conversion pallette. Here is your VI modified to use this with your U16 hex string: http://forums.lavag.org/index.php?act=attach&type=post&id=6285 http://forums.lavag.org/index.php?act=attach&type=post&id=6286 You could also just compare the output of the "Hex String to Number" vi with the output of your FOR loop and bypass the unnecessary conversion to strings, unless that is needed for some other reason. QUOTE(67nate @ Jul 2 2007, 06:53 AM) P.S. I could add a screen shot if someone told me how. What would the URL be? Use the attachment manager below the posting tool to upload pictures/VI's and attach them to your posts. It should be below the area that you type your message and above the "Post Options" and emoticons. Cheers!

QUOTE(Mellberg @ Jul 2 2007, 12:21 AM) 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) 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) 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) 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) 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) 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) Quite true! I've changed the behavior to undo all wire cleanups with a single undo. QUOTE(Gavin Burnell) Using the Traverse for References is neater in many ways I suspect, but why not ask Traverse for References just to return Wire class references, rather than GObjects and then filtering as at present ? 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) I had a feeling I was missing something silly... Thank you!

QUOTE(rolfk @ Jun 27 2007, 02:24 PM) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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 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