ThomasGutzler

Hi, I'm using the MQTT client by @Francois Normandin (https://github.com/LabVIEW-Open-Source/MQTT-Client) with a non-LabVIEW broker that requires credentials. I can't find how to set username/password. Is this supported? Cheers

Mh, looks like that was a problem I remember from 2018

At least you get broken wires. Have you tried quick-drop replacing a vi with a vim that has a different connector pane? The wires just connect to nothing, don't break and there's no indication that anything went wrong until you try to build it. Kwality

Down here, you can't really hire a good LabVIEW programmer; all 10 of them have jobs they don't want to leave, so you'll just have to make your own. That's often easiest if that person has no LV experience. In that case you know they haven't been poisoned by "that uni course" they did where most certainly single-vi spaghetti with lots of local variables for "storing data" was the result. Candidate must have good understanding of generic concepts and not make a face when quizzed about graphical programming

That was there to avoid the "Save modified files" dialog blocking everything. That was before I knew about the headless instance.

Thanks for the insight! G-CLI has been on my to-look-into list for a while. Haven't had the time yet. At the moment our only timeouts come from the build pipelines, which means if something goes wrong the pipeline fails and the developer has the press the "try again" button (After inspecting the build log to check if it's a true fail or not). Not the end of the world if the second build works.

Thanks Joerg, I've seen your website before. Probably while I was looking for solutions. I guess, in theory, my stuff works too. It's just the pain of debugging when things don't go as they should because LabVIEW decided to corrupt its compiled objects cache, or that build error that we get when we have the build folder open while it's building that sometimes happens even that folder isn't open, or solar flares... The fact that I can't debug a build that froze or do anything useful with an instance that got started programmatically and isn't finishing just opens this immense guessing game. I don't like it.

We've been building executables and vipm packages on Azure for quite a while now and most builds work. Our driver package (6500 files) takes about 45 minutes on a pretty low spec PC. Applications usually build within 10 minutes. All our builds are LabVIEW 2018 64bit though, no multi-version doom. But there's no reason why you couldn't build multiple versions. With Azure build pipelines you have the choice of either self-hosting your build server or using an Azure VM which you have to install the complete toolchain on. Azure VMs can spin up/down on demand which is supposed to save you money because you only pay for the time they're up. We're not doing that. Another cool thing is unit testing. The caraya test framework integrates nicely and posts your test results stright to the pipeline. More here: https://forums.vipm.io/topic/3293-unit-testing-with-azure/ Happy to share more thoughts - probably in a different thread or PM

Thanks! I'm going to try the LocalHostAppInstance. Looking at the options we have, is it fair to assume that I can ALSO set unattended mode or might that already be included? Would I be able to set all those things in the .ini file instead of starting an instance inside an instance? I can't find any documentation about it

Hi, I've been working on this for years but I still haven't managed to set up a build server that builds reliably. My inputs are a vipc file and a .lvproj with all relevant files checkout via git. From there it's a two-step process. A powershell script makes 2 separate calls to labview using two small helper vis: 1.) apply vipc file using VIPM API; close labview entirely 2.) build the project given a build spec name In the end of step 2 it comes down to this And I have no idea if the last 2 steps are needed but I'm definitely trying to work around problems there, such as: - some files have changed, because LabVIEW can't just open a project without touching it. So I need to save everything to avoid the "Don't you want to save" dialog blocking everything - I can't remember what the "Exit" is for I've played with clearing the build and compiled object cache before every build. I've just turned off automatic recovery saving on my build servers. But I still find myself with builds that just never finish. Often, the last line in my build log is "Attempting to build <whatever>". Of course there is no way to debug a build that's gone wrong because I can't just remote into the build server and look at what's going on because the labview instance that's been started by the build pipeline isn't visible on my desktop even though it's the same user. So all I can do is manually restart, and in most cases that fixes the problem. Of course, the problem is not fixed then ... Sometimes I remote into the build server and I see a vipm crash handler window. Sometimes I get the old "Sorry for the inconvenience" thing from labview but nothing is ever repeatable Are there any other recommended settings? Should I mark all files as read-only to stop labview from touching them? Any tricks, recommendations or other mildly related wisdom?

I remove all compiled code from my vis and rarely see problems with it. Nothing that can't be resolved by clearing the compiled object cache. However, I found that the project-level check box doesn't work properly, so I wrote my own quick drop plugin that goes through the project to fix everything up. In VIPM I usually keep the mass compile option after install checked, except for our build servers because they install a different set of packages with almost every build and it takes longer to mass compile everything. Remove Compiled Code.vi

What Neil said. Looks like you've got it worked out. The hardest thing to get your head around is the factory instrument creation. This is the only place where you might not use dynamic dispatch to call instrument specific vis containing their specific configuration. But as @drjdpowell said, you can use JSON for that.

Factory is a good way to create your instruments but you probably want one factory for all instruments rather than one for each type. That way you only pass the parent (abstract) reference around, which makes it easy to swap out one concrete instrument for another of the same type. Returning different data types from classes of the same instrument type is something you don't want. When designing your classes, you should already know what kind of data you expect that class structure to handle and all instruments of one type should be able to put their data into that one given format. Maybe @MikaelH can throw the Introduction to OpenGDS pdf your way. I can't find it.

Ok, I obviously got fooled by the abstraction of the VISA driver. The reason why my initial code "works" is that I never enabled the Term Char. Without looking up the details of the communication protocol over USB I'm assuming that it contains some sort of "message end" that isn't a term char but is understood by VISA. Otherwise, I'd be getting timeout errors on the 65535 byte reads. Nevertheless, I have changed my reads to the suggested method (but without term char enabled) and queried the scope using the old method until I got another timeout. And there is no timeout using the new method. This makes no sense to me knowing term char is disabled. Finally, regarding the 1 byte vs. 2 bytes at the message end. All messages I'm getting end on "0A" but not "0D0A".

I see where you're coming form @crossrulz, but if the presence of a term char in the data was a problem, why am I getting exactly the right amount of bytes?