ShaunR

4 hours ago, JKSH said:

You may not care @ShaunR, but I and others do.

  

You favour pragmatism. I understand the appeal and the benefits of a "first interaction support" AI.

My concerns center on the long-term, collective social and cognitive side effects of AI dependence and replacing human interactions with AI interactions. (AI can be used well or poorly) Are you interested in exploring this topic further?

I'm a programmer, not a social worker. My AI concerns are around privacy, confidentiality and data exfiltration. I don't really do hand-wringing, feely stuff.

My discussion input, in this thread, is about how to keep lavag.org relevant by utilising AI instead of just trying to defend against it. One way is to make lavag.org interactive when the few that still inhabit the forum (and the even fewer that answer questions) are asleep or do not have domain expertise. People with questions often want answers quickly because they have already spent days trying to resolve something and a forum is last resort. AI means that they may not have to wait 2 weeks for Rolf or you to come back from holiday to get something targeted, specific and useful.

3 hours ago, JKSH said:

The loss of motivation to learn how to ask questions well.

That's such a Linux thing. "Ask it the way I want or you 4 pages of me berating you about how to ask a question". Asking erudite questions is simply an efficiency.

3 hours ago, JKSH said:

The loss of opportunities to share our knowledge with others directly.

Don't care. Never did. 

3 hours ago, JKSH said:

The loss of human networking in general.

Overrated. There are symposiums and meetups for that. The forums are just a way to organise it.

I don't see any downsides here. Got anything else? 

AI bot's seem fairly obvious to me, ATM. They don't really understand comma's and lists.

On a different note. I've thought Lavag would be a good place for it's own AI bot. It could link questions to previous resolved answers. Automatically identify cross-posts. Guard against spam bots etc. Lavag.org is a huge resource that could be targeted domain training. Known meat-sacks could upvote and downvote the AI bot's response to train it. Too many downvotes, it disappears from the responses so as to not pollute with stupid responses.

I think lavag could utilise a simple AI as a first interaction support. The expertise of a years worth of LabVIEW (experienced intern). A users question is usually a much better search criteria than the site search where you need to know the keywords.
 

I should also point out it is forum etiquette to state and link if a question is a cross-post on Ni.com.

https://forums.ni.com/t5/Industrial-Communications/NI-9145-with-NI-9476-9375-in-TwinCAT/td-p/4485626

On 9/14/2026 at 3:49 AM, Gabriel Utomo said:

Wire the NI 9375 (setup [2]). The Digital Input worked just fine, but the Output didn't work (both NI 9375 & 9476).

IIRC. There is a safe-mode that will set outputs to a safe value (presumably 0v for sourcing 24v) when active. However. I think the status LED of the controller should be blinking red to signify that.

Apart from that. If a variable can be set but it's not being replicated in the slave device (the NI device is a slave, right?) then it points to a mismatch in the PDO mapping. I do not know how you would tell that from the XML files you supplied but you may know more about their construction than I.

54 minutes ago, Rolf Kalbermatter said:

I never did the IRC thing, but started with mailing lists as the main support channel. I have quite fond memories of the Info-LabVIEW mailing list started by Tom Coradeschi and currently maintained by Scott Hannahs for posterity. Back when you had to actually connect a modem through your main telephone line in order to go onto the big, friendly (back then at least) internet, mailing lists were very handy as one could respond to the mails offline and then connect to the internet provider to send off all the mails in one batch.

Mailing lists were great for maintainers, horrendous for users. Waiting a week to see if your question was answered and trawling through the archives in case you missed a response. One's issue getting engulfed in spam of the same simple issues posted by different people over and over again. I'm glad the days of IRC, Mailing Lists and, hopefully, Discord, are way behind us. Even SQLite eventually dumped the mailing list and support has greatly improved because of it.

19 minutes ago, Neil Pate said:

It is a pity you don't get on so well with Discord, your presence over there is sorely missed.

Discord is a poor support platform and I view Discord with the same contempt as IRC (and for similar reasons). If one thinks Lavag.org is a sub-optimal platform with little activity; answer the question or suggest posting the same question on NI.com. EtherCAT is a niche expertise and if you can't find help here or on NI.com, I very much doubt you will find it on your Discord server.

2 hours ago, Neil Pate said:

@Gabriel Utomo there is not much activity on LAVA these days. You might have more success if you post on the LabVIEW Discord http://discord.gg/labview

Unlikely.

1 hour ago, Rolf Kalbermatter said:

This is the default presentation that everybody should watch who is trying to implement serial port communication in LabVIEW: https://labviewwiki.org/wiki/VIWeek_2020/Proper_way_to_communicate_over_serial

Lots of exclamation points against using Bytes At Serial Port and then goes on to use Bytes At Serial Port 

More seriously though. You avoid a lot of the problems if you just pop up on the read prototype and set it to Synchronous IO mode instead of Asynchronous.

I don't have an Arduino to hand but here is a quick and dirty conversion of your dump file so you can see how it would be done.

Not much in the JPG to look at though 

str2jpg.zip

21 hours ago, Phillip Brooks said:

xkcd: Dependency

Why is the XKCD mage URL (for hotlinking/embedding) blocked for posting? -> "The link could not be embedded because that URL is not allowed."

42 minutes ago, Rolf Kalbermatter said:

The feedback one received in the past was virtually zero anyways

I see that as a testament to quality. No contact, no bugs.

54 minutes ago, Rolf Kalbermatter said:

I'm actually maintaining the LabVIEW ZIP library in this repository: https://github.com/Open-G

The other projects in there are not active as far as I can see.

After Sourceforge more or less succumbed to the Gods of advertisement under Slashdot ownership, the OpenG project on there was relocated to different repositories by different people. I happened getting involved by the person who did the OpenG Github repository and relocated my own copy of the LabVIEW ZIP library in my Github repository to that location. But the OpenG Github repository does not seem to have any other activity unfortunately.

The package for the library is however posted to vipm.io on each release.

I would not be opposed to spend some time on real bug fixes for other libraries but don't see much beef in adding new features to them. So far they work still surprisingly well for me after more than 20 years of existence with very little trouble. The most serious is probably the missing support for Maps and Sets in the Variant Data Library, but that is something I haven't really needed until yet.

I think the main issue (and probably the reason for the question originally) is the Cyber Resilience Act which basically makes everybody legally responsible for software they use. There are carve-outs for opensource but the only real way forward is through what they call "Software Stewards". I wouldn't stick your head above the parapet for OpenG. The next question will be "where's the SBOM and CVD Policy"  The way forward would be for NI or JKI to name themselves as "Software Stewards" for OpenG but it's a big ask for American companies.

On 7/31/2026 at 12:27 PM, hooovahh said:

I still leverage the VIT method in the New... VI >> From Template. 

Me too, for the compane. I got fed up with deleting connectors every time I created a new VI.

17 hours ago, John Welch said:

Has anyone used LabVIEW on an ARM version of Linux?

Can I Use LabVIEW on My Linux Machine with an ARM Processor?

On 7/13/2026 at 1:30 PM, hooovahh said:

I don't understand what you are saying here.  Are you saying that if the hardware uses a DLL for example, you won't know until you try to deploy to a target where that isn't supported?  I mean the VI will be broken in the context of a Linux target, so that will at least clue in the developer before having to deploy it and see it doesn't work.

No. I'm saying *if* the device is hardware independent then it wouldn't matter if a CSZ and/or Enviro device was installed and deployment of the hardware driver could be based on the platform, not the device. Rolf solved that by abstracting through VISA. However, you stipulated that you can't have both (CSZ & Enviro) classes in memory.

23 hours ago, hooovahh said:

I know this post is ancient by internet standards, but I've been using LVMark off and on for years now.  I recently posted a Hooovahh String package here on VIPM.IO.  I plan on making a video demonstrating features of that package including LVMark some day.  The LVMark code is mostly unchanged from the version posted here, just some comments and VIA_Ignore tags mostly.  I do think there are places where performance could be better, but I've only ever used it on relatively small strings.  There seems to be other LabVIEW Markdown libraries, like the one Ton linked to (but links seem to be dead), and a QControl here that has similar functionality.  I do like the simplicity of LVMark.

I wrote a markup string xcontrol. I really should look at it again because I don't think the mouse-over for links work properly on Windows 11.

15 hours ago, hooovahh said:

If I want to avoid always include, and if I want the code to have to be brought as a dependency,  I think there are only one of two options for forcing the library to be in memory, so the dependencies are brought along.  Either have a class constant somewhere, or a class specific VI.  It must be one of those two options right?  That was my original question of which design do people prefer and use to force some code to be dependent on that class?

Then you added not in memory for deployment to platforms. That's what messes the straight forward choice up because the platform hardware isn't abstracted.

21 hours ago, Rolf Kalbermatter said:

it's very flexible and does not require a static constant that needs to be installed somewhere and explicitly added to the caller in order to instantiate new device types.

Hooovahh is using the static binding for deployment though. Rather than abstract the transport he wants to abstract the device as a proxy for the transport because then platform specific deployment is automatic.

You use VISA for the hardware abstraction and configure the transport with a string. Hooovahh is attempting to configure the transport by not installing a device so that when it's deployed only the platform classes are deployed. I think he will run in to trouble if he has a device that has multiple transports but that doesn't seem an issue right now.

18 hours ago, hooovahh said:

And by that I mean the static dispatch parent with finding classes passed in, or explicit find for each child type?

Parking deployment for the moment (as I said, I think it's a separate issue) ...

I dislike both.

My workflow would be "Find" a chamber (i.e. detect one or more), "open" comms then start setting setpoints, dwells, ramps etc. I don't care who the manufacturer is - that was all sorted during the install, right? Ideally the "find" would return a list of available chambers (an array of class objects) so I'm not sure why I would need to use class specific "find" functions, or even use the actual class constants from a palette. If you no longer require class constants to be passed in to "find", then you can build a "found" array dynamically that users can use. In this flavour of "find, internally you can coerce to a more specific from the general type to actually probe and that coercion can be dependent on what's installed.

I'm not sure you can get away without dynamically loading. It seems you are basically wanting a plugin architecture. The problem with platform specific code is, I think, a separate issue. Note that a plugin architecture also solves your "find" since you can only find those that have been installed. The issue then becomes that you were reliant on static binding (class constants) to solve your deployment to target. This is the same as VI refnums.

What do you envisage the process to be when you have a chamber that has different implementations depending on platform? Let's say that the CSZ chamber must use TCP for Linux but USB for Windows? Now you don't have a static binding problem for deployment but you still have a platform problem.

11 minutes ago, crossrulz said:

If you have a specific structure for your chambers (ie everybody is under the "Hooovahh Chamber" directory), you could do a simple lookup and use the Get LV Class Default Value to dynamically load the classes. I do something similar with my HAL already, except I dictate what class to load based on a JSON file.

That's not the real problem (but the same solution as I was about to suggest). The main issue is the LabVIEW static linking. Traditionally we have gotten around it with conditional disable structures or calling CLFN's with a path.

hooovahh has created a class that isn't platform independent, only device independent and is attempting to solve platform dependencies with deployment.

I'll have to sleep on it.

I use a polymorphic VI. It basically just wraps the class constant for this purpose.The user can then have a single VI that they can choose the implementation method from a menu and that ripples down through the class functions. It means you only need 1 VI in the palette for the Open/New/Whatever and, once placed, the the user can change implementations without creating or deleting anything.

When there is a single type wired it looks much better because LabVIEW will show the class instance (see below) rather than the generic instance see (above).

The drawback is quick-drop (apparently) because you cannot choose a specific instance, only the polymorphic, but I ignore people that complain about that 

8 hours ago, jro1952 said:

Hello, I'm interested in adding maps to LabVIEW and I downloaded labview-gmaps-master.zip, but I can't use it; it's for newer versions. Could someone convert the package for version 2010? Thank you very much. labview-gmaps-master.zip 563.51 kB · 2 downloads

You should contact the developer. It may use features not available in earlier versions and it is a source control nightmare maintaining subtly difference versions. 

Retrieve Token String.vi