vugie

Here we have 2 brothers and one sister:

3dex.vi

Like AQ said - children of the same parent are independent. You shouldn't think about SceneObjects as about real objects. they are rather nodes. Not all of them must have visual representation (Drawable). There is one node which is a "root" ant it may not be transformed at all, neither be tighten to any visual object. All other objects are its children (not necessarily directly). If you want to make group of objects move together, or share some properties, just create a common parent for them.

You should also differentiate transformations from changing properties. Transformation is only geometrical movement (translation, rotation and scale). Changing color to blue is only changing the color property. Transformation of parent object always transforms children as well (however all transformations are relative, so it is only a kind of visual impression).

Most properties of nodes along with their actual possible values have one called "Inherited" and usually it is a default value for new nodes. It means that actual value of certain property will always be the same as for its parent. This is why you observed changing colors for all the spheres.

The Dialog Express VI has a start path.

I didn't explain it well...

From the start. Sandbox has defined "scripts" directory which is scanned to find installed scripts (by script I mean a VI where Active VI data is passed to). There is "New Sandbox VI" option which automatically creates new script from the template. It is a new unsaved VI, just like after clicking vit file. After creating the script you want to save it, but by default save dialog starts at directory of previously saved VI (or sth like this). So you have to remember where your scripts directory is and search for it. It may be a pain when it is located somewhere deep, so it is in conflict with "quick&dirty" paradigm of Scripting Sandbox.

Summarizing, I'm programatically creating new VI for edit and I want to have specified directory in save dialog when user presses Ctrl-S

I added documentation for script template (as BD comments).

Does anyone know how to set default directory for save dialog? Just for convenience when creating new script - dialog would automatically point to scripts directory.

The IEC61850_Associate_Req function has a callback fuction Confirmation as one of its parameters. How do I implement the callback using the Call Library Function node

Here is an example of how to create and use callbacks.

I uploaded a VIPM package of Waptia library.

I uploaded a VIPM package and updated naming convention for ZIP

Ok, so if I understand it is unlikely to find an equivalent ActiveX that has the characteristics sought, but it is possible that there is one in .Net.

Does anyone know it?

Irrlicht engine has .NET API

Axiom is a .NET port of OGRE

I didn't use them. Just know they exist

While I was trying this out, I realized that the download is a zip and not a VIPM package. I made a VIPM package, using your readme documenation. Should I upload it here, or did you have some reason for not making a VIPM package?

The only reason is that it was submitted in pre VIPM 2010 age. Please just send me the package and I'll add it to download. And thanks for the effort.

What you guys have against auto tool?... I use it all the time with only exception for picking colors (BTW it is ^$**#^#*#$@%$)

New fancy 3D charts. Do you also and when you accidentally put one of them on the front panel?

Have you ever noticed that it is impossible to put a 3d picture control to back? In fact, when the VI runs, a control that was set to front will disappear into the nothingness of the 3d picture control.

Is there a way to stop the aspiration of this black hole ?

There is one thing which is able it cover it. It is... another 3D Picture control.

I use the Code Capture Tool instead of the native feature. The CCT lets me save my snippets in older versions of LabVIEW.

Of course I knew that. Small boolean constants and blue scripting headers confused me.

Thanks for the effort on behalf of all people tied to older (but still good and usable) LV versions.

This is how I'm handling anomalies in my OCR:

Not related question: Why all snippets you post have header indicating 8.2 version regardless of version you actually created them in?

Yes you can't avoid a buffer copy but I wasn't sure if your buffer copy VIs did just a single buffer copy or if your first VI does some copying too.

The purple VIs in Get Frame.vi are part of MemBlock library and they simply call MoveBlock function.

But the main reason to do it in this way is simply to keep as much of the low level stuff in the DLL, especially since you have that DLL already anyhow.

I fully agree

Agreed - every now and then I'll have something I need to swipe something from and I'm on a machine that doesn't have VIPM installed. It's very convenient to just rename the file and extract.

Or just Ctrl+PgDn in Total Commander

If you don't have VIPM installed then what are you doing with the extracted packages?

Quick look into spec file gives you sufficient information what to do Ok, I saw the emoticon...

If you changed the user Event to be of a string instead of the cluster and changed the code in the Callback like this:

DLL void iCubeCallback (char *pBuffer, int IBufferSize, LVUserEventRef *eventRef){    LStrHandle *pBuf = NULL;	MgErr err = NumericArrayResize(uB, 1, (UHandle*)pBuf, IBufferSize);	if (noErr == err)	{    	MoveBlock(pBuffer, LStrBuf(**pBuf), IBufferSize);    	LStrLen(**pBuf) = IBufferSize;    	PostLVUserEvent(*eventRef, (void *)pBuf); 	}  	}

This way you receive the data string directly in the event structure and don't need to invoke buffer copy functions there.

In fact, it is more convenient. But (just to make things clear) - the buffer is still copied here, so (taking into account typical sizes of frames) there should be no performance differences between both versions.

Could you also show us the code for the ICubeSDK_SetCallback function?

I am excited about using this same idea to create a LV user event from a NSV value change callback registered within a CVI dll

I don't have it, as it is a part of camera SDK provided by manufacturer. I only call the DLL. It takes a pointer to a callback function which is (internally by SDK) called each time new frame arrives. I made separate dll which contains only the callback function I listed before.

I am developing a LabView interface to a legacy device driver which is in the form of a native Windows DLL.

The heart of the device driver is a callback function that periodically delivers data (video frames) from the device (a camera). ....

My question is: what event-driven alternatives to my polling solution are available?

This is very common issue for writing camera drivere. Here is my solution (for iCube camera):

Callback function:

DLL void iCubeCallback (char *pBuffer, int IBufferSize, LVUserEventRef *eventRef){	struct tBuff {		char *pBuff;		int size;	}  buff;	buff.pBuff=pBuffer;	buff.size=IBufferSize;	PostLVUserEvent(*eventRef, (void *)&buff);    	}

Initialization:

And Get Frame.vi:

To my knowledge there is no documented C API to the LabVIEW queues.

Do you know any undocumented functions for that?

Thank you Rolf for bringing this thread up. Although current solution works, I'm not much satisfied with it. BTW, now I can say that it is for lvODE library I published recently.

This is how the error handling is currently implemented:

The C part first. Error handler (this function is passed to main DLL to be called in case of error) and GetLastError function:

DLL void lvodeError (int errnum, const char *msg, va_list ap) {	lasterrnum=errnum;	vsprintf_s (lastmsg,256, msg,ap);}DLL int lvodeGetLastError (char *msg){	int temperr;	if (lasterrnum==0) 	{		return 0;	}	else	{		strcpy_s(msg, 256, lastmsg);		temperr=lasterrnum;		lasterrnum=0;		return temperr;	}}

lasterrnum and lastmsg are previously mentioned statics. Abort() is commented out in main DLL.

During Initialization I get address of error hadler and I pass it to main library (ode.dll):

LabVIEW part of GetLastError - not much complicated:

Typical call to main DLL:

So GetLastError should be called after each CLFN. As I'm still testing it, it is not put there now.

But as abort() is commented out (and I guess it is a must) and parts of code may run concurrently, I have doubts whether GetLastError will always get the error in right place...

Nothing special. I have a LabVIEW executable that responds to command line arguments. I wanted to print out a usage summary if invoked without arguments. Also want to print out debug messages over the course of execution and allow redirection to files etc. I wasn't sure that if there was a stdout in LabVIEW if printing to it would force it to show if a command line wasn't used. Seems like a moot concern now though.

Maybe it could be somehow realizable with OpenG Pipes... Just loose thought.

If you're being serious this is funny. Paragraphs of LVOOP dialog and all you have to say is: "I like the pretty colors".

And if you're being funny, well, this is funny.

I'm absolutely serious. Colored wires (not overused of course, not too fancy and well suited to icon colors) help me to keep block diagram clean and understandable. I seldom use LVOOP for whole application architecture, because 90% of my programming is prototyping solutions and I agree with what Jason said: changing the architecture based on LVOOP is a pain. I use classes mainly for well defined data types, often strongly related to real-world objects, not suspected to change too much and not too much dependent on other data types. So I mainly take advantage of encapsulation and wire colors play a main role here - I have up to several classes in whole the code and I just remember these colors. If I sometimes don't remember I know that they are related to headers of class methods icons. When I have slightly more complex inheritance hierarchy, I vary colors of children wires little bit.

I found that in general aesthetics is a one of most important factors which make (at least for me) programming in LabVIEW efficient and just a pleasure.

I'm not motivated enough to carefully read whole the discussion, so maybe it was put already.

What I like the most in LVOOP is custom colors for wires. The effect is worth the effort for implementing all these access methods...

No, that's not what I meant, I meant 'double click to open with TC'.

Any ideas on how to mange 'Top Level VIs' ?

That is how I understood it. After double-clicking TC extracts the clicked file to temp directory and launches it. And this behavior cannot be changed with plugin.

As for top level VIs I currently display them as they have "system" attribute, so they appear in different way. I don't know now how it will work with copying files to LLB.

cool, works great !

Good. I integrated the fix in new build.