Yair

About a decade ago, when the NI forums had a very similar spam problem, a couple of active users were given privileges to help with the spam. I realized fairly quickly that doing it manually wasn't that helpful and wrote some LV code which monitored the forums, recognized the spam, did all of the actions to remove it and block the user and then sent an email with the details. It worked quite well and would typically get rid of the spam within a minute or two of it being posted.

For completeness, on Windows it's also possible to execute a VI as a callback function like this: Write a VI with the needed callback signature and a mechanism to pass the data you want onward. Compile it into a DLL. Load it from the DLL using GetProcAddress and pass that as the callback pointer. I posted an example here, which I believe also uses EnumWindows. This comes with its own bunch of caveats, and I never actually used it beyond playing with it, but it is simpler and doesn't require text based code either.

There's a private method called Convert to Stub which does this. I never used it, but I understand it does have some caveats.

I don't see those and looking at your example, it doesn't seem familiar. Which LV version is this? Also, do you have any keys in the LabVIEW.ini file which perhaps enable these logs?

I haven't checked specifically for the code hooovahh linked to, but I assume it simply uses the .NET DataGrid control. This has a BackgroundColor property which you can set. You need to wire the terminal of the control into the property node and select the property. The data type for the color is a .NET datatype which doesn't need a constructor, so you can just wire the output into a property node to link it to the Color class and then disconnect that and select the relevant color and wire it as an input:

There is a checkbox for enabling a build log in the Advanced page of the build settings. I believe this is the same log, but I haven't compared them in a long time. The advantage there is that this option is easier to access and that it only applies to that specific build.

I can't say I understood what you have exactly (an example might help), but assuming your case structures take the strings and then parse and handle them, I would consider using scripting to split it into VIs where the VI name is whatever you handle in the specific case. The VIs should all have the same conpane and then you can call the correct VI dynamically. I think I would prefer having hundreds of VIs to a case structure with hundreds of cases. If you know that the two cases have the same code, you can then simply move then to a single folder, or you could try comparing them to see what the differences are. The scripting might be tedious and it might require some fiddling to get it in an EXE, but it should be doable.

Turns out this was only happening in a single computer, or at least that's what I'm told. The other one uses Modbus TCP for the more intensive comm, so I don't know if they would have noticed it there as easily. Anyway, after some grumbling, the client did replace the converter and said this resolved the issue, so I guess I will cancel the request. While I haven't seen the problems with sync myself (have been using the old NI Modbus code since the time it wasn't old and there it is set to sync), I don't think I can justify the request without a concrete use case.

I'm attaching some of Rolf's VIs from years ago. They do include code for writing an image to the clipboard (see the example in clipbrd.llb and look at the control or panel buttons). This would probably require adapting if you're on 64 bit LV. Clipboard - RolfK.zip

We're checking with the client to see if they can check with different hardware. They did say they are using the same converters in other places with no issues. I'm not sure which device and chipset it is. This does happen in the two places we have used this code (and converters) so far. In both cases, the code runs actors (one for each unit), and has an additional layer of locking for the bus on top of the one used in your code. One of the PCs only communicates with a single unit, so it only has a single actor. I'm not sure if sharing the code would help, but maybe we can do that if you feel it might be relevant. To be more clear as to what the actual issue is: The communication starts normally (it cycles through different Modbus commands as ~2-20 Hz) and after some time (my understanding was that often it was after only a few hundred cycles), the actor gets stuck, while the rest of the program keeps running and the UI is responsive. By adding some debugging indicators we have seen that it gets stuck at the read or write primitives and when adding the option to work synchronously, we have confirmed that this causes the freeze not to happen. This is the first time we used the Plasmionique toolkit. Before that we used the old NI modbus code, which is set to sync and where this didn't happen, but that has its own host of issues. Obviously, the actual problem isn't in your code, but somewhere in the serial stack (LV/VISA/driver). I'm not sure what the actual problems with sync would be, so I can't comment on that. The help says it locks the thread until the call is done and that this will impact performance if there are more than ~4 devices. Since the systems I have to work with at the moment have at most 2 RS485 buses, meaning no more than 2 devices in parallel, that's not something I can currently test.

Hi Porter, we have run into an issue with an EXE getting completely stuck and traced it to the VISA read (or write or both, can't remember) being configured to the async mode. This is in LV 2015 with VISA 15 (and I believe it was also tested with VISA 18.5, which was the latest supported version). Would it be possible to add a boolean property to the class to allow making the R/W calls in sync mode? Should be as simple as adding a case structure with a second copy of the node.

I have wrapped the needed parts of the Pylon .NET SDK, which was reasonably easy. The one thing which might help you with that specific one is that after you grab an image (either with a grab method or with a callback event), you can get the pixel data by getting the PixelData property from the grab result, calling .NET Object to Variant.vi on it and then converting the variant to a 1D U8 array. Note this could be an array with 3 bytes per pixel, which matches the LV picture control flattened format, or 1 byte per pixel, in which case you need to create a grayscale color table.

Yeah, I meant "I don't know about anything wrong with new VIs, but here's one way to cause this with a VI you create". The global setting I have is also configured to separate, so I think your idea is unlikely to be the cause. Anyway, the bug# for that one is 961456. By the time I thought about reporting it, the 2020 beta was already happening, so I don't know if NI fixed it for 2020 or SP1 or 2021 if it ever comes out.

Don't know about new VIs, but there is a bug where if you crash LV and then restore auto-saved VIs, they always have the flag turned off.

I haven't checked the behavior now, but I did remember this discussion from some years ago - https://forums.ni.com/t5/LabVIEW/Queues-Enqueue-Dequeue-Element-Scheduling/m-p/2367134#M737149 Note that in the post I linked to AQ does say that "the writers are serviced in the order they put in their request to write, so there's never a starvation" and that only the dequeues could be starved, but maybe this behaves differently in limited size queues or maybe this is different in different LV versions?

Well, it looks like that's just Windows. I can manually resize other app windows (Like Excel) to a small size and get the same thing. For instance, here's Notepad++ on Windows 10, where I have the mouse over the minimize button to highlight it, but the line is visible outside the window even if I'm not hovering over the button:

I haven't seen very long replies, but it looks like some of the replies are longer than was previously truncated, so I believe the switch flipping helped. I'll update if I see more truncation. Thanks.

Well, that creates a mixed reaction. On the one hand, obviously, congratulations, good luck, enjoy, etc. On the other, we're losing our resident Greg McKascle and we'll have to see if someone else with the same level of knowledge steps up to offer such access to internal information. I can think of some and hopefully one or more of them will provide. Good flying...

Since the latest update, it looks like email notifications don't show the whole message (see example below). It doesn't look like there is any user setting to control this. Any chance of changing this on the backend?

The button with the two arrows in a circle on the toolbar (next to the cleanup button) opens the reorder menu, which includes the options for grouping and ungrouping controls. Note that this is purely visual and there are no properties for the group.

I recently backsaved a few things from 2020 to 2015, including with classes, so at least there it works. I would suggest trying to save something simpler and if that works, then take only parts of the project (which obviously will load with missing dependencies) and just backsave those, to see where the issue is. With your image stuck at a vi.lib VI, I would also suggest making sure to mass compile the folder again (or at least the error ring folder) and possibly trying to remove the error rings from your code, if you don't have too many. If something would have problems with backsaving, I wouldn't be surprised if it would be an XNode, although it clearly has code for the backsaving.

The Application class has a couple of private methods which can do this (called Global Data.Set and Get) which operate on a name and a variant value (I believe this goes back at least to 2009). I think this should persist across QD calls. Note that you should pick a name which will be different from other things which might exist in the system.

No errors are added to the log when this happens. The errors that are there (the file is attached) are probably partly because of my attempts to manually install and partly because of another annoying bug - I don't recall the exact details, but basically my LV had a non-standard VI server port, and VIPM had trouble connecting to LV. I figured out that was probably the issue (as it happened before), so I changed it in LV to be the standard 3363 and then VIPM could connect, but when installing or mass compiling (can't remember what point exactly) it then failed to connect. I looked at the VIPM settings and saw that it did actually find the non-standard port, so I changed it in VIPM to the standard one, but it still had trouble connecting. Basically, it looks like that there are two points in the installation process of a package where VIPM tries to connect to LV and one of them caches the VI server settings and isn't updated when the settings are updated in VIPM until VIPM is restarted. To successfully install without restarting, I had to switch LV back and forth between the two ports. Well, I understand why you want to create a small barrier after you've explained it. In this specific case, my need is small enough that I haven't bothered with overcoming that barrier so far. VIPM error log.txt

Currently, with LV 2020 and VIPM 2020.1, I have the following problem: I open VIPM browser and search for any package (like an OpenG or MGI package) I find the package I open its page and select download I get a Windows popup message that it was downloaded almost immediately, but nothing happens if I click the message. The other three buttons on the page remain disabled, so I can't open the package in VIPM to install it. If I take a VIP file from elsewhere and double click it, then VIPM opens it and I can install it. Also, the downloads page to download older versions requires a sign-in.

NI is trying to release it earlier. See here - https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-LE/idc-p/4030035#M41946