David Boyd

QUOTE(NormKirchner @ Aug 17 2007, 01:39 AM)

Just thought up one for the more "senior" members of the community

Front: Getting old stinks

Back: I have memory.cpp problems

I would've liked to have had one of those colorful tie-dyed T-shirts at NIWeek with the message "Keep Austin Wired". I actually mentioned this in jest to a couple of the NI folks at the registration booth, but of course it's a non-starter idea for the following reasons:

- it's too local a joke

- the joke doesn't translate

- it would probably infringe on the original, which is copyrighted

- it's too geeky even for them

Dave

I'd like to join the fray but this year the whole family is here, and I got the kids passes to come in and watch the Lego Robotics event. Chris, any chance we could join up later on? We've got our own wheels for this trip. Needless to say, I didn't pre-register, so if we come we'd be paying for our food on our own.

As I write this, I'm waiting for the exhibit hall to open up. Been in class all day. I'll look for replies later on this evening.

Best wishes,

Dave

QUOTE(John Rouse @ Jul 7 2007, 12:33 AM)

Has Anyone succesfully implemented multiple (as in more than 8) serial ports using one or several USB

ports?

I really want to relieve this 16 port PCI card from my PC so that my platform can be more portable.

One other option you could consider, if you're looking for 16+ ports, is a portserver device over ethernet. I recently built a system which used a http://www.digi.com/products/serialservers/etherlite.jsp' target="_blank">Digi 32-port device. A second, private ethernet port on the PC running LabVIEW isn't essential, but is helpful to keep the traffic off the corporate net. Digi's drivers manage the portserver so the application code and VISA only address local com ports. The name mapping from com port to physical socket stays constant, which seems less likely with some USB solutions I've seen.

About 40USD per port added, which seemed reasonable.

Dave

QUOTE(xtaldaz @ Jul 3 2007, 01:20 PM)

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

Yes, it continues to work very well for me - as you said, it hasn't been rev'd since 2001 but is still useful.

QUOTE(xtaldaz @ Jul 3 2007, 01:20 PM)

I thought the TDM developers used such a cluster, but that was from the days before it became a true datatype. I read that it's a 128-bit fixed-point number, with 64 bits each side of the radix, so I guess that's the same memory footprint.

QUOTE(xtaldaz @ Jul 3 2007, 01:20 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.

QUOTE(xtaldaz @ Jul 3 2007, 01:20 PM)

Agreed, but solely because the interpretation of the string at runtime can be guaranteed to use the same localized date/time format that the variant to string conversion used. If this were not so, this would be a non-portable mess. I've seen other cases (in the Report Generation toolkit) where LV floating point values get an intermediate conversion to string before being passed to the Office automation methods, and some LV toolkit developer made a one-size-fits-all decision for how many digits are significant. This is why I avoid intermediate string conversions.

QUOTE(xtaldaz @ Jul 3 2007, 01:20 PM)

I think of them as separate entities based on the variant display in LabVIEW - if I set 'Show type' it displays 'OLE Variant' and 'Variant type->VT_DATE', etc., for variants returned by ADO or Office automation objects. If wired to the output of the LV 'To Variant' bullet it lists the LV datatype.

QUOTE(xtaldaz @ Jul 3 2007, 01:20 PM)

Done, but I reported the bug against a later version of LV.

QUOTE(xtaldaz @ Jul 3 2007, 01:20 PM)

I knew you left NI awhile back, it's great to have your expertise available here in the user community. Perhaps I'll see you at the Salt Lick; this year, the whole family will make the trip (to tour the Austin/Hill Country area while I take the CLA exam), so who knows where we'll go in the evenings.

Again, thanks for all your insights.

Dave

QUOTE(i2dx @ Jul 3 2007, 01:17 AM)

If the timestamp conversion does not work, just let me know, I'll fix that ...

Thanks, Christian. I just checked your toolkit VI (under 8.2.1) and I can tell you that it does not work for me.

I think as a general approach you want to avoid trying specific date/time text formats as your VI does. The approach I described (variant converts to string, then scan from string converts to LV timestamp using system's default format) works for me, but I can't be certain it will work under all OS/localization settings.

Thanks for your input on this. I've attached a VI (I stole your icon :ninja: ) to illustrate; any testing you could do in your environment would be greatly appreciated.

Dave

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

The DBs I'm currently using are still Access (2003), though I'm planning to migrate to SQL Server Express 2005 soon.

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 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.

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?

See you in Austin next month, perhaps?

Dave

Just discovered this while attempting to migrate a project from 8.0 to 8.2.1 which uses the Database Connectivity toolkit...

Looks like the Database Variant to Data primitive was mutated into an xnode in LV8.2 (I frankly hadn't noticed). The xnode type-adapts to the LV timestamp datatype when wired, but I can't get it to work. Whether the input variant is a VT_DATE or a VT_BSTR, the output of the node seems to be stuck at zero timestamp.

Anybody else notice this? Workarounds would involve an intermediate conversion to and from string representation of time, which always seems a bit iffy.

Dave

Ben,

Of late, we've used several Vartech 19" rackmount LCDs (running 1280 x 1024 native resolution) which are fitted with capacitive touchscreens. They're used on a general production line environment, and they've been very well accepted by the folks who interact with them. The LV app runs fullscreen and has a minimal number of tabbed pages, using slightly outsized buttons, dropdown listboxes, etc.

Not too expensive, though Vartech occasionally sends me marketing emails touting their latest 46" sunlight-readable touch-enabled hi-res NEMA4X-firehose-washdown models, which I don't even want to hear the cost of...

...but there are Vartech models larger than 19" which may fit your requirements without bankrupting your client.

Did your question about "large screen sizes affecting performance" imply large desktop pixel dimensions? Even the jumbo (32" and above, widescreen format) monitors I've seen typically only have resolutions of 1920 x 1080 or so, which seems a typical hi-res mode for any good desktop graphics adapter.

Good luck!

Dave

QUOTE(David Boyd @ Mar 26 2007, 07:17 AM)

OK, now that we're pretty far off-topic...

I remember a science-fiction story in which one of the characters was a girl whose name was mis-pronounced as 'Slally' because of a speech impediment... does anybody here remember the author/title? Chris, was that a typo or a sly reference to the story?

Dave

OK, found it (Google is your friend)...

http://www.amazon.com/Prince-Ombra-Roderick-MacLeish/dp/0312890249' target="_blank">Prince Ombra - Roderick MacLeish

QUOTE(LV Punk @ Mar 26 2007, 06:40 AM)

Don't worry, I think that was actually clerf http://forums.lavag.org/index.php?act=attach&type=post&id=5299''>http://forums.lavag.org/index.php?act=attach&type=post&id=5299'>http://forums.lavag.org/index.php?act=attach&type=post&id=5299, crelf's evil twin brother replying...

OK, now that we're pretty far off-topic...

I remember a science-fiction story in which one of the characters was a girl whose name was mis-pronounced as 'Slally' because of a speech impediment... does anybody here remember the author/title? Chris, was that a typo or a sly reference to the story?

Dave

QUOTE(JFM @ Feb 23 2007, 03:07 PM)

Hi,

I don't know if this classifies as a bug or not, but I find it very annoying that simple arithmetics (lika add, subtract etc.) does not work with the Timestamp datatype. At least not returning a TimeStamp datatype in the result.

What do you say; is it a bug, a requested feature...or is it just me

/J

Nope, this is not a bug. It is IMO the only way timestamp math should work.

Remember that timestamps are a LV datatype which represents one thing only: an absolute point in time, timezone-independent, in the LV epoch (January 1, 1904). Valid operations on a timestamp include:

Adding a numeric (seconds offset). Result is a new timestamp.

Subtracting a numeric (seconds offset). Result is a new timestamp. Note that the subtract primitive only allows the offset to be wired to the subtrahend, not the minuend.

Subtracting another timestamp. Result is a numeric (seconds offset).

You cannot add two timestamps (adding two absolute points in time is meaningless).

You can increment or decrement a timestamp (the unit is, of course, one second).

You cannot multiply or divide with a timestamp.

You can round a timestamp. This rounds to the nearest whole second.

You can compare timestamps with other numeric types, or test for zero value.

Transcendental functions, exponentiation, and negation are right out. (Neither shalt thou count to two, excepting as thou proceedest to three...)

I'm not sure what 'pain' Herbert refers to. The primitives work just fine for me in all the use cases I just listed.

Hope this helps.

Dave

... What constructor shall I select from the list in the "Select constructor" window ?

You should not need to browse for DLLs...

On the block diagram, drop a .NET constructor node (Connectivity->.NET->Constructor Node). From its configuration dialog, select the 'System' assembly from the dropdown. Find the 'System.Diagnostics' entry in the objects list, expand its tree and select 'PerformanceCounter'. From the list of constructors, I chose the constructor prototype which takes two parameters, categoryName and counterName. Wire string constants to these as I showed in the BD snippet. Then you'll need a create a .NET method node for NextValue() as shown. Dispose of the reference when through.

If you're going to invoke this repeatedly, you should consider placing the constructor outside the loop, and maintain the reference wire for calling NextValue(). The .NET constructors seem to be pretty time-intensive to execute (in my experience).

Hope this is clear.

Dave

This BD snippet shows one way to get this info, though it assumes you're running under Windows and have access to .NET methods.

Hope this helps.

Dave

EDIT: The constructor is from System.Diagnostics.

Is there any way to turn off the "feature" of a Multicolumn List Box (MCL) where a tip strip pops up with the full text contents of the cell? It becomes annoying when it pops-up just as you are trying to navigate to the column seperator to resize the column. I feel like smashing my head throught the screen when that happens. :headbang:

Michael,

Are you talking about behavior at edit, or runtime, or both? I've been bothered by similar behavior with tables starting in LV8.0. I have an app which accepts user touchscreen input over a table indicator. To provide feedback for the user, I track the touch/liftoff/drag info and I rewrite the text for the highlighted row using a bold font. If the extent of the bolded text exceeds (ever-so-slightly) the size of the cell the user is pointing to, LV generates the tipstrip, which can interfere with the tracking process. I think there's also an obscure race condition - when I register the touch liftoff (mouse up event), I flip to a different tab of the tab control which owns the table, and sometimes the tipstrip window remains. My wish is that the feature could be disabled on a per-control basis.

Best regards,

Dave

...and this page shows the reception of the daily diegest. There's also this page which doesn't have "opserver" listed, so the server's down at the moment.

Chris,

I think the opposite is true.. if 'opsserver' is not listed, that implies that the server for Info-LV (and the Igor list too) is not down, at least in the sense that it's pingable w/in Scott's local network. So as Gavin surmised, there must be some other problem.

As others have posted, I've had in-digest-ion since the 3rd of January.

Best regards,

Dave

I had time to screw around with this some more recently and found out that there actually is a full VI in here, which I somehow missed the first time around, but I seem to be having an error when trying to run it.

We PM'd back and forth a few times about this way back when you first posted. The 146C is a controller device for the MFCs. Are you sure you don't have access to the MFCs directly? Can you reply with any of the part numbers for the MFCs?

Was this supposed to be a simple control project you intended to implement in LV, or is this part of some much larger system?

Still curious...

Dave

Hi all

Have you see that we have a free (i think) graphics library with labview (exist in 7.0, after i don't know) .

Look at : National Instruments\Shared\Graphics and run symfac1.exe

Regards

Eric

OK, folks, what am I missing here? I have PDS 8.0 and 8.20 installed on my laptop, and I don't have a 'Graphics' folder under my 'Shared' folder. Does this come with a toolkit I don't have, like Vision?

Somewhat puzzled,

Dave

Ya, Google's really improving their satellite imagery.

OK, Michael, care to tell us where that image is located? Just curious.

Dave

P.S. I love looking at the member map and spotting the ones who are out in the Arctic Ocean or in the Patan

I'm with Mike - this is not a good way to start on LAVA. Irrespective of whether you are lazy or not (I know I am ), I strongly suggest you try to show us that you've treid - we expect that from everyone, not just students. Please upload some code to demonstrate what you've attempted, and we'll make suggestions.

My suggestion is that we rewind and start this relation ship again after you've read this and this.

This same poster also PM'd me a few hours ago asking for help, and sounding desperate. This is not a good way to get acquainted with the LAVA community. Just because there are listings of "who is online/active" doesn't give you the right to go door-to-door...

I dunno, maybe I'm just grouchy today, this is hardly out of the norm anymore...

Dave

...at the risk of flooding you, here's another method:

Chris,

You may want to do a 'Save for Previous' and edit your post. The original poster doesn't have lAbViEw 8.20.

Dang shift key... :laugh:

Dave

My customer wants to include the Windows login name of the current user in the report file for a unit under test.

I am using LabVIEW 8.01FD under WinXP Pro, SP2.

Any assistance GREATLY appreciated.

Roy

Roy,

The most reliable method I know (using the Windows API) is attached, it uses two CLNs and returns the login name and the NetBIOS computer name. I've used this since LV5. The attached VI is saved back to 7.1 format for the widest audience. Probably Dirk J.'s VI does the same thing, but his is in 8.2 format and I noticed that you're using LV8.

The VI Server property that Yen mentioned may work, but it doesn't always give you the Windows logon name - LV options (tools->options->revision history) may cause it to retrieve the LV registration name, or a 'prompt at startup' name. And I'm not at all sure that it works in built applications.

Hope this helps.

Dave

Download File:post-195-1162995389.vi

Jean-Pierre,

This technique does not seem to handle temperature conversion, due to the fact that there is an offset, in addition to a scaling coefficient (e.g., 0 degF != 0 degC != 0 K). Is there a simple solution that will account for this? I can't see anythin obvious that will work around this issue.

Also, for some reason this code generates an error for degF and degC, but seems to work OK for Fdeg and Cdeg -- strange.

Thanks,

I'm another one of those believers in the units feature of LV, I think it's often overlooked and a really clever concept.

My understanding of the way LabVIEW handles units for temperature is that degC and degF imply temperatures on their respective scales (with their respective offsets), while Cdeg and Fdeg represent a difference in degrees on the specified scale. Kelvin, of course, is the same either way since it is an absolute scale. So, for example, a temperature gradient value could be described as a PQ with units of Cdeg/m, or K/m, but you wouldn't want to express it as degC/m. Or consider the case of subtracting two values in degF - the answer could be properly labeled in Fdeg, but not degF. Regrettably, since the value on the wire is really just a value in Kelvins, if you create an indicator or constant from the wire, LV has no way to know whether you want to display a temperature difference or a point on a scale. I find it mildly unnerving that when I create a constant on the BD from a control/indicator with temperature units, the constant always shows up as Cdeg - essentially the same as the base units of K. This caused me no end of confusion when I first started using units for temperatures - I didn't get the difference between Cdeg and degC, and assumed that LabVIEW's behavior was somehow broken.

And it looks like even in LV 8.20, this bug hasn't been fixed.

Dave

<snip> because what I need this for has to do with an MKS mass flow controller that is not NI supported. I don't want to waste my company's money on a training that will not allow me to work with the equipment we have, as a new mass flow controller (an NI supported one) is far out of our financial reach at the present time.

AFAIK, there's no such thing as an 'NI supported mass flow controller'.

Sensors and instrumentation come from literally thousands of different vendors, with nearly an equal number of protocols, interface architectures, etc. If you're talking about stuff that ultimately wires up as 0-10V, 4-20mA, thermocouple, or digital I/O, there are plenty of hardware solutions from NI which span two orders of cost magnitude depending on channel count, conversion rate, resolution, and such.

If it's a garden-variety scope, DMM, power supply, RF voltmeter, spectrum analyzer, etc. from one of dozens of major vendors, and it talks serial, IEEE-488, or Ethernet, probably somebody has already written a set of VIs for communicating with it (ranging in quality from excellent to atrocious).

When you get to the more specialty use analytical or process control devices, you may a) luck out and find a vendor with a great package of VIs to control their device (rare in my experience), b) get some half-a$$ed attempt at a LV driver written by a summer intern the vendor had five years ago (far more common), c) feel lucky just to get a protocol document the vendor publishes and start coding your own (my personal favorite), or d) find out that it's your lucky day - somebody on LAVA or Info-LabVIEW has used this instrument and will send you some working code that gets you up and running in a day.

So, is this an 1179A series MFC with the RS-485 serial option? 'Cause if it is, you get option (d).

Let me know,

Dave

I wonder if this is not an 8.0 vs 8.0.1 issue in your case. I tried it in 8.0.1 and 8.2, but not 8.0. Though obviuosly still a bug, maybe it was "cleaned" up enough in 8.0.1 to get it to work in the project scenario. What ver are you using?

Then again, I guess you could just wait 'til you get your 8.2 CD's.

Regards,

Scott

Scott.

I am using 8.0, never having dealt with the patch/masscomp situation. My official 8.2 CDs arrived this past Friday. I don't know if I'll migrate the present app development to 8.2 anytime soon.

Thanks again for all the testing you did on my behalf. Eventually I'll get a bug report into NI for this.

Dave

Not to hijack the thread back to its original subject :laugh: , but...

Box came in the mail today - identified as the new copy of LV 8.20 FDS (we have a volume license for both PDS and FDS). Not that it really matters - the CD contents are whatever you have activation codes for. An identical box with PDS labelling will probably show up in a few more days.

But definitely no fancy zippered cases for us

Mostly I'm just happy to have the disks for the August 2006 driver release.

Dave