Mark Yedinak

I was going to say the same thing but refrained. (Side note: I actually had dog when I was in Korea.)

I apologize to anyone I offended. I certainly wasn't trying to.

I think this is a very good answer. This is especially true when taking the CLD test. There are many ways to skin a cat when it comes to coding and style and there isn't a single correct answer. However, it is very important to know the NI answer. That is, you need to understand what NI is looking for when you are taking the certification tests. What I did find was that the process of preparing for and taking the tests was extremely beneficial and it did make me think about my coding. The whole process has also helped me to improve my skills. (I recently passed the CLA exam so I have been through the complete process.)

I like the comic. As for useful reviews my team hasn't really established a formal process yet as we are fairly small. However one thing our embedded developers (using an Agile development process) do with their code reviews which I think makes sense is to exempt code that was pair programmed. The reason being is that if the code was paired programmed you already had multiple sets of eyes looking at it. This can save time during the code reviews. We have used pair programming on parts of our LabVIEW projects and found it to be helpful especially working on challenging pieces of code.

Thanks. There are a few things that should be fixed. At the moment if any varbind returns an error no data will be returned for the PDU. The library should parse the all varbinds and only discard those marked with errors.

One more vote for LVOOP.As others have said scripting is cool and you can do some really powerful stuff. However if you are building systems and not LabVIEW tools I believe that LVOOP will be much more useful to you.

Welcome to LAVA.

Ah, that sounds reasonable. Too bad though.

Here it is. snmp communication.zip

Congrats!

I PASSED!!! I am now a Certified LabVIEW Architect. Woo hoo!!!

Damn it Crelf, I'm a developer not an architect! (Live long and prosper)

If you use UDP and broadcasting you need to be aware that most switches will restrict UDP broadcasts to a single subnet. If you are in an environment where you may have multiple subnets the UDP broadcast scheme may not work in this environment. This has nothing to do with LabVIEW but rather how most networks and switches are configured.

I like this idea as well.

I would have to agree with you.

I would recommend taking the Advanced Architectures course.

I'm with you on this one. I'm not clever enough to catch the pun either.

I would opt for option #2. Have your state open whatever references it requires and close then upon completion. The subVIs will only get a reference to use and therefore it does not need to worry or be concerned about managing the references.

I agree with you. I would hate to be without my TiVo. NOw I just need to upgrade it to the HD XL unit.

That's cool. NI Week is well worth the investment. Not to mention that it is very fun too!

What if you were to add a parallel loop with an event structure to handle the UI stuff. The subVI's can generate an event to update the indicator with the appropriate data. The data can be included in the event itself. Each indicator can have its own event associated with it. For reuse purposes you can have the subVI's test the event reference to validate that a value was passed in. If it is "Not a Reference" it could skip posting the event.

This would certainly be the preferred method if you have the tools. We were very impressed with the new tools when we saw them at NI Week. We are in the process of upgrading several of our licenses to get the software engineering toolkit. However, since the toolkit is an add on I was suggesting other methods that were freely available. If you currently have the developer's suite license and are going to upgrade make sure you inform your sales rep. NI should give you a credit for the VI analyzer that you currently have with your developer's suite license. This can save you a few bucks.

On a Windows machine you can use the native task manager or perfmon. Over time you should be able to see if your memory size is increasing. They won't help you to isolate where in your code your memory leak is but they should help your determine if you have one.

If both sides are using basic TCP sockets than yes, it is possible. One side would have to be a TCP server and listen for connections on a specific port. The other side would be the client and establish a connection to the server. Once the connection is establish you simply send the data. Alternatively if you want less overhead and are not concerned if the data doesn't get delivered (which on a small LAN is not very likely to happen) you can use UDP. You still need a server and a client but there is less overhead when sending the data. There are examples of simple client/server communications in the LabVIEW examples. NOTE: I admit that I am not very familiar with the FPGA LabVIEW code but I am fairly sure they support the native TCP and UDP operations.

If you simply want to communicate over the network using TCP or UDP the native LabVIEW primatives will work fine. If you are looking to have explicit control of the NIC than that is whole other ball game and I am not sure if you will be able to do that easily.