Norm Kirchner

You might want to investigate REx - Remote Export Framework for LV built EXE https://lavag.org/topic/17024-rex-remote-export-framework-and-remote-events/ Although it can't give you a direct button click, it does the next best (possibly better) thing, giving you the ability to call a method externally that fires a LV event internal to the EXE. Good luck, ~,~ The Captain

Did you see the recently posted JSON adapter that was posted in the Code Repository? Looks very interesting for sure.

<for future reference> You might be speaking of RFmx for doing RF measurements on our VSA products. This 'Measurement Driver' makes short order out of taking common RF measurements, generic and standards based alike. It does not have a personality specific to doing EMC testing or EMC specific measurements. There is likely a good deal of overlap between the ESU40 measurements and what we can accomplish with RFmx, however I can imagine that the ESU40 has a lot of EMC usability features that you won't find in RFmx. Another item that might be of interest is investigating RealTime Spectrum Analyzer functionality, in the future should you need something more flexible than the ESU http://www.ni.com/webcast/3693/en/ What ends up happening with the above is that you gain some serious power to do things like frequency mask triggering as well as custom pre-processing data reduction; but it comes at the cost of not having as complete a solution out of the box. Hope that all helps ~Norm

Can you please back port to 2014?

In order to better answer the question, having some knowledge of exactly which VI (blocks) you wish to put your data into would be helpful. However to emulate what I believe you're trying to accomplish see below.think you're looking for Now as far as measurements that you specifically need, you should start to explore the measurements built into LabVIEW. This image is just the top of the iceberg. Good luck and welcome back to the LabVIEW world. Thanks for coming to the community to find your way Best, Norm Kirchner ~,~ The Captain was here

Would you mind back porting to 2015? Thanks, ~,~

I'll be there doing the photography again! Hopefully Martha can make it this year too. I'll try to post a link to last years photos here too.

By the by, some of my findings on the worst posts on LAVA are as follows for your comedic enjoyment

To keep things complete, I've attached the actual presentation that resulted. Thank you all for your feedback, and I encourage anyone to take this and use at their local user group meeting. Believe it or not, I was able to pile-drive through these in 7 minutes 30 sec/slide on average. However it could have gone for 30 min or more. The audience gave positive feedback on the material Make Friends, Not Flames.pptx

@pato7 What was the end solution you went with that worked for you?

Is that snippit working for anyone else? I'm not having any luck w/ it

My mistake, I left out that this is for the Indian CLA summit going on this week.

@pato7 So that I don't feel like I walked you into a trap, how sure of the frequency are you ahead of time? Also, how accurate do you need to be within? Frequency accuracy will directly play into phase accuracy.

I'll be giving a presentation this week called "Make Friends not Flames :: Online Forum Etiquette" I thought I would pass this across the community to get a pulse on if y'all think this is a well balanced list and no massive misses on my part. I know that we have a great document at LAVA Forum Guidelines https://docs.google.com/document/d/1Ce1aE4Kz6h1W5vdQER8LIc_9ZvW8QhHLQoqoVjcWw10/edit But we all have our little peeves, and this might be a fun airing of the grievances. It's for a 7 minute presentation, so the idea is 30 seconds each on average. The idea is to hit things for people who are newbs and veterans. DON"T Abuse the Private Message (PM) Feature Admonish a newb publicly Turn a commuinty forum post into a 2 person flame war Presume that people have knowledge of what hardware your using and how it's API / Interface works Be a 1 hit wonder Post Across multiple forum sub-forums Be a clueless homework hustler; we know what you're doing, do it the right way DO Search the best you can with site:lavag.org {your search} Remember what it was like when you were young and clueless Be apprecaitive Give ample detail in the form of: high level diagrams, videos, pictures, code and big picture purpose Share novel things that you figure out Start out saving for previous and make everyone's lives easier Be an active participant and share the love! In the end it might be a flop, but I hope it encourages those CLA in India to kick things up a notch. Your short term feedback will be appreciated and rolled right in. ~,~ The Captain Was Here /EDIT :: Presentation Added Make Friends, Not Flames.pptx

See image and attached code. This works great for simple signals and when you know the frequency of the signals coming in. If you don't know this or the signals coming in aren't simple sinusoids, then the game changes a bit. I thought I would start with this though. Good luck, Norm Code to post.vi

Leave it to the RF guy to whip out the DSP. The easy way to compare the phase of two sinusoid of the same frequency. Multiply the signal by another sine of the same frequency at 0deg phase and in parallel multiply it by another sine of same frequency at 90deg phase. Take the average of both of those signal into a re/im to polar, snag out the phase value and convert to degrees. Do that to the other signal as well and find the difference between the signals That is the easiest way to get what you want and is very immune to noise. I'm about to board a plane otherwise I'd attach the example.

Dave, I've got a version of ESF that will keep references live beyond the boundary of the creating hierarchy. Willing to dive back into that pond?

Ok... guess I'll just have to go check out all the marketing presentations {gak}

I heard a wise man say once, regarding your exact question. In short, we as G developers can not make our own functions that act excatly like the array primitives in LabVIEW. This techniques listed above by Hoova are the ones to focus on if you want that same kind of behavior. I vaguely recall that someone once made a tool which would make the poly VI stack for you, for all available data types; this way you don't have to replicate your VI over and over and make the poly. But I can not recall where that would be. Maybe someone else could chime in

Let's get a list of who's presenting what at NIWeek so that we don't have to rifle through the agenda to figure out whats actually worth going to!!! I've got 2 on alliance day (Monday) He Chose.....Wisely; Picking the right RF Software for your next RF Opportunity (2:30PM room 15) You can pick your customers, You can pick your SpecAn, but you can't pick your customers SpecAn (3:30 room 15) [specAn is a spectrum analyzer fwiw] For those of you a bit leery of an RF-centric presentation, consider that I usually hear this at least once after presenting; "that was very entertaining...I'm not sure if I understood it all...but it was entertaining" Looking forward to entertaining you all ~,~ The Captain Was Here....and will be there too. aka Norm Kirchner

Alex and Ryan et al. There is a basic coding principle that should apply to the 'car wash example' and other ones as well. "No one action should take longer than is acceptable for the program to react to a new request/trigger" So in short if you need to dwell at a point, as with the car wash example, you should have an idle, <no trigger> transition behavior that goes out, checks the timer and then comes back to the state. For the case where you're not just dwelling on an action and you need to perform a series of actions along a transition that will inherently take longer than what you need to have the program respond to, then there are a few other options. Make intermediate states that exist along the transition, thus enabling checking new triggers while moving through a transition. if no trigger happened that should get in the way of the transition, push the trigger back into the trigger Q and continue on with the next part of the trasition Break your one transition into multiple transitions which go into and out of the same state, and have some system variable which can help the state logic know which transition to move to next You could put some logic inside of the "False" case of the "transition complete" structure of the state machine portion of the code. from there it's up to you how to best complete the rest of the transition you're on given what you're trying to accomplish As ONLY a last ditch effort, you could actually access the action queue, and jettison your current action. BEWARE however, it is now upon you to be very explicit in ensuring that you end up back at a safe state from wherever you were along the transition. The most important perspective and question to ponder, MUST I handle this trigger immediately, if so, WHAT must happen to handle the trigger, CAN I break the handling of that trigger up into two sections which would leave the system safe (one that catches and informs the user it will be handled shortly, and then the rest that can be handled down the line in the normal state machine flow. Keep in mind, that most programs that you interact with have some kind of delay for a lot of actions (fractions of seconds to seconds) and they are often glanced over. Must your program respond faster than what most people are used to having programs respond to. Can it just wait to the end of the current transition And if your transitions are taking a long time, then that's an indicator to me that you might have too much going on in a single transition. I ran across this last point very recently, where a colleague was prompting the user along a transition in which measurements would be made as well. For a variety of reasons, (including choosing 'Cancel' in the dialog) it made sense to have a separate state in which the prompt would be given on the way to the new state (thus preparing the system to be in that new state) and then the idle transition in that new state, which finished up the remaining measurement actions and then at the end of that transitioning back to where he was. See some of the diagrams below for some color