Rolf Kalbermatter

Maybe in VI Properties: Execution: Allow Debugging?

It's starting to get really ridiculous. They seem to have optimized their spam bots to the point where they spam two forums with 120 posts so far, and others incidentally, most likely as trial to get them flooded too. If this continues like this you can shutdown this forum altogether! Nobody is coming here to see this shit and it drives the few that come here definitely away. I really hope Michael can find his admin login credentials and do something about this. Please let me ban Baba's this and Baba's that, visha's and all those other accounts. Pretty pretty please!!!!!!!!!

I do note that in the list of currently logged in users there are regularly users whose name looks suspicious and when checking them out they have supposedly 20, 40 or more posts but no current activity. Is this part of keeping them in the dark after banning them? Let them log in anyways and also maybe even create posts that are then consequently immediately /dev/nulled? I really wish Michael could throw that switch to require moderator approval of the first 3 or so post for every new user! It's not so nice to login on LavaG and find no new post by anyone as has been the case regularly lately, but I prefer that many times above finding a whole list of spam posts about call girls, drugs, counterfeit money and secret societies that are waiting for nothing else than to heap money over anyone who is willing to sell their soul to them.

Really????? 16 pages of spamming and still being busy!! Can we not just disable any kind of account creation for the time being, until this hole is fixed? Wouldn't this work too? https://invisioncommunity.com/forums/topic/473954-spam-attack-today/?do=findComment&comment=2943240

It's been getting a bit silent on that front in recent years but searching for PostLVUserEvent() on google (and more specifically the NI forum and here on LavaG) should give you a number of posts to study that will give you some ideas. But one warning, function pointers is usually mentioned in one of the last chapters of every C programming manual, since it is quite tricky to understand and use for most C programmers. It's definitely not a topic for the faint at heart.

LabVIEW can NOT generate a callback function pointer. That would require a very complex stack configuration dialog that would make the current Call Library Node configuration dialog look like childs play. Instead you have to write a wrapper DLL in C that provides the callback function, calls the driver function to install that callback function and the callback function needs to translate the actual callback event into a LabVIEW compatible event such as an occurrence or user event. The Callback tab in the Call Library Node configuration is despite its name NOT what you are looking for. It's not to configure a callback function that your DLL can call but instead to configure callback functions that the DLL provides that LabVIEW can call into while it loads the VI containing the function node (Reserve), when unloading that VI (Unreserve) and when aborting the VI hierarchy containing that function node (Abort). It's the opposite of what you try to do here.

It's a valid objection. But in this case with the full consent of the website operator. Even more than that, NI pays them for doing that. There are a few things Cloudflare can do, such as deflecting DOS attacks that can make it look attractive. Personally I mostly notice it as a delay when opening a CloudFlare "protected" website. In the case of NI this can sometimes amount to an infinite delay since the CloudFlare servers seem to get caught in some infinite loop trying to decide if I'm a bot, a hacker or a harmless visitor. Usually aborting the page loading and forcing a refresh results in an immediate success. A few times per year CloudFlare decides that trying to edit a post because of a typo and subsequently resubmitting it, is a very dangerous sign of web server flooding. My guess is that they get the timing wrong at those times and the analyzer thinks that the resubmit 30 seconds later was really 30 ms later, so can't possibly be a human. Of course these services are only tolerated when they are 100% invisible. Otherwise there will always be people feeling bad about them. And things can go bad, as has been proven by the recent CrowdStrike incident too.

Some Zeruzandah guy really starts to get on my nerves. 👿

😁 well, I can be sometimes tempted. And to be honest, selecting that menu option if I'm looking at the message already is really just taking up one second. It's in fact a lot quicker than selecting the report option and writing "SPAM" in it. Now, spending substantial time on their forum is another topic that could spark a lot of discussion. 😂

You can have a LabVIEW VI (hierarchy) run on the RPi but you will have to add the RPi as a target to your LabVIEW project. From there you can create a program pretty much in the same way as you would for one of the NI RIO hardware targets such as sbRIO, cRIO, or the myRIO. However the LabVIEW runtime on the RPi is running in its own chroot environment (basically a light-weight Linux Virtual Machine running a Debian OS variant) and is based on the same runtime that NI uses for the ARM based RIO hardware targets. And this runtime has no UI. There is no way to have the VIs running in the RPi, show their front panel on the RPi display. You would have to rely on indirect user display options such as webservices or similar that a webservice client then displays on the actual RPi host or any other network connected device.

Maybe there is an option in the forum software to add some extra users with limited moderation capabilities. Since I was promoted on the NI forums to be a shiny knight, I have one extra super power in that forum and that is to not just report messages to a moderator but to actually simply mark them as spam. As I understand it, it hides the message from the forum and reports it to the moderators who then have the final say if the message is really bad. Something like this could help to at least make the forum usable for the rest of the honorable forum users, while moderation can take a well deserved night of sleep and start in the morning with fresh energy. 🤗 It only would take a few trusted users around the globe to actually keep the forum fairly neat (unless of course a bot starts to massively target the forum. Then having to mark one message a time is a pretty badly scaling solution).

Not quite, they don't use NXG to create these application. NXG is truly and definitely dead. But they use the according C# frameworks and widget libraries they were creating for NXG.

Could it be that the filter event only works for LabVIEW file types? There is no reason to let an application filter file types that LabVIEW doesn't know about how to handle anyway. They will be simply dropped into the "round archive folder" /dev/null anyhow if the normal event doesn't capture them.

I was fairly sure that there was actually an application event for file open events passed from the OS to the running application, but seem to have dreamed that up. It shouldn't be to difficult to add although might have some implications. Would have to be a filter event that can check the file name and then indicates if LabVIEW should further handle it (for LabVIEW known file types), or if it should be ignored (potentially handling it yourself). Ahh, it's super secret private special stuff: And seems to have trouble in some newer versions than 8.2! Although Ton says he got it to work in 2009 again.

Even though many mathematic operators are commutative (meaning the order of execution of those operators does not change the result) this only applies if you have infinite resolution. But in order for a computer to have infinite resolution when doing numerical calculations, it needs also infinite amount of resources such as memory. Obviously that can't be done! 😁

We could allocate/resize the array but it is highly complicated. There are two basic possibilities: 1) Using NumericArrayResize() is possible but you need to calculate the byte size yourself. With complex datatypes (clusters) the actual byte size can depend on the bitness of your compilation and contain extra alignment (filler) bytes for non Windows 32-bit compilation. Really gets complicated, but the advantage is that it is at least documented. 2) There is an undocumented SetArraySize() function. It can work for arbitrary array elements including clusters and accounts for the platform specific alignment but is tricky since the datatype description for the array element is a LabVIEW type-descriptor. To get that right is pretty much as complicated as trying to calculate the array element size yourself and as it is undocumented you risk that something might suddenly change. The declaration for that function is: TH_REENTRANT MgErr _FUNCC SetArraySize(int16 **tdp, int32 off, int32 dims, UHandle *p, int32 size); tdp is the 16-bit LabVIEW type descriptor for the array element data type. This is basically the same thing that you get from Flatten Variant but you want to normally make sure that it does not contain any element labels as it does not need them and only makes the parsing slower. off is usually 0 as it allows to specify an offset into a more complex tdp array. The other parameters are exactly the same as for NumericArrayResize(). In fact NumericArrayResize() is a thin wrapper around this function that uses predefined tdp's depending on the first parameter of it.

You consequently have hidden the actual type number of your sbRIO in your pictures. I think I can see in one place a 963x but it is not sure. And most 963x except the 37 and 38 are VxWorks based and as such LabVIEW 2019 is the latest to support that. It also requires you do install CompactRIO software not later than 19.6. The 9637 is supported since LabVIEW 2015 and CompactRIO 15.5, but the 9638 requires at least LabVIEW 2019 and CompactRIO 19.5.

It should. The Report Generation Toolkit VIs are either built in (HTML Report) or access the according Word or Excel Active X component. However the Office ActiveX component is version sensitive. LabVIEW uses dynamic dispatch to access these interfaces, but uses early binding for that. It means it determines the actual method IDs to call at compile time rather than at runtime based on the method name. This has as consequences that the calling is slightly faster but any version difference in the ActiveX interface leads the LabVIEW method call into the abyss. So your Office installation on the target machine has to use the same version as what was used on the machine on which you build the application. The change to use late binding would have been fairly trivial for anyone having access to the LabVIEW source code, but alas was never considered a strong enough issue to let a developer spend a few hours on it. If I would have had to do it I would probably have left the early binding option in there and added an extra retry to try late binding at runtime if the initial methodID call would fail. Or even fancier, let the ActiveX method call have a menu option to select if it should do early binding, late binding or a combination of both with retry if the early bind call initially fails.

Pretty simple except if you need to resize the array in the C code. You can let LabVIEW create the necessary code for the function prototype and any datatypes. Create a VI with a Call Library Node, create all the parameters you want and configure their types. For parameters where you want to have LabVIEW datatypes passed to the C code, choose Adapt to Type. Then right click on the Call Library Node and select "Create C code". Select where to save the resulting file and voila. This would then look something like this: /* Call Library source file */ #include "extcode.h" #include "lv_prolog.h" /* Typedefs */ typedef struct { LStrHandle key; int32_t dataType; LStrHandle value; } TD2; typedef struct { int32_t dimSize; TD2 Cluster elt[1]; } TD1; typedef TD1 **TD1Hdl; #include "lv_epilog.h" void ReadData(uintptr_t connection, TD1Hdl data); void ReadData(uintptr_t connection, TD1Hdl data) { /* Insert code here */ } Personally I do not like the generic datatype names and I always rename them in a way like this: /* Call Library source file */ #include "extcode.h" #include "lv_prolog.h" /* Typedefs */ typedef struct { LStrHandle key; int32_t dataType; LStrHandle value; } KeyValuePairRec; typedef struct { int32_t dimSize; KeyValuePairRec elt[1]; } KeyValuePairArr; typedef KeyValuePairArr **KeyValuePairArrHdl; #include "lv_epilog.h" void ReadData(uintptr_t connection, KeyValuePairArrHdl data); void ReadData(uintptr_t connection, KeyValuePairArrHdl data) { int32_t i = 0; KeyValuePairRec *p = (*data)->elt; for (; i < (*data)->dimSize; i++, p++) { p->key; p->dataType; p->value; } }

Well this is one hell of an API to tackle. amqp_bytes_t seems to be actually a struct similar to a LabVIEW handle contents, with a size_t element indicating how many bytes the following pointer points at. That in itself is already nasty if you want to support both 32-bit and 64-bit LabVIEW, since size_t is a pointer sized unsigned integer and the pointer after is of course pointer sized too! Then you have the amqp_field_value_t which in principle is a library specific Variant. Basically you want to have an element that consist of a binary string based key value and a variant, except that the Variant manager API in LabVIEW while present is basically undocumented. Well it's not totally undocumented since the NI developers let slip through a header file in the GPU Toolkit download that actually declares quite some of the actual functions. Of course there is the problem that function declarations are hardly any real documentation. It only gives the function signature but doesn't explain anything about how the functions would need to be used. So there is in fact a lot of trial and error here and the realistically present danger, that the Variant datatype and its related functions are subject to change at the simple whim of any LabVIEW developer since the fact that it is not officially documented makes the API "subject to change" at any time, for any reason including simply the desire to change it. The only reason not to do so is that existing NI libraries such as the OPC UA Toolkit, which makes internally use of that API, would also need to be reviewed and changed in order to not crash with a new LabVIEW version. Since NI has a bit of a habit to release LabVIEW version synchronized Toolkits (albeit sometimes with a year long delay or an entire version even missing) this is however not an impossible limitation as it not only would limit the documented version compatibility but also be a technical limitation to help prevent version incompatible Toolkit installations. Even if you would use LabVIEW variants as value of the key value pair, you would need to do some binary translation since a LabVIEW variant is not the same as your amqp_field_value_t variant. Personally I would likely use a cluster with a LabVIEW string as key element and a flattened string of the binary data with extra integer for datatype indication. Then in the C code do a translation of these elements to the amqp_bytes_t and amqp_field_value_t data elements. If you allow for a simple 1 to 1 mapping of the field_value element, things could be fairly straightforward. Something like this: struct { LStrHandle key; LStrHandle value; // really the flattened binary data int32 datatype; // native LabVIEW datatype, could get rather nasty if you want to support complex // datatypes and not just scalars and a string as you would need to allow for a // hierarchical datatype description such as the i16 typedef array of LabVIEW itself } KeyValueRec; If you use a native LabVIEW Variant it would instead look like: struct { LStrHandle key; LvVariantPtr value; // Native LabVIEW variant } KeyValueRec; But as mentioned the API to actually access LvVariant from C code is completely undocumented.

VxWorks is quite special. It looks on many fronts like a Posix platform, but that is only a thin and not complete layer above the lower level and very specialized APIs. Programming to that lower level interface is sometimes required for specific operations but documentation was only available as part of the very expensive developer platform with according compiler. It's of academic interest now since VxWorks has been deprioritized by WindRiver in favor of their own Linux based RT platform. And NI has long ago stopped using it and never made the move to anything beyond 6.3 of the OS. It was anyhow only intended for the PowerPC hardware since they moved to that platform as power efficient embedded targets were not really an option on x86 based hardware at that time. But with the PowerPC loosing pretty much all markets, it was a dead end (at some point in time it was the most used embedded CPU solution, many printers and other devices, where users never ever saw anything of the internal hardware, were running on PowerPC). It was hard to port any reasonably sized code to VxWorks because of the higher level APIs often being very similar to other Posix platforms like Linux, but not always working exactly that way or not providing certain functionality on that level. Accessing the lower level API was very difficult because of the very limited documentation about it that could be found without investing an arm and a leg into the developer platform from WindRiver. But once that porting was done there was fairly little maintenance required both because the API stayed fairly consistent and NI didn't move to a different version (except VxWorks 6.1 to 6.3 between LabVIEW 8.2 and 8.5).

Unfortunately, Apple manages to almost consistently break backwards compatibility with earlier versions for anything but the most basic "Hello World" application. And yes that is only a mild exaggeration of the current state of affairs. For an application like LabVIEW there is almost no hope to be compatible over multiple OS versions without some tweaks. Partly this is caused by legacy code in LabVIEW that uses OS functions in a way that Apple has declared depreciated versions ago, partly it is simply because that is considered quite normal among Apple application developers. For someone used to program to the Windows API, this situation is nothing short of mind boggling.

It seems they are going to make normal ordering of perpetual licenses possible again. While the official stance was that the perpetual licenses were gone, the reality was that you could still order them but you had to be VERY insisting, and have some luck to know the right local NI sales person, to be able to order them. That will of course not help with a current Macintosh version of LabVIEW. Still, maybe some powers to be might decide that reviving that is also an option. Kind of doubt it as I have experience with trying to support Mac versions of LabVIEW toolkits that contain external compiled components and the experience is nothing short of "dramatic". But if there would be a client teasing NI convincingly about ordering a few thousand seats of LabVIEW if there was a Mac version available, I'm sure they would think very hard about that. 😁

It's Open Source (on SourceForge) and I started developping it more than 25 years ago. There never was any license involved but yes at that time Python 2.2 or thereabout was the actual version. I did some updates to also make it work in 2.3 and 2.5 and minor attempts to support 2.7 but had at that time lost interest in tinkering with it as I was getting more involved with Lua for LabVIEW and two scripting solutions next to each other seemed a bit excessive to work with. The shared library necessary to interface Python with LabVIEW definitely won't work out of the box with Python 3. There were simply to many changes with Python 3 to the internals as well as datatype system that that could work without some changes to the shared library interface code (the change to Unicode strings instead of ASCII is only one of them, but quite far reaching one). Also there is absolutely no support present for Python environments such as offered by Anaconda and the like. The main reason for starting with LabPython was actually that I had been trying to reverse engineer the script host interface that LabVIEW had introduced to interface to HiQ, and later Matlab. When searching for an existing scripting language that had an embedding interface to integrate into other applications to use as a test case, I came across a project called Python, that was still somewhat obscure at that time. I didn't particularly like Python, and that its inventor Guido van Rossum was actually Dutch did not affect my choice. And when reaching out to the Python community about how to embed Python in another application, I was frankly told that while there was an embedding API available in Python, there was little to no interest in supporting that and I was pretty much on my own trying to use that. It still seemed the most promising option as it was Open Source and had actually a real embedding API. I did not even come across Lua at that time, although before version 5.0 Lua had anyways fairly limited capabilities to integrate it in other applications. So I developed a Python script server for that interface to allow integration of Python, and even got help from someone from inside NI who was so friendly to give me the function prototype declarations that such an interface needed to support in order for LabVIEW to recognize the server and not crash when trying to load it. After it was done and started to work, I was less than thrilled by the fact that the script was actually a compile time resource, so could not be altered by the user of a LabVIEW application but only by its developer. As more of an afterthought, I added a programmatic interface to the already existing shared library and the main functionality of LabPython was born. As those old LabVIEW script nodes have been depreciated several years ago by NI, it would be definitely not a wise choice to try to build anything new based on that tech. Not even sure if LabVIEW 2023 and newer even would allow LabPython to be loaded as a script server. But its programmatic interface should be still usable, although for quite a few reasons not with Python 3 without some serious tinkering in the C code of the shared library interface.

Duplicate post from here: https://forums.ni.com/t5/LabVIEW/Read-from-INI-file-to-application-cluster/td-p/4369322