ShaunR

The market has spoken. While you may be correct from a technical point of view, Python is now dominant in T&M and for everything else, there is Matlab. That leaves FPGA and Hardware still in NI's wheelhouse with regards to LabVIEW. UI isn't a strength in LabVIEW and I take your point about Python with regards to WISIWIG component forms but when you do everything with an HTML interface-it's just a back-end choice with Python being a lot easier to interface to. The question to ask is...if I wanted to create an application that produced a walled garden like NI are now doing (a service in the cloud); how easy would it be with LabVIEW? I can guarantee that a lot of the services they are now promoting have very little LabVIEW programming in them and this is where many industries, including NI now, have already moved to.

Python. I know of very few LabVIEW positions in Europe for T&M. Very few vacancies are for LabVIEW now, generally. This seems to be a move to specific corporate customer types, like CERN. This will hit consultants. start-ups and small niche suppliers the hardest and say goodbye to most open source toolkits. With no new growth in uptake of LabVIEW and walled-off, future-proofing for existing customers, I see this as the death-throes of LabVIEW as eventually the corporate customers move away.

The way I usually get around this is either by not using variants (preferred) or saving as a string and specifying the type as another entry. e.g. { "config_file:"c:\temp\config.ini", "config_file~type":"str", "value":1.0E6, "Value~type":"ext" } This can be transparent to the user but not applicable if you have a strict field list for a file. Thank [insert deity] we can switch on strings in a case structure, eh?

I'm not aware of any use of Java in LabVIEW.

It's enticing me to downgrade to Python

If I buy a subscription license and then decide not to renew, what happens to my software? With subscription software, you will need to renew at the end of each term to maintain access to your software and associated services. Yikes. Software as a service?

I never found the general support much use. It used to be that you could moan at the sales engineer and he'd give you the extension number to one of the product developers. Progress sucks.

Do you have to sign an NDA as a NI Partner?

It's been a while but do you have the Linux automatic time update service running? IIRC it's default is enabled but can't remember which tool RT uses. You may have a conflict if you are manually adjusting using Set Time.

Like I said. Vague recollections. But it was a control that you could add and remove vision functions (rakes, morphologies etc) on-the-fly. It was more like an activeX control. I played with it for a while but never used it. It may not even have been the Vision Builder. But I do remember it was the same as the bottom panel of the actual application where the vision steps were displayed.

I have vague recollections that you could embed the Vision Builder into a FP. Maybe that's what the OP is talking about?

I have 2009, 2012 and 2021 working in the Windows 11 preview. NET 3.5 was a bit of a pain to install but apart from that, I've had no problems so far.

I use LabVIEW 2009 for all my development. While I don't have access to the latest and greatest features, compatibility is the main reason followed by robustness of that version. It should also be noted that I do have all versions (32 & 64 bit) from 2009 through to the latest that the final product is tested with. When producing code for customers I freeze versions on a per-project basis. You can consider this a micro version of what you are proposing. One of the worst things to do is to update half-way through a project and find out everything falls to pieces. Many projects have failed to meet the deadline due to this-I know from experience. This also applies for "bug-fix" updates. Generally, I will not use a version of LabVIEW on a project unless it is 1 year old or a customer demands it. I like to let those that must have the latest and greatest find the bugs LabVIEW is backward compatible over many versions but is not forward compatible. Therefore, if you producing tools for others to use, it is desirable to use the minimum version so that all forward versions can use it (bugs aside). LabVIEW is fairly unique in this regard and there are few, if any, that offer this feature-especially with 32 and 64 bit versions. This isn't much of an issue internal to teams but it is when distributing code outside or publicly. When in teams, updates must be synchronised so that everyone is using the same version. If one person updates their version and commits to the source control, others using a lower version cannot use that commit. Source control systems treat LabVIEW as binary so all members are forced to update to access the commit or the idiot that did it is forced to back-save and recommit . With large teams this is onerous but not insurmountable. If a volume licence is used, it can be easier to manage this than single licences. Version 2021 would be a good peg if you are looking to freeze the version. If everyone is on the same version, then compatibility isn't much of an issue on a day-to-day basis and you have a number of years (10+?) before your code will be obsoleted by an upgrade. You will also be saving a lot of maintenance headaches with the upgrade synchronisation and you will still be able to leverage code back to 2009. 2021 also has TLS which is a must-have for TCP nowadays, although you must keep on top of security updates which are usually only rolled out with new versions. If I didn't have my own TLS solution, I would have moved to 2020+ just for that. You won't be precluding yourself from upgrades, either. If something comes along that you must have, you can still upgrade. You will have just missed a couple of intermediate releases. While switching to single-seat licences is ok, it is worth bearing in mind that support is only granted with an SSP. I'm not going to suggest you have just one SSP and everyone and his dog claims they are using the SSP attached to that licence when contacting NI-that wouldn't be right But bear in mind that you won't get past the support triage without one. With your volume licence this would not have been an issue but with single seat licences only a person with an SSP for their seat is supposed to access support. At the end of the day, I view the difference between volume and single seat licencing as a procurement decision. It makes little difference to developers apart from they may have to order a licence and wait a bit. Volume licences make the purchasing department, IT and project managers' life a little easier rather then the developers. That's not my problem or my budgets

There are Python primitives that enable you to work with Python scripts; there is no Python Node like the Formula Node. Search the examples for "Python".

It's not under Front Panel. It's under Tool Bar. If you find your mind again, ask it to tell mine that I need it now.

Many moons ago I wrote a cloner for embedded devices. It basically dumped a device firmware image to an S-Record file which was then used to upload to other devices on the production line. Like Rolf said. It did enough to do the task for those devices and took a couple of hours to write the basic functionality - S-Records aren't a difficult format. It just started at an address and byte-copied chunks so only S3 was required for that (and the S0/9). I think you'll find that most people either knock up a quick utility like that or invoke the programmer utility. That's the Intel Hex format.

I think the UA_Server_run function may just write the boolean state to the running parameter (an out parm). Difficult to say with the info given but Pointer To Value for "running" might be all that's needed. The static volatile "running" variable is a red-herring in that it is an application variable that would be in LabVIEW as would the stopHandler. If the server is stopped and started by toggling the boolean, then there is a serious problem with either the DLL that exports UA_Server_run or the OP's understanding of how it works. I wouldn't be surprised if there is a UA_Server_stop which we haven't been shown.

Yeah. If you want a clean image at zoom you'll have to mask it. woopswee.vi

It is anti-aliasing because you have the zoom factor cranked up, right? Set the zoom factor to zero and get your magnifying glass out.

StrLen doesn't allocate anything. It just scans the string until it reaches \00 and returns the length minus the \00 char. It does the same as your match pattern above if you were to look at the Offset Past Match (-1). With StrLen + Moveblock, you are finding how many bytes you need to allocate to hold a *copy*, then copying from s[0] to another location (the initialise array in the VI I posted). The memory of the source string you are copying must already exist, somehow, otherwise bad things happen.

Ditto what Rolf said about corruption. Here's the PtrToStr VI with Rolfs suggestions. PtrToStr.vi

I think I may know what's going on here. char *s; /* If a string user is responsible for * allocating memory. */ The "v" in your cluster is actually a pointer to char so v in your cluster should be an array of bytes which *you* will initialise with n bytes. i.e. You have to create the pointer. The function obviously copies data into your string (byte array) which is why you have responsibility for allocating the memory, rather than the function allocating the memory and you copying the data into LabVIEW. So you are going to either something like this: or this What are you doing? The second one?

Yeah. Didn't think I'd get a definitive answer since size_t is only guaranteed to be greater than 15 bits. For MS it is UINT_MAX, which could be anything. The only way to know for certain is to test the compiled environment but even then it depends on things like if functions use 32 modular arithmetic. I don't think it can be resolved conclusively in LabVIEW but the choice is only unsigned pointer sized integer or a conditional case for target bitness. I guess you are alluding to the conditional for "most likely not to fall over in most circumstances" That's what they said about disk drives and look what happened

Is that regardless of Application bitness? Should this be a unsigned pointer sized integer or is a more complex solution required to ascertain the OS (target) bitness?

Are you sure you don't have a pointer to an array of strings?