Leaderboard

So I posted my ealier frustrations with the CLA Exam in Nom, Nom, Nom..., and since I recently presented at a user group meeting I was given the opportunity to take the exam again on the 19th. I'd been so busy I haven't had any time to practice but I figured I might as well. The second exam problem was very similar to the first, but I think a few requirements had been removed. My impression was that it had been simplified a bit. The first time around I worked on the api's for each major component and tried to get them connected together via messaging. None of the components were fully implemented. I had developed the messaging structure and tried to make sure the mediator loops (that handle message routing) were routing messages to their correct destinations. Honestly though, I don't remember how complete that part of the app was. At the time I felt like I had developed a reasonably good framework that could be filled in by CLDs who understood the framework. As I detailed in Nom, Nom, Nom..., NI disagreed. One piece of feedback I received from NI while reviewing the first exam was to implement one component completely so developers could use it as an implementation example for the other components I design. I did that this time around, but it took so much time I didn't do any work on several modules and the top end component tying all the pieces together wasn't fleshed out at all. When I finished the exam my solution felt far less complete than my solution for the first exam. There were many [Covers: xxx] tags I didn't get around to working on. I left with no expectations whatsoever and figured I'll keep presenting and keep retaking the exam until they take pity on me or just get tired of seeing my name. To prove truth is stranger than fiction, I passed. I am honestly just as surprised I passed this time as I was that I failed the first time. The overall structure of my app was the same this time around as the first time--components executing in parallel communicating via hierarchical messaging and Harel/UML style state machines as needed. I think I used class-based state machines the first time whereas this time I used a flat state machine contained on a single block diagram. That might have made it easier to understand but IMO is an implementation detail not terribly important to the overall architecture. I'm not complaining about passing but I have to say I still don't understand NI's grading system at all. Here's my scoring breakdown with evaluation comments in parentheses: Style: 10/10 Documentation: 16/20 (Architecture/modules not documented adequately for developer to implement/complete functionality.) Req Coverage: 18/30 (Percentage of requirements covered = 60%.) Arch Development: 30/40 (Comments had 4 different "xxx module not designed.") Baffled... (See y'all at the arch summit! )

Bluetooth and TCP both use the Windows Socket API, so it might be a hang-up internally where bluetooth blocks TCP for some reason. 5-8 seconds sounds a lot like the timeframe necessary for a discovery scan.

Just one final thought on this (probably not relevant). I have seen exactly what you describe when a machine has Bluetooth . The 5- 8 second freezes go away when the Bluetooth adapter is disabled. I never got to the bottom of this since the machine didn't need Bluetooth, so I just disabled it.

You: Similar: Yes, I am a google master.

Not really.....but... The project file is xml. So in the past I have cut and pasted the section <Item Name="Build Specifications" Type="Build"> ..... </item> and it worked fine.

Pierre, We do have a customer application with similar statistic (6000+ VIs but only around 100+ classes) and the build does take about 15 hours. Like you we have a lot of problems with the build (it is very easy to brake it for no obvious reason and when it take so long to do a rebuild this can very quickly eat weeks of your time). Here is some info that might help you. We notice that adding xcontrol can brake our build (ex: adding the 3dsurface plot xcontrol did that [took us 2 weeks to find that this was the issue]). Make sure your build output is as close as possible to the root folder (ex: C\build) so you wont hit the "path too long" issue that plague windows OS. Build that fail do sometime succeed when we do a control+shit+run arrow (re-compiles everything in memory) and a resave. Build that do fail on "regular" 32-bit OS do sometime succeed on 64-bit OS. Sometime adding more memory to the build machine helps. When none of the above succeed we have to try to figure out what was change since the last successful build. Note: we try very hard to do build very frequently to alleviate these issues. We have several machine (for instance Virtual Machine) where we can try several builds in parallel to speed up the debugging. So my first suggestion would be to let the build go until you get an error as it can take a very long time. Also, if you have not done so, make sure you can try the build on several machines (using VMs [Virtual Machine] is really ideal for this tasks). I feel your pain, and I wish you the best of luck. Please report back here when you found out what was the issue. PJM

The rules are simple C programming rules. If you pass an array of handles to C code and resize the array size, you are fully responsible to deallocate any elements that are occupied by the previous array beyond its new size and to allocate any elements thathaven't existed before in the array. Additionally you have to make sure to resize any existing handle to the required size before you modify its contents. And your last remark about that who allocated it also needs to deallocate it, that is ambiguous at least. In C the caller is usually responsible for both since there is no standrad way of passing ownership of memory between caller and callee, but APIs can decide to change that, by allocating and returning memory, but that has to be specifically documented by the API and such an API better provides a function to allow the caller to deallocate that memory later on, since the malloc/free from the API may not be compatible and not even refer to the same heap than the malloc/free of the caller. In LabVIEW the situation is different. LabVIEW uses a standardized memory manager throughout, so this limitation does not exist. Whoever holds onto a handle is responsible to manage and eventually release it and all of its contents. For a C function being called by LabVIEW with native handles, this means you may get in a handle, you may modify it and allocate/deallocate any handles therein, provided you also keep the related information such as the array size consistent. If you then pass the array back (which you basically always do if it is in a value parameter, and usually also if it is a reference parameter, you pass on ownership of that handle back to LabVIEW and it will need to manage it from thereon. An additional tidbit you should know is that LabVIEW uses for performance reasons often a null handle when an empty handle is required, but treats an empty handle also correctly. So your C code needs to be prepared to handle an array of 1000 empty strings to be really an array of 1000 null handles, meaning when you want to write something into these strings you can not just do a DSSetHandleSize() as that will crash on a null handle. Instead use NumericArrayResize() with element type uB, as this function gets the handle passed by reference and will correctly allocate a new handle if it was null.

Hi there. Could you post a link to the VIs that are giving you trouble here? If you don't feel comfortable posting the VIs publically, you can always privately email them to me at doug.tucker@ni.com I would like to do some further testing, as we've recently addressed and fixed an issue with astronomical numbers in the profiler (hopefully the fix will cover this case as well). If not, we will look into it!

OK - I may have found out something useful here - here's the timeline. I loaded the LV read and write VIs (using LV 2011 - downloaded it here at NI Week!). The first time, it ran until my computer went to sleep (about one hour). Then, it would pretty consistently fail between 2 and 40 minutes. So I started poking around and looking into the error code and who failed first. That lead me to suspect a timeout problem. I set the timeouts on both the read and write TCP functions to -1 (wait forever) and started it up last night. It was still running this morning (8+ hours). So, this is only a single data point, but it may be useful. Also, you have the writer listening for the reader. Although I think there's no reason while this is wrong, it seems to me that it's more typical for the data consumer to invoke the listener (most LV written server examples use this, I think). I also can't think of why you wouldn't want the reader/writer to wait for data up to forever as long as they have a valid connection - if the connection dies, the functions will stop blocking and return the error (not just lock up the system). I hope this helps, Mark

I've had the VIs running on a WinXP SP3 Core2 Duo 2 Ghz machine with 2 GB of RAM under LV 2011 for about 1-1/2 hours with no sign of issues. Can try with LV 2010, but don't have 9.0 installed. Tim

Have you tried playing with the mode input from TCP Read? Do you use message termination scheme with CR LF or something else? Basically LabVIEW defaults to a semi buffered mode but most simple socket programming without any poll() operation resembles more the immediate mode of LabVIEW. A mismatch in this mode with what a C program expects is usually the most likely reason for the behavior you see. The C Read with LabVIEW Write most likely will simply work if above is the culprit.

What sort of throughput are you trying to achieve? You could try and give LV a bit more time to service the TCPIP stack by increasing the buffer size.