jdunham

Hi Mikael: Even though your non-working code is probably trivial, maybe you should post a snapshot of that too. We do the same operation and haven't seen a problem in built exes. You mentioned it only happens on some computers. Is there a difference between XP and Vista/Win7?

I don't think that's entirely true. If you look at the wires on those arrays where you expect allocations, you'll see that those are not exactly Arrays, they are "sub-Arrays". See this AQ post for more details: -> post #13.

QUOTE (TG @ Jun 9 2009, 10:52 AM) Is '2' the error code from the invocation (System Exec VI), or the return code from the executable? Labview error messages can't be applied to the latter.

QUOTE (horatius @ Jun 5 2009, 03:13 AM) Why don't you just use a smaller array and use regeneration mode? If your input array is really complicated, then you can write some code to check the output status, and write to the output buffer in stages, keeping well ahead of the DAQ write mark. Granted, this is not as simple as the code you posted, but if you are running into memory problems, that's an easier fix than waiting while NI ignores your request to change the API.

QUOTE (crelf @ Jun 4 2009, 01:19 PM) Oh yeah, and we may even migrate to locking someday. The point was "don't let anyone tell you that the merge model can't be used with LabVIEW", even if they work for a very well-respected LabVIEW integrator. Hopefully the OP has figured out that the choice of locking or merging is the major one to make when rolling out a SCC system. But as long as they don't use VSS, they will probably be OK.

Just use Index Array and only wire the second index input.

A running VI has a unique namespace, the Project Name and the context. In VI's title bar (in edit mode) and at the bottom left, the namespace is shown: for example, "My VI.vi Front Panel on MyProject.lvproj/My Computer". I can't seem to find the VI Server property to dig this information out at runtime. I can get the context (with a private VIServer method), but not the project. Ok, I found some code that works, but I feel like I'm missing something more obvious. Is there an easier way?

QUOTE (mesmith @ Jun 4 2009, 10:56 AM) Agreed. We have been using SVN without locking on a large LabVIEW system for 5 years. The main thing is to think twice before committing a lot of recompiled VIs (like when you change a typedef). That makes it more likely to have a collision with another coworker's changes.

You can also enable VI Server in your built application, just by adding the same lines to built app's INI file as the lines in your LabVIEW.INI file (they can be removed later for security). With VI Server enabled, you can use methods like GetControlValue and SetControlValue or hit the Value(signalling) property of the booleans. You can do it from a remote machine with LabVIEW installed, since you probably don't want to put LV on the target machine. The main problem with this is that you probably have to spend time assisting your test engineers writing these little control programs, but it's certainly a reasonable alternative.

QUOTE (Warren @ Jun 1 2009, 01:30 PM) Well a serial port is totally different than a parallel port (well, they both use copper and electrons...). Parallel ports don't have a baud rate. It's a bit weird that VISA controls the parallel port and pretends that it's a serial port but don't let that throw you. If you try to set LPT1's baud rate, stop bits, parity, etc. in Visa, it will probably just ignore you. Most of the stuff in LabVIEW for Everyone should be about serial ports because they are much more common for communicating with real stuff you might get paid to work with. Parallel ports used as digital I/O is mostly for fiddling around when you're too cheap to buy a $100 I/O board from NI. Nothing wrong with being cheap but most companies are going to want the real thing. I'm glad you got it running!

QUOTE (Warren @ Jun 1 2009, 08:04 AM) "278" is NOT going to work as an input to the Visa Port. "LPT1" should work. "ASRL10::INSTR" should also work. If you right click on the VISA port, there are some options as to whether it accepts undefined names. These keep changing with different VISA/LabVIEW versions. The Parallel Port example ShaunR mentioned is at "C:\Program Files\National Instruments\LabVIEW 8.6\examples\portaccess\parallel port examples.llb\Parallel Port Read and Write Loop.vi" on my computer. I don't know if it's on version 8.0, but I think you're wasting time if you don't get your hands on a current version and try this out. The vi.lib VIs which it uses are at "C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Platform\portaccess.llb" Good luck Jason

QUOTE (Warren @ May 29 2009, 01:41 PM) According to http://www.interfacebus.com/Design_Connector_Parallel_PC_Port.html' rel='nofollow' target="_blank">this link, the grounds are on pins 19 and 20. I would expect that most ports just tie all the grounds together. Are you sending ASCII data out? How are you choosing the VISA port to use? Do you have the correct Base Address? Maybe you can post your VI and we can look at it.

QUOTE (Aristos Queue @ May 28 2009, 03:59 PM) Snarky is fine. :laugh: I searched for "embedded object" which ryank had mentioned, but that didn't help. I guess you posted this a few months before I started paying more attention to this site. I'll check it out.

QUOTE (Graeme @ May 28 2009, 03:12 PM) What happens if you replace the case structure with a single-frame sequence structure? I didn't run your VI, but for sure if you remove the case structure, then anything not dataflow-dependent on the queue element will execute long before you drop a message into your producer.

QUOTE (ryank @ May 28 2009, 07:52 AM) Ditto. QUOTE (ryank) However, I disagree that the need for run-time performance ends when an error is thrown. I think this represents a common misconception about errors: that once one happens, normal operation goes out the window. There are many "normal" errors that occur during the operation of most large systems. Timeouts are a prime example, but there are also lots of other examples (buffer overflows, underflows, the FTP toolkit's brilliant idea of throwing a warning after every operation, the timed loop error that is thrown every time you programmatically abort a loop). Per above you don't have to do the string manipulation if you still care about runtime performance. I was just saying that in most cases you don't. If I get a timeout error, then it's not too likely that I can still count on my control loop performance, but of course I can see other situations where it would be essential. "Timed out waiting for flight control system response, ejecting pilot...". Of course if you use the built-in error routines, it takes quite a bit of diagram space to avoid the string manipulation whether or not there is an error. This is really a problem best solved by NI. QUOTE (ryank) As for NI doing something about errors, I'll certainly post my specific error handler code as soon as I feel like it's ready, and Aristos Queue has already posted his embedded object error code. Eventually I suspect more tools will become part of the shipping product, but as this thread shows, it's far from a simple problem, especially since any new system absolutely has to support the overwhelmingly large number of VIs that rely on the error cluster. Well I know it's a hard problem, but I remember presentations about the deficiency of the error cluster in NI Weeks from the 1990s. I've always been kind of disappointed there hasn't been more action before now, though better late then never, I suppose. Suggestions to the Product Suggestion Center seem to go into a black hole from the submitter's perspective. It's actually hard to know what I've already submitted, but I think I have put error suggestions in there in the past. For example, I think the Clear Errors VI is poorly thought out, since it wipes out errors you expect along with errors you might not have. It should have the ability to clear out specific error codes, and to check before and after errors around a specific block of code. Without that, it's a very dangerous routine, and I believe it should be deprecated. Over the past few years I've spent a lot of time working on an error handler, and I know from other LAVA threads that most other advanced users have as well. It's just frustrating that so many man-hours have been put into fixing something that NI could have improved (with user feedback willingly volunteered) long ago. Thanks a lot to Chris for getting the ball rolling for NI Week. I wish I could be attending this year just for that. Do you have a link to AQ's error handler? I thought I remembered seeing it, but Google was no help just now, nor did a search on ni.com yield anything useful.

QUOTE (ryank @ May 26 2009, 02:10 PM) In our system, you can pass in a variant of whatever data wires you want and they are formatted into a string. However, by default this code, along with the code to grab the call chain, only runs if there is an error. There is no string handling unless there is an error thrown. Presumably if there is some kind of exception, need for real-time performance is probably over. All that stuff would be so much easier if it were supported internally by LabVIEW. It would be great for NI to show some leadership on this and modernize the error handling system. This would really boost my productivity. Hopefully at the very least they will attend the NI Week session

QUOTE (n00bzor @ May 27 2009, 12:55 PM) AFAIK, most sound cards are AC-coupled. So you can't just leave them at their max voltage if you want to keep a switch on. I don't think its a practical way to control a digital output. The standard parallel port contains discrete TTL lines. More information is here. If you don't have a built-in parallel port, you should be able to find a USB one for about US$15. These are a bit pricier (US$100), but would be easier to work with http://www.phidgets.com/products.php?category=0 If you want to have a lot of fun, you should ease into something like the Basic Stamp Let us know what works!

QUOTE (crelf @ May 26 2009, 03:01 PM) We use the former approach, putting XML in to the error source. Then it is easy to detect whether the right XML is on the wire, and so what class of error we have. The XML contains the panel name (often different than the VI name), any custom error message which is on the block diagram which generated the error, the call chain, and any run-time data which is autoformatted with something similar to the VariantConfig library.

QUOTE (Michael Malak @ May 26 2009, 03:26 PM) I posted a similar example in http://forums.lavag.org/Next-Newbie-Q-Local-variable-for-an-array-t14082.html' target="_blank">this thread It's a little different but maybe you can get some ideas.

QUOTE (Vladimir Drzik @ May 21 2009, 05:45 AM) I don't think this can work. The run-time engine does not contain the LabVIEW editor. This is on purpose because NI does not want you to build an application which is substantially the same as LabVIEW and distribute it for free under your app builder license.

QUOTE (angel_22 @ May 22 2009, 04:50 PM) Yes, the teachers at your university.

QUOTE (Aristos Queue @ May 22 2009, 06:12 AM) Thanks! :worship: At the risk of pushing my luck, how about a range specifically reserved for OpenG? :ninja:

QUOTE (Warren @ May 21 2009, 02:05 PM) There isn't a one-stop solution for writing a great spreadsheet file. You have to just write your sections in separate chunks. Here is a simple example: http://lavag.org/old_files/monthly_05_2009/post-1764-1242946205.png' target="_blank">

QUOTE (crelf @ May 20 2009, 03:10 PM) I'm not resting assured. My code overwhelmingly uses I32s and DBLs. Often I use Create Constant, but when the type has not yet been determined, then I go from the palette. It would be much better for me to have DBL and I32 available separately on the palette for both FP controls and BD constants. I suspect nothing will change, but you can't convince me the status quo is 'better'.

QUOTE (Aristos Queue @ May 20 2009, 09:40 PM) With a measly 6000 error codes. We've used a good portion of them, and undoubtedly they would conflict with other users' codes if were were ever to share code. I don't suppose we could have a few more of the 4 billion codes available? Whom do we have to waterboard to make this happen?