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)

You're going to confuse all of us . Reentrantcy is helpful in many instances, namely any time you have an operation/subvi that is used in multiple locations and/or in parallel data paths...

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)

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)

Excuse me as I make up my own jargon. I'm trying to learn the language of picture programming.

And excuse me because I've been using LV for so long that I've forgotten the jargon of text-based programming.

QUOTE

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)

Crystal, you are not supposed to tell everyone how old we are. But as I recall, you were the youngest one in the class!!

Yeah, I was a child prodigy...or something

See ya at the BBQ!

QUOTE(orko @ Jul 18 2007, 12:00 PM)

1990...well, they didn't have LabVIEW set up in my senior year of high school

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)

My gripe with the xnode is that the primitive version of DB V2D did work with timestamps, at least for me. I have plenty of code that works under LV8 but breaks under LV8.2 because of this.

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)

Hello, Crystal, thanks for the reply. It was from you that I originally got my copy of the DB toolkit so long ago. :thumbup:

Yup, I remember that. I'm glad it's still mostly working for you.

QUOTE(David Boyd @ Jul 3 2007, 12:40 AM)

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)

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)

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)

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)

I am using a .dsn file to connect to my database. I don't see any options to change the provider I am using similar to the "Data Link Properties" window you show below. Where do I do this? I tried creating a new .udl file and setting the "Data Link Properties" to the "Jet" Provider but anytime I test the connection to my database i get the "Test connection failed because of an error initializing provider. Cannot start your application. The workgroup information file is missing or opened exclusively by another user."

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)

If he uses the NI Database connectivity toolkit, me makes automatically usage of the Jet database engine. The Software "Microsoft Access" is only a frontent, where you can create/edit/etc your database. Each Windoze since Windows 2000 comes with the Jet Database Engine installed (it's not a driver, it's the database engine!) => you can automatically use *.mdb-files on each windows machine with an OS higher then Win2k. Besides: you can install the MDAC (Microsoft Data Access Components) on machines with an older OS to make usage of the Jet DBE

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)

Yeah. Sheriff Joe will lock you up in tent city. And were getting back into the 100's in Phoenix. Not a pretty sight.

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)

Swimming in a T-shirt is a lot better than swimming in boxer shorts! While many things in Texas may be big, my ###### isn't. I can't wear my LAVA boxers in public without getting arrested for indecent exposre. I want to be a lot of things in life, but a sex offender isn't one of them.

However, my girlfriend loves it when I wear them around the house :laugh:

J

Apparently we're kid-friendly in here and I can't say "arse". D'oh.

J

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 wish I'd known you had an XL LAVA shirt when you still worked here, Crystal...we could have traded!

-D

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)

Hey, if there's another T-shirt giveaway at the BBQ, make sure to bring plenty of Extra-Larges this time. Remember, everything's bigger in Texas.

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 suppose I can just come here and commiserate with the other ex-NI employees who frequent this joint (Crystal, where you at?) :laugh:

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?