ShaunR

Yeah. That's not what I'm after, though. I just want to open an appliance that someone else has gone through the excruciating pain of creating. Call me lazy but I've been mauled by Linux distros and the RIO evaluation board usb image so someone else can go through that for these platforms, thank you very much

When they say "RT" they really mean the Pharlap RT OS which is now called the NI Hypervisor, I think. (Windows PXI racks). That is Windows with an RT kernel. Interesting that new embedded platforms are coming with GUIs. Should be able to get VNC working on them too. Does anyone have a VMware or Virtualbox image of one of these GUI enabled systems?

Change the VIs reentrancy to be "Pre-allocated", rather than "shared", and see if it resolves your issue. The elapsed timer VI is one of those that relies on an uninitialised shift register and is set to pre-allocated so it must be called from either another pre-allocated clone or from a normal VI.

I usually gently point out these "discrepancies" if I have firm suspicions and give them the opportunity to rectify it and/or respond. They may have an agreement in place or they might have received the code in good faith but were not as diligent as you were and have been caught holding the ball. I'm fairly lenient with individuals and ignorance but can't abide business decisions that produce this situation. After that, it depends. I might ask the supplier if I can check with the original authors to see what their reaction is or I might tell the authors straight away-it really depends on their reaction and who they are. An expletive ridden email response telling me to insert parts of my anatomy in various orifices will definitely result in the latter with supporting evidence after several hours of investigation of all the software they have ever written, to boot. Does it happen alot? Not really in the LabVIEW world-much more in other domains. Most of the time it is an oversight or some engineer somewhere hiding a lack of ability from a boss. Corporate misappropriation does happen but it is an exception rather than the rule. It's happened twice to me with my software and both times a gentle nudge resolved it with no drama. Generally these things are a bit like witnesses at road accidents-noone wants to get involved even though they should.

Is your VI shared, re-entrant?

Yup. I can see this too with your example (@200ms). Tried it in LV2009, 2014 & 2015 and they all exhibit the behaviour. Looks like a Graph Indicator bug since the using a "Convert From Dynamic Data" set to "scaler" and placing an indicator doesn't do it.

Has no-one created a vmware image yet? Building Linux distros is like unraveling a jumper with chopsticks to make a tank-top.

This was a problem for me too.cThere is no elegant solution that I know of. You either architect your software to call dynamically the functions you need (plugin architecture) which works great in classic Labview where nothing is broken but you are stuffed if you use classes. Then, as you describe, the conditional disable. This is the only alternative I have found so far (open to more ideas) that works for everything but has some caveats (like the dependency has to be installed first so upgrades are difficult). I just put the onus on the developer/user to add a conditional disable tag into their project which also has the side effect of allowing them to choose whether to ship with that feature or not if they do have it (toolkits, obviously). The default shipped state is the plugin is disabled and they add the tag when they enable it which will either activate the feature if it is installed or break their VIs.

Nice. We didn't need a spec, but since you've given us one - polymorphic VIs are great. They never encapsulated Moveblock. I don't know why - it's the single most useful function for CLFNs. Tempting to wish for callback features but I'm ambivalent. If there is one good way to crash a LabVIEW program, it is to write some of it in another language. CLFNs are a last resort when no other options exists rather than standard coding practice. After all. If you want to write GPF ridden software, there are better languages like C and C++

OK. So it is a thin wrapper around the Tiny C Compiler.(Note that TCC is LGPL licenced ) It looks like the "State" is an opaque pointer to a structure so you might want to choose "Unsigned Pointer-Sized Integer" so that it is 32 and 64 bit ready. I would also suggest putting each function in a case structure and checking for 0. You can't test a pointer in C to see if it exists so the best you can do is hope that the library returns null pointers when memory is released or memory can't be allocated. For your DSNewPtr, which is a LabVIEW function; there are already VIs for that and others. I forget whether they are under resources or in vi.lib but I think you should separate out LabVIEW functions and application specific functions. LabVIEW functions are reuseable and usually cross platform , whereas application specific ones are or may not be. Looking forward to being able to auto-compile libbitcoin from LabVIEW

Amen! Although I don't think I've seen it. It was more to poke fun at eulogising ones own software.

Software is like a fart. Yours is OK but everyone elses stinks.

Been there, done that. T-shirts on sale soon. That's something I've been meaning to get into. I've got a little project for stripping out requirements and turning them into code that I think would benefit hugely from a neural net for natural language parsing.

Used Gradient Morphology instead of the fill holes but not bad for a 5 minute hack, I think.

Sweet. Looks like some nice little projects there. I too have a shedload of 1/2 finished projects. It took me, probably 10 years before I published one of them. I productionised a couple and gave a few away as freeware (you'll see them on my site an on here in the CR) and still I have about 30 that I use but have never published. That last 10% is 50% of the work Your ASCII art one looks interesting. I've been looking at visualising encryption keys and SSH has an ASCII art one so I'd like to play with that a bit. OTF compiler for encryption? Please! That's polymorphic virus country and you know it Looking forward to that one too Pure LabVIEW graphics sounds cool. The LabVIEW picture control, like most LabVIEW UI, is decades old so I'm looking forward to comparing with the Bitman library as well as the picture control. You might want to consider putting them in the CR so that versioning and updates are easier. Posting products in threads gets real messy, real quick and you always end up with support issues for outaded posts because they found them on search engines. You can put them in the uncertified to begin with then get them moved to the certified sections when you are happy with them.

I took this QR Code example and modified it with the SQLite API for LabVIEW for a database to make a simple example. You will need to decide on the database you will want to use (SQLite, MSSQL,MYSQL, Access etc) but it demonstrates the how and the way forward. QR Reader.vi

Off the top of my head....... I would probably do a find edges to locate the ordinates of the lines then draw the lines in the background colour (erasing them) then fill in the bits that were erased that went through the notes with a function like Fill Hole.

As a "real" LabVIEW programmer Maybe consider distribution via the LabVIEW Driver Network?

This is probably one of those situation where you ask 10 people and get 10 different answers. So here's mine. Open=Prepare resource. (General programming term used for comms (e.g. TCPIP) primitives, files, memory etc) OR Open=Particular function in LabVIEW to make a VIs front panel visible - only used in the FP context. Synonymous with "Show". Called/call = execute. Load/Loading/Loaded=Open (prepare resource meaning) from disk and place into memory... Launch=Run When Opened=Open (prepare resource meaning) then show the front panel (we can argue about this step) then execute.

Well. To be fair. The originals didn't have error clusters; just a boolean for when EOF was reached. But you could have (and am glad you didn't) normalised the behaviour with the Read from Text File function which is an enormous pain.

Ooooh. Now I want to know if speedy has the overflow or fixed behaviour

Aha. You've deprecated it to a warning. You are a legend Now please walk over, and smack with a wet sock, whoever is responsible for "Read From Text File" For posterity! (circa 2009)

Sure it is. Save and load it as a string and you can have any format you like. There is no date/time "type" in JSON!. Serializing dates to and from LabVIEW in a cross boundary way is, at best, a kludge and you always have edge cases (different separators, different offsets, different epochs.- the list goes on). If you view the date/time JSON object as a "helper" that tries the common types but specific ones you should just convert manually then there will be less bloat of the function as it trial and errors umpteen different formats and takes 10 hours to do so. You could even save the time and the format string along side it so you know how to re-interpret it. This cat has many skins. I never offer a date/time conversion in any toolkit for these reasons, but if I did, it would be a default conversion format with a string input to override with a custom one. That's my view, anyway.

If it were a bitness problem then you would see this error. You can also run the software without a broken run arrow to get a result. There seems to be little wrong with the LabVIEW end of things - you should be asking the supplier whats wrong with their DLL or looking at configuration of their system/device.

Do they throw an error 4 when they read the entire file? (one of my pet peeves)