Jim Kring

One thing that I would like is support for arrays in the To More Generic Class and To More Specific Class functions. For example, if I have an array of Lines, then in order to convert them to an array of Graphics (Lines are Graphics) I have to use the To More Generic Class function inside a For Loop (as shown below), since the function does not support arrays. http://forums.lavag.org/index.php?act=attach&type=post&id=6641 What I really want to do, is omit the For Loop and have the To More Generic Class function adapt to the array. But, it doesn't, as you can see in the screenshot below. http://forums.lavag.org/index.php?act=attach&type=post&id=6642 Additionally, To More Specific Class could benefit from support for arrays, but with an important consideration: it has an error output. Unlike To More Generic Class which detects type errors at edit time, To More Specific Class detects type errors at run time. And, since this function can generate an error, it might be ambiguous as to which element of the input array generated the error. There are basically two behaviors that one might desire: 1) Make the error output an array (as shown below). http://forums.lavag.org/index.php?act=attach&type=post&id=6643 2) Make the error output a scalar an stop iterating over input elements when an error is raised (as shown below). http://forums.lavag.org/index.php?act=attach&type=post&id=6644 Perhaps the user could chose between these two behaviors via a right-click option on the nodes. Or, if that's too much work, maybe behavior #2 would be standard and the user could then call Merge Errors explicitly to convert the error cluster array into a scalar (as shown below). http://forums.lavag.org/index.php?act=attach&type=post&id=6645 NOTE: There are other functions that could benefit from added support for arrays. For example, how about Close Reference?

I guess it didn't go so well for Heiko: http://forums.lavag.org/Problem-with-conve...V-85-t8847.html

See here for more info.

I haven't upgraded any existing projects to 8.5, yet, and I'm wondering how it went for everyone else? Please post your experiences here and let us all know how it went. Thanks,

We are planning to add support to the polymorphic VIs of the OpenG Array Tools library for some new datatypes and we want your suggestions for other datatypes for which we should add support. Please take a look at our proposal and post any feedback or ideas, here: http://forums.openg.org/index.php?showtopic=645 Thanks, -Jim

QUOTE(PJM_labview @ Aug 15 2007, 11:56 AM) <Even more shameless plug> If you can convince them that VIPM was actually written in LabVIEW (I once had trouble convincing someone that it wasn't written in C) </Even more shameless plug>

QUOTE(Aristos Queue @ Aug 2 2007, 09:08 AM) Any word yet on whether this might be addressed in a future version of LabVIEW? Thanks, -Jim

QUOTE(Ben @ Aug 14 2007, 01:12 PM) No, I don't think so. I'll be using them for quite a while.

QUOTE(jdunham @ Aug 13 2007, 04:42 PM) Since the whole point of DAQmx is to have context sensitive functions (on top of a well designed state model) that simply "do the right thing" when they are called, I'm guessing that the DAQmx API designers would agree that calling the DAQmx Read function on a task that is not yet running should repeatedly try to start the task (until a timeout occurs) if a "resource already in use" error occurs inside the DAQmx Read function. This bug is going down...

QUOTE(jdunham @ Aug 13 2007, 03:37 PM) Jason, Thanks for the advice. I'm sure I can get it working. It's just pretty odd that my use case isn't addressed under the hood. I've seen this error several times in trivial scenarios and I can't understand why it should be the user's problem to avoid the "resource busy" error when a timeout is specified. I opened a support request with NI at the same time (2 hours ago) that I started this thread on LAVA. So far I've only gotten automated responses from NI stating that someone will respond to me within 6 hours. The fact that I've already gotten about 5 responses on LAVA is a testament to what an awesome resource and community we have here Cheers, -Jim

Hello Everyone, Thanks for the responses! I am using a PXI-6225, which is an M Series device. I have not configured any additional timing -- I'm simply calling DAQmx Create Channel several times at startup to create all of my channels and then calling DAQmx Read (Analog DBL 1 Chan 1 Samp) to read any given channel on demand. Thanks, -Jim

QUOTE(Ben @ Aug 13 2007, 11:27 AM) I don't think that NI ever served us food from The Salt Lick. Even if they did, it was probably from The Salt Lick 360, which is not nearly as good, because it's not fresh off the BBQ. Oh yeah, I had prime rib last night

I have a large system where we are using DAQmx to acquire several analog voltages. Due to architectural considerations, we have decided to use separate DAQmx tasks for reading each channel. Here's the problem. We occasionally get error -50103 which states that "The Specified Resource is Reserved". I was able to find an NI knowledge base entry, Causes of NI-DAQmx Error 50103 "The Specified Resource is Reserved", which addresses this issue. Basically, the problem is that DAQmx Read is reentrant and I'm trying to read two channels (using separate DAQmx tasks) on the same board at the same time. Why would this cause an error? The DAQmx Read VI has a "timeout" input that defaults to 10 seconds! Why can't DAQmx Read simply wait until the resource is no longer "reserved" and then read the channel. If the resource does not become free before the timeout occurs, then I am fine with getting a timeout error or even error -50103. IMO, this is either a bug or a very poor design of the DAQmx API/behavior. My solution is to create a wrapper VI around DAQmx Read which implements a retry (in a While Loop) when error -50103 occurs, until the timeout expires. I'm also going to contact NI to see if I can convince them that this is a bug or valid feature request. Either way, I'll post updates here if I learn anything from NI. Does anyone else have experience with or thoughts about this issue? Thanks, -Jim

QUOTE(Aristos Queue @ Aug 10 2007, 02:12 PM) Woohoo!!! Thanks, NI :thumbup: -Jim

QUOTE(crelf @ Aug 10 2007, 11:42 AM) No, because http://thinkinging.com/2007/06/04/openg-is-an-unfair-advantage/' target="_blank"> OpenG is an unfair advantage.

QUOTE(crelf @ Aug 8 2007, 08:55 AM) http://forums.lavag.org/index.php?act=attach&type=post&id=6569''>http://forums.lavag.org/index.php?act=attach&type=post&id=6569'>http://forums.lavag.org/index.php?act=attach&type=post&id=6569

I think we should stop here: Texaco On the Move120 Slaughter Ln W Austin, TX 78748 (512) 292-8169 >> Google map of route and pinpoints <<

If I were to go LabVIEW easter egg hunting, I would probably open LabVIEW.exe in a text editor and look for words that might be INI keys (e.g., written in CamelCase)

QUOTE(Tomi Maila @ Aug 3 2007, 02:40 PM) I agree! I've been using LVClasses to try to implement some well-established design patterns and found that recursion is very necessary. Thanks AQ :worship:

Don't forget about the LabVIEW 8.5 Portal and especially New Features in 8.5. :thumbup:

One LVClass usability feature that I'd really like is to see (in addition to the ones you mentioned) is... When I right-click on a class method (or class wire) and choose Replace>> (or Insert>>), I'd like to see a list of the member VIs that I am allowed access to call (for example: private, protected, and or public) from the VI whose diagram I am working on.

I'm looking forward to seeing everyone at NIWeek! Woohoo, it's almost here! Please, come say hello. JKI's booth (#341) is once again strategically located next to the LabVIEW Community area at the back of the expo floor (map), so that we can pretend like we're working while we actually hang out and chat with our LabVIEW buddies Cheers, -Jim PS - I've just posted on my blog about some of the stuff I'll be doing at NIWeek.

Bug 1) When you drag and drop an LVClass onto a file path control, I would expect it to behave just like dragging and dropping a VI onto a file path control: the path to the LVClass file should be populated into the value of the path control. What currently happens is a LVClass refnum is created on top of the control. (Basically, LabVIEW just ignores the fact that you dropped the LVClass onto the path control and treats it as if you dropped the LVClass onto the VI's front panel). Bug 2) When you drag and drop a project document (a non-LabVIEW file type such as a TXT file, MS Word Document, etc.) from the Project Explorer window onto a file path control, I would expect it to behave just like dragging and dropping a VI onto a file path control: the path to the document should be populated into the value of the path control. What currently happens is a new file path control is created on the VI's front panel that is pre-populated with the path to the document!? Please tell me what use case this enables -- I can't think of any reason to want this behavior. Anyhow, that's all the complaining I'll do this morning. Gotta get back to preparing for NIWeek. Cheers, -Jim

Martin, Yes, that's very helpful. Thank you, -Jim

Martin: Do you know which setting change, specifically, caused the problem? This info would be useful to us for trying to reproduce, fix, and document the problem on our end. Neville: Thanks for the suggestion. I'm glad this worked! Thanks, -Jim