viSci

Yes that is the way it works in DAQmx. It makes sense that the task would start directly and then the acquiring of data into the buffer is inhibited until the trigger occurs. I believe you can check the state of a task to determine if it is still waiting for a trigger or not.

Sounds like a database application. You could develop in Microsoft Access and then wrap your stored procedures in LabVIEW. There are some good examples in the Database toolkit for that.

Thanks for the explanation. I am going to try to back compile our Python instrument driver to v2.7. That will probably be easier then trying to figure out how to modify the LabPython C code. The only pain is that our instrument driver is a work in progress so I will forever have to back compile to keep up.

Has anyone tried this out yet? http://sourceforge.net/projects/pybywire/ I gave it a go but without an example or docs could not really make heads or tails of its capabilities. It has a good pedigree since it is written by the same person who developed the zmq libraries.

Greetings All - I had the unrealistic idea that I could use LabPython with Python 3.x But unfortunately am getting this error straightaway when creating a new session... Is this a show stopper or is there some hope to work around this?

Maybe NI would consider posting CLA video on the Alliance Portal?

No I am hoping the mountain will come to me I am resident in the egalitarian camp. If someone has some valuable insight or a new and better way of doing something I would hope they would share that information in the public domain. If they would like the honor of first presenting the idea in a closed forum that seems perfectly reasonable. BTW you can keep any of the NI NDA related tidbits, they are probably about as exciting as the LV2015 beta features

All good points! I certainly do acknowledge and appreciate the generosity of the LV and LAVA community. I think the issue here is that there is an unrepresented group of LV folks who might call themselves NCLA's (Non-Certified LabVIEW Architect's). The CLA has little business or personal value for me so I have not pursued it, I maintain my CLD only because it is a condition for my Alliance membership. I am however interested in all advance topics in LV software engineering and I might think about going to a CLA summit if they become open to CLD's. I guess what irks me is the notion that I would not be allowed to even view the CLA material, no matter what, even if I paid for the access. Perhaps in the future NIWEEK will offer more CLA level sessions (which is the only reason I would want to go).

Now that Tomi M. has stopped posting to his blog, deep thought in the LV community is hard enough to find without hiding the CLA content for fear that we (non-CLA's) cannot untangle the meaning from the humor.

Actually I just got it to work. Somehow the assembly was not properly registered. I still cannot get the current IronPython .net assembly to work since the interfaces seem to have changed....

Greetings - Does anyone have a working example of LV calling an IronPython script. I have seen this old link https://decibel.ni.com/content/docs/DOC-1133 but it no longer compiles and it does not seem to correlate any longer with the current IronPython .net asembly.

I once used the PXI-6683 and the cRIO timesync driver which supports IEEE1588 and IRIG. I used a small PXI chassis to sync multiple cRIO's using ethernet based 1588. I initially experimented with IRIG but went with GPS inn the end.

After a lengthy search into the LIMS market we went with a product call Clarity LIMS by Genologics. Top Tier LIMS are very expensive > 50k and they are all web based with Relational DB backends.

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?