Dragoon235

I just realized one other thing I needed to clarify, this module needs to generate the temporal triggers. There is no external module generating them. Perhaps that is where the confusion with the pub/sub framework arose?

Thanks for the response, but I'm not sure that's what I need.

Maybe I should provide a little more elaboration. My question was not about message sending framework, as you have described in a pub/sub pattern. The statecharts are being used in place of an LVOO class, and there is not adequate time to re-factor the entire system design to use LVOOP. My goal is to design an extension module with minimal modification to the currently working code. My question was more about how would you specifically implement a message sender that responded to temporal triggers and data triggers. I'm not opposed to wrapping it in a class, but that is not of prime importance for this design. I will admit that I don't have much experience with LV classes.

Thanks again,

Jonathan

Hello,

I have an application that controls several pieces of equipment, and the basic architecture is a QSM-PC for each device. User button presses (interactions) are logged into an event structure which generates commands and loads them onto the respective queues. As an experiment, I tried implementing the system using the statechart module (if anyone is interested).

After this initial development stage, I need to add some automation to the system. Some of the automation is data driven, as in , when a device reports back a new data value. Other events are temporally triggered, such as acquiring a new video frame from from a framegrabber (no strict timing requirements). My goal is to have this system automation turned on or off with one (or a series of) button(s) on the manual control GUI.

My first thought was to set some of the timeout values on the dequeue to take care of the temporal servicing, and to rig an event structure to watch for new data for data driven operations. However, I would think that since I already have the messaging framework in place, and all necessary actions already have designated messages (take measurement, return data, report status, etc.), would it be possible to centralize this control? Does anyone have any suggestions for this type of automation?

Thanks,

Jonathan

Just as a warning, you can get weird color blending effects by doing grayscale filtering operations on color-planes of an image. The Gaussian filter should not cause much of a problem, but you could find some strange colors around the borders between regions of different color.

This is a bit of a stretch, but if you have matlab, you could use a matlab script node. They have a very large standard image processing library. But you might as well use Matlab for the project. Similarly, you could also use c code nodes, or compiled dlls, but this is overkill for labview. You'd probably do better developing natively in something else, rather than writing dlls for labview.

As for LV practice, I hate to rain on your parade, but do you know how many man-hours go into a toolkit for Labview (or for any programming language, for that matter)? I assure you that you will spend more time repeating other's work than doing your own. Remember, your time is money, too. Assuming you are an engineer, two weeks of your time is definitely more costly than a license. If you're a grad student, I can sympathize (I wear both hats), and I've heard the "make it work" message.

so much for "how to paint a house without a paintbrush"...

- Jon

A few thoughts on your situation:

Simple, but not elegant solution: create one queue for each consumer loop. This definitely is not the most efficient, but It should make your code work (if you're under a deadline). Another quick-n-dirty solution would be to use a chained producer consumer pattern, where the output of one consumer is the input of the next. This may or may not work with your data scenario, and at worst, this devolves into my first suggestion of make two copies of the data.

Hey, memory is cheap, right?

You should also consider block processing methods (think chunks of data rather than individual points): have at least two buffers, fill one buffer (for example, an array), process contents of one buffer (extract aggregate statistics and log to file) all while the other buffer is filling. This could be a queue of arrays. While this is in step with producer-consumer, this is more at the algorithm level than at the architecture level.

- Jon

If you are looking for just a MS Visio replacement (what giffy seems to be) you might want to try Dia. It was originally a linux app, but it has been ported to Windows.

Dia main site

Dia for Windows

I have had this problem as well with just standard LabVIEW controls and text labels (using 2009 app builder). They just seem to shift slightly, and things areout of skew.

Has anyone else encountered this?

- Jon

Paul,

Thanks for the feedback. I'm looking into your suggestions about the OO design patterns. I also have been reading up on the LabVIEW Statechart module, but I'm not sure if that will yield any fruit. Do you (or does any one else reading) have any experience with the Statechart module?

As a more specific response

1) In regards to the Model-View-Controller, I understand it as a design paradigm. I think I could probably do a better job separating the "model" (command sets and message encode/decode) and the "controller" (state transitions and handling user interface), but I'm not entirely sure where to draw the line in terms of LabVIEW. Is this where the OO command pattern comes in? This is partially why the Statechart module piqued my interest, as it seems at a quick glance to encapsulate the controller portion of the code quite nicely.

3a) As for performance, this will be running on a PC with native windows XP 32-bit edition. There are no "real-time" requirements, per-se, but it will need to stream video (a module yet to be developed). The I/O requirements are something like 4 devices over RS-232 via PCI (PCMCIA), a video capture card (ExpressCard), USB video capture (RS-170), and a usb control device. Critical (microsecond) timing is handled by custom hardware, and does not need to be handled at the software level.

3b) After doing a little more deep reading of the previous application's code, I found another potential bottleneck or two. The code was written to dynamically load the instruction sets of each piece of hardware from a text file at start of runtime. This was loaded into a string array; in some cases, the string array was searched to lookup the particular command. For this application, that is a bit of overkill (there is no anticipation of radical changes in the command set). Also, some command sets had ~200+ commands for any device. Not so good for an O(n) search just for a button press. I'm sure there may be something else under the hood, but at this point, I don't think it is worth looking for as there are about 150 vi's, some of which are bells and whistles like this. So I guess that's the message handling quirk.

4) Considering the value of a more seamless integration, I may rewrite the existing state machines to fall in step with the eventual design paradigm. In the meanwhile, I have been encapsulating helper code, such as "Camera XYZ Build Command" and "Device ABC Interpret Response". I think it should be quite feasible to wrap these into methods, yes?

Thanks for the help,

Jon

There are several VI's that can give you lots of information about particles after you have filtered them:

The Particle Analysis VI can tell you exactly how many pixels are in each blob. It can also do lots of other binary image statistics: elongation, circularity, etc...

Other Analysis VI's part of IMAQ can do other operations. I'd recommend using the filter command as suggested above to limit the amount of data.

The data in each cluster will vary (different control types and number of controls)

It's important to note that clusters are not dynamic. They are similar to struct's in C/C++. For example, an out port on a case statement; you cannot wire a cluster of two booleans and a cluster of a boolean and a numeric to the same port. You will get a broken wire. They are different types.

Variant datatypes store the data as well as the metadata for interpretation of said data. Flattened strings can also be used for this purpose, but they require a little more management by the programmer.

Here is a good article on variants and flattened strings from NI's Website:

NI on Variants

If you are trying to enter a coordinate, aren't there easier ways to do that (numerics, sliders, knobs)? Because that would be like creating a "mouse control". You could build a control as either a typedef or an XControl or similar with an event structure that registered the position of mouse clicks. Or you could just use the event structure to register the position of the mouse on a click. You could also register pressing of the arrow keys, or create a key binding of the arrow keys to buttons on the front panel. Otherwise, you are getting into some tricky programming in regards to emulating 3D motion in a 2d front panel.

If you mean to read from a physical track ball like a joystick, I think that involves some configuration on the OS side first such that it is not registered as the primary pointing device.

Hello,

I am in the process of developing a control application for a prototype optical system, and I was wondering if anyone could provide a second opinion for the program architecture I have chosen, especially with regards to performance. As follows is a description of the system and the code written thus far. Please forgive me if this is a bit verbose; I figured more detail would be better,

In terms of components, there are several different types of illuminators, cameras, and motors to control the optics. Total component count is around 8 independent parts that require control. The goal of the control application is two fold. First, it must be a framework to control each component independently to allow for testing, development, and real-time testing and tweaking. Second, it must be able to control each device in a "free run" mode, which is how the system will operate as designed; such that the application must react to basic user inputs (stop, go, "look at this") as well as handle input from the various devices and adapt (e.g. camera is low light, change PWM signal on illuminator).

Each device requires a control panel of 5-15 buttons as well as 3-4 fields, numeric or enum, to handle the most used commands. Also there is a string interface for handling the esoteric command that is not often used. There is also a panel to manage device connections, and a panel for the free run mode. I assumed a tabbed interface would be best.

As for under the hood, I started basically with the QSM-PC model as discussed on the expression flow website; one loop is an event structure that handles button presses and loads them onto queues, the rest are consumer loops controlling devices. In a previous system, one of my colleagues had used this architecture to control a system of a similar level of complexity, but there were complaints of the program not being very responsive I assumed that this had to do with control-reference-variant data in the message packet, or the queue manager. To try to improve performance in this new application, I have removed the "queue manager" completely and created a message packet with a device specific "message label" and boolean value rather than a variant. To sum up the typedef and enumerated values for each device:

Hardware Module X:

-Message packet

-Message label

-Device state data cluster

-Device state list

-Device command list

plus the queue for that device, and the while-case loop that execute's that case's state machine.

Several of the components have simple state machines (with polling the UI), each standalone VIs, that already work. I attempted to reuse this code by replacing polling operations with a dequeue-and-interpret-message segment of code in each polling state. Some of these state machines have multiple polling states, especially the non eye-safe laser (IDLE, IDLE-Armed, Wait-For-Stop). The state transition mechanism is essentially:

state data + current state + (message packet if polling state) => new state + new state data

In regards to performance concerns, the application will need to decode and display two incoming video streams at 30 fps. I am assuming this will take a large amount of processor time, so I want the rest of the application to be as nimble as possible.

Any and all suggestions are welcome. If you think there may be some other bottleneck that I haven't anticipated, I'd be curious to hear your thoughts. I don't have much experience estimating the performance of control references, variants or the like.

As an aside, I've never done OOP in LabVIEW, but I'm familiar with it from C++.

Thanks,

Jon