ShaunR

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)

If it's good enough for Apple, Google and now Microsoft ..........

If the user makes a mistake it is an error (on the users part). If it he needs to interpret a 20 GB log file to guess why, then that's an uncaught error with no recovery (on the programmers part). I always say, errors are for programmers only because users just want software that works-preferably with one button "Start". As a user of your software I do''t want to be "trained" how to interpret your logs of gibberish or wade through reams of irrelevance to find out what to wiggle. I want to know whats wrong and what to wiggle so it works. Well. Changing a background colour doesn't require pre-defined controls on the front panel and is supported by all controls/indicators. I'm not sure how you used an image but I would imagine it needed an image control next to each unless it was a list/tree or something. You can get (and save) lists of the controls and limits (from your database ) and have a generic check/set that just iterates over the visible controls and sets the colour and limits. This enables you to also tell the user why the value they entered is incorrect if it's outside limits and what is acceptable to enter. See the "Panel Settings Example" to see how this might work. The cluster? For me, no. That's used also for sequencing.

Without getting into error strategies; I haven't used the default LabVIEW handler in real applications since, probably, version 7. Yes I do use it for examples and quick checks of the error wire for debugging but I want a dialogue that is uniform with the rest of the look of the application for real apps. So I have a customisable 3 button dialogue that has images, on-the-fly translation, can query the database and has a timeout. It is used for errors, about boxes and confirmations - pretty much all dialogues - so the interface is consistent. I'm not a fan of the status bar for errors just as I'm not a fan of the status bar for mouse-over help. A one liner is not enough for users. They really need a plain [insert your language here] error message and an explanation of how to proceed. From a personal perspective, It just confuses me between something that's nice to know (which I associate with status bars so don't look often) and something I must know. For settings, I am a fan of the browser style of flagging errors. I.e change the background colour of the item and a message saying "sort that out!"

Indeed. I think it makes sense for the other products since 32/64 "bit software" is the LabVIEW IDE bitness. So both 32 and 64 bit LabVIEW are supported.

Interesting. LabVIEW 32 bit not supported. Is this the beginning on 32 bit obsolescence

I know of quite a few people that use the MDI toolkit for things like this. If your VI are self contained then it is incredibly easy just launching panels. I don't normally advocate MDI for devices due to possible resource conflicts but it may be worth looking at for your use case.

Indeed. But in LabVIEW, pure (CS) programmers are scarce and applied programmers are many which is why I pointed out the electrician/decorator example. 'Parallel processes' is actually worse since it has a well defined meaning in terms of the operating system and labview VIs run under the executable process. I see similar misuses of "threads". Anyway. Just food for thought.

I think your framework has come far enough now that you need to drop all this "actor" terminology. You now have specific modes of messaging and operations such as services, listeners, controllers and processes which are all merged under the banner "actor" - the same way everything is a "VI", even LVPOOP "methods". This is a similar scenario to the electrician/decorator problem and a switch of view will help understanding, adoption and epiphanies. I tend to think of actors as the micro and services et. al. as the macro. Your framework is superior to the Actor Framework so you should no longer ride on its terminology coat-tails and the OOP definition is just a universal catch-all for chunks of code (turtles all the way down). Calling all your use case solutions "actors" is just confusing and hiding the underlying application realisation and therein lies the power of your framework.

You are right. I've just noticed the semi-colons. I thought it was a JSON export format of STIL that was posted.

If manipulating, rather than creating; I would take a look at the new SQLite features.to see if that would be a solution. You could import a STIL files' JSON representation directly. You can then query (or update) it's parameters as if they were part of the database. This would link in extremely well with the rest of a test system so you could pull out test results and the STIL parameters for a particular configuration or date/time with transparent SQL queries.

Privacy policy?

IC. It was this I was referring to