Rolf Kalbermatter

QUOTE(thomas2609 @ Dec 19 2007, 09:10 AM)

why you don't you just read out the system time through kernel32.dll (see atached example LV8.0)?

That should get you the exact same time that is displayed in a LabVIEW timestamp set not to use UTC!! So not really sure what the benefit of that function would be.

Rolf Kalbermatter

QUOTE(tcplomp @ Dec 19 2007, 07:44 AM)

Are you sure about this (in the recent versions of LabVIEW).

I don't see the issue, but you must be aware that it's all in the eye of the beholder. The default timestamp control is formatted to show DST timing. However if you change the formatter to %^T you will get UTC time.

Indeed I concentrated on the technical ability to do what Tit asked for, but in hindsight I would be interested to know, what he wants to fix. LabVIEW 8 has great control over if you want to show UTC or local time and since LabVIEW 7 the date/time conversion for local time considers the timezone that was active at the time the timestamp represents rather than the current time. There are potential issues with the recent dynamic daylight saving time periods, caused by massive adjustments of that period all over the world. In Windows at least, only Vista allows for such dynamic daylight saving time periods. Older Windows versions will always use the current daylight saving period to calculate the local time for any timestamp, even in times where another period was valid.

I would expect that these things can be even a bit less perfect on RT targets, but there you usually shouldn't need to display local time anywhere. Instead just save the numeric timestamp, which was always UTC as long as LabVIEW was multiplatform and then interprete it on the desktop application accordingly.

Rolf Kalbermatter

QUOTE(Yen @ Nov 8 2007, 01:06 PM)

I didn't see any great positive reaction or helpful suggestions, and I've been quite busy, so I put it aside for a while.

I still use this all the time and it's great, but as I said, it has some issues.

The single biggest issue is managing the names and aliases and it has several sub-issues:

• Getting the item names in versions below 8. At the moment I can think of four options:
  Build them manually (not really an option).
  Hack the mnu files. I gave it a quick look and it doesn't look easy for primitives.
  Do the palettes in 8.x and find a way to change whatever needs changing.
  See if the palette API can handle mnu files from 7.x
  

If I only had more time! I hacked once into these files and once you understand the Macintosh like resource format basics (same as used for VIs, LLBs and most other pre-XML LabVIEW file formats) it's not that difficult to get at the info. Problem is my hacks were never really getting out of proof of concept state with the exception of the VI Library shell extension, but that was entirely written in C.

But it reminds me that LabVIEW itself exports a Resource Manager API and it should be not to difficult to target that one with a small VI library. I think it is in fact what the palette API does too. From there figuring out the structure of the palette resources won't be to difficult anymore.

Rolf Kalbermatter

QUOTE(Aristos Queue @ Dec 18 2007, 06:52 PM)

I never pin palettes, so drop vs insert weigh equally for me. But that's my personal take. The stuff I posted earlier is LV's general findings from users.

I do pin them down occasionally and intend to keep them there. But I also have a habit to close as much windows as possible so automatically, that whenever I need that damn pinned palette again, it is already gone

Rolf Kalbermatter

QUOTE(TiT @ Dec 19 2007, 05:49 AM)

Hello,

In order to get the correct local time with a timestamp in countries that have a summer time and a winter time (daylight saving stuff) the property has to be disabled in windows.

So my question is, how to programmatically enable/disable this windows option ?

Thanks in advance

Windows API: Get/SetTimeZoneInformation http://msdn2.microsoft.com/en-us/library/ms724944(VS.85).aspx' target="_blank">(link)

But it's not a trivial API and you have to do potentially some extra stuff such as getting a system Time structure correctly filled, etc. The one thing you can't avoid is that you need to adjust the application privilege before you can change the system time information. Because of that it would be best to write an external code DLL that does this all in a neat and proper way and import this as a single function into LabVIEW.

In the discription to the TIME_ZONE_INFORMATION structure it states that to disable daylight saving time you need to set the month value in both date structures to 0, among a few other conditions.

Rolf Kalbermatter

QUOTE(tcplomp @ Dec 15 2007, 02:30 AM)

Not if your SSP expired between 8.2.0 and 8.2.1

Ton

Well, not entirely true. You could download the LabVIEW evaluation version at that time and install it over the old one, preserving your license file, and everything was fine. The only difference between the upgrade and a full install was in fact preservation of already set things such as the license file.

Also installing theat version and activating it with the LabVIEW 8.2 serial number worked too, since they were both in terms of the license manager 8.2.

Unfortunately they pulled the 8.2.1 evaluation download and replaced it with the most recent one for 8.5 and here a non active SSP will render your 8.2 serial number invalid for this installation. Also 8.5 is in quite a few things more like a regression to 8.2.1 than anything else. But 8.5.1 is coming out somewhere next year. So if you upgrade now with SSP you get that upgrade automatically.

Rolf Kalbermatter

QUOTE(Cool-LV @ Dec 13 2007, 08:29 PM)

Thanks Rolf, appreciate your help very much

and I would like to share with you below FlexLM source which I searched

[link removed by moderator]

Don't do that! This source code is protected by copyright laws and NDAs. Either you got it as illegal copy from internet and then are not allowed to use it or look at it or under an NDA which you would just have preached by making it available for download.

Rolf Kalbermatter

QUOTE(M.M.K @ Dec 13 2007, 05:49 AM)

i ping two computers with correct IP addreses and shows me that the connection is worked but the errors comes from the program specifically from the listener.vi and the write.vi actually we connecte them through a cross cable.Can you tell me about your connection how you connect them specifically,Please?

Simple office network with DHCP. Obviously with a cross cable DHCP won't work but that you must have found out otherwise ping couldn't work either.

Rolf Kalbermatter

QUOTE(LV Punk @ Dec 12 2007, 10:37 AM)

I was http://www.internetnews.com/dev-news/article.php/3716046' target="_blank">reading this article this morning, and decided to check out the products mentioned. The two companies sell static source code analysis tools to detect race conditions. They are in the same business, have practically identical home pages, and even the customers shown in the 'crawls' are basically the same.

National Instruments is shown in both lists .

Yes but probably for analyzing their C source code, not for including that technology in a LabVIEW analyzer tool! Would be nice but I think the complexity of such a task would be very high. Coverity has been getting some publicity this year by offereing their services for free to some Open Source projects. But they did have some problems in getting those code scans be performed regularly. Apparently they had not enough staff to do the regular code base scans for all the projects they had offered that service.

Rolf Kalbermatter

QUOTE(jbrohan @ Aug 1 2005, 07:43 PM)

The original routine had the sign wrong on the Time Zone.

Here is the updated UTC Time Zone VI and the ExcelDateTime.vi

This converts dates from Excel numeric value (Re Format a column of dates in a spreadsheet to Numeric and these numbers are the excel dates I'm starting with). The conversion is to LabVIEW Time Stamp. There is a reverse function included in the same VI.

It is possible to determine your time zone from the G function Seconds to Date/Time.

1)feed in Zero this will give 1904-01-00 0:00:00 at Greenwich, but if you are in Montreal it gives 1903-12-31 20:00:00. (In the summer time) That's -4 hours offset.

2)Leave the Seconds input unconnected (Now) and examine the output Time Structure for DST. Add another hour for the Daylight Savings Time and you arrive at -5 which is out time zone.

3)This routine should work all over the world (Maybe even in Newfoundland which is 30 minutes ahead of Montreal.)

Your DST calculation might be flawed a bit. Before LabVIEW 7.0 LabVIEW always used the current time to evaluate if a timestamp had to be adjusted for DST. So if you run a VI using that in the summer it will return a different DST status and timezone offset for a specific timestamp (not the current one) than when you execute it in the winter.

In LabVIEW 7.0 I think they remedied that by taking the DST status that was actual at the time the timestamp itself represents except for timestamps that are before 1970 or something like that. For those it still uses the current time independant of the DST status that was actual at the time represented by the timestamp itself.

Rolf Kalbermatter

QUOTE(Jim Kring @ Feb 23 2007, 04:49 PM)

Adding two relative times is nonsensical: tomorrow + today = huh? (unless you're living in one of alpha's parallel universes)

I think you wanted to say absolute times here.

QUOTE(JFM @ Feb 27 2007, 09:18 AM)

Trying to force your way here? Since you want the addition to work on timestamps they should be made to support relative times?

But the timestamp was just invented to be able to properly distinguish between absolute and relative times. Before the timestamp datatype was available it was simply a floating point (well very early in LabVIEW it was in fact an unsigned 32bit integer but that got slowly remedied in later LabVIEW versions) number too. This gave problems as it was not really clear if a value was supposed to be absolute times or not

So the timestamp was added just for that reason. To have a unique datatype that could represent absolute time so that LabVIEW could make smart decisions how to operate on that. The disallowence of the addition operator on timestamps is one of those smart decisions.

QUOTE

It is in fact a fixed point representation. 64 bits for the integer part and 64 bits for the fractional part. As such it is obviously at least as accurate as a double floating point number for integer numbers but in fact can't represent the same range as a flaoting point number. While a flaoting point number can represent numbers from ~ -10^308 to 10^308 seconds the timestamp only can go from ~ -10^19 to 10^19 seconds (+-3*10^11 years relative to 1904). The difference is however that the integer part of the timestamp has still a resolution of 1 seocond when representing such a number while the floating point will have a resolution of ~10^293 seconds when representing its maximum value. In fact a 64 bit floating point number will get a resolution higher than 1 second as soon as it goes over ~ +-4.5*10^15 seconds (only ~1.4*10^8 years).

The additional 64 bytes of a timestamp for the fractional part allow for a total resolution of 2^-64 seconds which amounts to ~ 5*10^-20 seconds. Not sure if quantum theory allows for such a small time interval at all but I think LabVIEw 8 only used 32 bits of those 64 fractional bits anyhow.

Still all this number theory is really not that interesting and if it would be only because of the range and resolution a double floating point could have worked for a few more thousend years for sure as long as you don't require sub millisecond resolution. But the additional benefit of a distinct datatype really made the timestamp extra interesting. The only complain I have is that they didn't think about extra features such as allowing for timezone information being encoded in the timestamp too. I guess reserving 16 bit of the 64 fractional bits for this wouldn't have made the timestamp less useful. After all a resolution of 3.5*10-15 for a timestamp (around 3 femto seconds) still seems quite above any possible need even for hyper physics.

Rolf Kalbermatter

QUOTE(M.M.K @ Dec 13 2007, 01:42 AM)

the firewall is off for both computers.How can the labview application have permission to send TCP traffic.Can you give me the steps ?

Does it work with both applications locally?

Are you sure you use the correct IP adres?

If the first answers no, you have messed with the VIs somehow rendering them unoperable. I know the examples you mention work fine for me.

If you know your IP adress is right too, this is definitely out of LabVIEWs control, and something in your system, network setup or whatever is blocking you. In that case there is not much we could do for you as we can't see the system and check its settings.

Rolf Kalbermatter

QUOTE(Cool-LV @ Dec 12 2007, 08:36 PM)

thanks all, I've got more tips from Rolf,

namely, it is very difficult to reach the goal ?!! are there Macrovision FlexLM ActiveX component to call ?

I'm not sure they have an ActiveX component. The entire SDK is completely written in C without any traces of C++ or whatsover. And Macrovision wants to see money from anyone using their FlexLM solutions. Not likely that they will give a a free to use FlexLM ActiveX control to call.

But I could be wrong. I only looked into this some time ago for a client who wanted to have his software application protected.

It's probably easier to check out Microsofts MSDN site and look for their licensing API. Although they do not document all details, they do allow use of this API from other applications. Maybe that you can retrieve the machine ID from there somehow. Just be aware that this machine ID is in fact an arbitrary ID compiled together from an arbitrary selection of machine identification parameters. So this ID will always only work in comparison to the software that created it, meaning a machine ID computed by FlexLM is something that should be considered completely different than one computed by the MS Licensning API.

Rolf Kalbermatter

QUOTE(RONIN10 @ Dec 12 2007, 11:03 AM)

Right. I have it configured that way now and I'm still hanging the code. Here's my prototype as it exists now:

Anyway, I did have the big ah-ha! moment before when I was having trouble and realized that I was sending the value itself and not a pointer to the value. I don't know if this will show up reasonably, but here's my http://i80.photobucket.com/albums/j173/ronin10/NoParams_BlockDiagram.jpg' target="_blank">block diagram.

Hmm if it is still crashing then something is not right. What, I really can't tell you from what you show so far. Without more details about the last parameter or some short C code excerpt showing how it is normally called my possibilities to help are completely exhausted.

Rolf Kalbermatter

QUOTE(frentzen @ Dec 12 2007, 08:24 AM)

Hi Justin,

my fault, i forgot to add the other two files. Here comes the xml-file, the java file i could not upload.

The vi shows as a result, the data from the xml-file. I need to tell people what's going on in that vi, like

first it loads the java file, then it opens the xml-file and so on. So i have to go through step by step.

If you could help a little bit, would be great.

Thanks, Thomas

Are you sure this is not just your actual homework or assignment that you want us to do for you?

Figuring out what this all does, shouldn't be to difficult if you know a little bit about LabVIEW, Java and XML.

If you don't, I'm afraid you will fall through anyhow during your presentation, trying to explain some precooked

explanations you don't understand yourself.

Rolf Kalbermatter

QUOTE(george seifert @ Dec 12 2007, 08:36 AM)

OK, guys I need to get serious and back on track, please. I just repaired LV (8.5) overnight and rebooted. My VIs are still broken. Not only do I get the "The Governing Library is broken" for the timed loop, now I'm getting it on other built in VIs. What the heck is going on? I need to get this fixed.

Sorry, I've never seen these errors and if a LabVIEW repair didn't help, hmmm! Maybe try to do a device driver repair too?The timed loop goes deep into the system and and could depend on some low level NI device drivers that might have gotten belly up.

Rolf Kalbermatter

QUOTE(Karthick.v @ Dec 12 2007, 03:00 AM)

iam trying to access the usb camera image proceesing ,On NI forum disscusion i download the usb driver but i can't to install that ,the error msg popuping is (you must have a 7.1 or higher) but i have a Labview 8.2.1 ,Pls any one suggest me to favout that .....

It says you must have the IMAQ Vision library 7.1 or higher not LabVIEW! You have an IMAQ Vision Library and valid license?

Rolf Kalbermatter

QUOTE(Val Brown @ Dec 11 2007, 10:23 PM)

I'm on SSP and just received some CDs in the mail and they were labeled "Fourth Quarter" or something like that (I don't have them with me currently while I'm traveling). Was this not some form of "update"?

Specifically some of the components on the Driver CDs/DVD was updated and Upgrading them can mess up your MAX configuration and cause "bodily harm and death". I found this last one quite entertaining but I guess that is American cautioness. Otherwise someone installing this in a life support system (which you are strongly adviced to not do with any NI material in all NI manuals) could cause some serious casualties.

Rolf Kalbermatter

QUOTE(Cool-LV @ Dec 11 2007, 10:57 PM)

Hi all,

How to get my computer's ID(not ipconfig /all to the MAC address), the function likes NI Lisence Manager, computer ID item function ? how NI to do ? thanks !

NI didn't do it. They just bought the Macrovision FlexLM source code license and use that one. I've had a look at that code at some time. It is not a piece of C code anyone would want to dig into and make modifications to. Very convoluted, complicated and all in all unmaintainable IMHO.

Means you try to compile it and hope it works and once it does leave your fingers from it. It's also sad that around 1MB of the LabVIEW executable concists of this FlexLM code. LabVIEW itself does in 1MB assembly code a lot more and a lot more useful stuff.

FlexLM supposedly takes some specific machine parameters such as the HD serial, CPU ID, MAC adress etc. etc. and using some hash algoritmes calculates such IDs.

Rolf Kalbermatter

QUOTE(crelf @ Dec 11 2007, 04:06 PM)

PS: I'll be offline for a couple of week - as you suggested, I'm heading home and I'm *gulp* not even taking my laptop with me

Could that be because of intervention by some other significant person?

Rolf Kalbermatter

QUOTE(RONIN10 @ Dec 11 2007, 04:03 PM)

I apologize for that, but this is a proprietary code (despite the individual function's simplicity) and I'm only able to superficially describe the code. I cannot actually post the exact code. In that vein, this function call is made to determine the number of parameters in the established datastream. It should be returning an integer.

If it is really just an integer that is returned it's very trivial. Configure the parameter to be an int32 or whatever integer you expect and also tell it to pass that parameter as Pointer to Value (contrary to as Value). That should take care of your problem.

Rolf Kalbermatter

QUOTE(george seifert @ Dec 10 2007, 03:33 PM)

Thanks. The Bi-linear is pretty good. Some slight artifacts, but tolerable. BTW, there aren't any noticeable artifacts with even the Zero Order with a 32 bit image.

George

When you have to calculate the weighted average of several pixels, the result will be much more smoothly when you have 8 bits per color to distribute your values in, than in 8 bits altogether.

Rolf Kalbermatter

QUOTE(menghuihantang @ Dec 10 2007, 05:32 PM)

Ok, found the name. It's Relf, who has a book on imaging stuffs.

Well, a book can be a collection of articles, a working progress I guess :thumbup:

That is our resident http://forums.lavag.org/crelf-m181.html' target="_blank">LAVA champion in number of posts. He has for anything and everything here on LAVA an answer, but sometimes it is tongue in cheek. But he seems to slow down recently. Probably due to his preparations for a travel back home to down under.

And his book on LabVIEW imaging is quite good.

Rolf Kalbermatter

QUOTE(menghuihantang @ Dec 10 2007, 01:31 PM)

Thanks, Rolf, for taking the time to write that much for a rookie :thumbup:

If I am right, I think I read a book authored by the same name. I just couldn't find the book in the shelf. Are you that author?

I've made quite a lot of responses to posts about external code in LabVIEW on LAVA, the NI Developer Exchange, Info-LabVIEW mailing list and the German cousin of LAVA, and also published some short articles about this topic on http://expressionflow.com/author/rolfk/' target="_blank">Expression Flow but I haven't written a book so far

Rolf Kalbermatter

QUOTE(Norm Kirchner @ Dec 7 2007, 11:36 AM)

Two of these should do the trick

The modern version of our childhood telephones

But it's not clear if that is a network outlet or a power outlet. I sure hope for the first.

Rolf Kalbermatter