Leaderboard

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

View File Flatline Controls A set of custom controls, following the trend of a more flat UI design. Heavily influenced by Google’s Material Design, though constrained by what can be done with available tools and options in LabVIEW. Uses icons from Google Material Design. — Buttons based on the system booleans (with hover effects). Icons can be added as decals (such as from materialdesignicons.com) — Matched sets of controls for numeric/string/enum/etc., based on Silver controls, but swapping out all ‘chrome’ for simple boxes and lines. — flattened versions of switches/sliders/arrays/graphs etc. Now on the LabVIEW Tools Network JDP Science Tools group on NI.com. Submitter drjdpowell Submitted 06/13/2016 Category User Interface LabVIEW Version 2011 License Type BSD (Most common)

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.

Fair enough. Again the field is too broad to answer generally, but I can share two varieties I've worked on, both in the general area of SCADA. Project A is more of a local control application, where there was a decent amount of logic on the distributed systems. www.ni.com/dcaf is a good example of the general design used -- all data goes into a central storage and the control loop operates continuously off of that storage without ever stopping. Events were implemented as tag changes. Data is transferred between device and HMI by copying the full tag table between systems, so there is no concern about missing an event. This could be implemented using the CVT client comm library if you're using the CVT, but in concept its very simple -- make a TCP or UDP socket, send data on that socket at a fixed periodic rate. Project B was more of a daq application with a lot of attached devices and instruments and a tiny, tiny amount of control. As such, an event-oriented approach made sense. Everything used a QMH, data went over the network as separate packets in a TCP stream and were processed as individual updates (although for some HMIs this was copied into a global tag table like the CVT). Here, a TCP stream was used for data updates, while messages were sent using a request-response protocol on top of TCP (think similar to http). The advantage to this is that you always get a response immediately. If you say "move to here" and it knows it can't, you'll find out immediately rather than having to (for example) look for a fault bit to be set. For every system I've worked on I've found syslog to be handy -- this could be either the UDP-based library provided by NI or just making a simple string file logger yourself. Debugging is always a challenge, so a standard way to report human-readable information (debug messages, status updates, errors) is critical. If you make your own, timestamping is important. Some people like to have a central error handler, but I've never seen this work well. Reporting, sure, handling, not as much. My general pattern is 1-check for expected errors, 2-if the error is not expected, reset the process from scratch and report. For example if you're talking to a serial instrument and you get an error, tell anyone who might care, close the visa session, reset, and try again. Don't try anything fancy to fix it.

Oops. A bit embarrassing. Seems LabVIEW linking insists that VIs are in the VI.lib instead of user.lib when opening the project. and causes linking hell! Attached is a new version that fixes that. However. If it asks for "picktime.vi", it is a part of the LV distribution and located in "<labview version>\resource\dialog" which isn't on the LabVIEW search path by default, it seems. I'll delete the other file in the previous post to avoid confusion. Test Manager0101.zip

It has to be in memory to make sure the code can compile. Look back at his post: "By changing the subVI to Load and retain on first call, it will no longer be reserved for running when you run the top-level VI, and as a result, will not ever hang your app if you accidentally leave it open before running." Its in memory, but its state doesn't change from edit mode until the function runs. Personally, I think modals are evil always and so I use floating/normal if possible. It seems like any time someone uses a modal dialog its a situation where I was wanting to copy/paste from another part of the same application and now I can't because the modal takes over. Whatever you do, for the love of god please don't do what VIPM does where it endlessly forces itself in front of every other window every 3 seconds just to piss you off. I know the exe doesn't care or have emotions, but every time I install a package I ctrl+alt+delete the damn thing just to spite it.