jgcode

QUOTE (jlokanis @ Sep 21 2007, 05:37 AM) John, keep rolling out the magic :thumbup: Beautiful!

QUOTE (crelf @ Oct 28 2008, 07:36 PM) They're giving it away!!

QUOTE (Thang Nguyen @ Oct 28 2008, 11:11 PM) Hi Thang If you are just going VI to VI all you need is for vi B to run a FGV that accesses the queue for vi A and queues method(s) into it (Queue Manager). Therefore this approach may be the easiest also if you require high speed updates. In fact if vi A did all the processing and vi B was just displaying a point(s) on the map you could queue directly into a display loop (if you have one). I use the above when I know exactly: 1. Who/where I want to send the data to and 2. I know 100% that this vi is in memory. 3. For within VI loop-to-loop messaging. But when I don't know, I use use events. IMHO events are the king at doing this, so what you are doing is great however, an event manager might help with flexibility and scalability in the future: I do the above in most medium size apps that have a GUI. I have a main template that stays in memory all the time. It hosts the RTM, toolbar, status bar and a subpanel. Dynamic VIs are loaded into a subpanel (serially loaded) that go in and out of memory. I also have other screens that can be loaded at any time (e.g. setup screens, data screens) that are generic where any Dynamic VI may want to call them in parallel. I prefer to have these other screens not to be dynamic and are in memory with the template at all times (I just show/hide FP). But the below will work the same. About me: I prefer events to polling. I like to think of a screen as an object. I use type-def enums a lot. I like polymorphic VIs This is how I have implemented communication. I call it publisher/subscriber cause that is the easiest way to describe it - but you can call it want you want When the user changes data on a screen (e.g. selects a plot color in settings-type screen) I need to notify every other VI that is using that object data that it needs to update. To not do this via events and use polling is inefficient IMO Also as in this example a plot color change would cause a graph to have to update (which is expensive) I want to know exactly when this happens. In order to pass data to and from VIs I create a MFVI\Module that handles all events registering. The event is dynamically registered to all VI's GUI loop. So all VIs can potentially receive each notification however, you have to statically set which ones it is allowed in the event structure. This method is easy, flexible and scalable. I do not have to know what is in memory (e.g. by loading to a specific queue(s) manager etc.. - is the queue is memory is it not?). So when you have 10-20+ VI's with screens this is great. In the figure above - vi B is subscribed to an event from vi A The data passed is an enum. Which means the setup can publish an infinite number of messages. In this case there is only one message in the enum, but use the NewVal input wired to a case structure so you can choose which published messages to listen to and then load different local methods. Once vi B receives the message in it's GUI loop it loads its own state in a parallel main (working) loop (by using a Queue Manager via a FGV approach for loop-to-loop messaging) This state accesses vi A's object data, & vi B then updates its local temp data and runs any local methods it needs (e.g. update plot colors) [not shown] The biggest reason for me going this way was: 1. To share the RTM, button toolbar with all VIs from the template VI. 2. Communicating with screens in parallel - the user can potentially have open the main app, setup screen, admin setup screen, calibration screen, plot-manager-for-graph screen etc.. at the same time. So as soon as one screen is changed that another screen is dependent on and its in open (but you con't need to care either way), the dependent one updates immediately. A more efficient way for the above method that I have taken from the release of the JKI state machine (thank you) is to include the UI Structure in EVERY main loop. As having the GUI receive a message then load a state in parallel to a main loop I have recently come to see as it a bit of a wasted two-step process. Also any QSM's running in the background headless can receive notifications without needing to have a GUI loop in parallel. But i have not implemented this yet into my template. Check out the JKI SM which uses strings and and an event structure here

Breaking news out of Australia... Ok then.

QUOTE (normandinf @ Oct 26 2008, 02:57 AM) Classic :thumbup:

QUOTE (normandinf @ Oct 23 2008, 04:37 AM) http://lavag.org/old_files/monthly_10_2008/post-10325-1224952318.png' target="_blank">

QUOTE (labviewRTS @ Oct 19 2008, 11:52 PM) Yes VISA works for RS232. To design a strict type def right click on a control and select customise. This will open up the edit screen. Toggle the drop box under the run-time-menu from control to type def OR strict type def. Exit and save the .ctl file. Now you have a type def. If I was going to develop this project, and this is quickly and off the top of my head. I would design it to run locally first for debugging (keeping in mind parts which will have to be come distributed). Once I knew all my logic was good and it work. I would create proxy's for the modules that need to communicate over serial - so serial comms is transparent to the modules that don't need to know about it. You may want to look at using templates (.vit) so you can have 4 (or whatever) ATM's running from the same piece of code that can be spawned at run-time.

QUOTE (Val Brown @ Oct 19 2008, 07:37 PM) Cheers guys :beer: just ran some more tests and found the problem in app due to bug - not the above mentioned

QUOTE (Michael_Aivaliotis @ Oct 19 2008, 03:34 PM) Sorry guys Thanks for replying, my question was incomplete - it has been edited for correct grammer. I turn Defer Panel Updates to False but I didn't get an auto scale.

Hi I could not find anything on search: If I update a Graph whilst Panel Updates are Deferred and I have Auto Scaling enabled then the graph does not auto scale. If I do not defer panel updates then the graph auto scales. I am using LV8.6 and waveform graphs. Is this a bug or desired behavior? Cheers JG

QUOTE (labviewRTS @ Oct 19 2008, 10:54 AM) HH but nonetheless: Hi labviewRTS if serial comms is your issue ?? I recommend investigating NI VISA found on the Instrument IO>>VISA palette. It is really easy to use - like other OOPy modules (e.g. File IO) create a VISA reference (set port config here), do methods: VISA read/write/other, close VISA reference. You can also access properties-such as read bytes at port through nodes too. I recommend searching the Example Finder as there is a basic read/write there that is handy to get started. Instead of accessing a local file to verify transactions and get data, you just need a proxy to the Bank. Sounds like a cool project. Reminds me of an exam I once took.... Goodluck JG

QUOTE (Thang Nguyen @ Oct 18 2008, 04:43 AM) If you go http://joule.ni.com/nidu/cds/fn/p/sb/navsRel/lang/en?q=DSC&x=20&y=17' target="_blank">here on ni.com you can download the latest DSC module in 8.6. So you should be able to trial it.

QUOTE (Aaron L @ Oct 18 2008, 05:21 AM) Hi Aaron I had the same problem when I started coding and made my first exe. In code, I would type in all my values then press the LabVIEW run button, run the code and get my answer. As a compiled exe, it would start straight away and would ruin everything. So I am guessing the following may help (as it helped me) This was until I learned about the Event Structure (and design patterns). Building a UI into an application as FPGA suggested is far more productive then stopping the VI from running at startup. Do a little search on Producer Consumer (Events) to see how a UI event will trigger state(s) to run in a working (main) loop. Now the application will be running - but you (or the user) controls the execution of events, and does so expending minimal CPU resources. Once you get this powerful design pattern, it will really accelerate your development.

QUOTE (PaulG. @ Oct 17 2008, 10:23 AM) Now that's one way to stop the growth and decrease the reputation of an open forum such as LAVA: Telling people they aren't good enough to be given a correct answer to a legitimate question, even after that person explicitly said they are a newbie and have thanked previous posters for their constructive comments. Way to go! <edit> I actually do not have a problem with people having an opinion like the above - as everyone is entitled to one. I just see how it was helpful to the issue at hand (or the community as a whole) in any way, shape or form, to actually go ahead and post it. </edit>

QUOTE (jdunham @ Oct 17 2008, 11:08 AM) Thanks jdunham With passing an array into and out of the subvi: you could still edit the array in the subVI and pass out the same data type but with a different allocation (e.g. perform a build array). So I am wondering how smart the compiler is? Isn't the point of inplaceness to guarentee buffer reuse. I can see the problem if another operation was made in parallel in the inplaceness structure... But I would love to know if the subvi was in an inplaceness structure and no other functions were run on the data in the structure - would buffer reuse be guaranteed :question:

QUOTE (jdunham @ Oct 17 2008, 02:30 AM) Would running the above VI and forking data to the subvi in an inplaceness structure guarantee that a copy will not be made?

QUOTE (km4hr @ Oct 16 2008, 09:26 PM) The application builder is included in the professional version and dev suite otherwise it is an add-on. Log onto ni.com for prices in your area.

QUOTE (km4hr @ Oct 16 2008, 11:44 AM) If you turn the VI's into an application (e.g. build an executable) they :ninja: won't be able to get at the code.

QUOTE (marp84 @ Oct 16 2008, 08:45 AM) There are filter VI's located in the Signal Processing>>Filters sub-palate that may help you. I have also written custom ones easily enough before as well (e.g. 4th Order Dual Pass Butterworth etc..) Your ECG question is one for a domain expert not a programmer But you may be able to do some regression testing to see what filter cutoff(s) give you the closest signal representation with adequate noise removal.

QUOTE (Peter Laskey @ Oct 16 2008, 06:59 AM) Taking an array subset does not necessarily cause an allocation of memory for a new array - it depends on what you do with the subset. If you found the indexes of the new, zoomed-to window, indexed your data array with array subset and then ran the min/max function, it should not be memory expensive. This is provided you can inexpensively access your graph data from a buffer. Your VI did not seem to return the correct minimum value? This VI may help: Download File:post-10325-1224113464.vi Coded In LabVIEW 8.6

QUOTE (LV_FPGA_SE @ Oct 10 2008, 12:08 PM) A simulated lighting system would be cool? No need for hardware - just use multiple PC's to simulate hardware.

QUOTE (MJE @ Oct 8 2008, 09:38 PM) Seems like there is a bit to find out here... Just did an uninstall of a LV product. It did not remove a file installed to the desktop but when I click on it I get this: http://lavag.org/old_files/monthly_10_2008/post-10325-1223470454.png' target="_blank"> Weird!

QUOTE (MJE @ Oct 7 2008, 11:28 PM) Hi MJE, Cheers, I did read about the file location transparency. However, in Vista - Read/Write File Functions return an error in LV if you try to read/write a file you do not have admin access to. So the transparency only comes into play after you enable admin access. Other programs don't seem to have this problem - i.e. admin rights is not selected - so there must be a way around this?

QUOTE (jdunham @ Oct 7 2008, 02:22 AM) So your LabVIEW.exe can still access the config ini file in the program folders or is this only for XP? If so what are your plans for vista - everything to the Users folder?

QUOTE (jdunham @ Oct 6 2008, 01:47 PM) Great! Thanks for the tip jdunham :worship: - so I guess I should start doing that for XP too. Thinking out aloud however, if the installer installs the data files (whether in Program Files or elsewhere) wouldn't the installer know to remove them aswell on an uninstall? Or is there a built-in proxy in the installer that does not allow such behaviour? Does anyone know? If not....time for some testing methinks....