Jump to content

Yair

Members
  • Posts

    2,869
  • Joined

  • Last visited

  • Days Won

    44

Posts posted by Yair

  1. Still, I steadfastly deny any responsibility and suggest Yen be subjected to the :beer: Shiner Bock Beer Torture :beer:
    Don't try to dodge your accountability! You've sown the seed!

    Anyway, I guess this admission will get me thrown out of the forums permanently, but - I don't drink beer, so it wouldn't work on me. :P

    There. I've said it. :oops:

    Now you can have your way with me.

    and in Kermit's famous words: "We now return you to your regular scheduled programme..."
    Didn't work last time...

    Maybe we should invoke Godwyn's law so the thread is closed... ;)

  2. As Neville pointed out, the student edition is basically identical to the FDS, but one other thing which is rather annoying about it is that every front panel will always have the watermark of the student edition. If you're working with a large enough resolution this should hopefully not bother you too much.

    The wireless stuff can be implemented through the Bluetooth or TCP functions (I recommend the TCP over Wi-Fi) and it is extremely easy in LV.

    You should consider the fact that if you are completely new to LV you might have trouble producing a complex application - LV is much simpler to learn and use than other languages, but it's paradigm is somewhat different, and to produce quality results in complex systems requires some experience.

    P.S. Stay away from the base version (the $1,000 one). It lacks some important stuff (like the ability to configure event structures).

  3. An approach that immediately comes to mind is using the picture control - you will need to recognize the number of unique elements and how many connections each one has and decide where in the picture you want to display each one.

    Drawing the arrows is a joke (just create a subVI which recieves the start point and end point and adds the arrow head based on the angle) and writing text is not a real problem (you can easily create another subVI which will even write the text in a filled circle or rectangle), so the main challenge should be the code which decides where to put each element.

  4. My work here is done :)

    Maybe I should have thrown "I'm MELTIIIING" in there as well.

    When I went to that page, I thought "Fair enough, don't think I'd ever need it, but okay if that person needs something like that in their personal toolkit", and then after a few seconds I thought "Hang on a minute..."

    I think that to see why this was nominated here you have to actually open the VI (although it is true that the description also shows that the VI is far from being generalized enough).

  5. You can paste exisiting VIs on to the block diagram of a VI and then wire it up.
    I thought the point was to get rid of the subVIs. :nono:
    There are two things that could solve this. One thing is a complete overhaul of the formula node, making it a complete C compiler within labview, as it should be IMO :)
    Rolf will probably jump in soon enough to tell you that integrating a C compiler into LV is something that would be a huge undertaking and not worth it because that's exactly what LV is not (and you should always listen to Rolf). When he will tell you this he will probably also say that if you're already content to write this in C, you might as well use a real compiler and build the DLL.

    Isn't it nice that time is bidirectional and I can tell what will happen in the future? :D

  6. I haven't played much with dynamic code generation, but as far as I know this is more complex than copying and pasting - you have to select only functions and wires (not terminals) and then you have to replace the existing code and link the pasted code to the appropiate place.

    As far as I remember wires don't appear properly in the Objects[] property and so probably need to be handled seperately. Also, this will probably make your code really ugly (although if this is only for execution this should matter less). The other thing I would be afraid of is the reliability of thing - you wouldn't want your code to be messed up because the programmer overlooked something or because a scripting feature wasn't fully developed.

    If it's that important, it's probably better to do it manually or to write it in a single VI in the first place.

  7. Another thing, since you're working with multiple LV versions -

    I don't know about DAQmx, but at least for FieldPoint, the FP Driver installed on your development machine with 8.0 (FP 5.0) takes the place of the older FP driver and can not work with LV 6.1 and below. So, if you have LV 6.1 and you install 8.0, you will find that you can't use FP with your old LV version anymore. Just something you might want to watch out for, in case there is a DAQ equivalent or if you're using FP.

  8. I haven't done any LV<->Java communication, but using the LV TCP functions is simple and you can find several examples in the example finder (Help>Find Examples).

    Basically, you get a byte stream which is represented as a string. Normally, in the LV implementation, the sender calculates the size of the data and sends a 4 byte string (an I32) which tells the reciever exactly how much data it's going to get. That way, you can always read 4 bytes to get the size of the data and then ask for that size. You can do a similar implementation in your code, where you would (for example) always send x ASCII characters representing the length of the data.

    You can convert the string to a U8 array using one of the functions from the string palette and (if necessary) you can reverse the endianess of the bytes by using the VIs in the Advanced palette.

    I would advise that you stick to sending simple ASCII characters and not try to format more complex data into something that LV will understand.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.