Daklu

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:

1. 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?
   
2. 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.
   
3. 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.
   
4. 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:

1. 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.
   
2. 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.
   
3. 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.
   
4. 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.
   
5. 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.
   
6. 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

And I believe XML doesn't store the datatype inside the XML file

The xml doesn't know anything about the datatype, but the data is typed by the surrounding tags, yes?

QUOTE

*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

If you do take such a route, make sure to use error handling and that the 'default' case is used to generate an error otherwise you will have no feedback of 'unhandled' cases that might arise in the future...

Yep, did that. There are serious problems if A<X and A>Y at the same time...

QUOTE

True. Luckily for me my code only requires three cases to be handled so it's not *that* difficult.

QUOTE

Too late! The tablets have already been chiselled and given to Moses.

QUOTE

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

My mind's made up. Don't confuse me with the facts!

QUOTE

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)

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<X then  ' Do something interesting  If A=Z then	' Wow! Hold on to your shorts!  Else	' Meh, go home  End IfElseIf A>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<X then  ' Do something interestingElseIf A>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<W then [u]

QUOTE

Being able to detect events from elemnets inside of a cluster as an element of an array. No?

Yep, spot on. When you put it like that my request seems rather silly.

QUOTE

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