ShaunR

Yes, the GUI for a class also limits decrementing the version of a class.

Ton

Indeed. In fact it's the same as trying to set the revision number less than the current revision for a VI where it will object with error no. 1077 (which maybe is what it should be for classes rather than 53).

My opinion is that version numbers should be able to be set to whatever we want, however.

It's a shame that the conditional disable structure cannot tell what version of LabVIEW it is. I've got a "Tick Count" vi that uses the perf counter method on windows, the normal (1ms) one on the others and it would be great if I could put another case in there to use this little gem for when I'm working in 2010 and greater so it uses the best available (I have to work in 2009,10 and 11).

I try to change the version of a library or class with the accompanying VI, and this returns an error 53. Can anyone reproduce this?

Ton

I was able to set both class and lvlibs without any problems.

How are you calling the VI, i.e. what app refnum are you using? (I ran it standalone)

A little later.......

I can get error 53 if any of the Major, Minor, Fix numbers are zero. But works perfectly if they are all non-zero

Aha!

You cannot decrement the version of a user class. So if you are trying to set it to a lesser value, it fails with 53.

Indeed, however with DLLs you can't use any classes in the exported function terminals I believe?

Correct. But that doesn't mean you cannot do it.

I've played around quite a bit with LabVIEW plug-in architectures over the years and they have always fallen short. They work great in development and for modular development, but for deployment, you end up with either having to distribute the plugin source with the deployment/updates (which you might not want to to do) or removing the diagrams (and having a plethora of distribution updates for each target in each LV version).

It wasn't always the case, but now LabVIEW can create DLLs and it makes a lot more sense to use these. Whilst you don;t get away from distros for each target. You at least don't have to create distros for each LV version that the customer may use (and there are a lot of them). They can be loaded and unloaded at run-time, written in any language (including LV) and the plugins can be developed on any platform. Why faff around with LabVIEW specific methods when the OS already provides an elegant one.

That doesn't come as a complete surprise and it is a bit off topic.

Lets say you were using a driver which is 32bit but you also have another version which is 64bit or for a different platform.

You would have to build a different distribution for each of those cases no matter what tool you are using.

LVLibP is actually an advantage here since all you need is to rebuild all the LVLibPs according to the hierarchy and your application will run on your device.

A simple script can do it and an automatic builder is the place to put it in.

BTW, if someone needs me to convert the code to LV8.2 please ask.

Well. It's not off-topic since it is about code that you posted as an example in this topic

.

If you are happy to limit the portability of your source distributions, That's entirely up to you (I prefer the input from as many people as possible). One of the beauty's of LabVIEW is that it is multi-platform so anyone with LabVIEW x32/x64 or even linux and a Mac can use source posted on the forum. Only those with windows AND LabVIEW x32 can load your source.

That is because they are pre-compiled therefore you will only be able to use them on the same processor architecture and OS. Assuming you end up with a built executable this will not matter as you will run on the same runtime engine.

What is that saying about "assumptions being the mother of all muck-ups"? This is the very reason that I avoid packed lvlibs at all costs. I see no up-side but one huge down-side.

I would avoid packed libraries if you can. They do not seem to be multi-platform (not even on the same OS).

This is what happens if I try and load your library in LabVIEW 2011 x64 (it loads fine in x32).

You need to hook the windows messages to the the LabVIEW front panel (I haven't used the library though). This cannot be achieved with the event structure (I've been wingeing about event support for ages). It can only realistically be achieved with a DLL.

Here's the messages you need to look for

I think the WebSockets is going to be the thing to use in a couple years. As for Web UI Builder using SilverLight, you gotta remember, when we started creating that, HTML5 not only wasn't a standard, it looked like it would never *be* a standard. SilverLight was the only game in town for cross-browser multimedia of any scale (Flash just didn't scale up enough when we tested it). We got caught on the cusp of a change of tech... and will now have to spend some effort retooling.

More like a couple of months. IE10 has support in-built and that was the only outstanding problem (as it is always with IE).

We kind of hijacked another thread with our SSD benchmarks so I thought it only fair to move them to another separate thread.

So if you have a SSD; post the benchmarks here.

Shaun, is that using the default values for the benchmark VI? I thought my SSD was quite rapid but it looks shameful in comparison to your results.

Yup. Default values. The writes are a bit low on the posted benchmark 'cos my TV card was also buffering to disk.

Force GT 480GB

You can benchmark your disks using the Win32 File IO benchmarks which was designed to show the difference between the native labview functions and win32 IO.

If I remember correctly (it's been a while since I played with ETS), the win32 ones should work. If not, there are the native labview ones which definitely work.

And just for sheer awsomeness. Here's the benchmark for my SSD

Version difference, varying support by various browsers?

Quite minor now. The versions can be automatically detected (there are only two base variants) and only IE is the difficult one since it must use Silverlight (although the main difficulty is with Javascript detection of the sockets rather than LabVIEW).

I think that initiatives like WebSocket are more interesting in that respect, eventhough they have their problems too.

Care to expand?

Ooooh.

I'm gonna have have to look at my circular buffer VI to see if the "Swap Vector Elements" improves performance

Well my Dutch is worse . I'm from origin Swiss, with Swiss German, then had to learn French, of which I remember very little, then ventured into English and finally Dutch. So while I'm still fairly good in German, a bit less in English and Dutch, the mix of all these three hasn't helped the grammatical correctness of any of them.

Well. I can only speak two and write one so I try and convince people that I can write several by including programming languages to make me feel better

And all toolkits and modules.

Which you paid the licenses for, right?

Thanks a lot . And if anyone wonders, yes I fixed it as I prefer to fix grammatical errors whenever I can.

I'm a native English speaker and I couldn't give a monkey's about grammar on a forum ...lol

Your Dutch must be ultra juiste

They are the better ones. Can be tricky to get them hooked up and working through the serial communication, but that is a problem you have with all serial devices in one way or the other. But once they work they just tend to sit there and keep working until the entire system is dismantled, even if that is 15 years later.

I still have a few of the Series 2000 pre-production prototypes, one of which has been running my central heating since 1998 It's a bit of a waste of the controllers' talents-but rock solid!

I think the old ASCII Bi-synch and modbus drivers that I wrote are still around on the internet somewhere too

Well. I highly recommend Eurotherm controllers and they have LabVIEW drivers.

(Maybe I'm biased though since I used to work for them )

Hi Shaun,

I’m not sure I want to make that conversion an implicit part of the API. Users may want the full UTF-8 (which I don’t think is recoverable once it goes through "UTF8 to String”). And if they are using regular LabVIEW text (ANSI, I think) then it is a subset of UTF-8. I think it is better to document that the SQLite character encoding is UTF-8 and that ANSI is a subset, and let the User deal with any issues explicitly. Perhaps I should include those conversion primitives in the palettes.

That's the point. IF you are going to make it viewable by other applications, they inherently assume the encoding by the pragma call (PRAGMA encoding; ). Sqlites default encoding scheme is UTF8 but you can set it to others so text in the DB "should" be one of the defined types (none of which LabVIEW supports natively). If, for example, Chinese characters are inserted ( which, in labview are MBCS) then they will not display correctly in other apps.

I’m surprised that would be faster than the MoveBlock method (but I’ve not benchmarked it).

— James

I wouldn't worry too much about performance to begin with. Getting everything mapped out and functioning is (IMHO) more important since the optimisation does not prevent it's use and can take a while due to it being an iterative process (this can be achieved with each stable release).

If you are looking at making it directly compatible with other apps for viewing, you will need to insert using the "string to UTF8" and recover using the "UTF8 To String" vis as the methods Matt and I use do not honor this.

UTF8 Conversion

Why would reading in the data as string first be faster than reading it with MoveBlock() or into a byte array, as it's in both cases one memory buffer copy.

Because to use the Moveblock you have to use 3 API calls rather than one (Get the pointer, the size and then Move it).

When I read text the CLN's return value is a string, if that strings length doesn't match the expected number of bytes (can only happen if it contains \0) then I reread it using the moveblock method. So if the string doesn't contain /0 I can read it faster, but if it does mine is slower. This optimization is the reason my select is faster than Shaun’s.

That's not the reason

(I tried posting over on NI's site, but I was unable to upload images and I got tired of fighting with it.)

<snip>

If you ask me to explain the details of how something works I'll respond by waving my hands and mumbling incoherently. The primary idea is to allow more flexibility in mixing and matching different capabilities to get the exact behavior I need.

Interesting. So your SIF is "untyping" and "re-typing" using strings also.

Not sure what the "Culture" is for since file formats are locale agnostic. Is this to cater for decimal points and time? I'm also not sure of the need for a "Strategy" interface unless it is just from a purist point of view. After all. If you wire an object to the Serialize class you want it saved right away before you read it again, right? Perhaps you can expand on the use case for this?

I think the only real difference from what "you would like to see" and what I was envisioning is that the SIF Converter would actually be one of the Formats (JSON probably if it were up to me) meaning that the "Formatter" coverts from JSON to the others (they override the default). However, that is an implementation specific aspect so as not to re-invent the wheel and there is no reason why it cannot be a propriety syntax

I suppose one other difference is that I would probably not have the "Human Readable" interface and each file format (binary, JSON, XML et. al.) would have a discrete "Formatter" for it's implementation. In this way, different file formats have a unified interface (JSON in my example) and the formatter/file saving is a self-contained plug-in that you just pop in the directory/lib

Any USB device is going to be limited in it's current capability (both sourcing and sinking) and usually only 5v - You didn't say which relays (5v/12v/24v). You are much better going for a PCI solution such as the NI-PCI 6517 which will operate 12v and 24v directly without intermediary hardware (32x125mA max or 425 mA per single activated relay). You'll also have more than enough current headroom to add LEDs that can burn retinas at 100 paces If it is a 5V relay, you can still use the same card, but you may have to put a resistor in-line to drop the lower (off) threshold depending on the relay. Most of the time you can get away without this however.

You might want to take a look at Dispatcher in the CR which may give you most of what you want.

It worked perfectly. Thanks a lot ShaunR !!

Well. To be fair, Rolf was on the trail with a lot less info than I (gotta be worth a "like" or two).. His next post would have been the same once he saw your files.