oskarbosch

I'll be using that VI. As one of the reasons for me to move to 2010 was the separate compiled code. how do I control where labview puts the compiled code? (Note: have not looked into that yet either....)

I ended up making three customized controls of the 3 graph types. Now I just use those instead. I really never have had any use for the scale legend label. It seems to add no value at all. Putting a label there seems more confusing to the user than anything else. Again, thanks for the tip!!!

Perfect solution. :thumbup: Will use that. Much less work then making my own Xcontrol.... I basically got as far as customize control. Did not think to select the scale legend and then select customize control again. Great tip! Again, thanks for the tip!!! :beer:

Interesting suggestion. Seems kind of a work around the real issue though. It limits where you can put the scale legend. And often we have it below the graph. Not to the right of it (where we could move the scale legend labels under the graph). I'll see where I can use this trick. A collegue came with these posts at ni forums: It basically seems that this functionality was there before (Labview 7 and earlier), yet got eliminated in 8. Not sure why. Especially as I have never used those label fields. They are always in the way. Thanks for the tip though.

I would like to hide the text label in the scale legend. Typically LabVIEW always wants to show a text box with the axis label right next to the scaling tools (lock axis, autoscale axis toggle, and formatting buttons). I have attached a small jpeg showing just the scale legend with the two white text boxes (with in there "Time" and "Amplitude"). I was wondering if I would need Xcontrols for this? Any suggestions would be appreciated. Oskar

Kind of late in this post. Just needed error graphs and came across this example. Made me think. Made a modified version of the graph. The sample is creating many, many plots. Giving all kinds of colors.... Changed it to have just one graph, with each point made into 4 points. 1: Original point Xorg, Yorg 2: Xorg, Y+error 3: Xorg, Y-error 4: Xorg, Yorg. Selecting the point style to be the cross (+), it shows very nicely. :thumbup: Another approach (as mentioned above) would be two graphs. Original data, and the error bars using the points: 1: Xorg, Y+error 2: Xorg, Y-error 3: Xorg, NaN This gives just an error graph and would allow you to give it a different color (and point style) than the actual data. Can be useful (just not what a collegue here needed). Thanks for the idea's though. Oskar

Had a project here where we combined Java and LabVIEW. Did not have much problems getting values to LabVIEW. Just make a DLL in labview and call the DLL from Java. (you can find many source examples how to call DLL's in Java, it means writing an intermediate C dll that converts between a java style DLL and a generic windows style DLL which is what LabVIEW exports). We made a DLL that starts up a server part in the background. This server would take care of all the hardware communication. The main issue we had though was passing back big arrays. This caused some errors in the JVM, which we still have not resolved. Seemed to be timing related... But passing simple values was no problem. Hope this helps, Oskar

Using the string method does not seem very efficient, since handling strings is not fast. Another approach could be to find out the range (highest power of 10) of the number, and round relative to that number. Something like: m = log10 (number) p = trunc(m) //so round m to -infinity r = number * 10^(3-p) //where 3 stands for the digits of accuracy newnumber = 10^(p-3) * rounding( r ) Sorry for the weird notation, but seemed easier to explain this way than a LV diagram. Oskar

Looks like you'll have to revert the VI's back to version 7.1. Don't think 7.1 can read 7.1.1 version. Easy check, do file->save with options. And select save for previous version. In there you can select version 7.1 (when using labview 7.1.1 of course). That seems a giveaway that you will have to revert. Puzzled though why the others in the project can not run the 7.1.1 patch? Wouldn't that be more stable/robust than using 7.1?? Oskar

There are two easy ways to approach this : 1/ Use the OpenG commander and use the package that handles variants. There is a very useful function that writes a cluster immediatly to an INI file!! (see this link: http://www.openg.org/content/category/4/67/45/) 2/ use the labview cluster to XML string and vice-versa approach. Then write this XML string to a file / read the string from a file. Oskar

When reading the serial port, always try to: - determine what the end of the message is. NEVER read a fixed number of bytes. - Don't reinitialize the serial port all the time. Not good practice - flush the buffer of "old" data if the instrument could send out other message (as indicated by the previous post). - Always program timeout mechanism, so you don't end up waiting indefinite for your termination character (what if it never arrives???) you indicate that you always read 9 bytes. Change this read mechanism to read until the termination byte (on of your squares, preferable the second one) is received (this will typically be a linefeed (0x0A)). So you'll have to perform you read in a separate VI with its own while loop, where you read a byte at a time until you read the termination character. Hope this helps, Oskar

Also, if you are using windows XP-pro on the computer running the application, look into using Remote Desktop Client, build in XP-pro. When enabled, this allows one user to remotely take control of the computer (just like VNC would). Works very smooth, even over internet (don't know about modem speeds though.... ) The client side is a separate program and can be downloaded from the Microsoft website. VNC works well too and has the advantage to: - work on multiple platforms - still see the screen on the main computer (remote desktop switches to a login style screen) Oskar ps: let me know how you proceed, we're looking into similar stuff as well. Currently thinking of programming some kind of communication protocol in labview using internet technology (XML over HTTP). and write the client in Java or something similar. Flash player could be a good option too....(or AJAX....)

h4med, It looks like, in your VI, you are constantly opening the serial port. :thumbdown: Yet in your VB code you open it only when you load the form. So an easy fix would be to program a little dialog box, with stop button, that opens the serial port only in the beginning, sends the bytes as needed (only when the slider changes, use event structure). that should make it much smoother. :thumbup: Oskar

Joost, The first thing to determine is who is listening to an IP port and who will be sending data to it. If Labview is the "server" then use the "TCP listen.vi" Good place to start is in the function palette communication->TCP. When this listen vi returns with someone who is connected, receive or send bytes using the functions "TCP read.vi" and "TCP write.vi". For Java help I suggest to look into a TCP tutorial at the java.sun website. Look into how to use sockets in java (class: Socket, probably in package java.io). Hope this helps... Oskar

Also, sort of already mentioned by aledain, did you confirm that your serial port works with Hyperterminal. This is always a good first test. If that doesn't even work, then clearly you have a hardware problem. If that works, you might have to check you LV installation (and/or VISA). With LV6i, you might be able to use some serial communications that does not use VISA, but the "older" serpdrv driver. This could maybe be easier for testing purposes since you don't need VISA. With LV6i, check the vi's in the LLB: vi.lib\instr\serial.llb (note that com1 is port 0. So com4 is port 3). Hope this helps, Oskar

I have used serial communication extensively in previous version of LV. I noticed that in LV71 (I guess also in LV7) they changed the serial driver to use VISA. What this means for me right now is: 1/ Have to test a new driver and see how reliable it is. 2/ Will make my installations a lot more complex. Before I had to just install this one file (serpdrv). Now I have to figure out how to get the smallest installation of NI-VISA to work just for serial port communication. I bet it is not as small as the 25Kb that the serpdrv is. :headbang: Can anyone comment on their experience with VISA? How reliable is it? How easy is it to make a small installer (not using the LV app-builder) that installs only the serial port part of VISA? Should I just keep using the old serial port driver (seems not to difficult to "hack" this into LV71)? Anyone with any experience with the new LV71 approach. Also regarding distributing your application. I would appreciate. Oskar