viSci

Here is an example of what I am talking about.... Array Disable.vi

You can customize a boolean and replace the on and off images with different sized rectangles from the decorations palette. If you want to get fancy you can import graphics with alpha transparency so that the disabled state looks grayed out but still visible.

I have done this using a boolean that is small and non overlapping in the false state and large (eclipsing) and partially transparent in the true or disabled state.

Hey Rolf - Any word on the release of LuaVIEW 2.0? Maybe you could throw a small morsel out to your small but devoted Lua fan club

Wondering what the implications are for the LV community...

Protobuf is a widely used Google serialization standard. I have an instrument that only communicates via HDLC encoded ProtoBuf messages. Protobuf tools are available for most languages but not LV as far as I know. So was wondering if any crafty folks out there have come up with a way to talk ProtoBuf in LV. My understanding is that this would require building a Protobuf IDL (Interface Definition Language) compiler that would then guide a LV based encode/decode process.

Filipe - It appears that the compiler converts LV to Arduino sketches, is that correct? Will the compilers support such things as subvi's or structures?

What! That is fantastic! Filipe you are the man... (Do you need beta testers???)

Just poking this old thread to see how things are going with the MLua project...

Yes you are correct. A 32 bit windows app should be placed in the c:\program file (x86). It appears that the LabVIEW installer build will let you specify an arbitrary absolute installation path but if you name it c:\program files it will silently install in the x86 directory. This is one of those cases where the customer is not always right and I will attempt to explain again that their request to put a 32 bit application in the 64 bit directory does not make sense, is misleading and in fact maybe impossible to do in a standard LabVIEW installation build.

Normally, my project installers all default to the c:\program files (x86) directory since I have the 32 bit version of LabVIEW. I have a customer that would like their installer to install to c:\program files. I have tried to add a c:\program files absolute path to the list of destination directories and have also marked it as the default directory. No matter the installer still uses the original (x86) default directory. Does anyone know of a way to fix this?

Doesn't IMAQ have ring buffers built in?

I have a customer in the clinical assay processing business that would like to setup a LIMS system to automate and manage their workflow and interface to various off the shelf and custom analytical Instruments and robotics. In my search of various LIMS on the market I noticed that at one time there was a LIMS written in LabVIEW by a company called Cardiac which is no longer in business. I was wondering if anyone knows anything about this or similar products.

Your post prompted me to finally dig around for this one and guess what? C:\Program Files (x86)\National Instruments\LabVIEW 2013\vi.lib\Utility\Range And Ratio.llb\Scale Value to New Range.vi Can you imagine how many folks (myself included) have created their own version of this?

Simple and elegant, excellent idea Rolf!

It seems to me that if a cluster has unnamed elements, like in a slider with multiple sliders, it should still attempt to create a viable ini representation. Has anyone considered this yet?

As predicted, I was doing something stupid. What looked like a fired user event was really something entirely different and explainable. Thanks anyway for your sobering "this sinmply cannot be true" reality check

I have two identical vi's (app1 and app2) that both create a user event and register that event in a event structure. I have confirmed that each vi generates a unique User Event and Registration Refnum. I am finding that a triggered user event in app1 seems to also be received in app2. How is this possible? I am pretty certain that I must be doing something completely stupid but right now I cannot see it. Any thoughts would be very much appreciated. BTW this is LV 13.0f2

Yeah same here, blocked...

Did you run devcon.exe with the 'restart' switch? http://msdn.microsoft.com/en-us/library/windows/hardware/ff544807(v=vs.85).aspx

You can use a window utility called devcon.exe to restart a USB port. That might force LabVIEW to refresh its VISA driver. You can programmatically call devcon with the system exec.vi

Ok I am going to update to vipm 2014... Rats!...vipm 2014 update is freezing up at the 'Checking for a newer version' dialog Maybe I need to manually uninstall vipm 2013 first?

The latest task manager vip did not load on vipm 2013. I have LV2013 and 2010 on my machine

0MG, nanomsg... Now that would make an interesting VIShots episode.

Here is a demo of cluster to SQLite. It uses the 'other' SQLite toolkit SQLite Cluster Demo.zip