Leaderboard

Did you setup your SV event to ignore timestamp changes?

I think the stuff you've put together looks pretty slick. Since I'm (nominally) on the Web UI Builder team, I'd like to get an idea of what else you don't like about Web UI Builder. So far, I've got this: It's only on Windows and Mac. It requires a plugin. Price (note: the price is for building apps for deploying; it's free for developing). Do you think that you should get free / discounted access to build/deploy apps after buying some other product / combination of products? (Note: I have absolutely nothing to do with the business side of things, so I don't have any input on pricing, bundles, etc. I can represent your feelings if I'm around when the discussion comes up) What else?

It's an optional parameter on NI_DSC.lvlib:Request Value Change Notifications.

Well, there are times when we want to see an event when the variable has a new instance of the same value. A simple example immediately comes to mind: Latched Boolean on View: The View sends a true value for this button each time the user clicks it. So, the user might click Start, do stuff, stop, and then click Start again. The Start shared variable has a value of True in both cases, but the controller needs to know the user clicked the button again. (There are other ways to do this but this is about the simplest we have found.) Similarly, we might have the same situation when we send a setpoint. The controller may use an old or default setpoint until it receives a new value, which perhaps only occurs upon user demand. It is entirely plausible that the user could send the same setpoint after starting the controller on two successive runs. We sometimes program publishers only to write certain data on first call or if the values have changed (it sounds like you did something similar). If you can only edit the subscribers, that won't help, of course, and you will have to do the filtering on the subscriber side, but currently that means after the event triggers. I think generally the given behavior of getting an event is correct, however. EDIT: OK, I just looked at what sachsm suggested. That could be what you are seeking. I admit I've never paid any attention to that option. I definitely learned another new thing today! Thanks!

It is a question whether is it native or not, but similar issue was discussed here:

Yep, that's where I'm falling on this, too, especially after AQ explained some of the technical underpinnings to me. I guess my main frustration with this is that I met at least 4 or 5 CLAs just at the Summit (and that doesn't include everyone else at JKI) who have hit this issue at some point during development, gone half-crazy trying to even understand it, and eventually refactored their code around something they've given up trying to figure out. Why does this happen? Because of the lack of tools at our disposal for monitoring or influencing the Event Structure at runtime. I honestly don't have a strong opinion on whether this is a bug or not (nor have I; mostly I've been bemused by the whole thing ). But what I do have a strong position on is that if I could inspect/flush/otherwise manipulate the queue for an Event Structure I and others would've been able to understand, work around, and even exploit this behavior for better software years ago rather than wasting time cursing at LabVIEW.