jbjorlie

OK, I think you have all helped me quite a bit. I now see no reason to avoid shared variables for sharing data between vis when only one vi is ever going to write to them. That also gets me out of filtering out old data in queues and I can update the indicators only when I really need to. I can use messaging for all the commands and other requests. I do hate to force the inclusion of the Shared Var Engine on my builds though.

Using a waveform for individual reading does NOT seem like a good idea. Why not just store two channels: “Measurement” and “Measurement_Time”? That’s what I do.

That's what I do now, just thought there might be some slick way to stick them both together and keep it compact. Sometimes we have processes on the same test that would benefit from recording at different sample rates and I don't like to store time info as a separate value for every channel. One x scale is enough. However, I think just storing the sample rate in the attributes will be best.

Another technique is to realize that most simple indicators are really just text, or can easily be represented by text, and thus one can do a lot with a multicolumn listbox or tree control to display the state of your instruments.

That's a great idea but most of my GUI labels are for booleans, rings, and other controls. Things like: CH3 on the GUI has a Menu Ring, 2 Booleans, an indicator, and a Set Point control. Sometimes CH3 is controlling a Hydraulic Pump, pressurizing a test cell. Another time it may be controlling a Motor or a PID Heat/Cool process. I need to label everything accordingly. My object with this software has always been to have a single executable that can be configured to run many instruments while giving the user a similar experience. Training is a huge problem in our field as operators of our equipment come and go all the time. I want it to be easy, intuitive, and well labeled so they know what buttons to press and don't blow anything up.

Oh, and % output is great if you know what it means but try explaining it & why it jumps around so much to a Uzbeki lab tech without spending 22 hours summarizing PID control. MUCH easier to just ask them: You say it's not heating? Do you see the top LED blinking? You do? OK, that means power is going to the relay controlling the heater...I promise it is not a software bug, check your relays, etc...

The event handling deals with initial reads cleanly. We do use the DSC module for the shared variable events.

Not gonna happen on the budget in this office! DSC module does look quite nice for many things.

After all your great feedback thus far:

I feel the future is in each I/O "class" having it's own set of GUI plugins instead of customizing a set of controls/indicators at run time. Then I can just plug them into appropriately sized sub-panels on the main displays. That may be another generation away due to the work involved but I will perform this revision with the objective in mind. Queues seem the safest for sending cmds and non-recordable data between different vi levels but I need to find some sort of shared variable, functional global, or ViRegister solution for the process value updates and turning PID lights on/off.

Still not sure how to best switch between UI modes (keeping channels running through mediator or closing them and re-initializing once new screen is up) and whether or not to have the mediator for channel-GUI communication also be the mediator for GUI-GUI communication.

PAUL, I am in Tulsa, OKLAHOMA! (always add the ! after Oklahoma! for dramatic effect). Thank you for the well thought response and encouragement. Of all my responsibilities at this small company, none is more enjoyable than learning from you guys and writing LabView code. I suspect it would be great Full-Time work.

Lastly, JAMES, I have enjoyed your hassling with Stephen on the Actor Framework forum I love the idea of the AF and he must be quite a scientist to have created it. However, it seems on the verge of too much "safety" at the cost of usability, especially when introducing it into existing code. I hope the discussions there result in some small modifications to lower the entry barrier before it gets plopped into the <vi.lib> for eternity. LabView will always be a coding toolbox for the engineer and the tool sets need to be somewhat flexible. IMNO (newbie).

Nice, 2 of the super-megadudes I've been learning a lot from. Thanks fellas.

I'm glad to hear the messaging system can be so fast if done properly. Steen, that module control toolset looks pretty interesting. I was very interested in your vi registers idea until I read the whole thread...still seems like a brilliant way to share data. 1000 channels eh? are you controlling those or just monitoring them? Do you place each data value into a waveform to attach the timestamp? I was using waveforms in the last revision but it seemed to use up too much space. A file with only 30-40 data points per minute would be megabytes in size after a couple of days. I don't know why, it was in .tdms format and every time I took x readings I would average them, convert the result to waveform data, and append it to the file. Since it was not streaming data I didn't know of any better way. Now I just store a double value in the .tdms file which takes much less space than the waveform. I would love to store a timestamp for each value so if you have a good compact method let me know please. I need my data file to be tens of kilobytes, not megabytes.

I am running the UI on the control machine but the operator can also access a GUI from a remote machine which will plug in much like Steen's system noted above. I do keep the "business" seperate by making each channel the commander of it's own routines. It runs by itself only receiving change commands through a queue from the mediator. My education from this forum lead me to believe that was the best way to do it. I was going to have each channel write its data to the tdms file as well but maybe I should message the data to a central "Storage" vi and have it write the data??

Can either of you comment on the sub-panel vs. opening/closing GUI's question? If sub-panels is OK for a 500MHz XPe machine, what's the most efficient way to open and close the GUIs? I was going to use the new asynchrounous call node through the mediator but maybe I need a GUI mediator with the sub-panel control and a separate "business" mediator to handle the channel I/O?

I have a very hard time finding good examples of applications using multiple UI screens while controlling multiple I/O channels with different sample rates and different hardware! Everything NI puts out seems to rely on DAQmx or some unrealistic $$package$$$$.

Also, any suggestions on a better way to customize controls/indicators on the GUI at runtime. Right now I have to store all the captions, limits, marker spacing, etc...in a file/cluster and load them in using property nodes for each control.

Thanks again for the help. I have no mentor (or even co-creators) here so aside from my Bloomy Book & NI's outdated propaganda there's now way to learn proper architecture/style. LabView seems to be experiencing a renaissance since 8.5 and I want to be the best architect in the state

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.

QUOTE (Neville D @ Jun 1 2009, 01:04 PM)

OK, your requirements are fairly complex and will not be solved by simple remote panels or web browser interfaces considering re-entrancy/panel size/display requirements.

Design a protocol to talk to each instrument. Display commands sent and responses recieved in separate tabs on your HOST or control PC. That way you have complete freedom to setup and run the instrument without the complexities of panel size etc.

You can use shared variables to simplify the communication protocol.

Check out:

Command based architecture (you can replace TCP-IP with Shared Variables to simplify; there are examples on the NI site using SV's instead of TCP-IP)

Advanced LV-RT resources (you can read up stuff here and apply to your LV-based targets as well).

Neville.

I suspected I may not get off that easily. I suppose this gives me an opportunity to become a better LV programmer and learn some techniques. Thanks for the links and the posts! You will likely hear from me again!

Thank you Neville,

I will upload some code but it would not likely help much unless I uploaded the entire project! The vi I am having trouble with is simply a tab control with a subpanel on each tab. For remote instruments the subpanel is loaded with a "web browser" vi. When I run this web browser vi alone it works fine, just not when loaded into the subpanel!?!?!?

Also, once I run it once, it never seems to work again unless I restart LabView. I am guessing this is because it was never properly closed but I don't know how to shut off a web browser activex panel and/or destroy the reference?

I would LOVE TO USE REMOTE PANELS for this application but I know of no way to insert a remote panel into a subpanel or a tab control. Can this be done?

Thanks for your help!

I forgot to mention my reasoning: I do not want the remote vi to pop up in an unconstrained separate window. The touchpanel on the instrument is set to 800x600 res and when I connect to it via remote panels on my high res desktop the window is HUGE! I cannot have a title bar on the touch panel either.

Before posting this I searched for the best solution to constrain remote panels inside a "main" vi window and the web browser subpanel was the only solution I found.

I am using LabView 8.6 to create an executable which runs on a target instrument with a touch panel. Additionally, I need another executable to run on a remote PC which can control multiple target instruments. My idea was to use a program on the remote PC with a separate tab for each available instrument. On each tab would be a subpanel which ran a VI web browser. The web browser vi would simply display the target instrument's executable and the operator could request control and setup/run/view tests. When I create web browser vi and try to conect I just get a configured .html page for the instrument but no front panel image. The front panel window just says "Setting Up Plug-in Window" and will not load the panel. Using an external IE or Firefox app the page loads fine but does not load the application instance running on the instrument. I need re-entrancy as I am also running many "Single Instrument" vi instances on the remote PC to directly (via USB/Serial) operate additonal instruments. All instruments run from the same "Single Instrument.VI" program with different parameters. The remote PC simply calls the WebBrowser.vi or SingleInstrument.vi into the proper tab depending on the location of the target instrument.

I hope that was not too long for anyone to read but I want you to know what I am attempting. Also, if you have an alternate implementation which would avoid complication I am all ears and very willing to learn. Thanks much!