ShaunR

I wouldn't put 99.999% of any code written today on a satellite-and that includes my own. Go back 20 years and I would swear by any code that was written would have zero bugs otherwise it would not have been published. The reliance today on "updates" and "beta" versions is a detriment to all software. It's like psychologists creating models of human behaviour and expecting it to model real life...with updates. Call me cynical but I think software robustness is a far-cry from what it used to be. But that's progress, right?

I know what you mean. I have the same view about ActiveX and .NET. But XControls aren't as bad as those technologies and, although a lot of work to make them robust, they are worth it is some scenarios.

Nice. Is an XControl in the works? You know, for science

ครับผม

I did something similar a while ago. I eventually put it back in my private toolbox due to a lack of interest.

Why not just bypass the the USB-RS232 and talk directly with RS232? Wasn't the USB-RS232 used because there was no serial port, which you seem to have now?

I doubt it. Code monkeys have extreme problems with this kind of test because there are few parameters for them to follow. They are forced to think of a solution instead of being told how to implement one. The interesting thing is, though. Even if they are a code monkey, they may show skills or a propensity to think of solutions in the discussion afterwards that they previously haven't been called upon to utilise. While I don't think that is useful in Cat's case, it very useful if you are looking for a team member that you can cultivate.

You didn't and can't. Unless you are interviewing, there's not a lot you can do. When I interview I get them to do a 30 minute test. It's a test that they cannot complete in 30 mins. I tell them that they are not expected to finish, it's not expected to work, there is no right answer and I just want to see their thought process when tackling a task - just make sure it's tidy enough so I can read it. This is all true. After, we discuss the task. What they thought, what they were and weren't happy with, what issues they think their code has and why they did certain things. Additionally I ask things like how would they improve *my* test. Did it make them too uncomfortable, would they have preferred a specific result/correct answer etc. A good engineer will be able to articulate problems with interpretation of the instructions, the assumptions and decisions they had to make and what they would change now they know the task and we have discussed it with my input. What code they actually write is almost irrelevant and only serves as a common talking point but you'll spot the fakers straight away. You very quickly find out who is an engineer and who is a code monkey.

Well. There's also the Windows PDF which you can send to a printer, if you're feeling brave, but the ones you have detailed are by far the easiest.

This is a 3rd party (and free) solution I've used the past, successfully. Download Sumatra PDF from the website and install. You can use it to print from the command line. . Sumatra Print.vi

To use the PrintDocument .NET interface you need a 3rd party .NET assembly to render it (like Acrobat). Otherwise you'll just get a blank document.

You can register ActiveX controls using regsvr32.exe (located in windows/system32).

NI have said on many occasions that the VI diagram password system is not intended to protect IP - more of a disincentive to fiddle with diagrams (think of operators on a production line). NI's recommendation if you require stronger security is to remove the diagrams.

Nah. You just haven't had a misspent youth like I have ;)

If it's something like Get User Tag.vi or Set User Tag.vi, I can guarantee there is nothing in there that would surprise you.

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.