xtal

The conference party is held outside, so it is going to be very hot and muggy. Everything is very casual. The only time you won't be uncomfortably hot and sweaty is in the Convention Center itself. It's usually too cold in there to the point where I'm packing my fleece AND and extra sweater.

QUOTE(PaulG. @ Jul 31 2007, 04:48 PM) I disagree. I've written LOTS of LV code (instrument drivers, APIs, internal dialogs and tools, and now full-blown control apps) and very rarely needed to make anything reentrant. Maybe it's a personal LV style thing, but I think subVI modularity and use of the synchronization tools are easier to understand and maintain. QUOTE(dsaunders @ Jul 31 2007, 05:28 PM) Look in the wiki entry of Functional Global Variable for some more discussion on reentrancy uses. Feel free to fill it out a bit more, as it is a bit sparse in that section. Sharing data across several VIs would require using the VI Server method. Yes, these are great sources of information. In the sake of brevity, I eliminated the second practical use of reentrancy because the discussion was about device communication and mentioning recursion would open up a whole other can of worms. HChandler, back to your device VIs - Have you tested your VIs in a practical setting? I'm asking because LV is by nature multithreaded and the VISA interface is asynchronous by default. Since these details are already handled, you don't need to change that default behavior. I do similar applications where I'm communicating with a couple dozen RS485 temp controllers and I've never had any problems with timing, collisions, etc. No need for reentrant VIs, functional globals, or anything other than the standard defaults.

QUOTE(HChandler @ Jul 31 2007, 02:23 PM) And excuse me because I've been using LV for so long that I've forgotten the jargon of text-based programming. QUOTE OK so lets say I have a sub-vi that is used to poll multiple devices. Because of the peculiarities of bus arbitration, there are long latencies in accessing these devices. What if it is desired that several devices be queried in parallel using the same vi. Say my vi has has an input control node to direct inquiries to different buses and/or devices. Do they still have to wait for completion? Can this behavior be changed either modally or programmatically? A lot of this has to do with how the VIs are written and what type of interface you are talking about. Instrument drivers provide an example. Usually instrument driver VIs are not reentrant, but that doesn't mean you can't communicate with several of the same instruments at the same time. Look at the structure of the 34401 instrument driver that ships with LabVIEW. Instrument drivers are designed to be very modular but at the very bottom level are VISA Reads and VISA Writes. These bottom-level API functions can be set to be asynchronous or synchronous, but this is a feature of the underlying driver-level code in the VISA DLL. Most of the lower-level VISA functions are meant to do their operation and return immediately rather than sit and wait indefinitely. So a higher-level program that calls multiple 34401s won't spend much time in any of the subVIs or functions and it is rare that these calls collide with each other. The only time reentrancy really helps is when you are storing data in uninitialized shift registers and you need to access multiple calls to that subVI in parallel. Describe your application in more detail. What kind of devices are you controlling? What bus? What is considered a long latency? You can use things like occurances, notifiers, user events, dynamic events, etc. to signal and otherwise trigger something to happen as opposed to sitting in a particular subVI polling or otherwise waiting.

I don't have any good recommendations, but I just wanted to let you know that I do a lot of work with .NET assemblies that change versions often. I've been using 8.2.1 and have not had any problems. I've seen the dialog you showed but once I reselected the new DLL and saved all the VIs, everything was fine.

Think of a VI as having four pieces in memory at one time - front panel, block diagram, data space, and compiled code. So a normal VI that is non-reentrant will use the same of each of these chunks of memory each time it is called. What reentrancy gives you is a separate data space for each call, or instance, of that subVI. So if you are storing data inside non-initialized shift registers, you get a clean buffer for each subVI call. The code, front panel, and block diagram will be the same, so the subVI calls don't happen at the same time, they are sharing the same memory for each of the other pieces. However, things are a little trickier if you are debugging reentrant subVIs because you can get copies of each front panel when you open them. I'm going to stop now and see if this helps you understand the concept better. Reentrancy is a complicated topic, so please keep asking questions as you experiment.

QUOTE(DougWilson @ Jul 18 2007, 05:32 PM) Yeah, I was a child prodigy...or something See ya at the BBQ!

QUOTE(orko @ Jul 18 2007, 12:00 PM) Ouch! Seeing as how Doug and I took the very first LabVIEW 2.0 class together, that statement hurts a little. Pretty soon LV will be older than most of the people using it. Cheers, Doug! I'm glad to see you here!

QUOTE(David Boyd @ Jul 3 2007, 03:27 PM) Hmmm, I'm really curious why this behavior is different. The underlying code is very simple. For flat datatypes, the normal V2D is used and for nonflat datatypes, the regular V2D first converts the data to a string and then follows with an Unflatten From String to the type wired to the Type input. That's it. The only reason it needed to be a primitive in LV 6.0 (when the DB Toolkit first released) was because you couldn't make a VI with an input that adapted to *any* datatype. Of course, now we can use XNodes to make a truly polymorphic subVI. Maybe the internal structure of the timestamp changed or its 'flatness' isn't being read correctly in 8.2. Have you tried just using the regular V2D with the timestamp data? Aha!! I just tried it and got it to work. There are slight rounding issues with the decimal seconds, but it appears to work. I guess there's nothing like talking yourself through a problem and ending up solving it. Good luck on the CLA exam!

QUOTE(David Boyd @ Jul 3 2007, 12:40 AM) Yup, I remember that. I'm glad it's still mostly working for you. QUOTE(David Boyd @ Jul 3 2007, 12:40 AM) My first workaround idea is to use the DB Var to Data xnode to convert the datetime variant to a LV string, then pass the string to a Scan From String with a TS constant and a format specifier of %<%c>T. Hopefully the %c will cause the scan to parse the string in whatever format the target used to write the string in the first place. I did get a chance to play around with the DB V2D and timestamps quite a bit last evening and reminded myself of why there were problems. A lot of it has to do with the differences in datatypes in general. A timestamp in LabVIEW is a cluster of 4 I32s, but the VT_DATE (vbDate) in COM is a double precision floating point number that represents the date and the time. I found a couple nice descriptions through Google - here's one: http://www.newobjects.com/pages/ndl/SQLite2/SQL-Typing.htm I'm going to spare you the details of why the DB V2D would need to be completely rewritten to accommodate timestamps properly {unless you want me to go into it in a private message}. Let me just say that the way you are doing it now with converting it to a string is actually the best way. I played around with all sorts of crazy conversions and the string approach always worked. QUOTE(David Boyd @ Jul 3 2007, 12:40 AM) I should also note that the DB Variant To Data xnode fails for timestamps if the input is a LV variant, as well as an OLE variant. Another quirk I just noticed in Scan From String - if you don't wire a default timestamp value, and the scan fails, the previously converted value is returned. (Sort of reminiscent of the original problem with Variant to Data when passed an OLE null.) All of this is observed under 8.2.1. This part is out of my realm of knowledge. I thought LV variants and OLE variants were the same -- thus explaining the same behavior -- but I can't comment on the inner workings of variants. I do lots of .NET work now and thankfully, the variant type is not used. You should report that Scan From String behavior to NI as a bug. That doesn't seem like the correct behavior. QUOTE(David Boyd @ Jul 3 2007, 12:40 AM) Any idea why the DBV2D primitive was removed from LV and replaced with an xnode, And, why was the non-DB V2D node never 'fixed' w.r.t OLE variants? Wow, I could start a whole dissertation on this topic {where is that can of worms glyph when you need it}. I'll give the brief answer here and if you want more details, let me know and I'll fill you in. The main reason the DB V2D was converted from a primitive to an xnode is because primitives are part of the LabVIEW source code and thus tied to a particular version of LV. The DB V2D is only used by the Database Toolkit. Toolkits shouldn't have to be tied to a particular LV version -- as is evidenced by the fact that the DB Toolkit has been at version 1.0.1 for at least 5 versions of LV. Getting rid of that primitive severs the link between the two SW packages and now the DB V2D can be revved with the toolkit. QUOTE(David Boyd @ Jul 3 2007, 12:40 AM) See you in Austin next month, perhaps? I don't work for NI anymore, but since I still use NI products, I'm going to try and attend NIWeek. If I'm at NIWeek, I'll definitely be at the LAVA BBQ dinner.

Yup, I remember seeing that and having a workaround. Sadly, I don't remember what that workaround was exactly. But if you tell me what database app you are using and give me a little time, I can figure it out.

I've been on a Grand Canyon rafting trip for the past 2 weeks. On the first day, one of our boatmen was telling us about a strange guest he had on another trip. The person was a physicist from Europe somewhere and he kept talking about the 5th dimension all the time. I got a good laugh out of it as I was reminded of this thread. It just goes to show - LAVA is everywhere! .... or is that ... Alpha is everywhere!

QUOTE(warnermf @ Jun 20 2007, 11:12 AM) The version of LabVIEW doesn't matter. The database toolkit hasn't changed since LV 6.0. However, the version of your OS and Access do matter. And more specifically, the version of ADO (or MDAC) you use. As a quick check, can you get the examples that ship with the toolkit to work? Try the Logging and Playback ones; I know for a fact they use UDL files and the Jet driver for the connection. If these work, then you know the versions of OS, Access, and ADO are fine. The error you mention seems to be related to the Security options of Access. You might want to double-check with the person administering the database that you belong to the correct workgroup and have the proper access rights to connect with the database. Otherwise, I'm not sure what else to suggest.

QUOTE(i2dx @ Jun 15 2007, 01:50 AM) Actually, there *is* a driver for the Jet engine as shown here: http://forums.lavag.org/index.php?act=attach&type=post&id=6131''>http://forums.lavag.org/index.php?act=attach&type=post&id=6131'>http://forums.lavag.org/index.php?act=attach&type=post&id=6131 The error he was receiving was for the "Microsoft OLE DB Provider for ODBC Drivers" and I was telling him to not use ODBC and instead use the highlighted driver "Microsoft Jet 4.0 OLE DB Provider". ODBC is a technology that is being phased out and the OLE DB Providers are usually better written and support more data types. Yen, you are correct. I've used the Memo field types a number of times with the database toolkit and not had a problem. I really think it's a driver issue.

Actually, the error is occurring in the Microsoft OLE DB provider for ODBC. What I do in these situations is to change drivers to use the Jet driver. You'll have to use a UDL file to connect to the database rather than ODBC. This is how most of the shipping examples for the toolkit connect.

QUOTE(AnalogKid2DigitalMan @ May 24 2007, 11:24 AM) He's coming straight to Flagstaff, so Sheriff Joe and 100 deg heat aren't issues here. My wrath is, though

QUOTE(JasonKing @ May 23 2007, 04:14 PM) Don't bring them to AZ this weekend

Here are my launch times LabVIEW 8.2.1 on machine with no toolkits installed: 3s LabVIEW 8.2.1 with *all* toolkits installed: 30s

QUOTE(Darren @ May 23 2007, 03:03 PM) I traded my XL for a L and it still swims on me. Very sad...I so wanted to wear it.

QUOTE(Darren @ May 23 2007, 02:47 PM) But not all of us are from/in Texas. Variety is the spice of life - I know I also speak for Irene when I say that some of us look really silly in XL shirts and that's why we can't wear our spiffy LAVA shirts to work...or anywhere else.

Way to go, Nancy! I'm with you :thumbup:

QUOTE(JasonKing @ May 17 2007, 11:44 AM) I'm here I had a really long meeting with my local NI Sales guy today and didn't get to LAVA until late. He only comes to visit us maybe once a year, so I need to monopolize his time while I have him. Don't worry Jason, I'll bring you as my official date (unless I lose you in the canyon in the next few weeks ). Heck, we can even plan the "2nd annual unofficial NI-Week bar crawl" together over campfires and cocktails. I don't see where it says the organizers have to be NI employees, do you?

I totally understand Darren's quandary - since LV doesn't have NULLs, the concept of a NULL vote doesn't make sense. While I like the Salt Lick, I wouldn't mind going elsewhere, but I don't have a good alternative (seeing as I haven't lived in Austin for 13 years now). County Line is a good suggestion and is much closer. There should be a third option for "I don't care, I just want to hang out with the cool LAVA people".

That's great news. Thanks for the update.

Actually, ADO can communicate using either OLE DB or ODBC. OLE DB is the newer standard for database drivers, but each Database Management System (DBMS) implements their drivers differently. I've found that the Microsoft and Oracle OLE DB providers are of a much higher quality than their ODBC drivers. However, mySQL only provides ODBC drivers and they work fine. I've personally never used PostgreSQL, so I can't comment on which driver is better or supports more features for different kinds of queries. All I do know is that if one type of driver doesn't work, you use another. Instead of creating a UDL file, you use the Data Sources (ODBC) utility from Control Panel >> Administrative Tools. You create a DSN (name) for that connection and make sure to define all the appropriate parameters. Then when you use the DB Tools Open Connection, you wire a string containing the DSN to the Connection input rather the UDL path. The rest of the code won't have to change.

There isn't anything that jumps out to me as an immediate issue or resolution, so more debugging needs to be done to narrow down the problem. What does the error say? I'm trying to see if it's an ActiveX error, and error in the driver, a LabVIEW error, or a syntax issue. Does the non-parameterized version of that query work for PostgreSQL? Have you tried a simpler version of the parameterized query with different datatypes? Does the problem always occur with a date/time field or with any datatype?