Yair

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.