ShaunR

The most likely route is to carve off LabVIEW into a separate subsidiary company to let it sink or swim on it's own merits.

Well. It seems my response to this was deleted. Presumably the hyperbole I used angered the Lavagods.

I almost changed with 2013 because of the JSON primitive but alas, it was as much use a chocolate fireguard. I would change to 2020 because of the TLS support if it were not that I was forced to create my own solution 6 years ago If 2021 has multilingual support I will change to that but I won't hold my breath. I'll let you whizz-kids find all the bugs in the latest versions and my crusty VI's will still work for you. That is the magic of LabVIEW.

Nice list of features, not that I use any of them. Well. Maybe the occasional VIM but that was available unofficially in 2009 like many of the others You did, however, leave out the TLS for TCP in 2020 which is a huge one IMO. Unless NI find a way to give us proper multilingual support; that alone will mean it's eventual downfall. I predict it is only a matter of time until LabVIEW becomes a SaaS because of that.

Why wouldn't you use a notifier for this? It seems the only reason you have chosen this method is because it doesn't poll data (advantage over a global or local variable) or you have more than one element and expect the consumer(s?) to eventually catch up. A queue is a many-to-one construction whereas a notfier is a one-to-many so it seems a strange choice if you have multiple consumers.

Well. not exactly horses for courses and "generally used" brings us back to square one. Your experience is demonstrably the same as mine and many others yet cling to a specific use case (that i would agree with JKSH as an abuse) that you admit is obsolete. But you do you. I guess it's one of those differences between a Systems Engineer and a Programmer. Macro vs micro scale.

If you do that with the example then the detection time for "doggie died" is 9 times more which is why you use a single element queue. In an actual Watchdog rather than the example (where the wait is inline in the example rather than a timed event) the detection time is just the kicker's timeout. With your modification it would be 10 "kicks". If this were kicking every 10 minutes, that's a watchdog failure detection of 2 secs with an SEQ vs 100 minutes with your change. It seems you have proven my point with another practical example but are hung up on terminology.

Functional globals were used in lieu of DVR's before DVR's were invented. Maybe they were used inside classes to produce singletons before DVR's but there are lots of tricks to get around Labview POOP. I've always seen SEQ's used as a synchronisation method as demonstrated with the watchdog.

Queue's provide a feature that is not present with other methods such as notifiers and events. They provide a "back-pressure" in that the server can detect when when the queue is full. So any situation where server thottling or ordered, buffered synchronisation is required is a natural candidate to use a queue, even if the queue size is one. My point though is that a single element queue is not generally used as an alternative to a DVR and is used for a completely different reason. WD example.vi

That's not why most of us use single element queues. It is used mainly for synchronisation between concurrent operations. In that respect it is akin to pipelining or events and is an edge case of a queued state machine. In fact. I used a single element queue to make a "named events" VIM. A watchdog timer is a good example of when to use a SEQ and the data - value or type - is irrelevant.

I've been badgering Rolf for years to release his API properly. He's produced some fantastic API's that have no equal in terms of function and quality-especially cross platform. My current use case is for ffmpeg.

Generate output to a command prompt? LabVIEW has no concept of a being a console application and you can't natively create one. You can execute console apps using System Exec but if you want LabVIEW to behave as if it were a console app, you have to program a VI to specifically send to stdout and stderr streams. There are a couple of solutions to this: But my preferred solution is Rolf's Pipes API.

1. Standard way for variable length strings is to prepend the length. 2. The connection was closed. This can happen as part of normal communication, for example, when you press stop in loop C. This is because you will explicitly close the connection while your read loop is trying to connect or read.

You don't get an NI part number just by publishing on the Tools Network. Granted, when I was asked if i wanted to take advantage, it was a product on the tools network but it becomes a part of their product catalogue. Companies can then order it through NI themselves along with their other software and hardware and NI then pay you.

NI have (at least used to have) a facility where you can give them the software and their sales team will sell it alongside their other products. You get an NI product number and it's included in their software catalogue.

No news is good news. I have a couple of "tricks" I use here. Periodically I will remove the software from the public and wait to see if I get any complaints that it's missing. If there is still no feedback then it goes back in my private toolbox-no immediate interest means people are probably no longer using it and you don't have to support it in 10 years time when someone stumbles across it. Sometimes I release a "Beta" version. They are not really beta's (I don't believe in them) but fully tested products. These are usually for things that have taken me some time to create but created for my own benefit, need or curiosity. It is a way to gauge whether there is interest outside of my own and how much support would be needed to progress the product outside of my own needs. If no-one downloads it or passes judgement-yup, it goes back in my private toolbox

Boss: There's no "i" in team. ShaunR: There's no "u" either but there is "me".

I've written quite a few a test sequencers. They all worked roughly the same way which was a little bit like CSS in being able to include other files. Basically scripting. I have always been lucky though. I got to specify the hardware and using SCPI means you can just script the commands directly from the files with a simple TCPIP or Serial squirter and not bother with drivers. But simple wrappers around drivers can also be used for difficult stuff. I just extended the SCPI syntax to include the hardware route. So you end up with "recipe's" and add some custom stuff for delays/waits, a dialogue invoker and reporting and you were pretty much there. The UI was basically file listings and being able to order, add and delete them. The only other things were start, pause and stop. On one occasion I expanded the concept into a fully featured scripting language. After the first 3 times I could create a Test Sequencer in a day from scratch when moving to a new company. A couple of hours if i could reuse some stuff. Probably couldn't do that now though. I've forgotten too much and have had to make room for other stuff I did something very similar when using Test Stand too. I'd write a TCPIP connector and a LabVIEW VI would run in the background routing commands. All TS sequences just became sending strings to the connector and returning string results. Much simpler. Basically reducing TS to a Script Manager and reporting tool without all the usual complexity. You only have to train production people how add, remove and disable sequences and, if you have a techie production person, the format of the string commands.

Python has taken over the areas where LabVIEW traditionally dominated in test and measurement There are a couple of reasons for this not least that it's multi-platform and opens up more cost effective hardware options such as Raspberry PI's.

This also goes for any other non-LabVIEW UI used to control LabVIEW. I came across this issue with the Websocket API (as you probably know, I ditched LV UI's a long time ago in favour of HTML). Unlike other Websocket applications that send the HTML to be rendered, the implementation I chose was message based. So the VI would serve an image of the FP and the javascript would send back the click co-ordinates WRT the image. The Websocket API would then translate that into the LabVIEW FP co-ordinates and operate the control found there. It was a bit more involved than that but that was the basic principle. This also meant that you could script operations in JS for testing (or anything else for that matter-as long as it could do websockets, like Python) but that wasn't the original intent. One customer did write some Javascript (or maybe it was another language) that enabled them to record a series of operations and replay it back like the macro recording in Excel. I wasn't involved in that but thought it was neat.

This may help. There is also but I can't remember which dialogues it suppresses.

What a horrendous format TOML is. I won't be using this format unless forced to at knife-point.

Here's my tuppence. Get an indication from your IT dept when thy expect the issue to be resolved then get your project manager to bill the time against IT's budget. Add to your project plan the time they indicated and add a note that the project delivery date will be be delayed by at least that amount of time. Keep doing that if/when their indicated time expires until they resolve the issue. If you have weekly project meetings, make sure it is in the minutes and get an action on IT to resolve the issue and require status updates from IT so it never drops off the agenda. Ensure the IT issue is elevated to a high project risk category. Then. Download the VISA executable installer from "http://download.ni.com/evaluation/labview/ekit/other/downloader/" and tell your project manager you *may* have a temporary, sub-optimal solution which you are investigating for this particular package but that you fully expect continuing issues that may not have similar solutions even if you are successful this time, which is not guaranteed..

no cat for Cat? They are just text files (sort of). If you don't have a file called "state" in "/sys/power/" then i guess you don't have those features