Jump to content

Michael Aivaliotis

Administrators
  • Posts

    6,196
  • Joined

  • Last visited

  • Days Won

    104

Posts posted by Michael Aivaliotis

  1. beside the obvious that one is a graphical language and other is text based. We need to build a test scheme to test RF components for military and space industry, in addition to mixed-signals ICs. What would be the ideal platform to do the job described above? Why would NI build 2 products when one can do the job so it must be something in it to differentiate the 2 products, right? TIA.

    5750[/snapback]

    I'd love to answer this question intelligently but I don't think you've given me enough information. Yes, one is text based and the other is graphical. You state the following: We need to build a test scheme to test RF components for military and space industry, in addition to mixed-signals ICs. I've done that using LabVIEW. I've also done dozens of other applications in various industries, So? What hardware will you be using? NI or another vendor? Do you or any of your employees have programming experience? In what language? Do you have software engineers in-house or will you subcontract out?

    The main reason for the LabWindows product is to tap into the C programmer market. Those hard-core developers that refuse to use LabVIEW but are fluent in text-based programming.

  2. Ok, just set the record straight. OPC communication is just fine with Datasocket. I've done it and worked with it on about 200 tags.

    Also, OPC servers are a dime a dozen. Pretty much any OPC server you can think of will work with LabVIEW. The job of the OPC server is to provide a constant communication path to the hardware. It is responsible for hardware communications and protocol management. So, the most important question for you in an OPC server is: Does it communicate with the hardware you are using? LabVIEW is ignorant to this.

    OK, so the next question is: what's the deal with DSC module? The deal is that everytime you open a Datasocket tag connection to the OPC server, it opens up a new communication pipe between LabVIEW and the OPC server. 200 tags mean 200 connections. The DSC module opens up 1 sigle communication pipe to the OPC server regardless of how many tags you are reading. This can significantly speed up the update rate of your tags. This is not the only feature. DSC gives you automatic dataloging plus there are smarts like updating values only they're changed etc. One thing to note, Datasocket is free. You can easily try this theory right now (if you have the hardware).

    I've worked with both and can comment more, however one important lesson I learned is that you should try to get the fastest IO pipe you can get. For example, if you have a choice between serial or ethernet, choose ethernet. Whatever's the fastest option with your hardware. The money spent is worth it for the response you will see and feel.

  3. Thanks, I've already been looking in the Write to SGL File VI, but didn't want to change it. Copying and editing is a good idea! Thanks!  :thumbup:

    5120[/snapback]

    I know this is just symantics but in situations like this you can just open the original VI and do a "save as" then give it a different name.

  4. Good eye Michael!

    And a picture just big enough to make everyone VERY curious.

    Barrie

    4863[/snapback]

    Well, if you consider that the dimensions as stated are 1.5" square, it's very small. I like it.

  5. Hi!

    Is it possible to change a horizontal array of leds into a vertical array with some clicks?

    Or must I build it new in vertically arrangement?

    4648[/snapback]

    Sarah, a 1D array can be displayed in both horizontal or vertical. You just need to stretch the array with your mouse down instead of across.

    Unless you are referring to a 2D array? Then you must use the "Transpose 2D Array" function.

    post-2-1114542994.gif?width=400

  6. This was posted to the NI forums and I'm copying it here for commentary.

    It seems that all issues brought up by the community have been addressed. This includes the non-compete language which I personally didn't expect to be changed.

    I'd like to here feedback on this from the LAVA Forum members.

    Over the past few months there have been many postings about software activation and NI
  7. michael,

    and everyone that has offered it, thanks for the advice.  i looked at the presentation and was intrigued by the Queue diagram on page 41.  i was not able to find that code in the download.  is there any chance i can get that actual code?  i have retrofitted some early projects with queues and notifiers, but this is the first project im trying to use queues from the start and i would like to get it "right", if there is such a thing. :)

    thanks,

    robert

    4591[/snapback]

    Actually, this is my favorite little piece of code. It was impossible to cover everything in a 1 hour presentation so I left this code out but I should add it in. Here it is:

    Download File:post-2-1114377201.zip

  8. Why bother checking if it exists? Also, you should just install all the required files yourself instead of calling the NI msi file. I've been doing this for years and have never had problems with my apps not working. By doing this, you let the run-time files become part of your application setup. In order to see what needs to be installed from the run-time, just install the run-time on a virgin machine and take a look at the attached image.

    post-2-1114375224.gif?width=400

  9. how many separate loops can you get away with?

    thanks,

    robert

    post-981-1113333476.jpg?width=400

    4521[/snapback]

    Use as many as you feel comfortable with. There is no limit or right or wrong. One thing I would comment on is how you implement and document them. If you are using 2 loops in parallel then it's ok to have both of them on the same diagram outside of a sub-vi. This is good especially if the communication is mostly done between the 2 loops. As things grow in complexity however you will find that displaying and debugging code with 4 or more loops (on the same diagram) gets complicated. I would suggest you download and review some of the code in a presentation I gave a while back.

    http://lavausergroup.org/niweek2004/meetin...niweek_2004.zip

  10. I'm just throwing this out there to see if anyone else has had this problem. I have a M series DAQ card connected to an SCXI chassis that has a thermocouple module in it. The issue I'm seeing is that after a power failure, when the labview application starts talking to the card again it gives back an empty array of data from the DAQmx vi's (with no errors). The solution is to re-create the DAQmx channel configuration. If the system is shut-down and re-started gracefully then all is fine.

  11. i didn't know about the memory usage of the lv2 global versus the shift register aproach i used before.

    4419[/snapback]

    I would think that the memory usage would be the same since both approaches use a shift register. The only thing I see is a bit of overhead during the conversion process from variant to datatype. Also you have the issue of a call to a VI which takes up very little cpu time but a VI call nonetheless. If this VI will be called from a single caller all the time then I don't see the point. I would prefer to use a shift register in the caller. Like I said before, this would be a good a pproach if this VI is called from multiple callers.

×
×
  • Create New...

Important Information

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