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?