Leaderboard

Sure it's possible. When you are making your application in the project be sure and add an ICO file to the project that has multiple images in it. I usually do this to have several resolutions since it sometimes looks better when larger or smaller. I usually make an icon that has 5 images in it at different resolutions: 128x128, 64x64, 32x32, 24x24, and 16x16. Then in the application builder settings, pick the icon as the one from the project. I just opened my EXE in resource hacker and see them all listed under the icon section so I assume you can probably reference them by the index, just like LabVIEW does. Otherwise you could just include multiple image files in your application builder that just go into support. Then have your icon be a path to that image file by setting that in the registry.

Well, I wrote a whole library so I would never have to use modbus I/O servers ever again, so I'm not the person to ask on the second part As for datasockets themselves, they run in the UI thread and block. So for example someone resizing their window or opening the file menu and looking around will cause datasockets to block. You also can't run code which requires either the UI thread or root loop (I cant remember which) per this idea exchange request: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-it-possible-to-dispatch-VIs-dynamically-when-the-UI-thread/idi-p/1579534 Unfortunately, I can no longer find my kb on the subject, maybe it got lost during some of the web upgrades.

I believe Mitsubishi PLCs also talk Modbus. There is a big difference between OPC and OPC UA (this was pointed out to be on these forms, so I know there is at least one entry). I've yet to look up the difference. I am familiar with OPC, so my comments relate to that save where noted. There is a shipping example with LabVIEW on OPC using datasocket. I recommend sending a data block instead of individual tags, particularly if you have a lot data. There is overhead with each tag that can be problematic. Down side to a data block is having to parse out the information you're interested in. Meeting your update rate could be problematic. OPC is meant for process control (the acronym is "OLE for Process Control"). OPC goes through OLE which has the lowest priority Windows can assign. Anything with normal or high priority can block the OPC communication for 10s of seconds. OPC UA does not do this, so doesn't have the issue. I've used KepWare before and have had nothing but good experience with it. I did have to break up a data block into multiple once it reached somewhere around 128 bytes as communication stopped above that limit. I expect that's an OPC spec rather than a KepWare limitation. Don't know if KepWare can do OPC UA. I expect OPC isn't as mentioned as PROFINET and Ethernet/IP have become more dominant. It still has its applications. For logging and alarming, I believe LabVIEW DSC has that built in otherwise you have to make your own. I believe DSC can do OPC UA. I've never tried wireless, so can't fully answer about that one. I have had ethernet cables unplugged and PLCs taken out of run mode, and always had good recovery with that.

No requirements specification; no solution. If you don't have one, then write one. It will force you to consider the details of the system, the components and how they will interact. If you are in the position to dictate component/device choices then choose a multi-drop interface and ensure all devices/components use that interface (TCPIP/RS485/Profibus whatever-find the common denominator). Then try and normalise the protocols (SCPI for example). A judicious choice of device interface options means the difference between juggling RS232, TCPIP, GPIB, RS485 et. al when they all may have TCPIP options when purchased. It will decrease the code complexity by orders of magnitude when you come to write it. Once you have all that defined and documented, then you can start thinking about software.

There are multiple ways to do things; but pick one. Be wary of mixing different methods in such a way that the result is overly complex. So when you mention mixing CVT with an independent messaging system, that’s a worry. Note that smithd’s Projects don’t mix the two. Personally, I follow the messaging paradigm, rather than CVT-like tags (my tag-like functionality is a Register-Subscribe notification system build on messages), and I have a standard library and template for QMH “actors” (note: NOT Actor Framework) that can communicate locally or over TCP/IP (some videos).

Thanks. There is actually a couple more checkboxes that I've considered adding, but I have an excessive number of check boxes already. Possible Checkboxes.vi