Mixed Signal Graph Bugs

[Omar Mussa]

After experimenting a lot with the Mixed Signal Graph as part of my ill planned "challenge", I've found out why I hit so many issues.

Here's a list of CARS generated as part of my excercise...

CAR ID: 45UEA5X6

If you change a plot's scale programatically (using the ActiveYScale property) to a scale in a different plot area, the plot disappears from the plot legend

CAR ID: 46M8DBX6

If you set the Plot Legend to invisible and then 'Add Plot Area', the plot legend is visible for the new plot area.

CAR ID: 3L2FE3CM (may be tied to all LV objects, not sure, also this one already existed but is related to an issue I had)

If set the MSG 'Fit To Pane' and set the graph to scale object with pane, when you resize the pane the plot areas do not stay visible proportional to the pane size. (It is especially bad scaling down to smaller sizes - if you do this and then scale it back up a few times you will see the graph look very bad quickly).

Additionally, I requested two additional features (which means nothing in a lot of ways...) - 1) you should be able to Add and Remove Plot Areas via invoke nodes. 2) the plot bounds and plot area are overly coupled which means it becomes very difficult to resize the MSG without very poor results.

Thanks to everyone who helped me plow through my first (and possibly last) use of the Mixed Signal Graph.

[JasonKing]

Hi, Omar. I'm the developer responsible for most of the MSG code. I apologize for the problems you've run into, but they don't sound *that* bad to me. That's not to say they're not a nuisance - certainly they are. But without knowing what you're trying to do with the graph, it doesn't sound like it's unusable. I'd be very curious to see/hear what you are using it for.

I've often wondered why I didn't hear much about people using the MSG. Is it too buggy? Do people just not know about it? Etc. Unfortunately I am no longer working on it (and thus don't get the bug reports), but I'd certainly love to hear any feedback and will do what I can to steer things into a more useable direction, as I put a lot of effort into that beast.

Regarding adding and removing plot areas via VI Server. For technical reasons, we can't do that while the VI is running, but as a "Scripting" feature such a thing would be possible. Going forward, hopefully those technical reasons can be removed.

J

[Ton Plomp]

QUOTE(JasonKing @ Mar 9 2007, 09:06 PM)

I've often wondered why I didn't hear much about people using the MSG.

Well Jason,

thanks for the control (truely)

What I would like for the MSG, is more documentation. Somehow I don't get it, as a developer I need the properties and methods alike the developer experiences the control. And for the MSG this is just not provided. I have looked at the MSG (in 8.0) and found it promising but not usefull. Sorry their are no other words to express my feelings.

So maybe a white paper (just like the one on LVOOP) of the specifics of the MSG for developers would be wonderfull.

It would be great if you remove my feeling that the MSG is a express-picture control

Ton

[JasonKing]

Hi, Ton. I can't say I fully understand your complaints. What makes it feel like an "express picture control"? What do you mean by "I need the properties and methods alike the developer experiences the control"? I'm not challenging those statements, I just don't understand them so I'm not sure how to respond, or how we can make the documentation better to address these issues.

In short, the mixed-signal graph is intended to allow you to put both digital and analog data on the same graph, sharing an X-scale. I've seen many VIs where users have two separate graphs and have to write a bunch of diagram code to keep the X scales in sync because the data shares the same time axis. This graph should be make life easier for this type of user.

Additionally, it does function a bit like an "express" graph because it accepts XY, Waveform, or digital data. This wasn't really the intention when we started out, but it was a nice result of all the other work that had to be done. It's not really meant to be an improved waveform or XY graph, other than it allows one to overlay other types of data with it, and you can use one cursor (a multi-plot cursor) to track values across multiple plots.

Anyway, I'm sure you can see what the graph is *meant* to do, but perhaps it fails in that regard. I'd certainly like to understand how it fails, and what we can do to fix that. If it's as simple as beefing up the documentation, that's good news

Thanks.

J

[Omar Mussa]

Hi Jason,

My use case for the Mixed Signal Graph was not the one NI (you) intended it to be. I wanted to have a nice, elegant looking way to display database historical data from a data logging system and wanted to have multiple graphs share a common X axis so that the user could easily scroll through time (x-axis) for several plots that were not time aligned. The MSG was a useful tool in this regard but it took a LOT longer than I expected to figure out the workarounds to the issues I ran into.

QUOTE(JasonKing @ Mar 9 2007, 12:06 PM)

That's not to say they're not a nuisance - certainly they are. But without knowing what you're trying to do with the graph, it doesn't sound like it's unusable.

Well - I'd agree except that figuring out the workarounds was about 2 days of work and that is not what I expected going in - I really was 90% done in a few hours but the last 10% was almost impossible and I definitely had to cut back some of the original 'features' due to these issues. In particular, it was really disconcerting to watch a plot disappear from the plot legend when I changed the active Y-Axis to a different plot. That made the whole drag/drop part that is nicely integrated into the tree useless to me. Also, I wanted the user to be able to see 1-3 plots depending on how the user wanted to look at their data - it took a long time to figure out an effective way to resize the plot areas because doing that would resize the plot bounds which distorted the graph and the entire scene. I also spent a long time getting the axes to remain visible/invisible based on what the user wanted to see. These were things that were cosmetic, but very important to my application.

I think the two following statements reflect a wider sentiment between NI and the LabVIEW development community (especially professionals).

QUOTE(JasonKing @ Mar 9 2007, 12:06 PM)

I've often wondered why I didn't hear much about people using the MSG. Is it too buggy?

J

QUOTE(tcplomp @ Mar 9 2007, 03:19 PM)

Somehow I don't

get

it, as a developer I need the properties and methods alike the developer experiences the control. And for the MSG this is just not provided.

Developers who are building custom applications need access to properties/methods to make the controls integrate with their applications. While its great for demo purposes to be able to whip out a graph that shows mixed signal DAQ data in a few minutes without getting too customized, the best professional apps tend to do a LOT of UI work to make the application meet or EXCEED the user expectations - this translates into developers wanting properties/methods to enable us to do that. The MSG is an example of a graph whose best features have no API or at best an obscure one that is not well conveyed - so most users will go to great lengths to integrate a different graph (like the XY graph) with a richer API so that they can get the desired user experience. (In fact, the NI App Engineer I worked with was actually steering me away from the MSG because he thought it would be better for me to create 3 XY graph controls then to use 1 MSG with 3 plot areas...)

[JasonKing]

Hi, Omar. Thank you for sharing your thoughts. I can certainly see why those bugs were frustrating to you, and certainly I don't expect you to have to (or even be able to) work around them. It does sound like some of your frustrations are due to not being able to find an (easy) way to get the graph to do what you wanted it to, which is partially a function of wanting to do things with it that we don't intend to be possible. That doesn't mean they aren't valid suggestions of features to add, but I don't necessarily see it as a failing of the control itself (of course I expect you to disagree with this

QUOTE(Omar Mussa @ Mar 12 2007, 11:25 AM)

Developers who are building custom applications need access to properties/methods to make the controls integrate with their applications. While its great for demo purposes to be able to whip out a graph that shows mixed signal DAQ data in a few minutes without getting too customized, the best professional apps tend to do a LOT of UI work to make the application meet or EXCEED the user expectations - this translates into developers wanting properties/methods to enable us to do that.

I think you make a valid point. I am certainly familiar with the need to customize the look and layout of controls in LV front panels. However, I do think it's unrealistic to expect us at NI to forsee all the customization options that you feel are necessary. Remember that our requirements and intended use cases may not include what you would like to use it for. That may be partially due to an oversight on our part, but it might also be by design due to a compromise of function over ease of use or even implementation. Regardless, this gap between the product we deliver and the product you would like can be closed with some simple feedback. We obviously have some feedback now (though not a list of specific properties and methods you'd like to allow the customization you would like - can you provide one?), and can try to incorporate that into the feature in future releases of LabVIEW. An alternative is to get involved in the beta process and have a chance to get the feedback to us sooner (in this case we could have gotten the feedback during the 8.0 beta and hopefully added the properties and methods for that release).

QUOTE(Omar Mussa @ Mar 12 2007, 11:25 AM)

The MSG is an example of a graph whose best features have no API or at best an obscure one that is not well conveyed - so most users will go to great lengths to integrate a different graph (like the XY graph) with a richer API so that they can get the desired user experience.

Again, any specifics you can provide will be greatly appreciated. I assure you we do what we can to take all of our users into consideration when designing new features and choosing what properties and methods to expose to allow users to get the most possible out of their use. As one who "owned" the code behind the graphs for many years, I'm very aware that we have users that rely on the ability to customize the look and layout programmatically, as well as demand high performance at the same time. It is frustrating to hear feedback that the "1.0" version of this control was not sufficient to meet your needs, but I do hope that some users are able to get some benefit out of it, and hope that we can address your needs in the future.

J

EDIT: Omar, I re-read your initial post and see that you filed a few CARs and some product suggestions as well. Thank you for doing that. If you don't mind duplicating your time, listing the desired features (props & methods, primarily) plus use cases, that'd be helpful. Thanks.

[GregSands]

I found a couple more shortcomings of the MSG back when I looked at it in 8.0.1 - I submitted them at the time, but it might help to add them to this thread (still in 8.2):

1) A multi-plot cursor does not snap correctly if XScale.Multiplier is not set to 1 - it seems to ignore it altogether. A single-plot cursor on the same graph does not have this problem. The XScale.Offset as similar problems - see attached VI.

2) I would have hoped to have the same functionality available as a standard Waveform graph, but some are missing: e.g. Cursor Events

I was hoping to use the MSG to display easily align and interact with multiple signals, but the functionality was not quite there to allow me to do it - I ended up staying with several Waveform graphs and manually keeping them in sync - more work, but I could do exactly what I needed.

Cheers ~ Greg