Daklu

QUOTE(Yen @ Feb 7 2008, 11:47 AM) Why? Primarily it's a ui asthetic design issue. Plus buttons wouldn't give me the advantage of an enum. I could use an enum with a drop down box, but it's not really the right control from a ui design standpoint. (Switching tabs shifts data categories. Switching the alias, also a drop down box, changes the data within the category. Switching data categories is a bigger change and should be reflected in the ui.) Also, since I've already structured my program around tabs I'm reluctant to go back and change it. I suspect it wouldn't be that big of a deal but I'd rather not. Now lets see if I can attach an image...

QUOTE(crelf @ Feb 7 2008, 10:40 AM) But the fundamental problem is I can't use that enum in an array as an input to a sub vi, because tabs can't be in an array unless they are a constant. (And of course they aren't constants when they are a sub vi control input.) I'd like to have the advantage of using the tab enum in my sub vi's AND I'd like to use my tab state array in those sub vi's. They appear to be mutually exclusive desires. Is there a good work around?

I have an application with several tabs each of which uses the same controls. Functions change depending on what tab is active. To simplify coding I created a single cluster of front panel controls and put it on (as opposed to in) the tab control. Now I have only a single copy of each control and I can direct the program flow by getting the value from the tab control. Each tab needs to remember the state of all the controls the last time it was active so when the user switches back to that tab all the settings and values are the same way they were left. To be "smart" I bundled the tab control (which I typedef'd) with the cluster of front panel controls and put that in an array constant on my block diagram. Each element correlates to one tab on my tab control. I use the tab control in the array element to identify which tab that element is storing information for. This works great until I tried to create some sub VIs to handle lower level chores. It turns out Tab controls/indicators can't be put in arrays or clusters. (But Tab constants can...) So my question is, is there a better way or "best practice" to store tab states? I thought about creating an enum typedef with just the tab names, but if the tab control or tabname control get out of order subtle bugs will be introduced that may not be noticed for quite some time. I've worked around the issue for now by pulling the tab state element out of the array before sending it to a sub vi but it's not an ideal solution.

You guys are great! Not only do I get my questions answered, but I get answers to the questions I didn't know to ask! :thumbup: It turns out I'll probably skip the Perforce solution and go with SVN/Tortoise. The biggest advantage of Perforce is the Labview integration, and since most of our licenses are Full I don't think they can integrate scc anyway. Plus $800 a seat is a big pill for my manager to swallow... especially when there are internal solutions we could get for free. QUOTE Usually I can figure things out so I feel like an idiot asking the question, but which binary am I supposed to download? Tortoise 1.4.7 is supposed to work with SVN 1.4.6, which I can't find. I see 1.4.5 and various dev libraries for 1.4.6... ?

Right now it's only me using the depot installed on my laptop. I anticipate moving the depot to the same server that hosts my Labview installation files sometime in the not-too-distant future. There is an outside chance additional users (maybe 5-10) will be storing their Labview source in the depot once I do that. (In fact, we have enough key Labview tools right now that I'm going to encourage it.) In general we will not be having multiple people working on the same project, but each engineer has several projects going at any one time. Just to throw a little twist in, I'm currently contracting at Microsoft meaning I could easily get VSS free. When I was looking at that I came across some comments about having to embed some text in the vi's to prevent corrupting the depot. It was a while ago so I may be misremembering, but it was enough to scare me away from that solution. I really do like the SVN option since it is more intuitive for our main users, engineers. Unfortunately I suspect running Apache on corpnet would violate IT policy. Apparently SVN can run under a separate server that doesn't require Apache, but I don't know enough about that to say whether or not it will work. QUOTE Doesn't this leave an open changelist waiting to be submitted? I think it would annoy me having semi-permanent changelists cluttering up my interface.

I have been playing around with the palettes trying to figure out exactly how I want to add my personal toolbox vi's to it. I have a problem now that has me quite frustrated. I had several sub palettes in the user.lib directory that I have since deleted; however, the sub palettes still show up in the User Libraries palette with a big question mark indicating they do not exist. When I edit the palette set and right click on the question mark icons I do not have the option to delete them. How do I get rid of them?Found a resolution. When I am editing the palette set and come across a non-existant sub palette that I can't delete, I right-click on it and select sychronize with directory. That frees up all the missing palettes and lets me delete them.

Thanks for the replies. I'm definitely learning more as I go along but then I hit roadblocks that stump me. Is there a way to create a directory structure in depot other than by creating it in my workspace and adding it? I'd really like the depot to have an organized structure but have each project directory in the depot, which may be several layers deep, to map to a directory in my root workspace. I've played around with the mappings but so far haven't been successful. I successfully got my projects in the depot. To experiment I went back and deleted the files in my workspace. The process for getting the files back into my workspace seems awfully weird. I have to go into my depot and check out the files I want followed by reverting them. Only after I revert them will they be copied to my workspace. Then of course I need to check them out again. Isn't there a more straightforward way to do this? (Edit: I tried "Get Latest Revision" but that didn't do anything.) (FYI, I was doing all this through the P4V client program, not Labview.)

So I'm fairly new to SCC systems having only minimal exposure to the Tortoise SVN client recently and MS VSS over eight years ago. I took the plunge and installed Perforce and the P4V client to maintain my source code. I've read through some of the posts by gmart and have a better understanding of the Perforce way, but there are still a few things I find confusing: When I checkout code, I would expect a copy of the repository to be placed somewhere on my computer where I can edit it. With Perforce I have to copy the code from the repository to my working directory, then check it out. If I try to checkout code that does not already exist on my computer I get an error. Is this how it is supposed to work? When I checkin code, I would expect the code to be moved from my working directory to the repository. Perforce leaves it there. If I want to edit the code I need to check it out again. (Unless, of course, I check the 'keep checked out' option.) Weird. It is very counter-intuitive. On several occasions I have checked out a project, edited it, and tried to save it only to find I "don't have permission" to save that file. I assume that is because Perforce has marked it as under source control. Does that mean every time I want to save the file I have to check it back in? That would get really ugly, really fast. Workspaces -- How do you organize your workspaces? Do you create a different workspace for each project you work on or have only one workspace for all your projects? Thanks!

Shift-Enter works for string constants but not for free text labels which is where I would like to see it. I suppose I could comment my code with string constants but that seems so... wrong.

As I've been working with Labview for the past year and a half I've noticed there are several trivial tasks I am *constantly* doing that don't matter much individually, but when taken as a whole become annoyances. For most vi's I write 98% of my time is spent on the block diagram. The following suggestions would go a long way towards lowering my irritation factor: Enhance the options for default position for labels. On sub vi's I typically put the control labels on the left and the indicator labels on the right. This leaves the wiring path unblocked and occupies less precious vertical space. I also like to put loop labels in the top-left position. Being able to have different default label positions for different types of block diagram objects would stop the constant repositioning. Free label word wrapping. When using free labels I prefer to use automatic word wrapping as opposed to a hard cr-lf. This lets me easily resize it to fit in the best location. What I end up doing now is typing out enough text to be roughly the width I want, clicking on the box and doing a slight resize to fix the width, then going back and finishing the text. It would be nice to have a keyboard shortcut that essentially says "I'm using automatic word wrapping but I want to stop growing horizontally now and wrap to the next line." Ctl-Enter puts a hard stop in the label; maybe Shift-Enter could be used for this. Working in the block diagram I'm baffled as to why there aren't controls and indicators in the funtion pallette. All the time I'm dragging constants onto the block diagram and then right-clicking to change them to a control or indicator. Why not use modifier keys to change the object being placed on the BD? For instance, if I hold Ctl down while dragging a boolean constant onto the block diagram it would drop a boolean control rather than a boolean constant. Holding down Shift could drop a boolean indicator. Block diagram zooming. I brought this up with an NI rep at a conference and the response I received was (to paraphrase), "We don't want people to create block diagrams more than one screen size." Bleh. Forcing the customer to adhere to your preconceived notions of coding style is a bad idea. Imagine if Visual Studio only allowed 25 lines in each code module because "functions should never be longer than one screen." What would happen? Aside from mass migration to other programming environments people would cram more code onto each line. Goodbye readability. Being able to zoom out to get a complete view of the block diagram is important for me to get a better understanding of what is happening. Yes, BDs *shouldn't* be larger than one screen, but sometimes they are. (We have one engineer who has dual 30" monitors at his desk. His vi's aren't larger than his screen, but they are certainly larger than mine!) I have also found that trying to limit the size of my block diagram actually makes it harder to follow. I squeeze wires and objects closer together in an attempt to make use of the limited space. Being able to zoom out would relieve me of the need to pack everything in. I could layout my objects in a way that is logical and allow more whitespace to ease reading. Integrated Development Environment. This is another request I made to the NI rep. He had an answer that sounded reasonable but I forgot what it is. The fact that fulfilling the wish is impossible doesn't stop me from requesting it. (Yes, please move that mountain 2 miles south so I have a better view of it.) Labview windows all over the place drives me absolutely nuts. I connect my laptop to multiple monitors at home and at work; it is not uncommon for me to open a vi and have the window be located completely off the screen! I might have 8-12 block diagrams (and by extension, front panels) open at any one time. Throw in additional windows for pallettes and contextual help and I feel like I'm stuck in 1995 coding in VB5. Labview really needs an IDE with dockable toolbars, tabbed code windows, etc. Front panel auto-home. The front panel has a home location indicated by the large dot on the grid. Sometimes front panel objects get shuffled around such that the home location is either covered by an object or way off the screen somewhere. How about an easy way to automatically return the home location to the top left corner of the FP window?

QUOTE The xml doesn't know anything about the datatype, but the data is typed by the surrounding tags, yes? QUOTE even test it against a DTD or XML Schema. *blink* *blink* [*Looks blankly at Jan silently wishing I understood XML better*] The schema Labview uses is pre-defined and fixed. I assume it would pass (or fail) every time. How would I use the results of that test to figure out the data the xml document has? Here's my problem in a nutshell. I have a Java app and Labview app communicating via network sockets and using xml fragments to pass the data. Every so often Labview requests a packet of data from Java but it doesn't know exactly what information will be coming. Maybe it will be a cluster of 3 DBL fp numbers, maybe it will be a single U8, maybe it will be a string and boolean. How can I unflatten the xml string without knowing beforehand what the data structure looks like? I could parse the string to figure out the datatypes inside but that defeats the whole purpose of using xml.

(This question grew out of my question on this thread.) I'm not all that familiar with XML so maybe this question is a little stupid... When using the Unflatten From XML vi, why is there a requirement to define the type being received? The xml data already has the type information embedded in it. As near as I can tell this requirement means I must know what data I'm going to receive before actually receiving it.

Right now the list is very small. Labview will request a data packet and the Java app will send it. That's it. I'll take your word that's it's not ugly but I'm an engineer, not a programmer, and this is outside anything I've ever done before. I suppose I have to start climbing the learning curve sometime. (Anyone have simple sample code they can post?)

Yikes! That sounds ugly. Thanks for the tip--guess I'd better break out the help files.

We currently have a fairly standard test station setup that consists of a computer running Labview, a mechanical actuation system, and a device under test (DUT.) Labview sends commands the the mechanical system via a motion controller telling it how to interact with the DUT. The DUT then sends data back to Labview via a USB-8451. The data loop looks like: Labview -> Mechanical System -> DUT <--> Labview I have just received a request to use this test setup to test some new prototypes; however, in the prototypes the DUT firmware is being emulated by a Java application running on a pc. The conceived data loop looks like: Labview -> Mechanical System -> DUT -> Java Application <-?-> Labview Before I knew the firmware emulation was written in Java I suggested the developer strip the UI and package the functions in a dll so I could wrap it in a vi and implement it directly in my Labview app. AFAIK, dll's can't be created from Java apps. (But I have no experience with Java so I don't really know.) I'm not too fond of have the two applications running simultaneously; getting them to communicate reliably seems like a great way to get in over my head. (Read - take me a really long time to do.) I'm also worried that route will introduce too much latency when Labview requests a piece of data from the DUT. Unfortunately I don't know Java and the firmware emulation developer doesn't know Labview so at the moment we're looking at each other across a chasm trying to figure out how to bridge it. Anyone have ideas to get me pointed in the right direction?

<smartass> QUOTE Yep, did that. There are serious problems if A<X and A>Y at the same time... QUOTE the problem with your design is that it is difficult to tell at edit time if you handle every case True. Luckily for me my code only requires three cases to be handled so it's not *that* difficult. QUOTE I would avoid this route if possible. Too late! The tablets have already been chiselled and given to Moses. QUOTE You forget that more than one of the case may be true simultaneously. In the general case, yes. In my particular case, no. (At least, not under normal human circumstances. I make no claims as to validity of my statement when applied on the quantum scale, at relativistic speeds, or in alternate dimensions.) QUOTE Therefore I suggest the following modification. My mind's made up. Don't confuse me with the facts! QUOTE This is an overkill for the example in this thread. Truer words were never spoken... </smartass> In all honesty I really appreciate the comments and suggestions. Since I've moved beyond that section of code I doubt I'll go back and change it but now I have better ideas of how to handle it the next time the issue arises. Despite its ease of use, one of the Labview annoyances that still gets to me from time to time is the amount of clicking through to different frames are required to grasp the big picture. Case structures, event frames, diagram disable, and stacked sequences all hide code increasing, for me, the amount of time required to absorb the code. In my original post the text algorithm took 9 lines and it is easy to see all the code at once and grasp the meaning. Labview implementations are a little more obscure and require more effort to implement and decipher. </whining> QUOTE(jpdrolet @ Aug 18 2007, 01:26 PM) I don't like embedded cases so the following structures most closely look like an elseif structures: http://forums.lavag.org/index.php?act=attach&type=post&id=6681''>http://forums.lavag.org/index.php?act=attach&type=post&id=6681'>http://forums.lavag.org/index.php?act=attach&type=post&id=6681 Actually, if I'm reading this right I don't think it works. The case containing "Meh, go home" is supposed to be evaluated only when all other cases are false. The way I see it there are multiple cases being evaluated when A<X or A>Y. One way to write the text equivalent of your code is: If A&lt;X then ' Do something interesting If A=Z then ' Wow! Hold on to your shorts! Else ' Meh, go home End IfElseIf A&gt;Y then ' Do something more interesting ' Meh, go homeElseIf A=Z then ' Wow! Hold on to your shorts!Else ' Meh, go homeEnd If

I figured out something that is (IMO) better than nested case structures and slightly cleaner than a series of comparisons with string assignments. (Probably not as good as a formula node though.) Instead of doing comparisons in series, I do them in parallel and output the results to a boolean array. Then I convert the array to a number and wire the number into the case structure. By setting cases for conditions number=2^n I can easily cover all my cases. The case names are numbers rather than descriptive but I can work around that by putting a test comment in the case.

All variables are doubles in this particular instance. Hiding all the comparisons in a sub vi is a valid option... I was just hoping for something a little more elegant.

Sorry for the double post. IE choked while I was writing this and unbeknownst to me posted a garbled, incomplete message. See the other post instead.

I have one variable I need to compare against several other variables in order to choose which case to run. It's easy to do in text languages using ElseIf or Select statements, but I can't figure out if it is possible for Labview case structures to be defined by variables. If A&lt;X then ' Do something interestingElseIf A&gt;Y then ' Do something more interestingElseIf A=Z ' Wow! Hold on to your shorts!Else ' Meh, go home.End If I could do a series of comparisons and send a string to the case structure telling it which case to execute but anything more than a couple cases makes the block diagram very ugly very quickly. Is there any way to define a case using a variable?

I have one variable I need to compare against several other variables in order to choose which case to run. It's easy to do in text languages using ElseIf or Select statements, but I can't figure out if it is possible for Labview case structures to be defined by variables. Pseudocode[/u]If A&lt;W then [u]

QUOTE Yep, spot on. When you put it like that my request seems rather silly. QUOTE One other caveat of having clusters inside of an array is that it makes it impossible to change the behaviour/properties of a specific control inside one of the clusters, like blinking or disabling, since all of the properties of each element follow suit and they all blink/disable. I discovered this too and it put the kabosh on the whole idea of clusters inside arrays on the front panel. In addition to my original question I learned a fundamental concept I hadn't picked up on. Building arrays in the block diagram provides most of the benefits of an array while avoiding the front panel restrictions. Thanks orko!

Thanks for the responses. I've used arrays of clusters on the front panel before but it always felt like an inadequate solution. Come to find out it is...

I have created a cluster to control the various parameters of a device we are building. Included in the cluster are three buttons, Start, Stop, and Select. The cluster controls 1 of 8 channels the device has. Since the channel controls are identical and I need to iterate through all of them regularly, naturally I thought this would be an ideal place to use an array... Now I'm faced with the problem of figuring out how to generate and handle events from within each array element/cluster. The event handler structure doesn't appear to let me drill down into array elements. It *will* generate an event if I click somewhere within the array. Using a complex series of coordinate masks, mouse button filtering, and value change comparisons I was able to get the Select button to behave how I want, but it's going to get really messy if I try to implement Start and Stop buttons in a similar fashion. Is there an easier way to access cluster element events that are embedded in an array? Or am I completely missing the boat by trying to use an array for this? Thanks