ShaunR

Sweet. My apologies. I always call them "Call Library Nodes" through laziness. Perhaps you might have got there quicker if I had used the correct acronym - CLFN). A "Like" point will be more than sufficient

I've always found the TCPIP to be rock solid (at least as far as crashes). Look for CLNs.

Many thanks to all of you that tested on the Mac. Seems to work fine on i386 with 10.5 and up (PPC was dropped by Apple a while ago and will not be supported) . A new version of the SQLite API For LabVIEW with Mac support will be released in the next week or so for those who are interested.

Sounds like a library call problem. All later labview versions are extremely non-resilient to pointer failures. The fact that it works fine on x32 but not x64 kind of points to an invalid pointer being passed (usually passing a fixed size pointer rather than a pointer-sized). I don't know what the GDS is, but are there an CLNS in the code?

Hmmm. I'm not sure what you have in mind (need to see the diagram I guess). The serializable just has a time (in whatever base format you like-integer, double, etc.....but something useful since that will be the default) it's just of "type" string. The "formatter" is still the modifier from this base format. The default serialize is obviously whatever you decide is the base. But that can be overridden by the formatter to produce any format you like.

CAN is merely a communications interface like ethernet, RS232, RS 422, STANAG 1553 etc. The USB8473 is a converter to enable you to connect to a device that has a CAN interface via the USB port of your computer.

Right click on the read and write VIs, set them to "synchronous" and you might be able to get that down a bit.

I would actually argue that maybe 1 type is enough and the problem is purely string manipulation. However, that excludes the binary (hence my suggestion). My JSON VIs, the JKI config file and the rather splendid library posted in the Setting Control Property By Name thread are all about "untyping" and "re-typing". I have found strings far superior to any other form for this since all labview datatypes can be represented in this way and, for human readable, have to be converted to them anyway, The introduction of the case statements support for strings has been a god-send. I'm not sure what you mean by " They don't have any ability to add their components piecemeal or to define themselves as a single string entity.". They are still just collections of characters that mean something to humans. And we are not talking about adding functionality to an existing in-built object are we? . N rank arrays are fairly straight forward to encode and decode if using strings as the base type (it's a parsing problem solved with recursion where the minimum element is a 1D array). Size and dim is really only required for binary, and the flatten already does that. The real difficulty is decoding to labviews strict typing since we cannot create a variant (which circumvents the requirement for typed terminals) at run-time. We are therefore forced to create a typed terminal for every type that we want to support and limit array dimensions to those conversions we have implemented. I think maybe you are looking at it from the wrong end. Timestamps and paths are really, really easy to serialise and so is the data inside an objects cluster (we can already do all of this). In fact. Paths and timestamps are objects, but, apart from their properties and data-not a lot of good to properly serialise since we cannot create them at run-time (I've been dreaming of this for decades )..

AQ. I presume your reluctance to support many of the types in LabVIEW is down to reconciling the speed and compactness of binary with the easy (albeit slower and bloated) representation of portable text based. Perhaps a different way of looking at this is to separate the binary from the text based serialization. After all. Aren't classes just XML files? All scalars and objects can be represented in XML, JSON and even ini files since the standards are well defined. The string intermediary is a very good representation since all types can all be represented in string form. An API with only these features would be invaluable to everyone including us muggles (jki config file VIs on steroids). We could then add more formats as the product matures.. The flatten already accepts objects but just doesn't quite serialize enough. That could be addressed to provide the binary. This is actually one feature that would budge me from LV 2009

Not a fan. Just a really easy way to link labview to browsers. I think another thread would be very short i.e. Prefer anything over xml .

Yup indeedy. There are some optimisations you can do to reduce the cases. All controls have a "label" and "Caption" of type text (single case), U8,U16,I8 I16 et al can have one case etc. But as soon as you get to graphs and the more complex controls, you pretty much end up with a case for each property/type That implementation is a lot cleaner than mine though but, in my defense, mine does produce JSON strings (for obvious reasons)

Don't you just love strict typing I've got a control scraper and it's counterpart which sets the values. Unfortunately it's part of the websocket API, so can't give it to you. Basically you have to use variants to get the control type and use the controls ref with the appropriate value property type to set it (case structure with a frame for almost every type). This means that it runs in the UI thread which is a real downer. You can encode the type in your string if you want it to be generic for transmission or you can use coercion to force values to the target controls type (different type of genicity). I would also suggest JSON rather than a comma delimited string Alternatively, you can wait for the serialization VIs in the other thread.

Clusters?

No idea about the LV bit.I just clicked on the *dmg and installed it since this is the only reason for me to use the Mac (I'm not even sure I know how to uninstall it ). PM me an email address and I'll send the API anyway so that if you do get something working; your ready to go.

All testing is valuable. I can compile the speed test which will also exercise the AES encryption as well as give a benchmark on your MAC (I'm running in a VM). Let me know which run-time engine you have (2009, 2010 or 2011) and an email address and I'll send it to you (I don't know how big it will be, but knowing LV a few MB-if thats a consideration for your mailbox limits). ......a bit later.... Scrub that. I don't have the app builder for Mac . Thanks for the offer though.

Hi Peeps. I've finally managed to compile SQLite binaries for the Macintosh and have tested the SQLite API For LabVIEW on OSX Lion (10.7) but need some kind-hearted people to test on other OSX systems to establish a minimum version (in particular 10.4 to 10.6). If anyone is interested and can spare a few minutes to try it out; please PM me with an email address and I will send the pre-release

Can you elaborate? Does this mean that saving the name of the clone created (at launch) and then opening a reference to it later is "unstable"?

Labview 2011 ships with http vis. Alternatively there is an old openG set of VIs which work really well if the answer to your datasocket issue (which I never use) turns out to be impossible.

What issue? Getting clones?

The LabVIEW Task Manager may do what you need

Why do you need their paths? The open VI reference accepts the VI name (if it is in memory).

That is just the youtube limits. Search youtube for "The Trap" to see the rest (the original was one hour and that was 1 of 6 on youtube). In addition to the video being a part of a longer one . It, itself, was one of three, hour long, programs.The first one (of which you have seen a bit), examines the theories of John Nash and Laing as people being suspicious, self interested beings and the adoption of his theories and models by economists. The others discuss what our Chicago friends did with it, how we reacted to it and (IMO) much of the reason why the world is the way it is today. The three parts (if you are interested) are: F*ck You Buddy The Lonely Robot We will force you to be free.

Yeah.. Well....You can blame game theory for that!.

\resource\plugins\utilities\IfDef.llb\SetSymbols.vi/GetSymbols.vi and the conditional disable structure does pretty much everything.