ShaunR

Hello,

I would like to install and run on a Windows 7 PC an application built on my developpement PC (LabVIEW 8.5.1 under XP).

I had some problems with the front panel fonts solved as described on another post by adding on the .ini file:

appFont="Tahoma" 13dialogFont="Tahoma" 13systemFont="Tahoma" 13

The data acquisition works normally.

The program should open some acquired data directly on OpenOffice scalc. To do that it looks on the registry the Path of scalc. There seems to be some problems accessing the registry: The vi "Open Registry Key.vi" working normally on XP returns a -604 error on Windows 7.

Any hints?

Thank you.

Error -604 is "Access Denied". Its probably the UAC (User Account Control) which was first introduced in Vista and consequently first disabled in Vista .

Try disabling UAC and see if that helps.

Disabling UAC

The LAVA CR Web front-end (what we already have now) accepts Zip files or Packages. This will not change.

We don't have a VIPM compatible LAVA CR repository yet and I don't know if we will ever have one. But I would love to have one and if the LAVA community yells loud enough (hint hint) maybe we will. Who knows

But in this hypothetical future, if we did have a VIPM compatible LAVA CR repository, then only packaged submissions would go into that repository since that is the only format compatible with the VIPM repository. However we would continue accepting Zip files and packages into the LAVA CR Web front-end.

Sweet. Thanks for clarifying.

Currently LAVA CR accepts submissions as Zip files or Packages. Only packages would be submitted to the LAVA (VIPM compatible) Repository.

Hmmm.

Does that mean you would have 2 repostories one for packages and one for zip files? Or do you mean that you will not accept a submission UNLESS it is packaged for VIPM?

*exactly*! And then we could talk about how VIPM users can either automatically or manually connect to the repository.

How would you handle the submissions to the LAVA repository that aren't packaged in a VIPM distribution?

It doesn't fit on my screen.

Better put in a capital req for that 42" LCD TV monitor.

I still don't know exactly what a "neat curve" means.

At the risk of tryin' to walk with both feet in mouth. Maybe he means something like this?

Sales and Marketing:

Engineering:

Anyone out there have a better way of separating the noise from the spikes?

6 Sigma analysis.Anything greater than +- 3 standard deviations from the mean (or in this case +3 STD).

Works well for these waveforms.

No, the WM_Seticon returns a handle with the old icon.

You can drop this VI:

To set or Reset the icon of a front panel vi!

Here's some little demo code:

That sets and resets the icon of a FP window.

Note that if you don't reset the icon it will be in memory until the FP window is closed.

Can anybody tell me how the code runs on:

LabVIEW 32 on Windows64-bit

LabVIEW 64 on Windows64-bit

Ton

Works fine on both x64 an x32 using Win7 and Vista ( once I'd replaced all the ogk stuff )

Yes that definitly works!

Thanks for correcting me.

Now comes the bonus question:

Mac

Linux

Ton

Buy me a MAC and LabView for MAC and Linux and I'll tell you

BTW. No problems changing the icon back again?

Maybe named after the top level .lvlib would be better?

How about "Eric"? That's a good solid name.

Change the "uType " to "1" (icon) instead of "0" (bitmap) and load an ".ico" file.

Name: OPP Push File

Submitter: ShaunR

Submitted: 29 Aug 2010

File Updated: 03 Jan 2011

Category: Remote Control, Monitoring and the Internet

LabVIEW Version: 2009

License Type: Other (included with download)

OPP Bluetooth is a partial implementation of the OBEX Object Push Profile (OPP) demonstrating "pushing" a file

to a bluetooth device (e.g. mobile phone).

Installation:

Unzip to a directory of your choice.

Required Packages:

Labview 9.0 or greater.

Transport.lvlib (included).

Bytes2kbits.vi (included).

Elapsed Time.vi (included).

Filter EOF Error.vi (included).

Percent.vi (included).

Rolling Average.vi (included).

Str To UTF16.vi (included).

UTF16 To Str.vi (included).

Known Issues.

None.

Contact:

PM ShaunR on lavag.org (http://www.lavag.org)

Versioning:

Version 1.1

Added more mime-types

see mimetypes.txt.

Changed the default mime-type if file extension unknown.

Changed from sending nothing to sending as "application/octet-stream"

since some mobiles require a type.

Added more vi documentation.

Changed the transport layer to use transport.lvlib.

Knowledge of the channel number no longer required.

Changed the default payload size.

Changed to 8192 since my HTC Desire doesn't like 14273 )

Added/clarified licensing/copyright.

Version 1.0

Initial release.

Initially release on the old lava website.

Click here to download this file

Name: Transport.lvlib

Submitter: ShaunR

Submitted: 30 Aug 2010

File Updated: 27 Aug 2011

Category: Remote Control, Monitoring and the Internet

LabVIEW Version: 2009

License Type: Creative Commons Attribution-Noncommercial-Share Alike 3.0

Transport.lvlib is a LabView API to simplify and accelerate networked communication development.

It simplifies development by abstracting TCPIP, UDP and Bluetooth interfaces

into a single polymorphic vi which is a thin wrapper around the conventional

open, read, write, close and listener VIs for all the network interfaces.

It removes dependency on the underlying hardware transport protocol and provides

a uniform application interface enabling abstraction of the application from the interface.

Features:

Supports TCPIP, Bluetooth and UDP (p2p, broadcast and multicast) interfaces.

Supports encryption (blowfish).

Supports zlib compression (only on platforms Win32, Win64 and linux 32)

Installation:

Unzip to a directory of your choice.

Add the supplied .mnu file to your palette.

Required Packages:

Labview 9.0 or greater.

labview_blowfish_encryption library (included).

Known Issues.

None.

Versioning:

Current version 1.0.

See changelog.txt.

Contact:

PM ShaunR on lavag.org (http://www.lavag.org)

Credits:

Thanks to Tad Taylor for releasing he blowfish encryption

library to the community.

Click here to download this file

I just read a MBRS140T3 document from osemi.com, MBRS140T3 is a chip of Schottky Power Rectifier. Two leads are in the MBRS140T3 chip. That makes me confused

My understand for a rectifier is something like a diode bridge which convert the AC to DC. It should have 2 AC input and 2 DC output (one is gnd) connectors. I am afraid I misunderstand what is power rectifier, so I google it. The answer from google is "Power rectifiers supply power from an AC source to a DC load".

Now the MBRS140T3 chip has only 2 leads. One should be AC input, the other one should be DC output. I guess the only possibility is that it cut the negative voltage half cycle and only use the positive half. Am I correct?? If that is the case. How I should connect the Schottky Power Rectifier to get 100% duty cycle in "positive voltage output" (not 50% positive and 50% negative)?

THanks

It is a single diode which, by itself, can perform half wave rectification . The terminolgy of "rectifier" and "diode" in single diode AC->DC conversion is purely symantics. You will need 2 of them if you are using a center tapped transformer or 4 (more usual) for non- center tapped.

Rectifier

Hi.

We have created a TestStand sequence using mainly labview vi code modules. The test sequence is complete and is running as it should in the sequence editor.

After I used the Deploument Tool to build an image which could be moved a production PC, something went wrong. The test sequence will still start and it seems to run fine, but the execution is extremely slow!

It doesn''t matter if I run on the production PC or on my computer (where the sequence was created). I can run the sequence from the development location, and everything is ok, I then close the sequence and load it from the location created by the Deployment Tool and it runs slowly...

It is not because the tracing speed is set to slow, and it seems to be the vi''s themselves that are executing slowly. Almost as if the "Highlight Execution" is on.

Any idea what is going on...?

Best regards

Stephan.

Try turning "Trace Execution" off altogether. I know you say that your "Trace Execution" is not set to slow, but this phenomina existed on even the earliest versions when the speed option wasn't available.

An in a similar light to MikaelHs question. Are you using a termination character to detect the end of string (and if so which one?)?

I guess you could be right, but it could be more the point of checking that your download is ok (from a transfer point of view rather than security)?

Anyways, there might be other reasons for allowing text files besides my example, so I was curious to see what others think.

Zip files have a checksum built in. You get warnings/failures if the file is corrupt and you try to extract. Most text files are MD5 hashes which is more of a test of trust than corruption - to ensure the file downloaded IS ithe file you are expecting..

Does it suppurt custom Run-Time Short Cut Menu for front panel elements?

Not currently. But it does support custom run-time main menus

The "Example Use.vi" uses a custom menu

Is THIS the sort of thing you are after?

Is the issue here that you are trying to do a two stage process in 1 go? i.e read from a Solaris drive, process the data and save it to NTFS? The 25MB/s might just be the limitation of the solaris drive (ATA 33 perchance?) and you might not be able to overcome that.

What about slapping a brand new 1TB NTFS formatted SATAII drive (they are cheap after all) in the windows box alongside the UFS drive. Start a flavour of linux (such as Debian) in a virtual machine or as a live CD. Install this Linux-NTFS in the virtual machine or live CD and just copy everything to the new drive. Throw away the old drive or take it home to build you own solaris system

Then run your software on the data, NTFS to NTFS.

Probably missing something as per usual

Hi!

During the writing of a simple program to test SCPI commands for my instrument, I stumbled on a puzzle. When I send the *IDN? command and afterwards try to read the response, the string I get is ´1. If I do it again, response is the same. Only after the third reading do I get the serial number of the instrument. The same thing happens when using MAX test control panel.

The instrument is HM1508-2 (oscilloscope from Hameg), it is connected over USB. I use VISA Open, Write, Read, Clear and Close functions.

What could be the problem and how can I make the program get the correct response every time? I can post a picture of block diagram.

Thank you.

Is the unit addressable? You may be seeing the units address prepended. The manual will tell you more.

This is my understanding of an abstraction layer as well.

Indeed. Nebulus describes a "hardware abstraction layer"But you can also have "software abstraction layers" for example ADO for databases.

We are in a little bit of discussion in info-LabVIEW concerning someone's idea of wanting shift registers available in stacked sequences. Yes. You read correctly. I don't need to start that discussion here because I already know how >90% already feel about that.

However, a comment stirred up a question in me:

Define "abstraction layers" as they pertain to Global warming/"climate change" LabVIEW applications.

Thank you.

Not being aware of the info-labview discussion-heres my two penneth.

In general terms. An abstraction layer is an interface presented to higher level funtions, that hides the implementation. In terms of Labview, a good example of a HAL (hardware abstraction layer) would be VISA.

Thinking laterally (or is it vertically). You could create a single global event that each control can decide to register with or not. You can then filter the incoming events and take decisions based on either its type (boolen, numeric cluster etc) or a specific control. What this acheives is that changes to the system are consolodated into 1 vi.