Samapico

How does that explain string 2 being "z" ? The two results appear to be contradictory... According to the help, String 2's result would appear to be a bug...

But I'm still wondering: why would they make string ranges non-inclusive? In what case is it useful? Considering numeric ranges are inclusive, this really seems to be counter-intuitive.

It looks like it could be useful, but I have a few comments:

When sorting by "state", it seems to be sorting items in each class/library by themselves... So there's no way to tell right away which VI's are running if you have a large project. It's not easy though, I guess you'd have to split library/class groups if they have VI's in different states. For example:

[-] a.lvlib:

____someVI.vi (RunTop)

____anotherVI.vi (RunSub)

[-] b.lvlib:

____something.vi (RunSub)

____bleh.vi (RunSub)

...

[-] a.lvlib:

____hmmm.vi (Idle)

[...]

I'd guess that doing that would be quite hard... but how about a way to filter by state instead? You could quickly find running VI's in a short list.

The project I'm running has over 1000 VI's... this task manager takes about 20 seconds for a single refresh. It's pretty painful... Do you guys have any optimization in mind that could improve this?

Still a handy tool, thanks for sharing

Hmmm, how can you get a 0x2 or 2x0 array? Wouldn't both be empty arrays anyway (i.e. 0x0) ?

Could this be saved as 2010? I'm curious to try it out...

Thanks

You could use a listbox... it's pretty easy to set colors to cells/rows with that.

I read through all this quickly, maybe it's been said/proposed already... but is there any way to have it tell you which sub-VI is currently running?

i.e. if you have one top VI, that spawns multiple threads (not even dynamically, in our case), and when a "stop" is issued, all these threads must quit, and we often find ourselves unable to know which one is stuck, and where it's stuck.

So basically, listing the 'bottom' VI's, as well as the 'top' VI(s), without necessarily listing the entire call chain.

I don't think a double would have problems with these decimals, but the date/time might be using singles internally... But yeah

The other two methods aren't precise enough to see the <0.5ms variation in times. The ms timer can only time to the millisecond, and the datetime is even less accurate.

Yeah... take a look at the attached image. The datetime makes you think it's accurate by showing a bunch of decimals, but it still has a ~1ms resolution.

The example you posted actually proves that the high res timer IS way more accurate. More accurate than the wait(ms) VI anyway

Edit: Using the same kind of code, the resolution of the high res timer is about ~0.31106 microseconds,

or 3.1106 E-7 seconds.

Pretty cool, imo.

Make the background of the cluster transparent, and place another control behind it, and move that control depending on which one is selected

OR

Place a boolean indicator (like the square LED one) in your cluster, behind the other controls. You can set the false/true color of that indicator to whatever you want, and when the active cell changes, scroll through your array and set that value to false for every item, except the one that is selected.

See screenshot of 20 seconds of work I think you should be able to do something nice that way

I think he wants to know which DLL to call, the function name and its parameters to pop a standard Windows messagebox, with the standard (?), /!\ or (X) icons and stuff.

Is there a specific reason for that?

I haven't watched that video, but I didn't use dynamic dispatch inputs either when I created my constructor methods because they force you to use the same inputs for every child class... what if you have a specific property in one of these classes, and you want to initialize its value in its constructor?

Also, if you don't use dynamic dispatch, you can use the convention to never place a lvclass object constant on the block diagram, but you have to use constructor methods that output an initialized object.

Well, the easy way is to delete the terminal and re-create it

This seems like a lot of work in comparison - do you use this often and prefer it over the constructor/init method? Are you able to comment on pros/cons?

Cheers

-JG

I never really used this, to be honest, I usually use a constructor method.

An advantage would be that you can't "forget" to use the constructor method on your object, and you're forced to create the override, or it will simply not compile.

I'm guessing that if you have many independent properties, it would be a lot of work, but in jasonh_'s case, if the X/Y/Z limits can be given by a single VI, it could be worth it. It's just one more VI to create (just like you'd need to create a constructor anyway).

And it's really just right-click->override... -> change some constants -> save

Another option could be to have VI's such as 'GetRangeXYZ', put it in the parent class with the property 'Require descendant classes to override this dynamic dispatch VI'.

Then you create these override VI's in child classes so that they simply output constants.

I posted a VI snippet in one of your other topics answering to another member. It's not as pretty as the one on your image, but it gets the job done. It simply draws 3 lines, one for each axis (X=Red, Y=Green, Z=Blue) with a specified length (in units) and width (in pixels).

I notice one formatting issue: On the Site News main page there's extra space on one of the threads (see attached). Unclear as to why. I did perform a cache clean.

There should be an ad there, between the first and second topics. If you have some kind of ad-blocker, or if some ad doesn't load for some reason, I guess it would create that kind of gap.

Just check the STL file format and create the file "manually". The tricky part is to link the vertices to make polygons if you only have a point cloud as an input, but if you have that part figured out, it should be pretty straightforward.

You can get the values I used with the VI snippet I posted, Vector 1 and Vector 2 have the same value and it's set as the default value.

I figured it was something about floating point calculations, but I wasn't aware the computations could go through extended precision registers, I thought 'double' was pretty much the most accurate it could get.

Thanks for the explanation.

I have not had experience on your specific robot, but I would think the only thing you would have to worry about is a LabVIEW-compatible motion controller. Many manufacturers sell LV SDK's for their controllers. I found this link with a Google search (FANUC LR mate robot LabVIEW):

http://sine.ni.com/c...doc/p/id/cs-810

It's been done and it's a start.

That isn't a robot controller... it's just an interface that can communicate with it via standard I/O's such as Modbus. (I know, I work there ). We don't even use the NI Robotics toolkit, or the PCDK API (I didn't know there even was such a thing...).

With a protocol like Modbus TCP, we can send data to the Group Inputs (GIN) of the robot, and we have Karel tasks that run on it that can do stuff with that data (i.e. execute action #X with parameters Y,Z). You could probably do some basic similar operations with a TP Program, though.

First of all, I found a fix to this problem, but I'm just very curious on the reasons it could happen, so please don't reply with "just use XXX and it will work"

I had a very simple formula node that did this:

angle = acos(DP/(n1*n2));

In some cases, the result was NaN because it somehow calculated acos(1.000000001) or something, even though it was mathematically 1.0. DP is the dot product between V1 and V2, n1 and n2 are the length of V1 and V2. All these inputs are of type Double.

Doing the same thing with LabVIEW primitives gave the correct result (0) with the same inputs.

I tried two other things:

float64 angle;

angle = acos(DP/(n1*n2));

float64 angle;

float64 acosvalue;

acosvalue = DP/(n1*n2);

angle = acos(acosvalue);

Guess what... the first one gave NaN, and the second one gave 0. ??? Why?

This is using LV2009. I just tried it in 2010 and it works fine (both methods return 0). It's still pretty weird.

I attached a snippet, with the offending inputs as default value.

Edit: Just noticed... even without the 'is NaN?' check of the LV-primitive method, the result is correct. I just added it as extra precaution.

Also, here's a screenshot showing probes of the results:

Interesting... I'll have to evaluate if (TimeToFix * ResourcesCost > TimeToSwitchLibrary * ResourcesCost + LibraryCost)

Merci

[...]but the labview program is covered by the case False structure

But normally if you place a structure on top of existing code, the code will get placed in the default case.

The Modbus library provided on NI's site has a nice bug that makes Modbus Serial useless in slave mode when there are other slaves. See here for topic: http://forums.ni.com/t5/LabVIEW/Modbus-problems-with-multiple-clients/td-p/1112871/page/2

I was wondering if any LAVA people ever had to deal with this, and if there are alternatives or fixes available somewhere?

Link to the Modbus library: http://sine.ni.com/devzone/cda/epd/p/id/4756

There seems to be a whole lot of other bugs in there, according to the comments...

Not sure if I understand correctly... Add the case structure, save it and attach that, so we know what you mean.

^

That could cause some problems though... if the arrays in each of your clusters are of different lengths, putting it all in a 2D array would add some unwanted padding.