ShaunR

I don't claim it works under Windows. Thats why I suggested the file change notification for Windows..

SQLite doesn't support UPSERT.

You misunderstand. It won't work cross process because it is not a system-wide hook. It works great in LabVIEW on all platforms but won't tell you when another application has changed it.- not even on Linux Funnily enough, it does work the way you think it does on VxWorks because there is only one process.

That's not the function you are looking for. This is.

I wasn't hopeful, but it's always worth asking the question I think there are similar issues with some of the DAQ too. I've only touched the surface with limitations since I've never used Linux in anger, so to speak-just for testing toolkits. It will be interesting to see what NI do with their PXI racks as ETS is Windows 7 (nee windows XP).

Interesting. Anything you can share? I've been eying Linux with the advent of Windows 10. All my toolkits (except the MDI Toolkit) are tested and work under Linux - it is just the NI licencing toolkit that prevents distribution (for now) on that platform. Vision is a rare requirement for me but, none-the-less, I really want a single platform rather than "choices" dependent on requirements. That used to be Windows but it looks no longer fit-for-purpose. If the holes in support are gradually closed (preferably by NI) then I would make the transition to Linux as the first-choice platform. I'm seriously thinking about formulating a "LabVIEW Linux" virtual machine image and distribution depending on licencing concerns since I have been using LabVIEW on VPSs for some time now for testing Websockets. That has given me some experience with Linux MIS and so now have standardised on LabVIEW, Codeblocks and CodeTyphon as a cross platform development configuration for Linux as well as Windows - dual boot, VM or VPS. Makulu Linux has a feature whereby you can create a distribution as a clone of your desktop so I'm looking to see how that works 'cos that's brilliant and just the job! At this point I am fairly comfortable about breaking 20-odd years of Windows only development with a move to Linux for test and automation.

Yes. But that's not really how it works and depends a lot on the provider. The service provider will either black-hole your server address for 24-48 hours at a time - so no-one can see it - until it goes away or you may get stung for exceeding your bandwidth and have to pay extortionate amounts per GB (if you have a limit). The rest of your sentiments I agree with, though, I'm just boggled why Michaels decision is even being questioned because I consider it is a black and white choice for the site owner and he's made the decision.

You said unless there where technical reasons and I gave you a very important one.Now your objection is about DDOS policies and registration? . I'm struggling to understand the vehemence of your objection to a standard practice for websites (which is standard because of the reason I outlined) and why it is such an issue for you on LavaG.

You can't ban malicious people that hog your server resources by downloading every file on your site from just a couple of computers if it's open to everyone. At least if they have to register you increase the work they have to do to and can mitigate it somewhat without having to spend huge amounts on DDOS services.

You can always use Windows 7 until end of life. Linux is getting some love by NI and device manufacturers have standardised on TCPIP and USB so it's becoming a pretty good alternative if you don't need Vision. It seems the time is ripe for Linux RT Desktop :

Apparently they can only be deferred by months and security updates cannot be prevented at all.

OK. So I decided to evaluate Windows 10 - not as a desktop OS, but as a DAQ and automation platform like Windows 7 on PXI racks. My conclusion was that it is no longer a viable platform for test/DAQ and automation. There were 4 main killers for me. Updates are forced by Microsoft when connected to the Internet which not only means that we no longer have control over versioning of a deployment but we also have no control over bandwidth usage. The only options are for immediate update or deferred (6 months) update. WE are no longer able to stage deployments with tested targets that are guaranteed to remain stable and prevent mutation of the customers system. Resource usage by background windows processes that cannot be disabled are prohibitive for DAQ and unpredictable when they occur (yes I'm looking at you "Microsoft Common Language runtime native compiler") It is opaque as to exactly what information is being sent to Microsoft and the system is set for maximum disclosure of private data as default. This means it is difficult or even impossible to guarantee a customers privacy. Even if a comprehensive assessment is made of leaked information, there is no confidence that settings will not be reverted or measures circumvented by future updates (see Item 1.) Bandwidth usage is hijacked in order for M$ to deploy updates to nearby machines using "Background Intelligent Transfer" (basically bittorrent). At present this can be disabled in the services but I am not confident that will always be the case. This has caused a couple of mobile applications to exceed limits and result in reduced service speeds and high data usage charges.

If you are sure, then will bow to your better judgment and familiarity with the API. It's such an awful thing to do in modern APIs that I would have only expected that sort of thing in 1990s 32 bit code to thunk down to 16 bit :D. It was (is) actually Aristos Queue's signature and it was C++ rather than C. Unless you are a masochist, you don't need write any C/C++ code in LabVIEW because ..... whats a pointer? I'm sure Microsoft said exactly the same thing right before their first "Blue Screen of Death" report.

There is something wrong here. Constants don't change from 32 to 64 bit. Are you sure you are not looking at a pointer to a structure? .....later, after some googling.... #define VIDIOC_S_FMT _IOWR('V', 5, struct v4l2_format) It's not a constant, it is a macro expansion to a function.You re inspecting a function pointer.

Actually you already answered your own question which was "No it isn't a bug" (the many surprises about typdefs?). Therefore you only have two options; put up with it or write a script. I'm guessing most of us don't encounter it at all (like me, although I know it happens) or it's just a minor and rare annoyance not warranting a script. So you can't really blame us for wandering off and musing the merits of enums (which would solve your problem). Good point. Breaking a VI so you know where to modify is definitely an advantage of enums but are you still writing systems with lots of cases that need to be modified everywhere? I thought we had retired those organic architectures years ago

One of the biggest (but not the only) "pro" for enums used to be that case statements created readable case names when wired and for things like state-machines it was a lot easier to see what was happening-readability. That really became a moot point when cases started to support strings. Enums are overrated and overused now IMO and pretty useless in flexible messaging architectures. I was only recently turned on to the text combo box too which, when you consider string case structures, is an excellent enum replacement, I used it for the Encryption Compendium for LabVIEW since there is a predefined list of algorithms to choose from. Not only did it allow for using new algos if the user updates the binaries without having to wait for me to release a new version (they just type in the name) but it enabled paramterisation of the algorithms (like DH 1024 or DH 2048) for advanced uses. Catering for the different methods could have got real messy and much harder to use the standard set of algos without it.

This also has other subtle implications such as you can change the ring strings at run-time whereas you cannot with enums. This means that if you want to translate a UI.......don't use Enums on the FP.

Buy an SSD? Only load the sections that are not the same as the LabVIEW in-memory defaults? Only load what you need when you need it (just in time config)? Split out into multiple files? (diminishing returns) Refactor to to use smaller configurations? Lets face it. 15-30 seconds to load 10,000 line inifiles is pretty damned good for a convenience function where you are probably stuffing complex clusters into it. What is your target time?

It's no worse than having to use the property nodes and callbacks for ActiveX/.NET controls or the external windows of the Vision toolkit and this is, or is potentially, cross platform.

Well. you are sending a waveform as a block (array) of data which has a fixed dt so you need to know the start time, Prepend the date/time to your double array and read it the other end to set your x axis start. You can then compare that value with the time you received it to get a rough latency of transmission.

OK. So you want to "pull" and like ini-files. Hell. there is a whole operating system based on ini files, eh Linux? So why not? Each "actor" (I hate that terminology) has its own ini-file, whos name is dependent on the actor, process, service or whatevers name Lets say you have an "Acquire_DC_volts" then you could have acquire_dc_volts.ini. Your "System config Engine" broadcasts a "UPDATE" message (event or queue list-up to you and your architecture) that prompts each actor that wants config info to issue a query message to the "System Config Engine" that says "I want this file". The "System Config Engine" then loads the file and sends it to the requester. Why do it this way instead of relying on each actor to load it? Because you can make an API and handle more than just config files, you can order the requests if there are inter-dependencies and you can swap out ini-files for a DB later once you have succumbed to the dark side .. You can see this type of messaging in the VIM Hal Demo. There is a FILE.vi [service] that does the actual reading and if you look in MSG.vi you will see the requests (e.g. MSGPOPUP>FILE>READ>msg.txt" and "MSGPOPUP>FILE>READ>bonnie.txt" ), It doesn't happen on config changes because there is no user changeable config, rather, when certain events happen - but it's the same thing.

You do, obviously

Yes. I use a different topology-I'm at the other end of the spectrum I talkedabout earlier. I only send UPDATE messages and whoever needs the configuration goes and queries the database for whatever they are interested in. You push; I pull

Well. Messages are ephemeral and config info is persistent so at some point it needs to go in a file. This means that messages are great for when the user changes something but a pain for bulk settings. Depending on the storage, your framework and your personal preferences, the emphasis will vary between the extremes of messaging every parameter and just messaging a change has occurred.

If you can use a LV2Global to transfer information then it isn't a separate process-in the operating system sense. May seem pedantic, but it makes a huge difference to the solutions available. Anyway..... I think most people now use a messaging system of various flavours so it's usually a case of just registering for the message wherever you need it. Usually for me that just means re-read the database which can supply you with the sharing like a global but without dependencies..