Search the Community

The data in the sub-panel is always at the very top level when refreshed, I don't want that, what should I do? The picture below is a screenshot of me.

I'll be doing a SCADA for a high vacuum system. I have not yet settled on the graphic style of the hmi (skeuo, flat, diagrammatic, whatever), but I'd like to do something slick. I have looked at DSC controls: 3d pipes somewhat do the job, but all the rest is crude. Looked into the DSC images navigator, images are sooo 2002, and again little specific to lab. Have looked at https://www.openautomationsoftware.com/downloads/free-hmi-symbols/, images are pngs and not too much choice either. Searched a bit the net and found nothing. I miss specific elements like vertical turbopumps, guillotine gates, vacuum chambers, ideally scalable. I'm tempted to inkscape down my path of personal crap-art, but I know it will end into another bad trip. Is there anyone who can suggest a nice source of suitable elements?

I am working on a complete redesign of our instrument control software. I'll be using LVOOP and some form of messaging/queue system. The program must control 10+ different types of instruments, each having variations in I/O (pressure control, temp control, motors, different types of controllers, etc...). Most of our instruments run from a touchscreen attached to an embedded PC. A few run from a desktop and we have some that need the desktop version to control multiple instruments at the same time (using a tab control in my old program). So far I have a top-level vi that decides if this is a touchscreen, desktop, or simple test-viewer and launches the proper set of user interfaces. There are UI's for IDLE state, Test Setup, Config, Calibrate, Run Test, and so on... I have been studying discussions here from the super-megadudes on frameworks, lvoop, messaging, and how NOT to do things. After giving my best shot to AQ's AF I'm now using LapDog messaging from Daklu & it is time to ask some questions! 1. Would you recommend using a single top-level UI and then plugging in different pages (Test Setup, Idle, Run Test, etc...) via sub-panels? In the past I have found that complex sup-panels can really slow things down. However, without them I end up seeing the desktop when switching between UI's. Not a big deal but not very professional looking. 2. On the framework subject, is it better to have my I/O channels messaging a mediator who then messages the current UI or should they message the UI directly? 3. What about updating indicators? It seems that passing UI indicator references to CHx is faster than CHx sending messages to the UI (or to mediator then to UI). I need good response time: Example - I want an LED to light up on the front panel when a heating relay is turned on and off. The relay may only be on for 50ms every second. Can I really send a LED ON msg and then an LED OFF msg and expect it to work smoothly? For 2-8 channels at once? 3. Should I be re-opening the channels every time I switch UI pages or should I initialize them once and leave them running even when they are not doing anything? If the latter, what happens to the queues when the UI closes and another opens? I could pass the callee queue but what about the caller queue? 4. I have a CHx parent class with children for each I/O "type". At runtime, some stored config information would tell CHx what child to use, which channel # this is, what to label the UI controls and indicators, and, according to the type of UI (also using classes), which controls to show/hide for appropriate functionality. There was a thought of giving each I/O class a UI and then plugging them into sub-panels on the bigger UI but I thought that may be too confusing for the poor sucker that inherits my code. It already seems that using LVOOP and a messaging framework distorts what I think of as "dataflow" drastically. Any quick thoughts on this or pointers to similar discussions? Here are some UI screenshots so you can get an idea of what I am doing: I truly attempted using the Actor Framework from the bottom up but I just cannot wrap my head around implementing it on this scale. Everything is so deeply encapsulated that I cannot figure out how to actually DO anything! LapDog allows me the freedom to implement a moderate amount of LVOOP without having to wrap every aspect of the program into classes and messages. I know that's a mess of vague questions for a single post, sorry! I'm new to all this.