ShaunR

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

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

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?)?

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

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

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

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

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.

Heathen

Yep. That would do it. The key point being "ActiveX". You can try to make sure the open ref is only executed once (when the vi is started...ie outside any loops) and hope that the "stall" isn't from the get method.

Check to make sure you have "wired through" the shift register. You will normally see this behaviour if there is a case selector with an unwired tunnel. If there is a case which has no wire connecting the left shift register node to the right node, that case will insert a "NULL" reference.

It can be done (including your additional criteria) by saving the vi as a template (vit). You can then open it in edit mode (requirement for changing execution systems and priorities) modify the parms and then run it like this: However. This is probably not very helpful in the long term since the priority property is "Read Only" in the run-time engine so if you deploy it it will fail:frusty:

Private or public?

Does it currently auto-grow or do you have to make it grow manually?

You have to do a bit more than that to force LV to run certain vi's is certain threads. This is where "Threadconfig.vi" comes into its own. vi.lib\utility\sysinfo\threadconfig.vi It all gets a bit tricky from here on in as you need to manually manage what vi's are going into which execution systems and at what priorities. Most of what you need to know is in this thread (no pun intended...lol) Loop Timing & Execution difference

Didn't know Labview had a "Pizzle" . Amazing what the NI boys can do nowadays

I can't walk and chew gum at the same time either

There are examples shipped with Labview. Hardware Input and Output\General

Well. A sticky at the top would dramatically reduce the "Why Can't I" PMs. And although they may have something to put in the general area (although haven't seen many newbies that don't post relevent to their problems), it might be a worthwile excersise to lock it for a short period to "Train" them and ease the workload on the mods for moving them. Just my 2 cents.